Bugzilla

Think I've figured out this one. This is caused by our clamping of end time to the duration[0]. However, we don't clamp the start time. So we can get into a state where oddly formed files will cause the algorithm to end up with a start time and end time greater than our duration. Then we only clamp the end time such that end < start and we then create an invalid interval.

This looks to be caused by the final cluster in the block having a timecode that is inconsistent with other timecodes and number of frames (it jumps ahead by an hour from what you'd expect given previous clusters).

I think we should handle this as in the current malformed cases by skipping the malformed interval. We could try and clamp the interval back into valid ranges, but I don't know if it's worth the time for busted files.

Fix incoming.

https://searchfox.org/mozilla-central/rev/be413c29deeb86be6cdac22445e0d0b035cb9e04/dom/media/webm/WebMDemuxer.cpp#978

Think I've figured out this one. This is caused by our clamping of end time to the duration[0]. However, we don't clamp the start time. So we can get into a state where oddly formed files will cause the algorithm to end up with a start time and end time greater than our duration. Then we only clamp the end time such that end < start and we then create an invalid interval.

This looks to be caused by the final cluster in the block having a timecode that is inconsistent with other timecodes and number of frames (it jumps ahead by an hour from what you'd expect given previous clusters).

I think we should handle this as in the current malformed cases by skipping the malformed interval. We could try and clamp the interval back into valid ranges, but I don't know if it's worth the time for busted files.

Fix incoming.

[0] https://searchfox.org/mozilla-central/rev/be413c29deeb86be6cdac22445e0d0b035cb9e04/dom/media/webm/WebMDemuxer.cpp#978