[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
grow.
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