2016-01-05 2:12 GMT+08:00 Nicolas George <geo...@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. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
