[FFmpeg-user] Slow seeking for GB-scale MOVs?

[John Hawkinson]

Any thoughts on this issue, or how best to narrow or debug it? (Platform is MacOS if that's helpful, but I could do so from Linux is that's easier.)

Thank you!

--
jhawk at alum.mit.edu
John Hawkinson


John Hawkinson <jhawk at alum.mit.edu> wrote on Sun,  7 Jun 2020
at 19:26:26 EDT in <20200607232626.GA74974 at alum.mit.edu>:

> Date: Sun, 7 Jun 2020 19:26:26 -0400
> From: John Hawkinson <jhawk at alum.mit.edu>
> To: ffmpeg-user at ffmpeg.org
> Subject: Slow seeking for GB-scale MOVs?
> Message-ID: <20200607232626.GA74974 at alum.mit.edu>
> 
> When I try to seek within a 5 GB MOV file (24 hours 12 minutes of video; someone screwed up) over http, it seems that ffmpeg downloads a lot more data than is necessary, and so is fairly slow to start (delay of minutes on a medium-speed network connection), seemingly unnecessarily so. In particular, it seems that in the search for the moov atom, it may end up downloading the final 69 MB of the file, and that takes quite a while.
> 
> (I'm not quite sure of this -- the http traces from libavformat appear to indicate the start of HTTP byte-range queries, but don't indicate  the end of such a transfer. For instance, iniially there is a GET for "Range: bytes=0-" and shortly thereafter there is a GET for "Range: bytes=6050885555-" and it's clear that the first could not have downloaded the entire 5 GB file before turning to the second. So maybe I am missing when http transfer stops and maybe that matters here.)
> 
> I spent a while staring at libavformat/mov.c and I wasn't able to discern exactly how/when it decides to do this seeking, although empirically it would appear that the offset it begins to retrieve is a function of the 'sz' reported in the 'mdat' trace line, and it finds the 'moov' atom quite quickly. Yet there is long delay (again, a minute-ish, depending on connection speed) before any playback starts. There are a few stages along the way, with a lot of AvIndex output about halfway before playback begins, but that don't seem correlated with http GETs.
> 
> My example is trying to seek 30 minutes into http://mediadownload.iqm2.com/CambridgeMA/2288.mpeg4 , the 5 GB video.
> So, for instance:
> 
> bash$ ffplay -ss 30:00 -loglevel trace http://mediadownload.iqm2.com/CambridgeMA/2288.mpeg4
...
> 
> The complete uncut output at the defaul loglevel is uninteresting.
> The above is excerpted from loglevel trace, which gives nearly 1 GB of output and is probably not helpful here in the entirety.
> 
> A lightly edited version and prematurely truncated version of the trace output follows, with prefixed timestamps (via tai64n/tai64nlocal).
> 
> 
> Anyhow, is there a way to reduce how much ffmpeg downloads when it goes for the moov atom, and am I correct in thinking that that is the issue here?
> 
> Thanks.
> 
> 
> p.s.: I'm not 100% sure this HTTP resource cited above will persist. It's possible someone may decide to correct the errantly recorded 24+ hours of video (it should have been only 9) and so the problem may go away or shift.
> 
> --
> jhawk at alum.mit.edu
> John Hawkinson
...