On 10/09/2017 02:40 PM, Carl Eugen Hoyos wrote: > 2017-10-09 22:09 GMT+02:00 John Stebbins <jstebb...@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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
