1911008 - Assertion failure: (track[i - 1]->mTrackInfo->GetID() == track[i]->mTrackInfo->GetID() && track[i - 1]->mTimecode <= track[i]->mTimecode) || track[i]->mKeyframe, at /builds/worker/checkouts/gecko/dom/media/mediasource/TrackBuffersManager.cpp:1818

Status: NEW

(Core :: Audio/Video: Playback, defect)

Description

[Tyson Smith [:tsmith]]

Found with m-c 20240608-3d3c5f739ff3 (--enable-debug --enable-fuzzing)

This was found by visiting a live website with a debug build.

STR:

• Launch browser and visit site

This issue was triggered by visiting http://oneangrygamer.net/.

A Pernosco session is available here: https://pernos.co/debug/E5qan1hh9ASicEbmkFP4CA/index.html

Assertion failure: (track[i - 1]->mTrackInfo->GetID() == track[i]->mTrackInfo->GetID() && track[i - 1]->mTimecode <= track[i]->mTimecode) || track[i]->mKeyframe, at /builds/worker/checkouts/gecko/dom/media/mediasource/TrackBuffersManager.cpp:1818

#0 0x7fa18187ece2 in mozilla::TrackBuffersManager::CompleteCodedFrameProcessing() /builds/worker/checkouts/gecko/dom/media/mediasource/TrackBuffersManager.cpp:1815:7
#1 0x7fa18187fd5d in mozilla::TrackBuffersManager::OnVideoDemuxCompleted(RefPtr<mozilla::MediaTrackDemuxer::SamplesHolder> const&) /builds/worker/checkouts/gecko/dom/media/mediasource/TrackBuffersManager.cpp:1746:3
#2 0x7fa18189dc11 in InvokeMethod<mozilla::TrackBuffersManager, void (mozilla::TrackBuffersManager::*)(const mozilla::MediaResult &), const mozilla::MediaResult &> /builds/worker/workspace/obj-build/dist/include/mozilla/MozPromise.h
#3 0x7fa18189dc11 in InvokeCallbackMethod<false, mozilla::TrackBuffersManager, void (mozilla::TrackBuffersManager::*)(const mozilla::MediaResult &), const mozilla::MediaResult &, RefPtr<mozilla::MozPromise<mozilla::MediaResult, mozilla::MediaResult, false>::Private> > /builds/worker/workspace/obj-build/dist/include/mozilla/MozPromise.h:683:5
#4 0x7fa18189dc11 in mozilla::MozPromise<RefPtr<mozilla::MediaTrackDemuxer::SamplesHolder>, mozilla::MediaResult, true>::ThenValue<mozilla::TrackBuffersManager*, void (mozilla::TrackBuffersManager::*)(RefPtr<mozilla::MediaTrackDemuxer::SamplesHolder> const&), void (mozilla::TrackBuffersManager::*)(mozilla::MediaResult const&)>::DoResolveOrRejectInternal(mozilla::MozPromise<RefPtr<mozilla::MediaTrackDemuxer::SamplesHolder>, mozilla::MediaResult, true>::ResolveOrRejectValue&) /builds/worker/workspace/obj-build/dist/include/mozilla/MozPromise.h
#5 0x7fa181354eb5 in mozilla::MozPromise<RefPtr<mozilla::MediaTrackDemuxer::SamplesHolder>, mozilla::MediaResult, true>::ThenValueBase::ResolveOrRejectRunnable::Run() /builds/worker/workspace/obj-build/dist/include/mozilla/MozPromise.h:488:21
#6 0x7fa17d9d7028 in mozilla::TaskQueue::Runner::Run() /builds/worker/checkouts/gecko/xpcom/threads/TaskQueue.cpp:257:20
#7 0x7fa17d9fff28 in nsThreadPool::Run() /builds/worker/checkouts/gecko/xpcom/threads/nsThreadPool.cpp:456:14
#8 0x7fa17d9f644c in nsThread::ProcessNextEvent(bool, bool*) /builds/worker/checkouts/gecko/xpcom/threads/nsThread.cpp:1198:16
#9 0x7fa17d9fcfbf in NS_ProcessNextEvent(nsIThread*, bool) /builds/worker/checkouts/gecko/xpcom/threads/nsThreadUtils.cpp:480:10
#10 0x7fa17e558ebc in mozilla::ipc::MessagePumpForNonMainThreads::Run(base::MessagePump::Delegate*) /builds/worker/checkouts/gecko/ipc/glue/MessagePump.cpp:300:20
#11 0x7fa17e4aea71 in RunHandler /builds/worker/checkouts/gecko/ipc/chromium/src/base/message_loop.cc:363:3
#12 0x7fa17e4aea71 in MessageLoop::Run() /builds/worker/checkouts/gecko/ipc/chromium/src/base/message_loop.cc:345:3

Comment 1

[Paul Adenot (:padenot)]

Karl, maybe related to the inconsistencies you looked into the other day?

Comment 2

[Karl Tomlinson (:karlt)]

Yes, thanks. I'm keen to take a look to see exactly how this is happening.

Comment 3

[Karl Tomlinson (:karlt)]

This is the same a similar situation as to bug 1909750.

When the new sample interval does not overlap any existing sample start time, no overlapping frames are removed and so no dependent frames are removed, which is consistent with the corresponding Coded Frame Processing steps.

Not even dependencies of truncated overlapping frames are removed.

CheckNextInsertionIndex() might be assuming that the truncation should have introduced a gap in mBufferedRanges, but that did not happen due to bug 1909750.

In this case, there is a gap in mBufferedRanges between a key frame and some of its dependent frames, small and presumably due to rounding of timestamps and durations. The insertion index is set to correspond to this gap, so the inserted frame separates dependent frames from their keyframe, which the failing assertion was asserting would not happen.

I don't know whether the new frame should be inserted in decode timestamp order, separating dependent frames from their keyframe, or before the next keyframe so that dependent frames are adjacent to their keyframe.

Or perhaps there is a bug in the spec and dependent frames of truncated frames should be removed, which was my expectation before reading the spec.

Comment 4

[Karl Tomlinson (:karlt)]

Unlike bug 1909750, there is a frame with a start time that would be contained in the new frame's interval, but that is not found because the frames are not in presentation order and so the loop exits before the reaching it assuming that it will be removed, but it is not removed because firstRemovedIndex is not set.

Comment 5

[Karl Tomlinson (:karlt)]

https://treeherder.mozilla.org/jobs?repo=try&revision=f3dc9b7e7f86c92fb9b096a2748b1218c7bbf406