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

[Manuel Tiglio]

> On Jul 31, 2017, at 2:52 PM, Nicolas George <george at nsup.org> wrote:
> 
> 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
> scenes.
> 
> 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
> accordingly.
> 
> 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
> constraints.
> 
> Regards,
> 
> -- 
>  Nicolas George

Thanks Nicolas, so your point seems to be not be concerned with peak bitrates but only with average ones and buffer sizes. Is that a more or less accurate summary? 



> _______________________________________________
> ffmpeg-user mailing list
> ffmpeg-user at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
> 
> To unsubscribe, visit link above, or email
> ffmpeg-user-request at ffmpeg.org with subject "unsubscribe".