1233639 - ended event may not always be fired

Status: NEW

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

Description

[Jean-Yves Avenard [:jya]]

Attachment: nspr.log

Spawned From bug 1229987 comment 43.

If the video track is slightly longer than the audio track, the MDSM may stop requesting video frames from the reader and never detects that it's EOS.

Causing the event to never be fired.

The log attached shows that the MDSM has requested the exact number of frames available but didn't continue to receive the EOS signal.

Comment 1

[Jean-Yves Avenard [:jya]]

the log was created by using the MediaFormatReader:5 NSPR_MODULES_LOG.

The right timing condition was created by delaying audio decoding (using mediasource and only feeding some audio) and letting it play until the waiting event is fired.

We then add a little bit more video and end the mediasource.

ended event should always fire per spec

Comment 2

[JW Wang [:jwwang] [:jw_wang]]

It would be nice to have a test case to repro the problem.

Comment 3

[Jean-Yves Avenard [:jya]]

(In reply to JW Wang [:jwwang] from comment #2)
> It would be nice to have a test case to repro the problem.

once bug 1229987 land, dom/media/mediasource/test/test_WaitingToEndedTransition_mp4.html will cause about 25% failure rate on win7 debug.

unfortunately, it's all timing related, and I've never been able to reproduce the problem locally.

What I can reproduce often however is that the waiting event is not always fired when you would expect it to (which is at worse the start time of the last audio frame). Yet I see waiting event sometimes fired 65ms earlier.

Comment 4

[Jean-Yves Avenard [:jya]]

here is one run.
https://treeherder.mozilla.org/#/jobs?repo=try&revision=cafb2714a9a3

win8 debug run was 76% failure rate, however I only re-ran the try 5 times ... 
https://treeherder.mozilla.org/#/jobs?repo=try&revision=e2b7518507ae

Comment 5

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

Mass change P2 -> P3