CCE Constant BitRate is not constant?

duronator · 17th March 2002, 12:11

I encoded an SVCD-clip in CCE using CBR 1100. When I look at the resulting stream with Bitrate Viewer I can see bitrate values as low as 300 and high values exceeding 2000. It also reports an average bitrate of 1299. Because of the low values, my Pioneer 444 struggles with the playback. It clearly does not like low bitrates.

The same happens when I use VBR and supply a minimum bitrate of 700 and average 1150. The resulting file always has parts where the bitrate is much lower.

How come?

duronator · 17th March 2002, 12:16

By the way, I also tried Tmpgenc with a CBR of 1100. Looking at the stream with Bitrate Viewer, the stream is much more constant (lowest bitrate is 1085, highest is about 1400). Still, it reports an average of 1299 even though I encoded at 1100.

Doom9 · 17th March 2002, 13:21

I know that feeling.. tried to get a 6mbit/s cbr stream for streaming purposes and the best I got from every encoder I tried was bitrate fluctuations of around 1mbit. Using tmpg's vbr mode and use padding for the min bitrate may help in your case.

duronator · 17th March 2002, 19:20

Quote:

Originally posted by Doom9
I know that feeling.. tried to get a 6mbit/s cbr stream for streaming purposes and the best I got from every encoder I tried was bitrate fluctuations of around 1mbit. Using tmpg's vbr mode and use padding for the min bitrate may help in your case.

Strange thing though. You would expect that the encoder would at least *try* to respect my min. input.

This padding thing, is that an option in Tmpgenc somewhere? And is this not possible in CCE?

Pko · 18th March 2002, 14:40

I think that "constant bitrate" by itself has no real meaning... it must be specified as "constant bitrate in a given buffer".

For example, if you consider PAL at 25fps, if you take a second it will have 25 images. If all the images are I frames, *perhaps* all of them can be compressed to exact the same size, but that is not generally posible nor even desiderable, since that would be very inefficient.

If you compress it to, say, a GOP of IPBBBPBBP (for example, I know it has little meaning), the bitrate will be widly different if you start in a I frame or in a B frame and take three different frames; that is, IPB or BBB will all point to 3/25 of a sec, but the I frame will take much more bytes.

But if you measure bitrate in a 2 sec scale, each "step" will take 50 pictures and so the bitrate can be much more "constant". And you cannot specify "use only complete GOPs and measure the bitrate in each GOP", since the GOPs can be of different lengths (caused by scene changes, for example).

So, the MPEG stream for a given application must have a definite buffer (and GOP constraints) and the encoder must make sure that the stream is constant inside that buffer, but if you measure the bitrate without considering that conditions, of course the bitrate will change a lot. But the error is not in the encoding, but in the interpretation of the results (not that bitrate viewer gives wrong results, only that you must interpret them with the given buffer and GOP constraints)

duronator · 18th March 2002, 19:13

Quote:

Originally posted by Pko
I think that "constant bitrate" by itself has no real meaning... it must be specified as "constant bitrate in a given buffer".
....

Sounds very reasonable. Thanks for taking the time to clear that up!

17th March 2002, 12:11	#1 \| Link
duronator Registered User Join Date: Nov 2001 Posts: 45	CCE Constant BitRate is not constant? I encoded an SVCD-clip in CCE using CBR 1100. When I look at the resulting stream with Bitrate Viewer I can see bitrate values as low as 300 and high values exceeding 2000. It also reports an average bitrate of 1299. Because of the low values, my Pioneer 444 struggles with the playback. It clearly does not like low bitrates. The same happens when I use VBR and supply a minimum bitrate of 700 and average 1150. The resulting file always has parts where the bitrate is much lower. How come?

17th March 2002, 13:21	#3 \| Link
Doom9 clueless n00b Join Date: Oct 2001 Location: somewhere over the rainbow Posts: 10,579	I know that feeling.. tried to get a 6mbit/s cbr stream for streaming purposes and the best I got from every encoder I tried was bitrate fluctuations of around 1mbit. Using tmpg's vbr mode and use padding for the min bitrate may help in your case. __________________ For the web's most comprehensive collection of DVD backup guides go to www.doom9.org

17th March 2002, 12:16	#2 \| Link
duronator Registered User Join Date: Nov 2001 Posts: 45	By the way, I also tried Tmpgenc with a CBR of 1100. Looking at the stream with Bitrate Viewer, the stream is much more constant (lowest bitrate is 1085, highest is about 1400). Still, it reports an average of 1299 even though I encoded at 1100.

18th March 2002, 14:40	#5 \| Link
Pko Registered User Join Date: Feb 2002 Posts: 140	I think that "constant bitrate" by itself has no real meaning... it must be specified as "constant bitrate in a given buffer". For example, if you consider PAL at 25fps, if you take a second it will have 25 images. If all the images are I frames, perhaps all of them can be compressed to exact the same size, but that is not generally posible nor even desiderable, since that would be very inefficient. If you compress it to, say, a GOP of IPBBBPBBP (for example, I know it has little meaning), the bitrate will be widly different if you start in a I frame or in a B frame and take three different frames; that is, IPB or BBB will all point to 3/25 of a sec, but the I frame will take much more bytes. But if you measure bitrate in a 2 sec scale, each "step" will take 50 pictures and so the bitrate can be much more "constant". And you cannot specify "use only complete GOPs and measure the bitrate in each GOP", since the GOPs can be of different lengths (caused by scene changes, for example). So, the MPEG stream for a given application must have a definite buffer (and GOP constraints) and the encoder must make sure that the stream is constant inside that buffer, but if you measure the bitrate without considering that conditions, of course the bitrate will change a lot. But the error is not in the encoding, but in the interpretation of the results (not that bitrate viewer gives wrong results, only that you must interpret them with the given buffer and GOP constraints)