[FFmpeg-trac] #5080(undetermined:new): Excessive HTTP GETs reading MP4 from web server

FFmpeg trac at avcodec.org
Tue Jan 12 20:58:53 CET 2016

#5080: Excessive HTTP GETs reading MP4 from web server
             Reporter:  nealzebub    |                    Owner:
                 Type:  defect       |                   Status:  new
             Priority:  normal       |                Component:
              Version:  git-master   |  undetermined
             Keywords:  http mov     |               Resolution:
             Blocking:               |               Blocked By:
Analyzed by developer:  0            |  Reproduced by developer:  0

Comment (by stefang):

 nealzebub, you are right that the differences do get smaller again, I only
 looked at the trimmed list and not the PNG before I wrote my post. So in
 this case there would not be a big buffering requirement to handle the
 file smoothly.
 However, handling such files correctly still is difficult to implement. If
 you look at the abstraction of a demuxer e.g. 'mov' - which gets the order
 'give me the next packet in time' - and the protocol e.g. 'http' - which
 understands 'give me the next few bytes' and 'seek to position x' - you
 have a problem with badly interleaved files.
 The demuxer would need some logic to detect the gap between the current
 audio position and the current video position in the file and buffer it by
 itself. Only then would a seek back to the lower of the two positions be
 avoided. And an additional buffer I would say is not a desirable thing in
 a demuxer and would raise the question how big such a buffer is allowed to

 Anyway, I think your report is absolutely valid. I would just argue that
 the current behaviour is not a bug and would relabel it as an enhancement
 request to handle badly interleaved files in a smoother way.

Ticket URL: <https://trac.ffmpeg.org/ticket/5080#comment:9>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker

More information about the FFmpeg-trac mailing list