2.6.4 encoding x264 and priority setting

[AQUAR]

Encoding with x264 is much slower with 2.6.4 than with 2.5.6, same machine same fundamental setting same test video.
With 2.5.6  encoding at about 300 fps priority setting low
With 2.6.4 encoding at about 70 fps priority setting very high.

Setting 2.6.4  priority to normal and encoding drops to under 10 fps.
The encoding dialog window is mostly frozen.

Setting 2.6.4 priority less than normal and the encoding process stops but CPU usage stays at 100%.

Has anyone else noticed these kind of issues?

Might the encoding slow down be due to the different approaches (time base vs frame base)?

[Jan Gruuthuse]

check rate control for 2.5.6 = 26?
check rate control for 2.6.4 = 20?
and in Preferences if threading is set to the same?
The used hw encoding could also play a part.

[AQUAR]

rate control was set the same for both (26)
threading the same although all cores are used regardless of settings in 2.6.4 (not checked if that the case in 2.5.6)

HW for encoding also the same using just the cpu on the same machine/
Libraries for the encoding will of course be different but expected better performance from 2.6.4.

Note: Of course no criticisms meant in stating these observations.

[Jan Gruuthuse]

I don't see these differences on ubuntu 12.04 64-bit. With mpeg-ts re-encoding. I'm using vdpau (nvidia)
If you both tests again: use the same priority setting.
Threading allow only for real cpu cores and not count HT ones: like Intel core I7 has 4 cpu cores and showing including HT, 8 cores, you would set threading to 4.

[AQUAR]

Thanks Jan

2.5.6 rate recoding is fast at over 300 fps regardless of priority setting.
2.6.4 dies at normal or lower priority setting.

I am not using any video decoder options under preferences (don't think they have an impact on encoding speed)

Muxing into any type of container (eg mpeg ts) has no impact.

To be clear though we are just talking about MPEG4 AVC encoding, eg MPEG4 ASP works great under both versions.

Maybe there is a codec library issue for AVC or a beta issue (using rev 8736).   

Regarding CPU multicore threading:
I am trialling this on an 4 core (I7) and all cores are used even if I custom set the threading to 2.
Two being the minimum it will let me set.
Avidemuxe 2.5.6 32bit and 64bit - ditto.   

[AQUAR]

Going back to V2.6.1 there is no problem with AVC, it uses the libx264-129.dll library.
Encoding the same test video here gives over 200 fps at below normal priority.
V2.6.4 uses libx264-106.dll for AVC encoding and presents the issues described.

106.dll older than 129.dll?
Hoping the developers, like mean, will notice or are working on this library.

[mean]

I've updated x264 to -123 on WIN32, not WIN64
Is it better ?

[mean]

Build in progress, should be ready in ~ 30 mn

[AQUAR]

@ mean - Appreciate that.

I DL'd the 32bit and 64bit rev 8806 for testing.
32bit build has no such issues wrt to AVC encoding speed at different avidemux encoding priority settings.
64 bit build remains naughty as before (expected with libx264-106.dll).

Can the 64 bit version be build with a more compatible AVC library as well?

I should have mentioned that the OS is a clean install of win7/x64 SP1.

   

[mean]

If the win32 works ok, i'll update the win64 to the same version.
The win64 is still flawed as far as built system is concerned
Thanks for checking

[AQUAR]

I'll test it when available and report the results (tiny effort in return).

[mean]

should be updated (untested)

[AQUAR]

DL avidemux_r8810_win64.7z for checking the AVC encoding issue.

Avidemux 8810 doesn't link/load the libx264 module (at least I didn't see it in windows 7 resource monitor).
The module is still libx264-106.dll, it has the same hash as before.
I am guessing the updated dll module is being called but missing (noob observation!).

Of course mpeg4-avc is missing from the video output options.

[mean]

And putting that file in avidemux folder helps ?
http://fixounet.free.fr/2.6/libx264-123.dll

[AQUAR]

 
That worked well FPS way up @ encoding priority low.
Encoding "progress window" no longer freezes.