Closed
Bug 1108086
Opened 10 years ago
Closed 10 years ago
MSE & H.264: Steam Live Broadcasts fails to load
Categories
(Core :: Audio/Video, defect, P5)
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.
Comment 1•10 years ago
|
||
Unable to test, credentials required.
Component: Untriaged → Video/Audio
Product: Firefox → Core
Assignee | ||
Comment 2•10 years ago
|
||
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.
Updated•10 years ago
|
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
Updated•10 years ago
|
Whiteboard: [testcase in comment 3]
Updated•10 years ago
|
Priority: -- → P5
Assignee | ||
Comment 4•10 years ago
|
||
(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 | ||
Updated•10 years ago
|
Assignee: nobody → jyavenard
Assignee | ||
Comment 5•10 years ago
|
||
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.
Assignee | ||
Comment 7•10 years ago
|
||
too bad, because we would have supported it :)
Assignee | ||
Comment 8•10 years ago
|
||
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: 10 years ago
Flags: needinfo?(tph)
Resolution: --- → WORKSFORME
Reporter | ||
Comment 9•10 years ago
|
||
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.
Reporter | ||
Comment 10•10 years ago
|
||
You need to log in
before you can comment on or make changes to this bug.
Description
•