Bitrate Question

[x0pht]

Hi there,

How are video/audio bitrates calculated? is it simply stream size/length (in sec)?

Here's what confused me. I had a few raw streams - a VC1 video, a LPCM audio, a TrueHD, an AC3, a Vorbis. when only the VC1 and TrueHD were muxed in a single mkv file, the MKVVerify reported the video bitrate was 16,800 Kbps, the truehd was 1,736 Kbps, which was what they were supposed to be.

Then I muxed all the streams together, the video was reported to be 16,788 Kbps, truehd was 1,734 Kbps. Why's there a difference?

EDIT: actually the bitrate of LPCM stream was changed too after being muxed, it was 3 Kbps less than the raw stream.

[jagabo]

How are video/audio bitrates calculated? is it simply stream size/length (in sec)?

Basically, yes.

size = bitrate * running time

Here's what confused me. I had a few raw streams - a VC1 video, a LPCM audio, a TrueHD, an AC3, a Vorbis. when only the VC1 and TrueHD were muxed in a single mkv file, the MKVVerify reported the video bitrate was 16,800 Kbps, the truehd was 1,736 Kbps, which was what they were supposed to be.

Then I muxed all the streams together, the video was reported to be 16,788 Kbps, truehd was 1,734 Kbps. Why's there a difference?

EDIT: actually the bitrate of LPCM stream was changed too after being muxed, it was 3 Kbps less than the raw stream.

This is largely because programs don't actually detect the size of each stream by reading through the entire file. They usually make assumptions about the size or bitrate based on the header information and the size of the file. Sometimes that header information is incorrect. It might report the max bitrate, not the average, for a VBR encoded file. They may not take into consideration container overhead (or just roughly estimate it), etc.

[x0pht]

[QUOTE=jagabo;2049320]

This is largely because programs don't actually detect the size of each stream by reading through the entire file. They usually make assumptions about the size or bitrate based on the header information and the size of the file. Sometimes that header information is incorrect. It might report the max bitrate, not the average, for a VBR encoded file. They may not take into consideration container overhead (or just roughly estimate it), etc.

Thank you for the prompt reply, jagabo.

indeed that can be true on a lot of programs, but mkvverify reads through the entire file and reports based on the actual values it detects - not on the header info or any metadata - it parses the whole file. and actually the stream sizes/frames/durations reported by mkvverify were consistent, the only difference was bitrates.

I've been testing since i posted this thread. for the specific file i mentioned in the previous post, the problem appears to lie at the vorbis stream. when it's delayed for 950ms, the video bitrate is reported to be 16,788. when it's not delayed at all, video bitrate is 16,790.

i guess the question now is - does a stream delay affects the bitrate calculations of other streams in a mkv?

[jagabo]

I could speculate about the reasons but why don't you just ask the author of the program? In any case, it's only a 0.01 percent difference.

http://www.alexander-noe.com/

[x0pht]

thanks for the suggestion. i'll try. though the author seems to have stopped updating his program since 2006. but i still suspect the problem is rather program-independent, and format-relevant - mkv.

i know such a percentage of difference is no big deal. but i usually can't help but wonder the reasons and causes.

update: when the vorbis stream is delayed by -1050ms, the video bitrate becomes 16,793.

[poisondeathray]

Nevermind, I have no idea what I'm talking about