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 <tjop...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
