Closed
Bug 1267036
Opened 8 years ago
Closed 8 years ago
firefox not running automatically a webradio if player it's in HTML5
Categories
(Core :: Audio/Video: Playback, defect)
Tracking
()
RESOLVED
FIXED
mozilla49
People
(Reporter: echosmart792, Assigned: jya, NeedInfo)
References
(Depends on 1 open bug, )
Details
(Keywords: regression)
Attachments
(1 file)
58 bytes,
text/x-review-board-request
|
jwwang
:
review+
ritu
:
approval-mozilla-aurora+
ritu
:
approval-mozilla-beta+
lizzard
:
approval-mozilla-esr45+
|
Details |
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.86 Safari/537.36 Steps to reproduce: this is my page: http://echoradio.net16.net/html5/index.html Firefox not running automatically HTML5 radio players. In Google Chrome autoplay running excelent. Actual results: This is the script: <audio controls autoplay="autoplay"><source src="http://79.172.194.189:4040/live.mp3/" type="audio/mp3">Your browser does not support the audio element.</audio> In Chrome autoplay running ok, but in Firefox autoplay not running only manual play.
Comment 1•8 years ago
|
||
regression window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=e8cc99a3321cd07d081ac501dd0dbf4c4d933061&tochange=b493cde48ac0fefdb6808abf8ed3745f27f22c57 suspect: Bug 1229256
Blocks: 1229256
Status: UNCONFIRMED → NEW
status-firefox45:
--- → wontfix
status-firefox46:
--- → wontfix
status-firefox47:
--- → affected
status-firefox48:
--- → affected
status-firefox-esr38:
--- → unaffected
status-firefox-esr45:
--- → affected
Component: Untriaged → Audio/Video: Playback
Ever confirmed: true
Flags: needinfo?(jyavenard)
Keywords: regression
Assignee | ||
Comment 2•8 years ago
|
||
Weird. JW, this stream (which I mirrored there to show more useful information) will not typically start ; if I start debugging however it will play fine. There appear to be a race at which HTMLMediaElement::UpdateReadyStateInternal is actually called MediaDecoder::CanPlayThrough() will return, if debugging, true. The most relevant part of this stream is that: 1- duration is infinity 2- media resource length isn't defined. HTMLMediaElement::UpdateReadyStateInternal doesn't appear to be called again Eugene, likely relevant, MP3TrackDemuxer::GetBuffered() will always return an empty interval because the duration is reported as being -1, so it can't calculate the buffered range. This is likely why HTMLMediaElement::UpdateReadyStateInternal isn't called again as the buffered range doesn't change over time. So my guess is that, HTMLMediaElement::UpdateReadyStateInternal can be called when the MediaResource has detected the download rate to be stable; as the MediaResource length is < 0 and mDownloadRateReliable is true, MediaDecoder::CanPlayThrough() will return true and media playback. However, if this test fail, the next opportunity to have HTMLMediaElement::UpdateReadyStateInternal be called again would be dependent on the buffered range to change, but as MP3Demuxer::GetBuffered() always returns an empty range (and as such never change over time), UpdateReadyStateInternal isn't called again. Now, even if MP3 duration wasn't -1, we still have the issue that GetEstimatedBufferedTimeRanges() requires a known length to work. JW, should the duration be infinite and MediaResource::GetLength() return -1, shouldn't we have a mechanism to force calling HTMLMediaElement::UpdateReadyStateInternal even if the buffered range didn't change? like maybe upon element.progress being fired?
Flags: needinfo?(jwwang)
Flags: needinfo?(esawin)
Assignee | ||
Comment 3•8 years ago
|
||
It's likely this commit that caused the regression: https://hg.mozilla.org/integration/mozilla-inbound/rev/1148f6a8b576 This would call UpdateReadyState(); every time NotifyDataArrived was called. getting around the issue shown above. So I see two ways to fix this, and IMHO, both should be done: - Have UpdateReadyState(); be called when progress is fired (as it doesn't happen as often as NotifyDataArrived) - Have MP3Demuxer::GetBuffered() properly calculate a buffered range : if it doesn't have a duration, nor know the length of the resource ; it still knows how many frames it has seen so far. that enough should be sufficient to calculate a simplistic buffered range.
Flags: needinfo?(jyavenard)
Assignee | ||
Comment 4•8 years ago
|
||
Under some circumstances, the MP3Demuxer is unable to calculate the buffered range which would prevent the readyState value to be recalculated. To get around this we force recalculation when the progress event is fired. Review commit: https://reviewboard.mozilla.org/r/48661/diff/#index_header See other reviews: https://reviewboard.mozilla.org/r/48661/
Attachment #8744688 -
Flags: review?(jwwang)
Assignee | ||
Updated•8 years ago
|
Flags: needinfo?(jwwang)
Reporter | ||
Comment 5•8 years ago
|
||
More information. I'm using Firefor in Ubuntu. It's possible to fix this ?
Comment 6•8 years ago
|
||
I saw lots of warings: [Child 19643] WARNING: Unimplemented function NotifyDataArrived: file dom/media/MP3Demuxer.cpp, line 89 Isn't bug 1169485 all we need to update buffer ranges correctly?
Assignee | ||
Comment 7•8 years ago
|
||
(In reply to JW Wang [:jwwang] from comment #6) > I saw lots of warings: > [Child 19643] WARNING: Unimplemented function NotifyDataArrived: file > dom/media/MP3Demuxer.cpp, line 89 > > Isn't bug 1169485 all we need to update buffer ranges correctly? Not really. This is just for use with MSE, for which GetBuffered isn't even required. We will have the same issues with with other MP3 players (DirectShow or OMXReader); which must have the MediaResource duration be known to estimate the buffered range. So at this stage, forcing a call to UpdateReadyState is the only reliable way to fix it. Doing so in the "progress" every handling is the least taxing as it's as most only called every 350ms and if the data is in the cache, it won't be called again. The previous method of calling it from NotifyDataArrived would cause much greater And unecessary calls.
Comment 8•8 years ago
|
||
Comment on attachment 8744688 [details] MozReview Request: Bug 1267036: Force recalculation of readyState when download is progressing. r?jwwang https://reviewboard.mozilla.org/r/48661/#review45433
Attachment #8744688 -
Flags: review?(jwwang) → review+
Comment 10•8 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/a84bf33d3e9a
Status: NEW → RESOLVED
Closed: 8 years ago
status-firefox49:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla49
Comment 11•8 years ago
|
||
I've created bug 1267862 to address the MP3Demuxer::GetBuffered implementation.
Flags: needinfo?(esawin)
Comment 12•8 years ago
|
||
Jya -- Does it make sense to request uplift to 48/47?
Assignee: nobody → jyavenard
Flags: needinfo?(jyavenard)
Assignee | ||
Comment 13•8 years ago
|
||
Comment on attachment 8744688 [details] MozReview Request: Bug 1267036: Force recalculation of readyState when download is progressing. r?jwwang Approval Request Comment [Feature/regressing bug #]:1267036 [User impact if declined]:Media playback may not automatically start. [Describe test coverage new/current, TreeHerder]:in central for a while. Lots of mochitest. [Risks and why]: low. Reverting to previous behaviour. [String/UUID change made/needed]: none
Flags: needinfo?(jyavenard)
Attachment #8744688 -
Flags: approval-mozilla-beta?
Attachment #8744688 -
Flags: approval-mozilla-aurora?
Hello Echosmart792, could you please verify this issue is fixed as expected on a latest Nightly build? Thanks!
Flags: needinfo?(echosmart792)
Comment on attachment 8744688 [details] MozReview Request: Bug 1267036: Force recalculation of readyState when download is progressing. r?jwwang While this is not a recent regression, the fix looks simple. Aurora48+, Beta47+
Attachment #8744688 -
Flags: approval-mozilla-beta?
Attachment #8744688 -
Flags: approval-mozilla-beta+
Attachment #8744688 -
Flags: approval-mozilla-aurora?
Attachment #8744688 -
Flags: approval-mozilla-aurora+
Hi Jean-Yves, ESR45 is also affected. Do you think we should consider uplifting to ESR? Or just leave it wontfix.
Flags: needinfo?(jyavenard)
Comment 17•8 years ago
|
||
bugherder uplift |
https://hg.mozilla.org/releases/mozilla-aurora/rev/7772a4493512
Comment 18•8 years ago
|
||
bugherder uplift |
https://hg.mozilla.org/releases/mozilla-beta/rev/5220d6bc3ffd
Assignee | ||
Comment 19•8 years ago
|
||
Comment on attachment 8744688 [details] MozReview Request: Bug 1267036: Force recalculation of readyState when download is progressing. r?jwwang [Approval Request Comment] If this is not a sec:{high,crit} bug, please state case for ESR consideration: User impact if declined: media playback doesn't start. Fix Landed on Version: 47 Risk to taking this patch (and alternatives if risky): low String or UUID changes made by this patch: none See https://wiki.mozilla.org/Release_Management/ESR_Landing_Process for more info.
Flags: needinfo?(jyavenard)
Attachment #8744688 -
Flags: approval-mozilla-esr45?
Hi Liz, fyi, this is an ESR45 uplift nom. You own 45.2.0 so you get to make a decision. :)
Flags: needinfo?(lhenry)
Comment 21•8 years ago
|
||
I won't start uplifting stuff to ESR yet but I don't think this makes the bar, it's not a major security or stability fix, and users can still manually start playback.
Flags: needinfo?(lhenry)
Updated•8 years ago
|
QA Whiteboard: [good first verify]
Comment 22•8 years ago
|
||
I have reproduced this bug with Firefox Nightly 48.0a1 (Build ID: 20160424030601) on Windows 8.1, 64-bit with the instructions from comment 0. Verified as fixed with Firefox Beta 47.0b5 (Build ID: 20160512003946) Mozilla/5.0 (Windows NT 6.3; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0 Verified as fixed with Firefox Developer edition 48.0a2 (Build ID: 20160513004028) Mozilla/5.0 (Windows NT 6.3; WOW64; rv:48.0) Gecko/20100101 Firefox/48.0 Verified as fixed with Firefox Nightly 49.0a1 (Build ID: 20160512030253) Mozilla/5.0 (Windows NT 6.3; WOW64; rv:49.0) Gecko/20100101 Firefox/49.0
QA Whiteboard: [good first verify] → [good first verify][bugday-20160511]
Comment 23•8 years ago
|
||
Reproduced this issue using Fx 46.01 on Ubuntu 14.04 x64, Windows 10 x64 and Mac OS X 10.9.5. Confirming the fix on Firefox 49.0a1 (20160514030209),47.0b7(20160516123243) and 48.0a2(20160517004009) using platforms Windows 10 x64, Mac OS x 10.9.5 and Ubuntu 14.04 x64.
Comment 24•8 years ago
|
||
Comment on attachment 8744688 [details] MozReview Request: Bug 1267036: Force recalculation of readyState when download is progressing. r?jwwang Verified on other channels, fix for media playback that regressed in 45, ok to uplift to esr45.
Attachment #8744688 -
Flags: approval-mozilla-esr45? → approval-mozilla-esr45+
Comment 25•8 years ago
|
||
bugherder uplift |
https://hg.mozilla.org/releases/mozilla-esr45/rev/1a1d754e8095
You need to log in
before you can comment on or make changes to this bug.
Description
•