Closed Bug 1128811 Opened 5 years ago Closed 5 years ago

Seeking gets stuck if MediaDecoderStateMachine is in RequestStatus::Waiting mode

Categories

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

x86_64
Windows 8.1
defect

Tracking

()

RESOLVED FIXED
mozilla38
Tracking Status
firefox36 --- unaffected
firefox37 + fixed
firefox38 --- fixed

People

(Reporter: cpearce, Assigned: bholley)

References

(Blocks 1 open bug)

Details

Attachments

(2 files)

While playing this video:
https://www.youtube.com/watch?v=qQD6kM-ScIE

I hit this error in the console:

[6624] WARNING: 'failure == prevFailure', file c:/Users/cpearce/src/mozilla/purple/dom/media/fmp4/MP4Reader.cpp, line 97
[6624] WARNING: Failed reading the same block twice: offset=478601, count=8: file c:/Users/cpearce/src/mozilla/purple/dom/media/fmp4/MP4Reader.cpp, line 99

Video also froze, and I only had audio playing back.

I had played a little bit of video, then seeked to about 3:15, and then I hit that failure.

I could not reproduce it again.
This was with a freshly updated m-c; 70cfc57476b7.
I can reliably reproduce this like so:
1. Load https://www.youtube.com/watch?v=nz74OzjwXlA
2. Seek to near the end, say 3:25 or so.
3. Play until playback reaches the end.
4. Seek to earlier in the media, say 2:45, the error will trigger, and we'll get no video playback. Seems to happen more when the seek target is unbuffered.
Priority: -- → P1
That error basically just means that the demuxer errored out because the data wasn't there. It doesn't necessarily mean that we've done something wrong, though it seems like we probably should be judiciously using GetBuffered to avoid requesting samples that we don't have. As far as I gathered, Anthony made the demuxer conservative in its reporting, so we should never error out trying to read data that GetBuffered tells us we have.

I can reproduce with the STR in comment 2. Will capture a log and have a look.
Assignee: nobody → bobbyholley
Attaching a log if the problem as reproduced by following Chris' STR.
So the error with the chinese video has to do with the fact that we don't reject data wait promises in MediaSourceReader::Seek. So the seek never completes, because the MDSM thinks it's still waiting for dataa and refuses to dispatch new sample requests.

I actually noticed this by inspection a few days ago, and had a patch to fix this already in my queue for bug 1129246. So I'm just going to transplant that patch over here.

The "Failed reading the same block twice" warning is still worth investigating at some point, but orthogonal to the concrete bug that Chris identified here.
Summary: MSE/MP4 Failed reading the same block twice → Seeking gets stuck if MediaDecoderStateMachine is in RequestStatus::Waiting mode
Attachment #8559524 - Flags: review?(cpearce)
Attachment #8559524 - Flags: review?(cpearce) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/baffa46b36fe

ni rillian for uplift.
Flags: needinfo?(giles)
https://hg.mozilla.org/mozilla-central/rev/baffa46b36fe
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla38
Comment on attachment 8559524 [details] [diff] [review]
Reject data wait promises when we seek. v1

Approval Request Comment
[Feature/regressing bug #]: MSE
[User impact if declined]: Playback stalls after seeking on YouTube.
[Describe test coverage new/current, TreeHerder]: Landed on m-c.
[Risks and why]: This affects non-MSE video playback, but is straightforward. Risk seems low at this point.
[String/UUID change made/needed]: None.
Flags: needinfo?(giles)
Attachment #8559524 - Flags: approval-mozilla-aurora?
Comment on attachment 8559524 [details] [diff] [review]
Reject data wait promises when we seek. v1

Been on m-c for 2 weeks already. Looks safe. Aurora+
Attachment #8559524 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
You need to log in before you can comment on or make changes to this bug.