Code runs slower in Release mode than in Debug mode

MuldeR

Well, if it turns out it's not actually the GUI-related stuff, but the encoder DLL, that is slow, your problem isn't Qt related. You then should try to track down the problem with your "libx264.dll" file then.

x264 will be really slow, if you build it without Assembly enabled. To build with Assembly, YASM is require. But the configure script of x264 won't let you build without Assembly anyway - unless you add "--disable-asm".

If you can live with an x264 that is outdated by a few months, you could compare to the last DLL's I compiled:
"libx264-125-r2200M-win32.7z":http://code.google.com/p/mulder/downloads/detail?name=libx264-125-r2200M-win32.7z&can=2&q=&sort=filename+-uploaded

(Will have to make some "fresh" builds soon ^^)

koliva

[quote author="MuldeR" date="1357826995"]Well, if it turns out it's not actually the GUI-related stuff, but the encoder DLL, that is slow, your problem isn't Qt related. You then should try to track down the problem with your "libx264.dll" file then.

x264 will be really slow, if you build it without Assembly enabled, which requires YASM. But the configure script of x264 won't let you build without Assembly - unless you add "--disable-asm".[/quote]

I will try to compile the dll based on the instructions given in http://doom10.org/index.php?topic=26.0. I will report back the results.

koliva

[quote author="MuldeR" date="1357826995"]Well, if it turns out it's not actually the GUI-related stuff, but the encoder DLL, that is slow, your problem isn't Qt related. You then should try to track down the problem with your "libx264.dll" file then.

x264 will be really slow, if you build it without Assembly enabled. To build with Assembly, YASM is require. But the configure script of x264 won't let you build without Assembly anyway - unless you add "--disable-asm".

If you can live with an x264 that is outdated by a few months, you could compare to the last DLL's I compiled:
"libx264-125-r2200M-win32.7z":http://code.google.com/p/mulder/downloads/detail?name=libx264-125-r2200M-win32.7z&can=2&q=&sort=filename+-uploaded

(Will have to make some "fresh" builds soon ^^)[/quote]

Hi Mulder,

I have been trying to compile the dll with MinGW based on the instructions in http://www.ayobamiadewole.com/Blog/Others/x264compilation.aspx. For some reason, I couldn't compile it. The MinGW gives error like "No working C compiler found.". Although I did a search on it, I couldn't resolve it. Then I tried to use your builds. However, I statically link the dll and for this, I use libx264.lib as well. I don't see this lib in your builds. Could you please guide me where to find the libx264.lib or why I am getting the error that I wrote above in MinGW?
Thanks.

MuldeR

About your error: Well, it didn't find a C compiler ;-)

If you type "gcc -v" in the same console (MSYS) where you are going to run "./configure", what happens?

For details, see the "config.log" file that was created...

--

About the .lib file: What you are used to from MSVC as a .lib file will be an .a file with GCC/MinGW.

Indeed, I did not package the .a file (import library) along with the DLL's, because those were intended as a drop-in replacement for Avidemux (or similar tools that already use an existing libx264.dll).

But: It seems you already compiled x264 yourself, only your builds were "too slow". So if you build x264 again the way you did before, you should get the .a file plus a DLL. You can then simply replace that DLL with my DLL for comparison. Note, however, you will have to compile the .a file that matches my DLL's, so will have to compile x264 r2200 (core-125), aka GIT commit "999b753ff0f4dc872077f4fa90d465e948cbe656":http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=999b753ff0f4dc872077f4fa90d465e948cbe656.

Also, when you compile the application that uses the x264 DLL, you have to use the .h file from r2200 then!

koliva

[quote author="MuldeR" date="1357913737"]About your error: Well, it didn't find a C compiler ;-)

If you type "gcc -v" in the same console (MSYS) where you are going to run "./configure", what happens?

For details, see the "config.log" file that was created...

--

About the .lib file: What you are used to from MSVC as a .lib file will be an .a file with GCC/MinGW.

Indeed, I did not package the .a file (import library) along with the DLL's, because those were intended as a drop-in replacement for Avidemux (or similar tools that already use an existing libx264.dll).

But: It seems you already compiled x264 yourself, only your builds were "too slow". So if you build x264 again the way you did before, you should get the .a file plus a DLL. You can then simply replace that DLL with my DLL for comparison. Note, however, you will need to compile .a file that matches my DLL's, so will have to compile x264 r2200 (core-125), aka GIT commit "999b753ff0f4dc872077f4fa90d465e948cbe656":http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=999b753ff0f4dc872077f4fa90d465e948cbe656.

Also, when you compile the application that uses the x264 DLL, you have to use the .h file from r2200 then![/quote]

Hi Mulder,

I have just found the problem about compilation error. This is how I made the dll and lib:

I typed in MinGW,

./configure
make (exe is created.)
./configure --disable-cli --enable-shared --extra-ldflags=-Wl,--output-def=libx264.def
make (dll is created)
In MSVC command prompt I typed,
LIB /DEF:libx264.def (lkib is created)

The error that I got was just because I was mistyping --extra-ldflags. I mean instead of Wl I was typing wl :)

With the new dll and lib, I still have the same problem. In release mode it runs slower. Actually "slower" word may not be correct. I am having 500 ms latency in Release mode and about 90 ms in Debug mode.

My question now is that, what happens if I run the 5. step above for your dll? Won't it create lib file for your dll?

MuldeR

Yes, but you would need the correct "libx264.def" for x264 r2200 (core-125)!

--

Also: What do you mean with "delay"? It's normal that the call to x264_encoder_encode() will block some time.

