[FFmpeg-devel] [PATCH] qt-faststart: Add mode for probing faststart-ness

Tomas Härdin tjoppen at acc.umu.se
Wed Aug 1 21:33:43 EEST 2018


tis 2018-07-31 klockan 14:46 -0700 skrev Baptiste Coudurier:
> Hey Tomas,
> 
> > On Sat, Jul 28, 2018 at 1:56 AM, Tomas Härdin <tjoppen at acc.umu.se> wrote:
> 
> > lör 2018-07-28 klockan 10:31 +0530 skrev Gyan Doshi:
> > > 
> > > On 28-07-2018 03:33 AM, Tomas Härdin wrote:
> > > > 
> > > > woot! I didn't know the mov demuxer dumped such things. It is quite
> > > > slow however, since it will scan through every leaf atom in the
> > > > file.
> > > > For example, running time ffmpeg -i input.mov -v 56 2>&1 | wc on a
> > > > 1.5
> > > > GiB MP4 on an SSD takes:
> > > 
> > > Use the subfile protocol to forgo parsing the whole file, e.g.
> > > 
> > >      ffmpeg -i subfile,,start,0,end,10000,,:in.mp4 -v 56 2>&1 | grep
> > > -e
> > > "type:'moov'" -e "type:'mdat'" | head -1 | grep moov
> > > 
> > > This assumes that at least one of the two targeted boxes moov/mdat
> > > start
> > > within the first 10000 bytes.
> > 
> > Neat. This is similar to the first suggestion I had to the peertube
> > devs, dd:ing off the first MiB or so then probing that. We'll see what
> > they say, and what Baptiste thinks I guess
> 
> 
> Interesting, I can see the interest of checking this. Could ffprobe do that
> somehow ?
> Would be an interesting information to report.
> Not sure it belongs in qt-faststart, and not sure checking fragmented files
> would be in
> the scope of qt-faststart. What do you think ?

My main concern with adding this in ffprobe is the amount of plumbing
needed. Perhaps the demuxer could set a metadata field?

I judged separating fragmented from non-fragmented streamable files as
valuable for this patch, partly because I had to do something to make
qt-faststart not complain about fragmented files. But that also allows
it to abort early. Not that parsing top-level atoms only is
particularly hard work.. Do we know of any players that *don't* support
fragmented MP4?

For now PeerTube seem to be going with something similar to Gyan's
suggestion, so they don't have to keep more C code than necessary
around: https://gist.github.com/rigelk/95e41dacb66df652039e59350a9eb7b4

I think we might want users that actually need this before pushing.
Else it's just technical debt. Good exercise for me to get a bit better
grasp on FATE however

/Tomas


More information about the ffmpeg-devel mailing list