1089480 - YouTube permafreeze with MediaSource Extensions enabled

Status: VERIFIED FIXED

(Core :: Audio/Video, defect)

Description

[Leman Bennett [Omega]]

On my machine, this video with a timestamp in its link does not play even though the video attempts load.

Comment 1

[Leman Bennett [Omega]]

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

Comment 2

[Leman Bennett [Omega]]

Video plays without the timestamp url tacked on.

Comment 3

[cajbir (:cajbir)]

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.

Comment 4

[cajbir (:cajbir)]

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

[cajbir (:cajbir)]

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?

Comment 6

[Matt Woodrow (:mattwoodrow)]

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

Comment 7

[Matt Woodrow (:mattwoodrow)]

Attachment: Assume a start time of 0 for MSE videos

Comment 8

[Matt Woodrow (:mattwoodrow)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/ac5e69c40ff1

Comment 9

[Carsten Book [:Tomcat]]

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

Comment 10

[Matt Woodrow (:mattwoodrow)]

Attachment: Assume a start time of 0 for MSE videos v2

Sadness, it appears that the Video/AudioQueue held by the MediaDecoderReader is not the same as the queue held by MediaDecoderStateMachine.

Comment 11

[Matt Woodrow (:mattwoodrow)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/01eedb9f44d9

Comment 12

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/01eedb9f44d9

Comment 13

[Bogdan Maris, Desktop QA]

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.