Can't achieve decent CBR

[leoenc]

(I posted this in the GUI forum, but I believe it is relevant to this forum actually):

Hi everyone,

I have read the discussions with akupenguin regarding how to achieve CBR.
The only way I can generate a stream that does not peak over the specified bitrate, is when entering a VBV bufsize value.

When using a buffer size equal to bit rate, this causes ugly "artifact flashes" from time to time, making the video unacceptable.

If VBV bufsize is set to 0, the artifact flashes are gone, but the stream peaks way above the specified bit rate.

When using much greater numbers than 2000kbps in VBV bufsize, the artifacts are gone, but I can't just put any number I like there, for streaming reasons.

Below is the generated command line from MeGUI. Can anyone help?

--bitrate 2000 --level 3 --keyint 40 --ref 3 --mixed-refs --bframes 3 --b-rdo --bime --weightb --subme 6 --trellis 1 --analyse p8x8,b8x8,i4x4 --qpmin 1 --vbv-bufsize 2000 --vbv-maxrate 2000 --ratetol 0.1 --threads auto --thread-input --progress --no-psnr --no-ssim --output "E:\test.264" "E:\test.avs"

[Manao]

The bug has been introduced in rev 651. Rev 650 works properly.

[leoenc]

Thanks Manao, but I was using 635, through MeGUI (which shows as latest).
I have downloaded the 650 build and manually replaced the EXE in MeGUI's folder, but the problem is still there.

Any ideas?

[leoenc]

OK I have found out that my flickering issue is caused by the low maximum keyframe interval (40). When using a buffer size large enough, the flickering is gone (I have no idea why).

Is there a way to get rid of the flickering, without increasing the keyframe interval, or buffer size?

[audyovydeo]

OK I have found out that my flickering issue is caused by the low maximum keyframe interval (40). When using a buffer size large enough, the flickering is gone (I have no idea why).

Is there a way to get rid of the flickering, without increasing the keyframe interval, or buffer size?

mmmh, I'd have to see your video, but it sort of sounds like a problem I had when encoding with QuickTime H264 (before I heard about x264).

1. What is your source fps ?
2. What happens when you set --keyint to your source fps value ?

I have no idea as to the relationship with the VBV buffer though.

audyovydeo

[leoenc]

Source fps is 25.
Setting keyint to 25 shows the flickering every 25 fps, instead of 40.

Thanks audyovydeo

[leoenc]

I managed to decrease the keyframe flicker by increasing the ratetol to 1 (from 0.1). Now with a VBV bufsize of 2000, the flickering seems to occur only in static backgrounds.

[DarkZell666]

Does your 'flickering' look like blocks that appear and disappear every second or so ? This is what happens when a codec inserts a keyframe in a stupid place (like in a static scene as you described). There isn't much you can do about it, all codecs behave that way (even XviD and DivX do, if you set the keyint too small ...).

But since you aim for 'real' CBR, the keyframes cause a problem since they are the frames that eat the most bits. So when the codec detects it's time to insert a keyframe, for it to fit into the specified buffer size, it squeezes it's quality (and the quality of the 4 or 5 following p-/b-frames with it so vbv constraints aren't violated). So finally, each keyframe inserted causes a 'blocky flash'. You'll get CBR more easily with less keyframes (bigger keyint) imho, but for a safe streaming context, you'll need to insert more than usual (keyint smaller than 50 or 60).

So apart from relaxing your streaming conditions a bit, there isn't much you can do about it ... (maybe pump up deblocking to +6,+6 ? It may even make things worse but it's worth having a try :p)

[leoenc]

DarkZell666

Yes I suspected there isn't much else to be done in my case.
Anyway, thanks for the thorough explanation!

[audyovydeo]

Strangely, in my QuickTime h264 case, the problem disappeared when I switched "keyframes" settings from "automatic" to "every" "25"
(ie my input frame rate).

Although DarkZell666's explanation makes perfect sense, at the time I'd explained away the problem like so : "when keyframe=automatic, keyframes are so far apart that the last P/B frames in the GOP are of very bad quality, so by forcing a smaller keyframe interval, the problem disappears."

out of curiosity I'll try to reproduce the problem with x264 which has a much higher number of configurable parameters.

[akupenguin]

P/B-frames don't get lower quality just because they're far from an I-frame. On the contrary, with CBR + large GOP you see the transition from high quality P/B-frames at the end of one GOP to the low quality I-frame at the start of the next. With CBR + small GOP, none of the frames are high quality. But consistent low quality looks better than some low and some high.

[audyovydeo]

I stand corrected akupenguin.

Off-topic, I've only been a x264 user for 4/5 months, and exploring it formally since r640. One of the things I miss most is which options are mutually-exclusive. I think I've done the rounds of the internet guides, but how can one be sure... could anyone point me to such a guide / provide this info ?

thanks in advance
audyovydeo

[audyovydeo]

DarkZell666
Yes I suspected there isn't much else to be done in my case.
Anyway, thanks for the thorough explanation!

DarkZell,

I was thinking another thing you could try :
do a test run of your cmdline less the "bitrate" and "vbv------" options, and see what avg bitrate x264 estimates at the end of the run. If (as probable) it overshoots your target you can then tweak the other settings (--me umh ? higher --ref ? ) to get nearer your target.

This should probably get you better overall than having x264 force the bitrate you theorised.

I also notice you didn't specify --no-fast-pskip and --no-dct-decimate while using trellis.

[DarkZell666]

In fact, all this streaming & CBR stuff got me to understand something rather important ...

The average bitrate throughout the clip will obviously be somewhere near what's specified, but there's a limit to how much data the recieving client can buffer "in advance". If the average bitrate is 800kbps, some scenes can be of 500kbps, and others could be 1200kbps (just taking random numbers right ?).

It would be ideal to stream a constant 800kbps stream, but that would mean that some video would be sent "in advance", in order to compensate for the next scene. Not sending that video in advance, the bitrate-hungry scene wouldn't be displayed in real-time because it's bitrate exceeds that of your bandwidth ... And this explains why the vbv was created in the first place : to limit the maximum amount of data that needs to be buffered by the client "in advance" (and at the same time limit the maximum bitrate allocated to bitrate-hungry scenes).

*sorry I just went tilt before going out to lunch :p*