[FFmpeg-devel] [PATCH] mov.c: read fragment start dts from fragmented mp4

Michael Niedermayer michaelni at gmx.at
Thu Oct 9 17:30:23 CEST 2014


On Thu, Oct 09, 2014 at 08:52:29AM +0300, Mika Raento wrote:
> On 8 October 2014 16:03, Michael Niedermayer <michaelni at gmx.at> wrote:
[...]
> >> +    if (avio_rb32(f) != mfra_size) {
> >> +        av_log(s, AV_LOG_DEBUG, "doesn't look like mfra (size)\n");
> >> +        return -1;
> >> +    }
> >> +    if (avio_rb32(f) != MKBETAG('m', 'f', 'r', 'a')) {
> >> +        av_log(s, AV_LOG_DEBUG, "doesn't look like mfra (tag)\n");
> >> +        return -1;
> >> +    }
> >> +    av_log(s, AV_LOG_VERBOSE, "stream has mfra\n");
> >> +    while (!read_tfra(s)) {
> >> +        /* Empty */
> >> +    }
> >> +    return 0;
> >> +}
> >> +
> >>  static int mov_read_header(AVFormatContext *s)
> >>  {
> >>      MOVContext *mov = s->priv_data;
> >
> >> @@ -3565,6 +3678,9 @@ static int mov_read_header(AVFormatContext *s)
> >>      else
> >>          atom.size = INT64_MAX;
> >>
> >> +    if (pb->seekable) {
> >> +        mov_read_mfra(s);
> >> +    }
> >
> > mov_read_mfra() requires multiple seeks, these are quite expensive if
> > the file is not local but accessed over the network.
> > Is it possible to detect (most) files which do not have mfra atoms
> > reliably without having to try to read the mfra atom so as to avoid
> > doing these potentially expensive seeks ?
> 
> That's an excellent question. Here are some possibilities:
> - we could only do it for filenames ending in .ismv (nothing forces
> fragmented mp4s to be called .ismv)
> - we could have a flag to look or not look for the mfra, and maybe
> default it to true if the filename ends in .ismv (+ for performance, -
> for usability)
> - we could trigger the code only once we see a moof (I'd need to
> restructure the code, reading mfra as the first thing looked like the
> minimal change)

i think it has to be automatic to be usefull, users cant be expected
to set all kinds of flags on a per file basis, iam not sure using
the file extension would be reliable enough so as not to break any
files. So if its possible then using something from the files content
would be best moof or otherwise.
The goal here is to avoid the extra latency the back and forth seeking
needs so a solution would make only sense if it itself doesnt require
extra seeking outside the IO buffer

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Everything should be made as simple as possible, but not simpler.
-- Albert Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20141009/b92de573/attachment.asc>


More information about the ffmpeg-devel mailing list