1192517 - Webm mediasource mochitest timing out when using incomplete media segment

Status: RESOLVED DUPLICATE of bug 1195073

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

Description

[Jean-Yves Avenard [:jya]]

From https://bugzilla.mozilla.org/show_bug.cgi?id=1182946#c31

I don't believe it should make a difference in the tests. 

It should be investigated as it may be reflecting an actual problem.

Comment 1

[Jan Gerber]

Attachment: Bug-1192517-Set-MediaSegmentRange-to-decodable-range.patch

Looks like something was wrong indeed. While the bug did not fail,
the video was not playable after ms.endOfStream().
Possibly we should also check that after 'sourceended' the video is seekable.
Here an extended test: http://r-w-x.org/tests/test_SeekableAfterEndOfStreamSplit.html

In any case, this can be fixed by returning all available frames in ParseStartAndEndTimestamps.

Comment 2

[Jean-Yves Avenard [:jya]]

Comment on attachment 8647981 [details] [diff] [review]
Bug-1192517-Set-MediaSegmentRange-to-decodable-range.patch

Review of attachment 8647981 [details] [diff] [review]:
-----------------------------------------------------------------

302 to kinetik as I have no idea what this would do now

Comment 3

[Matthew Gregan [:kinetik]]

Comment on attachment 8647981 [details] [diff] [review]
Bug-1192517-Set-MediaSegmentRange-to-decodable-range.patch

Review of attachment 8647981 [details] [diff] [review]:
-----------------------------------------------------------------

r+ with comment

::: dom/media/mediasource/ContainerParser.cpp
@@ +250,5 @@
>        segmentEndIdx -= 1;
>      }
> +    if (segmentEndIdx > 0 && mOffset < mapping[segmentEndIdx].mEndOffset) {
> +      segmentEndIdx -= 1;
> +    }

It seems like this needs to walk back like the endIdx loop below does?

Comment 4

[Jan Gerber]

Attachment: Bug-1192517-Set-MediaSegmentRange-to-decodable-range.patch

(In reply to Matthew Gregan [:kinetik] from comment #3)
> Comment on attachment 8647981 [details] [diff] [review]
> Bug-1192517-Set-MediaSegmentRange-to-decodable-range.patch
> 
> Review of attachment 8647981 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> r+ with comment
> 
> ::: dom/media/mediasource/ContainerParser.cpp
> @@ +250,5 @@
> >        segmentEndIdx -= 1;
> >      }
> > +    if (segmentEndIdx > 0 && mOffset < mapping[segmentEndIdx].mEndOffset) {
> > +      segmentEndIdx -= 1;
> > +    }
> 
> It seems like this needs to walk back like the endIdx loop below does?

endIdx spanns the entire buffer (possibly multiple clusters)
while segmentEndIdx is only the first cluster in the buffer.
looking at it again, it looks more correct to combine the two
and also only return the duration of the first cluster.

Comment 5

[Jan Gerber]

Attachment: Bug-1192517-Set-MediaSegmentRange-to-decodable-range.patch

Found 2 issues with the previous patch, while testing with Opus:

- WebM Opus files can also include a BlockGroup, allow that that.
- One mapping is enough for MediaRange, remove endIdx > 0 check

Comment 6

[Jean-Yves Avenard [:jya]]

sounds like fixing the opus issue would make bug 1195073 a duplicate

Comment 7

[Jean-Yves Avenard [:jya]]

with this new version of the patch, the test case in bug 1195073 will always cause an assert due to a duration of -169001000 being found in one of the sample.

Now it seems that it's now attempting to demux the sample of the partial media segment, but exposes another problem elsewhere

