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

[FFmpeg]

#5080: Excessive HTTP GETs reading MP4 from web server
-------------------------------------+------------------------------------
             Reporter:  nealzebub    |                    Owner:
                 Type:  enhancement  |                   Status:  open
             Priority:  wish         |                Component:  avformat
              Version:  git-master   |               Resolution:
             Keywords:  http mov     |               Blocked By:
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+------------------------------------

Comment (by Misaki):

 It's easier to handle when audio is earlier, since it's typically lower
 bitrate than video.

 I have occasionally (rarely) found ffmpeg producing files, when using http
 input, where the audio is significantly delayed. I didn't look at byte
 positions, just relative timestamp positions as it seems media players use
 that instead of byte position.

 This resulted in files where common media players didn't have audio.
 Seeking to the middle of the file would turn audio back on. (totem video
 player also has problems when audio length is more than three times longer
 than video, things like that.)

 In rare cases, ffmpeg will produce a file that it can't recognize itself,
 even when using probesize options as it suggests, but it isn't common
 enough to have reported it yet.

 I was going to suggest using another program like wget to download the
 file, but that actually leads to a bunch of error messages in ffmpeg.

  ffmpeg -analyzeduration 50M -probesize 50M -i <(wget -qO -
 http://transcodes.s3.amazonaws.com/content/iPhone4_upload_via_3G.MP4)

 [mov,mp4,m4a,3gp,3g2,mj2 @ 0x1270000] stream 0, offset 0x2c: partial file
 [mov,mp4,m4a,3gp,3g2,mj2 @ 0x1270000] Could not find codec parameters for
 stream 1 (Video: h264 (avc1 / 0x31637661), none(tv, bt709), 224x128, 133
 kb/s): unspecified pixel format
 Consider increasing the value for the 'analyzeduration' and 'probesize'
 options

 (Setting an output format, like pulse or opengl, leads to other,
 different, errors.)

 Maybe the log output explains it, but ffmpeg/ffprobe might be using a
 buffer based on timestamps, just like media players often use, and not
 based on file size. The video resolution is pretty small; the encoder or
 muxer might just be adding packets when the file size exceeds a certain
 amount, not when timestamps exceed a certain amount. (Actually, it seems
 the maximum difference is ~1 second; the variation in position might be
 due to video frame size.) My comment is decreasing in usefulness, but why
 is the audio listed as being later in time, but earlier in file position?
 I had thought that -show_packets, unlike -show_frames, listed frames in
 position order, but it doesn't do so with this file.

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