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 to tell) 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. thanks. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel