[FFmpeg-devel] [PATCH] avformat/concatdec: get bit_rate from internal format

Zhang Rui bbcallen at gmail.com
Tue Jan 5 03:41:17 CET 2016

2016-01-05 2:12 GMT+08:00 Nicolas George <george at nsup.org>:
> Le quintidi 15 nivôse, an CCXXIV, Zhang Rui a écrit :
>> Actually, I use custom IO in my own application to prefetch data via HTTP.
>> I'm trying to calculate duration from bytes with bit_rate, for:
>> 1. Calculate necessary download speed.
>> 2. Adjust prefetch buffer size.
>> 3. Show prefetched duration in progress bar.
>> I thought AVFormatContext.bit_rate is a convenient alias.
>> Is AVCodecContext.bit_rate more suitable for these purpose?
> I see. At first glance it makes sense, but I do not think you are on the
> right track, for two reasons.
> First, you will have trouble using custom I/O with the concat demuxer, it is
> not really meant for programmatic use. All it does is read packets from the
> underlying demuxers and adjust timestamps: in an application, you can easily
> do the same directly with more control. Then you have access to the
> properties of each file, including bit_rate.
> Second, the bit_rate is only an average. With VFR content, you would end up
> buffering way more than necessary for still scenes (not really a problem if
> memory is cheap), and then under-run very fast as soon as there is water or
> foliage visible.
> To handle VFR content, you need to adjust dynamically. IMHO, the best way of
> doing that is to buffer packets after the demuxer, not octets before it.
> Demuxing is fast, and the memory use is roughly the same, mostly the
> payload, so it does not change anything. But if you buffer after the
> demuxer, you have access to the timestamps of the packets: you can decide
> you want to buffer 20 seconds of movie, you just have to demux until the
> timestamp is right, you do not need to estimate how many octets it makes.
> Hope this helps.

Got it.
Thanks for your patient reply.

More information about the ffmpeg-devel mailing list