The first few calls will return right away, returning nothing. That's because x264 internally buffers frames.

But once the buffer has been filled, each call will return an encoded frame and thus not return until the next frame has been encoded. You rally have to think of "speed" as the frames per second averaged for the whole clip.

koliva

[quote author="MuldeR" date="1357915574"]Yes, but you would need the correct "libx264.def" for x264 r2200 (core-125)!

Also: What do you mean with "delay"? It's normal that the call to x264_encoder_encode() will block.

The first few calls will return right away, returning nothing. That's because x264 internally buffers frames.

But once the buffer has been filled, each call will return an encoded frame and thus not return until the next frame has been encoded. You rally have to think of "speed" as the frames per second averaged for the whole clip.[/quote]

I meant latency by delay. Let me explain my application to you.
I am capturing the screen and encoding it with x264 and sending it to another computer over network and there it is decoded and visualized. So I have basically two laptops and I open a timer with millisecond accuracy. then I put the two screens next to each other and take a picture. I calculate the latency by subtracting the two values.
The problem is, when I run my code in Release mode, I see about 500 ms latency while if I run exactly the same code in Debug mode, I got 90 ms latency. I am breaking my calls to find what causing this.

MuldeR

Are you even using the same x264 settings ?????

x264 does have some delay, because of lookahead and stuff. Good for "offline" encoding, but can be a problem for "real time" streaming. Latency can be much reduced by tweaking encoder settings! The CLI encoder has a special option "--tune zerolatency" for this purpose. Also "--preset" controls overall encoder speed.

(Maybe the "Debug" build just happens to use other settings that happen to reduce latency)

koliva

[quote author="MuldeR" date="1357916334"]Are you even using the same x264 settings ?????

x264 does have some delay, because of lookahead and stuff. Good for "offline" encoding, but can be a problem for "real time" streaming. Latency can be much reduced by tweaking encoder settings! The CLI encoder has a special option "--tune zerolatency" for this purpose. Also "--preset" controls overall encoder speed.

(Maybe the "Debug" build just happens to use other settings that happen to reduce latency)[/quote]

The code is exactly the same. Actually it's a quite a short code since I use the default presets with VBV encoding.

For the encoder settings I use:

x264_param_default( &param );
x264_param_default_preset(&param, "ultrafast", "zerolatency");    
param.i_width = aWidth;
param.i_height = aHeight;

param.i_keyint_max = X264_KEYINT_MAX_INFINITE;
param.i_keyint_min = X264_KEYINT_MAX_INFINITE;
param.rc.i_vbv_max_bitrate = 5600;     //Bitrate in kbps
param.rc.i_vbv_buffer_size = param.rc.i_vbv_max_bitrate/40;

I really want to try your dll in my system. I have checked my dll build and its version is
#define X264_BUILD 129
in x264.h. Could you please tell me step by step how to compile yours? Is it just replacing the libx264.dll.a with your dll and changing the extension again to .dll.a ?

MuldeR

Nope.

Check out x264 r2200 (core-125).

As said before, that's GIT commit "999b753ff0f4dc872077f4fa90d465e948cbe656":http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=999b753ff0f4dc872077f4fa90d465e948cbe656.

That revision has the suitable .h file. Also, if you compile that, as usual, it will give you the needed .a file.

BTW: The .dll.a file is the equivalent to the .lib file from MSVC's LIB tool. It's not the DLL!

--

Did you verify x264_param_default() and x264_param_default_preset() do the same in Debug/Release ???

koliva

[quote author="MuldeR" date="1357917061"]Nope.
As said before, that's GIT commit "999b753ff0f4dc872077f4fa90d465e948cbe656":http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=999b753ff0f4dc872077f4fa90d465e948cbe656.

That revision has the suitable .h file. Also, if you compile that, as usual, it will give you the needed .a file.

BTW: The .dll.a file is the equivalent to the .lib file from MSVC's LIB tool. It's not the DLL!

--

Did you verify x264_param_default() and x264_param_default_preset() do the same in Debug/Release ???[/quote]

In Git GUI I connected to the server which is git://git.videolan.org/ and I can clone the last version. But I don't know how I can check out x264 rr2200. Could you please help me?

How can I verify what they are doing in Debug and Release mode?

MuldeR

[quote]In Git GUI I connected to the server which is git://git.videolan.org/ and I can clone the last version. But I don't know how I can check out x264 rr2200. Could you please help me?[/quote]

If on Windows, do yourself a favor and use TortoiseGIT! Or just use the GIT console:
http://www.kernel.org/pub/software/scm/git/docs/git-checkout.html

[quote]How can I verify what they are doing in Debug and Release mode?[/quote]

Check the content of your x264_param_t after the call and compare...

MuldeR

Just checked my HDD at home and found the old x264 build files :-)

So here is libx264.DLL r2200 (core-125) including the correct header files and import library:
http://www.mediafire.com/file/637yqnuiqu3nuua/libx264_r2200_gcc471_x86.zip

Note: libx264.dll.a is the import library (to link against the DLL) while libx264.a is the static library.

koliva

[quote author="MuldeR" date="1357937312"]Just checked my HDD at home and found the old x264 build files :-)

So here is libx264.DLL r2200 (core-125) including the correct header files and import library:
http://www.mediafire.com/file/637yqnuiqu3nuua/libx264_r2200_gcc471_x86.zip

Note: libx264.dll.a is the import library (to link against the DLL) while libx264.a is the static library.[/quote]

Hi Mulder,

Thanks a lot for your help. I am currently not available to try it out but Monday I will certainly give it a try. Thanks a billion.