On 9 October 2014 18:30, Michael Niedermayer <michae...@gmx.at> wrote:
> On Thu, Oct 09, 2014 at 08:52:29AM +0300, Mika Raento wrote:
>> On 8 October 2014 16:03, Michael Niedermayer <michae...@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
Right. Thanks for the input. I'll rewrite this to look for the mfra
when hitting a moof box.
That will still cause seeks, but there's no way to avoid them if we do
want to read the mfra - and without the mfra the dts are wrong.
Mika
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Everything should be made as simple as possible, but not simpler.
> -- Albert Einstein
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
