YouTube permafreeze with MediaSource Extensions enabled

VERIFIED FIXED in Firefox 36

Status

()

VERIFIED FIXED
5 years ago
4 years ago

People

(Reporter: lh.bennett, Assigned: mattwoodrow)

Tracking

Trunk
mozilla36
x86
Windows 8.1
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox36 verified)

Details

(URL)

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

5 years ago
On my machine, this video with a timestamp in its link does not play even though the video attempts load.
(Reporter)

Comment 1

5 years ago
Error Console reports:

Media resource mediasource:https://www.youtube.com/80753176-fb4d-415e-96db-f141f9ec3875 could not be decoded. watch
Use of getAttributeNode() is deprecated. Use getAttribute() instead. html5player.js:36
Blocks: 1083588
(Reporter)

Comment 2

5 years ago
Video plays without the timestamp url tacked on.

Comment 3

5 years ago
Thanks for the report. The element is blocked in the seek request waiting for buffers with a time of 70.042000. The two buffers contained in the file top out at 70.008 and 70.003:

-1891649792[7fde7fa67e40]: MediaSourceReader(7fde7ee43400)::WaitForTimeRange(70042000) waiting
-1287424128[7fdeb21455c0]: SourceBuffer(7fde7ec92aa0)::GetBuffered ranges=[(35.035000, 70.003000)]
-1287424128[7fdeb21455c0]: MediaSource(7fde7ee13c10)::DurationChange(aNewDuration=70.008000 fuzz=0.001000)
-1287424128[7fdeb21455c0]: MediaSource(7fde7ee13c10) Dispatch event 'sourceended'
-1287424128[7fdeb21455c0]: SourceBuffer(7fde7ec92a10)::GetBuffered ranges=[(30.042000, 70.008000)]
-1287424128[7fdeb21455c0]: SourceBuffer(7fde7ec92aa0)::GetBuffered ranges=[(35.035000, 70.003000)]

I don't know why it's waiting for a time range of 70 vs the 40 we've requested to seek to from the time in the URL. Perhaps the bug lies there.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 4

5 years ago
The call the the reader's seek method shows it has a start time:

-1891649792[7fde7fa67e40]: MediaSourceReader(7fde7ee43400)::Seek(aTime=70042000, aStart=30042000, aEnd=100047000, aCurrent=30042000)

Note that aTime-aStart is actually the time we want to seek to. This is what the Seek call looks like on the same video but manually seeked instead of using the URL parameter:

524662528[7f75150d9da0]: MediaSourceReader(7f75101e9800)::Seek(aTime=40471640, aStart=0, aEnd=70005000, aCurrent=1401020)

Comment 5

5 years ago
This is what the WebMReader seek method gets when in a non-mse enabled firefox:

WebMReader::Seek(aTarget=40000000 aStartTime=0 aEndTime=70087000 aCurrentTime=0

I wonder why MSE gets different values?

Updated

5 years ago
Assignee: nobody → matt.woodrow
(Assignee)

Comment 6

5 years ago
This happens because we compute the start time of the video (and the origin of the media timeline) as the time of the first frame provided to use by the media resource (see https://html.spec.whatwg.org/multipage/embedded-content.html#media-timeline).

We then treat seek times as being relative to this start time/media timeline origin.

In this case the true start time of the video is at 0 seconds, but with the timestamp provided the first frame we receive is at 30 seconds so we assume this is the start. Seeking to 40 seconds then gets adjusted to 70 seconds, and we try seek to a position past the end of the video.

It looks like chrome/blink always uses a start time of 0 when working with MSE to avoid this problem.

They create a ChunkDemuxer when working with a MediaSource: https://code.google.com/p/chromium/codesearch#chromium/src/media/blink/webmediaplayer_impl.cc&sq=package:chromium&type=cs&rcl=1414389207&l=893

and ChunkDemuxer::GetStartTime always returns 0: https://code.google.com/p/chromium/codesearch#chromium/src/media/filters/chunk_demuxer.cc&sq=package:chromium&type=cs&rcl=1414389207&l=1151
(Assignee)

Comment 7

5 years ago
Attachment #8512381 - Flags: review?(cajbir.bugzilla)

Updated

5 years ago
Attachment #8512381 - Flags: review?(cajbir.bugzilla) → review+
sorry Matt, had to back this out for test m-2 bustage on Linux, Windows like https://treeherder.mozilla.org/ui/logviewer.html#?job_id=3345868&repo=mozilla-inbound
(Assignee)

Comment 10

5 years ago
Sadness, it appears that the Video/AudioQueue held by the MediaDecoderReader is not the same as the queue held by MediaDecoderStateMachine.
Attachment #8512381 - Attachment is obsolete: true
Attachment #8512956 - Flags: review?(cajbir.bugzilla)

Updated

5 years ago
Attachment #8512956 - Flags: review?(cajbir.bugzilla) → review+
https://hg.mozilla.org/mozilla-central/rev/01eedb9f44d9
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla36
Reproduced the initial issue on a old Nightly build from 2014-10-27, verified that the issue is fixed on Windows 7 64bit, Mac OS X 10.9.5 and Ubuntu 14.04 32bit using Firefox 36 beta 4.
Status: RESOLVED → VERIFIED
status-firefox36: --- → verified
You need to log in before you can comment on or make changes to this bug.