[FFmpeg-devel] [RFC] avformat/mov: fixing sidx loading issues.
agrecascino123 at gmail.com
Sun Feb 3 19:33:52 EET 2019
hi, i recently posted a patch to the mailing list that came from some very
incorrect assumptions about the bmff spec. i've figured out what the actual
issue is, and it is arguably more complex to solve, and requires some more
serious changes to how sidx is loaded to fix, as such i'd like to list out
the possible "solutions" in order of hackiness, and as i don't know the
spec perfectly, i'd like to hear some thoughts on how each follows the
spec. here we go:
1. checking offset = size and that the track id is equal to last track id.
this works for both the fate test i failed early and the sample file, but
breaks if the sidx atoms are out of order by track id. it also apparently
doesn't take into account "non-indexed streams" that the spec seems to
talk about in the description for a sidx box.
2. counting the number of sidx boxes there are and seeing if that's equal
to the number of tracks * the number of moof boxes.
i initially thought that there was a way to count moof boxes, but there
probably isn't, and such there is no way to do this without reading the
entire file. this doesn't take into account non-indexed streams, and
probably breaks mpeg-ts. not a great idea.
3. the above but using the number of non-indexed streams(if there is a way
works, but probably breaks mpeg-ts. probably not good.
4. just outright counting the number of sidx boxes and making the
comparison the current sidx id to the number of sidx boxes.
i imagine this is easy to implement for mpeg-ts, but requires some parser
changes for fragmented mp4s, as we need to find the number of sidx boxes
before parsing the rest of the file. this is the least hacky solution and
would probably work in all cases, but it would probably require a little a
bit more effort.
if you have any ideas on how to do this better, feel free to scream your
heart out, as i don't really entirely know what i'm doing.
More information about the ffmpeg-devel