Bug 1389304 showed that there's an issue where buffered range not matching the samples returned can cause assertions. That is due to the buffered range being calculated using all samples, be them usable or not. However, the first demuxed sample's time must match the buffered range start. A sample won't be demuxed if it has a size of 0. As such, we must ensure that if a sample has a size of 0, it is never added to the table's sample list (which is used by the mp4_demuxer::Index) Similar to the fix in bug 1389304

Jean-Yves - what is the impact/priority of this issue?

I'd say low... the fuzz team may come with content that could crash firefox though.

MP4 rust parser doesn't scan 'moof' yet but it is good if we could add this sample into our test. BTW, the problem of this sample is its 'trex' box is invalid so parser can't retrieve the default audio sample size/duration. And its 'trun' table is also empty so there is no way to know audio sample size/duration. [trex] size=12+20 track id = 41039 default sample description index = 3403808769 default sample duration = 1024 default sample size = 6 default sample flags = 0 [traf] size=8+56 [tfhd] size=12+8, flags=20020 track ID = 1 default sample flags = 2000000 [tfdt] size=12+4 base media decode time = 0 [trun] size=12+8, flags=1 sample count = 22 data offset = 17713 entry 0000 = entry 0001 = entry 0002 = entry 0003 = entry 0004 = entry 0005 = entry 0006 = entry 0007 = entry 0008 = entry 0009 = entry 0010 = entry 0011 = entry 0012 = entry 0013 = entry 0014 = entry 0015 = entry 0016 = entry 0017 = entry 0018 = entry 0019 = entry 0020 = entry 0021 =

It may not scan moof, but that's irrelevant. it scan the samples table in the moov. It's for those files this bug is about (non-fragmented)