Incorrect operation of the Mpeg4 AVC (x264) codec in two pass options

[zbkor]

Good Morning. Avidemuv is a great program, but it is quite a mistake in my opinion. In the "Mpeg4 AVC (x264)" codec in the "Video Size (Two Pass)" and "Average Bitrate (Two Pass)" options, no matter what Size or Bitrate value I use, I will always get the same size. In other codecs these options work. I am using the latest version of avidemux portable (r200101_win64Qt5_78).
Regards

[eumagga0x2a]

Just tried the video size 2pass mode of the x264 encoder plugin, which is ultimately the same average bitrate 2pass mode with bitrate value computed automatically based on the specified size of the video stream, both with the latest official mingw build as you did* as well as with my private build off the git master packaged as zip: WFM (works for me). The output size (the size of the raw video stream) matched the specified value pretty well.

Please provide more information.

*) ...albeit ackaged as .exe which should not matter as all Avidemux builds are portable when launched with the command line option

--portable

or with avidemux.exe renamed to avidemux_portable.exe, no matter how packaged.

[zbkor]

eumagga0x2a indeed other mp4 files work as you type. I have a file from the camera that Mpeg4 AVC (x264) can not reduce two pass. Interestingly (xvid4) and (x265) cope with it, i.e. reduce it in two passages. This file loaded into avidemux shows such data - H264, 1920x1080, 1: 1, 30,027 fps, time 20s, audio skip. Its size is almost 40MB. I wanted to reduce it in two pass to 10MB and he made the resulting file by 212MB. With other settings it also makes a 212MB file. The xvid and x265 codecs reduce it in two passages to the value I set, i.e. they are more intelligent. Sorry to bother you, but I was already afraid that this codec (x264) does so with every mp4 file, but fortunately it is not. Probably if you wanted to solve this problem somehow I would have to send you this file.

[eumagga0x2a]

If the content is innocuous enough, you could provide it as a sample via WeTransfer, Mega, Dropbox or Google Drive. Short duration may be a factor.

[zbkor]

https://we.tl/t-pcVdIEd0gk  I am sorry I am doing this for the first time

[eumagga0x2a]

Thank you for the sample, I could reproduce the issue (quantizer staying all the time at 11). However, it doesn't seem to be related to the duration as in other cases of short videos the specified average bitrate in 2pass mode is respected. At the first glance, it looks like an issue of the libx264 library, out of our control.

By the way, in the constant quality mode, I have to go down to ~29 to approx. match the bitrate of the source. No wonder that at 11, the output is huge.

[zbkor]

It turns out that x264 doesn't like custom FPS. As you probably noticed, this file has a custom FPS 30.027 and when I added the FPS change from 30.027 to 30.00 everything started to play (the quantizer returned to normal). It is a pity that this codec has such a disadvantage. As you can see, archaic xvid and x265 are not afraid of custom FPS. I work on x264 because almost all devices support it. There is still a lot of x265 non-cutting equipment in use. Thanks for the explanation.

[eumagga0x2a]

The video has variable fps at 1/1000 time base, changing that should never be necessary. The issue might have been a regression from [videoEncoder/x264] Set timebase from the filter info, guess variable frame rate input from frame increment and timebase and configure encoder accordingly. So propably we still have to lie to the encoder library, will investigate later.

Thank you very much for your input.

[eumagga0x2a]

Should be fixed now, thank you very much for your report.

[zbkor]

eumagga0x2a this error crept in to the previous build (r200101_win64Qt5_77). Earlier versions work correctly with the x264 codec.

[eumagga0x2a]

The regression was introduced on 2019-12-16 and fixed on 2020-01-13 in code, the fix will be present in future nightlies.