here is the backtrace:
1285521408[12dab14d0]: TrackBuffersManager(1182d7000:audio/webm)::ProcessFrames: Processing audio/ogg; codecs=opus frame(pts:169001000 end:0, dts:169001000, duration:-169001000, kf:1)
Assertion failure: aStart <= aEnd, at /Users/jyavenard/Work/Mozilla/mozilla-central/dom/media/Intervals.h:56
#01: mozilla::media::Interval<mozilla::media::TimeUnit>::Interval<mozilla::media::TimeUnit, mozilla::media::TimeUnit>(mozilla::media::TimeUnit&&, mozilla::media::TimeUnit&&)[/Users/jyavenard/Work/Mozilla/mozilla-central/obj-ff-dbg/dist/NightlyDebug.app/Contents/MacOS/XUL +0x333b081]
#02: mozilla::media::Interval<mozilla::media::TimeUnit>::Interval<mozilla::media::TimeUnit, mozilla::media::TimeUnit>(mozilla::media::TimeUnit&&, mozilla::media::TimeUnit&&)[/Users/jyavenard/Work/Mozilla/mozilla-central/obj-ff-dbg/dist/NightlyDebug.app/Contents/MacOS/XUL +0x3293f05]
#03: mozilla::TrackBuffersManager::ProcessFrames(nsTArray<nsRefPtr<mozilla::MediaRawData> >&, mozilla::TrackBuffersManager::TrackData&)[/Users/jyavenard/Work/Mozilla/mozilla-central/obj-ff-dbg/dist/NightlyDebug.app/Contents/MacOS/XUL +0x34268e8]
#04: mozilla::TrackBuffersManager::CompleteCodedFrameProcessing()[/Users/jyavenard/Work/Mozilla/mozilla-central/obj-ff-dbg/dist/NightlyDebug.app/Contents/MacOS/XUL +0x3425d8f]
#05: mozilla::TrackBuffersManager::OnAudioDemuxCompleted(nsRefPtr<mozilla::MediaTrackDemuxer::SamplesHolder>)[/Users/jyavenard/Work/Mozilla/mozilla-central/obj-ff-dbg/dist/NightlyDebug.app/Contents/MacOS/XUL +0x3426451]
#06: mozilla::EnableIf<(ReturnTypeIs<void (mozilla::TrackBuffersManager::*)(nsRefPtr<mozilla::MediaTrackDemuxer::SamplesHolder>), void>::value) && (TakesArgument<void (mozilla::TrackBuffersManager::*)(nsRefPtr<mozilla::MediaTrackDemuxer::SamplesHolder>)>::valu[/Users/jyavenard/Work/Mozilla/mozilla-central/obj-ff-dbg/dist/NightlyDebug.app/Contents/MacOS/XUL +0x3436ae6]
#07: mozilla::MozPromise<nsRefPtr<mozilla::MediaTrackDemuxer::SamplesHolder>, mozilla::DemuxerFailureReason, true>::MethodThenValue<mozilla::TrackBuffersManager, void (mozilla::TrackBuffersManager::*)(nsRefPtr<mozilla::MediaTrackDemuxer::SamplesHolder>), void [/Users/jyavenard/Work/Mozilla/mozilla-central/obj-ff-dbg/dist/NightlyDebug.app/Contents/MacOS/XUL +0x343692f]
#08: mozilla::MozPromise<nsRefPtr<mozilla::MediaTrackDemuxer::SamplesHolder>, mozilla::DemuxerFailureReason, true>::ThenValueBase::DoResolveOrReject(mozilla::MozPromise<nsRefPtr<mozilla::MediaTrackDemuxer::SamplesHolder>, mozilla::DemuxerFailureReason, true>::[/Users/jyavenard/Work/Mozilla/mozilla-central/obj-ff-dbg/dist/NightlyDebug.app/Contents/MacOS/XUL +0x32cf4b6]
#09: mozilla::MozPromise<nsRefPtr<mozilla::MediaTrackDemuxer::SamplesHolder>, mozilla::DemuxerFailureReason, true>::ThenValueBase::ResolveOrRejectRunnable::Run()[/Users/jyavenard/Work/Mozilla/mozilla-central/obj-ff-dbg/dist/NightlyDebug.app/Contents/MacOS/XUL +0x32cf19c]
#10: mozilla::AutoTaskDispatcher::TaskGroupRunnable::Run()[/Users/jyavenard/Work/Mozilla/mozilla-central/obj-ff-dbg/dist/NightlyDebug.app/Contents/MacOS/XUL +0x1bb0c9]
#11: mozilla::TaskQueue::Runner::Run()[/Users/jyavenard/Work/Mozilla/mozilla-central/obj-ff-dbg/dist/NightlyDebug.app/Contents/MacOS/XUL +0x19185f]
#12: nsThreadPool::Run()[/Users/jyavenard/Work/Mozilla/mozilla-central/obj-ff-dbg/dist/NightlyDebug.app/Contents/MacOS/XUL +0x19d598]
#13: non-virtual thunk to nsThreadPool::Run()[/Users/jyavenard/Work/Mozilla/mozilla-central/obj-ff-dbg/dist/NightlyDebug.app/Contents/MacOS/XUL +0x19d69c]
#14: nsThread::ProcessNextEvent(bool, bool*)[/Users/jyavenard/Work/Mozilla/mozilla-central/obj-ff-dbg/dist/NightlyDebug.app/Contents/MacOS/XUL +0x199f6b]
#15: NS_ProcessNextEvent(nsIThread*, bool)[/Users/jyavenard/Work/Mozilla/mozilla-central/obj-ff-dbg/dist/NightlyDebug.app/Contents/MacOS/XUL +0x218ee7]
#16: mozilla::ipc::MessagePumpForNonMainThreads::Run(base::MessagePump::Delegate*)[/Users/jyavenard/Work/Mozilla/mozilla-central/obj-ff-dbg/dist/NightlyDebug.app/Contents/MacOS/XUL +0x8756e0]
#17: MessageLoop::RunInternal()[/Users/jyavenard/Work/Mozilla/mozilla-central/obj-ff-dbg/dist/NightlyDebug.app/Contents/MacOS/XUL +0x7e1895]
#18: MessageLoop::RunHandler()[/Users/jyavenard/Work/Mozilla/mozilla-central/obj-ff-dbg/dist/NightlyDebug.app/Contents/MacOS/XUL +0x7e17a5]
#19: MessageLoop::Run()[/Users/jyavenard/Work/Mozilla/mozilla-central/obj-ff-dbg/dist/NightlyDebug.app/Contents/MacOS/XUL +0x7e174d]
#20: nsThread::ThreadFunc(void*)[/Users/jyavenard/Work/Mozilla/mozilla-central/obj-ff-dbg/dist/NightlyDebug.app/Contents/MacOS/XUL +0x198359]
#21: _pt_root[/Users/jyavenard/Work/Mozilla/mozilla-central/obj-ff-dbg/dist/NightlyDebug.app/Contents/MacOS/libnss3.dylib +0x377241]
#22: _pthread_body[/usr/lib/system/libsystem_pthread.dylib +0x3268]
#23: _pthread_body[/usr/lib/system/libsystem_pthread.dylib +0x31e5]

