Closed Bug 1108086 Opened 6 years ago Closed 5 years ago

MSE & H.264: Steam Live Broadcasts fails to load

Categories

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

37 Branch
x86_64
Windows 7
defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: tph, Assigned: jya)

References

(Blocks 1 open bug)

Details

(Keywords: testcase, Whiteboard: [testcase in comment 3])

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0
Build ID: 20141205030202

Steps to reproduce:

1. Download the Firefox nightly.
2. Go to https://www.youtube.com/html5 to verify that support for all codecs is enabled, specifically "MSE & H.264".
3. Go to http://steamcommunity.com/?subsection=broadcasts and click on any broadcast.


Actual results:

None of the broadcasts is loading.


Expected results:

The stream should start.
Unable to test, credentials required.
Component: Untriaged → Video/Audio
Product: Firefox → Core
Blocks: MSE
Please provide an actual link to a video where you have the problem.

AFAICT, broadcasts are using flash and all links to YouTube's MSE are working fine for me.
Flags: needinfo?(tph)
I created a test case for the Steam Live Broadcast that reproduces a couple issues that prevent the video from playing correctly (since the segments expire fairly quickly from Akamai's network):

https://dl.dropboxusercontent.com/u/759758/steamvideo/test.html
https://dl.dropboxusercontent.com/u/759758/steamvideo/steamvideo.zip (downloadable version)

I have MSE & H.264 through WMF. This test works correctly in Chrome but not Firefox. There are two Chrome-specific implementation details that cause it to fail in FF:

1. Chrome's 'buffered' TimeRanges are normalized into one time range of all segments. Firefox shows one time range per segment. This causes the Steam player to believe it never has enough video data buffered to begin playback. MSE spec says TimeRanges should be normalized, but time values are strange in FF.

2. Chrome will play the video as segments are parsed in, while Firefox will not play the video until endOfStream is called. Steam's player will not call endOfStream as it is a live broadcast. The test I've posted will call endOfStream, but removing that line will cause the video not to play.

3. Also of note, Chrome's Media element reports a duration of Infinity (correct according to spec) while Firefox reports a duration of 0.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(tph)
Keywords: testcase
Summary: MSE & H.264 support doesn't seem to work properly. → MSE & H.264: Steam Live Broadcasts fails to load
Whiteboard: [testcase in comment 3]
Depends on: 1118123
Priority: -- → P5
Depends on: 1118533
(In reply to azuisleet from comment #3)
> I created a test case for the Steam Live Broadcast that reproduces a couple
> issues that prevent the video from playing correctly (since the segments
> expire fairly quickly from Akamai's network):
> 
> https://dl.dropboxusercontent.com/u/759758/steamvideo/test.html
> https://dl.dropboxusercontent.com/u/759758/steamvideo/steamvideo.zip
> (downloadable version)
> 
> I have MSE & H.264 through WMF. This test works correctly in Chrome but not
> Firefox. There are two Chrome-specific implementation details that cause it
> to fail in FF:
> 
> 1. Chrome's 'buffered' TimeRanges are normalized into one time range of all
> segments. Firefox shows one time range per segment. This causes the Steam
> player to believe it never has enough video data buffered to begin playback.
> MSE spec says TimeRanges should be normalized, but time values are strange
> in FF.

Actually, the issue is different.
the MP4 stream contains combined audio and video, which we do not support at this stage.
This cause appendBuffer to do the wrong thing here
> 
> 2. Chrome will play the video as segments are parsed in, while Firefox will
> not play the video until endOfStream is called. Steam's player will not call
> endOfStream as it is a live broadcast. The test I've posted will call
> endOfStream, but removing that line will cause the video not to play.

this will be fixed with bug 1118123. Duration of the video element nor the mediasource were updated until endOfStream was called. As the steam player waits for the duration to be > 5s; it was waiting forever.

> 
> 3. Also of note, Chrome's Media element reports a duration of Infinity
> (correct according to spec) while Firefox reports a duration of 0.

this is what is contained in the init segment...
Assignee: nobody → jyavenard
With our new MSE stack I have both sample code working nicely.
But the steam web site itself, playback doesn't start

Data is being appended and buffered just fine and accumulate as you would expect:
SourceBuffer(133f80900:video/mp4)::GetBuffered: ranges=[(20241.127000, 20280.102000)]

here we have 39s worth of data, does the web site, like your example check that there's more than 5s of data prior calling play ?
Flags: needinfo?(tph)
I checked a handful of broadcasts with the latest Nightly and all streams appear to work correctly both video and audio. I am seeing the correct buffered ranges as you reported.

The website does still indeed have the logic for checking if there are 5ms of data loaded. Interestingly, they actually split the audio and video buffers, so the original example is no longer representative of Steam Broadcasts.
too bad, because we would have supported it :)
Depends on: 1176494
Now that Steams has split its audio and video into two sourcebuffer, it now works fine using the old MSE code.

Should it ever go back to using a single sourcebuffer for both audio&video, it should work with the new MSE.

closing as WORKSFORME. maybe it should be added to the whitelist
Status: NEW → RESOLVED
Closed: 5 years ago
Flags: needinfo?(tph)
Resolution: --- → WORKSFORME
So Firefox 40 is out but Steam still isn't in the whitelist? Have to set media.mediasource.whitelist to false to be able to view broadcasts.
You need to log in before you can comment on or make changes to this bug.