Issue metadata
Sign in to add a comment
|
HTML5 Audio element gets stuck in seeking state for AAC files
Reported by
sc...@audioaddict.com,
Oct 9 2017
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36 Steps to reproduce the problem: Don't have great steps to reproduce as this issue is intermittent. Our website is a streaming music service which plays music through the HTML5 Audio element. We've never experienced this problem until Chrome 61. As far as we can tell right now, this issue only occurs with AAC encoded files. We've reproduced with valid media files using the following encodings: - AAC-HE @ 64kbps - AAC @ 128kbps We've NOT been able to reproduce with the following encodings: - MP3 @ 320kbps It does not necessarily occur to the same media files. Our site plays many audio files back-to-back re-using the same HTML5 Audio element. Here's roughly the steps that occur: 1. Play an audio file form user triggered interaction 2. Wait for `ended` event to be emitted 3. Set `el.src` to next media file in our 'playlist' 4. Set `el.currentTime = 0;` 5. Wait for `seeked` event to be emitted 6. Call `el.play()` If we repeat this sequence again and again (using AAC files) and eventually Step 5 will not occur. What is the expected behavior? A valid 'seeking' event should (eventually) be followed by a 'seeked' event What went wrong? Occasionally, the 'seeked' event is never emitted. Here's the logged media events, in sequence, when we reproduced this issue. Note that no 'seeked' event is ever emitted: loadstart loadedmetadata loadeddata canplay seeking progress progress suspend Here is the state of the media element when this issue occurs. Clearly it's "stuck" in the seeking phase: el.paused - true el.seeking - true el.seekable.start(0) - 0 el.seekable.end(0) - 254.212 el.duration - 254.212 el.ended - false el.currentTime - 0 el.error - null el.readyState - 1 el.volume - 0.8 Manually calling `play()` on the element or assigning `el.currentTime = 0` seems to break free of the stuck state. Did this work before? Yes Chrome 60 Does this work in other browsers? Yes Chrome version: 61.0.3163.100 Channel: stable OS Version: OS X 10.12.4 Flash Version: Shockwave Flash 27.0 r0
,
Oct 10 2017
Unfortunately, due to the intermittent nature, there's not a specific test case or test url I can provide. However, there should be enough information here to isolate potential causes. The steps to reproduce can be followed using an AAC file and will eventually trigger the issue. I've attached an AAC file if that helps.
,
Oct 10 2017
Thank you for providing more feedback. Adding requester "divya.padigela@techmahindra.com" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 10 2017
A few more details: - appears to only occur when seeking to 0 position - seeking to non-zero positions does not seem to be impacted - Deleting the src then adding it back seems to resolve the stuck state - Calling play() does NOT break free of the stuck state as previously reported
,
Oct 12 2017
scott@ Thanks for the feedback. Could you please provide the AAC file for us to proceed with the triaging of the issue. Thanks..
,
Oct 23 2017
,
Oct 23 2017
I'll take a look at this soon to see if it's a bug in ffmpeg. In your test bed does a simple html page that just repeatedly does steps 1..6 with the error.mp4 file above ever fail?
,
Oct 23 2017
I attempted to reproduce using a simple scripted scenario with steps 1-6 and was not able to reproduce.
In our particular code base, we check the readyState of the element during a seek attempt to ensure it has enough data to seek.
Here's the pseudo-code of our 'seek' method
--------------------------------------------------------------------------------
seek = (n) ->
if el.readyState >= el.HAVE_METADATA
el.currentTime = n
else
setTimeout((-> seek(n)), 50)
--------------------------------------------------------------------------------
I'll see if I can get a working test case using the recursive seek. Perhaps that is creating some sort of a race condition. However, we've been using this guarded recursive seek since ~Chrome56 without any issue.
I will try to report back soon with working test case.
,
Nov 21 2017
Can you check if Chrome Canary shows this issue still? We've updated ffmpeg so if it was an issue there it may be fixed.
,
Nov 27 2017
Seems to have been resolved by the ffmpeg update. Thanks all!
,
Nov 27 2017
Great! |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by divya.pa...@techmahindra.com
, Oct 10 2017Labels: Triaged-ET Needs-Triage-M61 Needs-Feedback