[FFmpeg-devel] [PATCH] mov: fix decode of fragments that overlap in time

[John Stebbins]

On 10/09/2017 02:40 PM, Carl Eugen Hoyos wrote:
> 2017-10-09 22:09 GMT+02:00 John Stebbins <jstebbins at jetheaddev.com>:
>
>> +    // This shouldn't happen
>> +    return NULL;
> As in: This cannot happen and should be an assert()
> or this does not happen for valid files and should print
> an error?
>
> Same below.
>
>

In theory, there are a couple of scenarios where this could happen.  They all involve the moov being at the end of the
file after a moof. ffmpeg errors out with AVERROR_INVALIDDATA in several other scenarios if it detects this condition. 
E.g. in mov_read_trun and several other places, it does this:

    for (i = 0; i < c->fc->nb_streams; i++) {
        if (c->fc->streams[i]->id == frag->track_id) {
            st = c->fc->streams[i];
            break;
        }
    }
    if (!st) {
        av_log(c->fc, AV_LOG_ERROR, "could not find corresponding track id %u\n", frag->track_id);
        return AVERROR_INVALIDDATA;
    }

The spec says moov *should* come before moof, but does not require it. So this isn't technically invalid data.  But
ffmpeg doesn't currently support moov after moof, so I figured I was safe in not supporting it in this patch.  I could
add code similar to the above AVStream checking in a few key places (which would print an error) and that would make
those "shouldn't happen" into impossible conditions where an assert would be warranted.

-- 
John      GnuPG fingerprint: D0EC B3DB C372 D1F1 0B01  83F0 49F1 D7B2 60D4 D0F7


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20171009/920a810f/attachment.sig>