989888 - Add test for SourceBuffer.buffered containing valid results before loadedmetadata fires

Status: RESOLVED FIXED

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

Description

[cajbir (:cajbir)]

With HTML 5 player enabled on YouTube when playing a video that uses DASH we block in MediaSourceReader::ReadMetadata until the entire resource is loaded.

YouTube checks 'buffered' to know when it can start playback. In our implementation 'buffered' fails in WebM if we haven't got past ReadMetadata. Since ReadMetadata is blocked, 'buffered' is always empty and video playback doesn't start.

Comment 1

[cajbir (:cajbir)]

Attachment: Fix

Remove reliance on GetBuffered needing ReadMetadata to have completed. This gets YouTube playback working for DASH videos for single stream cases.

Comment 2

[Chris Pearce [:cpearce (Not reading bugmail)]]

(In reply to cajbir (:cajbir) from comment #0)
> With HTML 5 player enabled on YouTube when playing a video that uses DASH we
> block in MediaSourceReader::ReadMetadata until the entire resource is loaded.

Separate from the issue of GetBuffered() not working before we've finished loading metadata, should we not block in MediaSourceReader::ReadMetadata until the entire resource is loaded? Or do you mean we block until the first segment is appended to the stream?


> YouTube checks 'buffered' to know when it can start playback. In our
> implementation 'buffered' fails in WebM if we haven't got past ReadMetadata.
> Since ReadMetadata is blocked, 'buffered' is always empty and video playback
> doesn't start.

It would be good to have a test for this, that also tests (or easily made to test) MP4 as well, so that we don't hit this with MP4 as well.

Comment 3

[cajbir (:cajbir)]

(In reply to Chris Pearce (:cpearce) from comment #2)
> Separate from the issue of GetBuffered() not working before we've finished
> loading metadata, should we not block in MediaSourceReader::ReadMetadata
> until the entire resource is loaded? Or do you mean we block until the first
> segment is appended to the stream?

We block in ReadMetadata until data is appended for all source buffers. In the case of youtube they have a video and an audio source. The audio source blocks for data in ReadMetadata. The youtube player is adding data to the video source and doesn't add to the audio source until it gets feedback from GetBuffered that the data was added. This doesn't happen until end of stream because of the bug.

> It would be good to have a test for this, that also tests (or easily made to
> test) MP4 as well, so that we don't hit this with MP4 as well.

Yes, it would be.

Comment 4

[Matthew Gregan [:kinetik]]

Comment on attachment 8399250 [details] [diff] [review]
Fix

Review of attachment 8399250 [details] [diff] [review]:
-----------------------------------------------------------------

Sorry about the delay getting to this.  I don't think we need this right now since YouTube have changed their MSE implementation to avoid waiting for buffered video data before appending audio streams.  Their previous behaviour was valid, but the changes coming in bug 881512 are moving to make more of the initialization asynchronous, avoiding this problem in the first place.

::: content/media/webm/WebMReader.cpp
@@ +1016,5 @@
>    MediaResource* resource = mDecoder->GetResource();
>  
>    uint64_t timecodeScale;
>    if (!mContext || nestegg_tstamp_scale(mContext, &timecodeScale) == -1) {
> +    timecodeScale = 1000000;

The thing that concerns me about this is that for any file with a non-default timecode scale (of which there probably aren't many, making this potential problem all the more obscure when it occurs) is that the reported buffered range will change in scale once mContext has been initialized.

The only way I can see around that is to teach the WebM buffered range parser to extract the timecode scale as it's parsing the incoming data.

Comment 5

[Matthew Gregan [:kinetik]]

The patches in bug 881512 should fix this by running the initialization (specifically, the ReadMetadata call) of each SourceBuffer's decoder asynchronously.  Once that completes, SourceBuffer.buffered should be reporting accurate values even before the main ReadMetadata call on the MediaSourceDecoder has completed.  Keep this bug open to use for confirmation and adding a specific testcase.

Comment 6

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

Can we close this bug?

Comment 7

[cajbir (:cajbir)]

Not unless the request in comment 5 has been completed which I don't think it has.

Comment 8

[Jean-Yves Avenard [:jya]]

This is fix with bug 1125776. Various mochitest that relies on loadedmetadata to be fired as soon as as an init segment is appended have been added too