Avidemux 2.6.4 - H.264 encode by video size is massively broken

[AQUAR]

Sample file:
http://www.datafilehost.com/d/0bc8d5ab

Recoded the sample with MPEG4 ASP (xvid4)
Container this time was mkv.

2 pass - video size at 10 MB gives video bit rate of 766 Kbps
2 pass - video size at 30 MB gives video bit rate of 1800 Kbps
2 pass - video size at  50 MB also gives video bit rate of 1800 Kbps

All cases the frame rate changed from constant rate to variable rate.

Maybe minimum possible quantization is somehow being exceeded by the larger sizes?
Using 2.5.6 the video size settings gives results as expected.

[thany]

Strangely, I can no longer reproduce this issue. I did a couple of things:
1) upgrade to build 8874
2) set the H.264 parameters manually
3) save the whole thing as an auto script

One of these things must have worked around the problem for me.

/edit
Scratch that. I triggered the issue again. I honestly don't know what I did to cause this issue once again. I performed an encode like any other that worked normally...

[AQUAR]

Recoded the sample video a few times with 2.6.x and 2.5.6. (MPEG4-ASP xvid)

With a video size set to 50 MB, 2.5.6 provides a near 50 MB result.
With this generous video size the quantiser value sits mostly at 1 (presume this value defines some quantisation scale code?)
The bit rate can be quite high for complex scenes (~8000 Kbs).   

With a video size set to 50 MB, 2.6.4 (32 bit) always greatly under sizes.
Even with this generous video size the quantiser value ranges between 1 and 4.
The bit rate at quantiser 1 also seems much lower than for 2.5.6 (`3000 Kbs).

I guess the encoder parameters for these XVID encoders must be quite different.

Tried with 2.6.4 (64 bit) but it doesn't like this exercise and crashes immediately on pass 1.

Created another sample video with different compression and container.
Results is a similar undersizing with 2.6.4.

Interesting!

[thany]

The undersizing problem *may* be explained by avidemux not incorporating the audio track into the video size. I found that when this undersizing problem occurs, I can subract the size of the audiotrack to the total resulting video size, which is more or less the video size I had set in the encoder options.

For example,
I set a video size of 700MB. But the resulting file becomes 850MB. That means audiotrack is around 150MB (which in my case is about correct when I do the bitrate*time calculation).
So in this scenario I would have to set the video size to 550MB, and because the audio track is still the same, it will result in a total video size of around 700MB.

[AQUAR]

Thanks,

You are right in that the total file size comprises all of the container streams(video plus audio plus subs).
But in this case, I am comparing the size of the video stream (set by user input & is an encoder parameter) and the resulting video stream size.

It undersizes on both MPEG4-ASP (Xvid4) and MPEG4-ASP (ff) so it seems more than just encoder related.

If you try constant bitrate encoding with a 'higher' bitrate than what you get from the video stream size result, you also run into the same  problem.
Now increasing the compression level eventually results in avidemux complying with user input but the compression is too high for my aim.

My target aim is to encode for a specific average bits per pixel metric, and that is not possible at the moment because setting the target video size isn't working (or is being code limited). 

[thany]

Okay, it's happening again. Got a MP4 file about 1,5GB in size, tried to convert it to H264/AAC in MKV, and results in 18GB. Another one became 38GB, would you believe it?! This shouldn't even be possible.

It's definately not an isolated case. But it has thus far only happened on the 32-bits version.
This time I was using r8882 on Windows XP.

[thany]

And another one.

Just a friendly reminder. Would it make sense to install the latest nightly at all?

/edit
And another one. I keep the failed ones in one place, but there's no real pattern to them. It's WMV, AVI and MP4, some of them 720p, some 1080p, some 480p or less. Supplying example files is of no use, it seems to have nothing to do with the files themselves. I suppose the devs should take a good look at why this happens so oftenly on the 32bits version, and never (seems to) on the 64-bits version.

[AQUAR]

Just a thought
Does this happen if you run the programs as portables?
Both 32 bit and 64 bit adress the same data location and maybe there is some cross contamination.

Will try it for the undersizing issue.

[thany]

No, I'm running the two on separate machines. One cannot run 64-bit, and the other can. One is Windows XP, and the other is Windows 7.

[thany]

Said to say... This morning I had to find out the exact same thing happens on linux (Ubuntu 13.04, Avidemux 2.6.5 final, built from sources).
I simply copied over the video file and the py-file from the windows box (the one that was showing this issue in the first place), changed the path in the py-file, and executed it just from the GUI.

I'm itching to try this on Windows x64, because I still haven't seen it happening there.

On Windows x86 it keeps happening for yet different videos, now using nightly 8894.
This time two MP4s that are just over 2GB in size, became MKVs over 30GB when finished. The files are perfectly well playable, so I don't really understand what it is exactly that's taking up so much extra space.

For completeness sake, the settings are:
Input: MP4 with H264/AAC, 1920x1080, duration = 1:02:27.
Video: AVC (x264), Avg bitrate = 2500kbps, motion estimation method = 9, the rest is default.
Video filter: resize to 1280x720 bicubic.
Audio: Copy (input was AAC 128kbps).
Container: MKV

/edit
When I do a rough calculation of the actual outputted bitrate for these 30GB files, my calculator says 30GB should be around 64000kbps. The files are a bit bigger and there's audio. So my suspicion is that Avidemux might somehow be using a bitrate of 65536kbps (or 0xFFFF for the uninitiated ). Could this perhaps be the case?

[mean]

could you post the output on linux ?
avidemux3_qt4 >& logFile

[thany]

Sure, no problem. But it's gonna take a while if I have to do the encode again... Should I let both passes finish?

[mean]

up to beginning of pass 2 is enough
Thanks

[thany]

I let the second pass go to 17%, not on purpose. I just walked away and came back to see 17%
Anyway, I hope the attached logfile will be of help. Ans sorry about it being a zip, it was too large otherwise.

[thany]

Is this issue still going to be resolved? I was kinda hoping for a status update... Something that tells me someone is working to resolve it.

In the mean time, I tried again with a newer nightly. Build 8913 this time. And back to Windows XP as well. Well, see attached screenshots. There's very little to add, but to point out that I explicitly set it to 2500kbps, but it's encoding at over 55,000kbps.