> On Jul 31, 2017, at 2:52 PM, Nicolas George <geo...@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@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-user > > To unsubscribe, visit link above, or email > ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe". _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
