[FFmpeg-user] 2 pass CBR or VBR not really fixing the bitrate?

Nicolas George george at nsup.org
Tue Aug 1 00:52:01 EEST 2017

Le tridi 13 thermidor, an CCXXV, Manuel Tiglio a écrit :
> Correct. I tried first fixing the distance between keyframes to 2
> seconds and then 2-pass VBV and the other way around and also not
> fixing the distance between keyframes. 
> I think I see your point now. To answer your question, the average is
> done through the entire video, so in a much longer timescale than the
> distance between keyframes. By looking at the data (I can send you
> some plots) I’d say that decreasing the averaging time would not
> change much, but I can try. Any recommendations on that? 

> >> Can you type a typical example of what you mean for that? CBR is a
> >> 100% constrained VBR (i.e. ideally no fluctuations in the bitrate from
> >> its average), essentially. 
> > Except it does not mean anything practical.
> What do you mean? 

Ok, I will try to explain one last time.

You never have "100% constrained VBR". That would mean every single
frame has the exact same size. There are only one class of codecs that
do that: uncompressed video. Yes, with uncompressed video, every full-HD
image will use exactly 6220800 octets (assuming no chroma sub-sampling
and 8-bits depth), and every minute of movie will fill a dual-layer DVD.

But compressed codecs are very different. I already mentioned I-frames,
who are much larger than P- and B-frames. But that is not all. Simple
scenes, like a shot of the sky, need much less data than complex scenes,
like water or foliage. Still scenes require much less data than fast

For actual streaming, the client has a buffer, with a certain capacity
that amounts to a certain duration. If you want the streaming to go
smoothly, the constraint is that the average bit rate over a window with
the same width as the buffer is never beyond the bandwidth.

So, to achieve smooth streaming, you need to know the size of the buffer
of your clients, or at least a lower bound for it, and set your encoder

Now, about two-pass encoding. 

Remember that your viewers will always notice the parts with the worst
quality. Therefore, the most pleasing result will be achieved when the
quality is as constant as possible. If you have no constraint at all,
then set a constant quality (cbr for x264).

But if you have bit rate constraints, it is the same as having a budget:
you have to make sacrifices, and you better choose the sacrifices that
will be the most painless.

Let us take an example: you must encode one minute into 4 mega-octets.
If the minute is made of 30 seconds fast complex content and 30 seconds
slow simple content, then you want to invest 3 mega-octets into the
first part and only 1 into the second part. But if the content is fast
and complex for the whole minute, then you need to invest 2 mega-octets
for both halves; the quality will be lower, but you cannot do anything
about it if you are on a budget.

That is where two-pass encoding comes into play: when the codec is
processing the first 30 seconds, it does not know about the contents of
the second half, so it cannot decide whether to cut 50%-50% or 75%-25%
or anything else. So you make a first run to collect statistics about
the complexity of the video, and then a second pass to allocate your
budget according to these statistics.

But encoders also have a buffer. They do not encode one frame at a time,
they encode many at once and make global decisions on them. If the
window of the encoder is larger than the window of the decoder, then
two-pass encoding is completely useless.

As for how to apply this to your specific problem, only you can know the


  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-user/attachments/20170731/743ff2ab/attachment.sig>

More information about the ffmpeg-user mailing list