Actual Bitrate?

[TheBashar]

I'm having trouble backing out what video bitrate was used for a VFR AVC MKV.

When the no audio test clip was encoded in MeGUI, it reported:
"Actual bitrate after encoding without container overhead: 758.53"

To back solve for this value I think I have to:

Extract the raw AVC stream
Mux the raw stream into an MP4
Determine the non-VFR time length of the MP4
Divide the size of the raw stream by the non-VFR play length.


I do this, but the value I get does not match the MeGUI log. Can anyone spot a mistake in my process for determining the bitrate?


The size of the raw AVC stream is: 21,488,606 bytes
The play length of the nonVFR MP4 is: 4:31 [m:ss] (vfr was 4:46)
((21488606 / 1024) * 8 ) / (4 * 60 + 31) = 619.48


619.48 is << 758.53

In case the devil is in the details, I use:

MeGUI to encode x264 to MP4 container
MMG to mux the MP4 AVC stream into MKV with timecode file
Files above this point are not available for calculations
MKVExtractGUI to extract the raw AVC stream
YAMB and MP4Box to mux the raw AVC back to an MP4
MPC to play the MP4 and view the play length


Any help understanding the disparity would be greatly appreciated!

[Doom9]

first of all, I feel the need to state that none of this is vfr related and you're going at it the wrong way. You should be looking at raw stream output from x264.exe.... you get the bitrate by dividing size by lenght in seconds of your avisynth input.

Then, looking at the sources, what is reported as bitrate without encoding overhead is the last line from x264.exe: encoded 51 frames, 19.31 fps, 1020.16 kb/s . I built that in accordance with what aku told me that value represents.. if you do a search restricted to this forum you should find it again.

[TheBashar]

Thanks for the reply D9, though I feel the need to state that it is VFR related because the length of time needs to come from a non timecode adjusted source. Getting the length from the avisynth input is not possible because we are backing out the bitrate from the final encode. You should consider the sources unavailable for the purposes of backing out the bitrate used.

Now, examining the MeGUI log again, I see that it says 29.97 fps (6793 frames)

That's interesting because that translates to 226.66 seconds. Using that value get's me closer to MeGUI logged bitrate. I guess now I have to focus on how to get back to the accurate avs time....

Turning on some extra YAMB info, I see now that it thinks it's 25fps. So..

(4 * 60 + 31) * 25 / 29.97 = 226 (close enough)

Okay, so that gets me within 5% of of the MeGUI reported rate. I would have preferred closer, but that's good enough I guess.

Thanks for your help D9!

[Doom9]

Getting the length from the avisynth input is not possible because we are backing out the bitrate from the final encodeThat's just the wrong approach. You should start at the other end.. it's more straightforward, less error prone, and below you'll find the details that prove the bitrate is in fact accurately reported:

Since AviSynth is inheritently constant FPS, and your source is reported as 29.97 fps, that means that the 23.976 parts will be played too fast, but that's it. So VFR or not really doesn't matter at all at this point. The source is 29.97 fps, has 6793 frames, thus has a play length of 226.66 seconds. And 21,488,606 * 8 / (226.66 * 1000) = 758.44 kbit/s. Now if you search for that post I mentioned, aku pointed out what exactly is all taken into account by that report.. it's not just the raw stream, it contains certain additional things (I'm afraid I don't recall what.. but if you want to find out, it takes you as long to search as it takes me ;), which I think would account for the missing 0.09 kbit/s. In fact, assuming you used b-frames and that 10.4 byte/frame overhead seems pretty accurate, we'd have a 2.49 kbit/s container overhead for a 29.97 fps source, so we're definitely not dealing with a report that includes the container overhead.

[TheBashar]

I don't know how to spell it out for you Doom: I want to find the video bitrate from the final encoded movie. Period.

I was never questioning the accuracy of MeGUI, just trying to recreate from the other end.

Thanks again for your help getting me within 5%.

[Doom9]

I'm not saying you're questioning MeGUI, in fact since I'm using x264's output, you could only question that ;)
Still, you can do it the wrong way round. Doesn't change the fact that you have to look at your source as 6793 frames @ 29.97fps, and with your raw size, you get the bitrate from my above post. Likewise, in your second post you realized your mp4 muxing blunder and also came to a 226 second length, which is the actual play length at the constant framerate, and using that length, framerate and raw size, you once again get the correct bitrate.

So basically where you got wrong is muxing the raw stream into an MP4 is that you didn't specify a framerate (I missed that, having written a GUI for it it's the most natural thing for me to specify a framerate, and clearly you didn't use the mp4 muxer in MeGUI - it forces you to select a framerate) and thus ended up with a wrong constant framerate stream length which in turn ends up with an incorrect framerate.

And
((21488606 / 1024) * 8 ) / ((4 * 60 + 31) * 25 / 29.97) ~= 758.44, which is 0.011% off, not 5%.

Urgh, wait a tick, your formula is wrong. It needs to start with 21488606 * 8 (now we have bits) / 1000 (now we have kilobits), and then divide by the play length. And naturally, if you're going to use a 2 digit precision for the final bitrate, the intermediate values should be even more precise.. you're discarding more than half a second by not using a higher precision for the play length. I've used two digits after the comma, which gets us pretty darned close.

There would be an even funkier way to derive the play length by the way.. you could use the length of the time adjusted mkv file, and knowing which parts are 23.976 and which are 29.97 you could reconstruct the play length of the stream before VFR adjustment.. it should also come back as 226 seconds. You would still have to extract the raw video stream to get the size though, unless you are willing to do overhead calculations for matroska (also possible, but to be accurate you'd need to know a lot of details about your source, like how many I/P/B frames it has, and details about your audio tracks). The exact details can be found in the container forum, mosu gave them in reply to a couple questions of mine.

[TheBashar]

Awesome thank you! I hate getting bitten in the arse by the kilobits/kibibits mistake.

And you're right, I "clearly didn't use the mp4 muxer in MeGUI" becuase your muxer doesn't take raw AVC streams as input.

[Doom9]

becuase your muxer doesn't take raw AVC streams as input.Wrong, it does. The filter is *.m4v;*.264;*.mp4 for the video input. The exposed muxing functionality is a testbed for the muxer that's used when you create an mp4 after encoding ;)

[TheBashar]

Wrong, it does. The filter is *.m4v;*.264;*.mp4 for the video input. The exposed muxing functionality is a testbed for the muxer that's used when you create an mp4 after encoding ;)

Good to know, I'll use it instead of YAMB. Thanks.

[foxyshadis]

A quick note - if you really *must* see the final bitrate at the encoding stage, you could set the fps in your avisynth script to be whatever you want. Calculate number of frames / final time and you've got it. After all, the timecode file is fps-independant.

Hm, I didn't think about vfr being lower quality in some parts due to some sections being jammed together and later played with a lower bitrate in the area. On the other hand, I suppose that rate control would take care of that so it's not an issue.