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.
Attachment #8699847 - Attachment mime type: text/x-log → text/html
Summary: ended event may not always fire → ended event may not always be fired
Attachment #8699847 - Attachment mime type: text/html → text/plain
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
It would be nice to have a test case to repro the problem.
(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.
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
Mass change P2 -> P3
Priority: P2 → P3
You need to log in before you can comment on or make changes to this bug.