> But if the ID isn't coming from a tkhd (either because none exits, or because you have truns before the tkhd appears), perhaps we can consider invalid.
Taking a closer look at the spec, I think it actually _is valid_ to have truns before tkhd. They "strongly recommend" that the header boxes like tkhd be placed first, but its not a "must". No clue how often ffmpeg encounters such a file, but today's defaulting of id = the number of streams probably facilitates playback in such cases because the probability of tkhd's track id matching that default is reasonably high. Still, I'll take a stab at the approach, if just for discussion/testing. On Thu, Dec 13, 2018 at 12:39 PM Chris Cunningham <chcunning...@chromium.org> wrote: > "st->id" is not necessary for demuxing AFAIK, please correct me if Im >> wrong. >> Would an init value to -1 for st->id work ? >> > > st->id does get used here and there. For ex, mov_read_trun reads the id to > decide which stream corresponds to the current fragment. But if the ID > isn't coming from a tkhd (either because none exits, or because you have > truns before the tkhd appears), perhaps we can consider invalid. Using a > value of -1 would make that easier to detect. It risks breaking some bad > files, but I'm fine with that if you'd support it. I'll send a new patch > and we can see if Michael finds new breaks. > > Chris > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