Comment 8

[Jean-Yves Avenard [:jya]]

oh I see what's going on.

The webm demuxer calculate the end time of a media segment by looking at the start time of the next one.

Here, the segments are out of order, so it should be handled in the same fashion as when hitting EOS.

Comment 9

[Jean-Yves Avenard [:jya]]

trying to fix bug 1195073 in an acceptable fashion, I added detection to discontinuity in the TrackBuffersManager by looking at the start and end value returned by the ContainerParser::ParseStartAndEndTimestamps

and it outputs completely rubbish data:
First append:

WebMContainerParser(138754510:audio/webm)::ParseStartAndEndTimestamps: [80001000, 82981000] [fso=272, leo=65768, l=150 endIdx=148]
then:
ParseStartAndEndTimestamps: [5203316792000, 5203320072000] [fso=4414321849, leo=65825, l=165 endIdx=163]

WebMContainerParser(13ab3efb0:audio/webm)::ParseStartAndEndTimestamps: [5078662428000, 5078662468000] [fso=4414321849, leo=1455, l=3 endIdx=1]

WebMContainerParser(117362e30:audio/webm)::ParseStartAndEndTimestamps: [5202787672000, 5202789652000] [fso=4414321849, leo=40789, l=100 endIdx=98]

this goes on for a while and then it returns the next lot:
WebMContainerParser(10035c070:audio/webm)::ParseStartAndEndTimestamps: [90001000, 92641000] [fso=272, leo=55074, l=133 endIdx=131]

a new ContainerParser is created whenever a media segment is parsed.

Comment 10

[Jean-Yves Avenard [:jya]]

I've reworked the ContainerParser. Will post shortly.

Comment 11

[Jean-Yves Avenard [:jya]]

Comment on attachment 8648765 [details] [diff] [review]
Bug-1192517-Set-MediaSegmentRange-to-decodable-range.patch

Review of attachment 8648765 [details] [diff] [review]:
-----------------------------------------------------------------

This is the wrong approach ; turned out, it's cluster we need to identify . not blocks.

Comment 13

[Jean-Yves Avenard [:jya]]

Putting all under the same umbrella bug; as it will make uplift easier should we want to enable MSE on linux in 42.

And as bug 1195073 contains more information.