Media event 'playing' should be fired when sound/video begin rendering, not when bytes first arrive
Reported by
davidswa...@gmail.com,
Dec 6 2016
|
|||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.99 Safari/537.36 Steps to reproduce the problem: 1. Create an audio element whose source is a stream 2. Add a callback for the 'isplaying' event that logs a timestamp for when the first bytes arrived and when this event fires. 3. It may be necessary to throttle the stream to make the time difference noticeable What is the expected behavior? 'isplaying' should fire approximately when sound is first heard through a speaker or video begins playing. Firefox does this. What went wrong? 'isplaying' fires 270-1100 msec before any sound leaves the speakers. Did this work before? N/A Does this work in other browsers? Yes Chrome version: 54.0.2840.99 Channel: n/a OS Version: 10.0 Flash Version: Shockwave Flash 23.0 r0 This seemed related to an already-filed bug, so I reported it as a comment there: https://bugs.chromium.org/p/chromium/issues/detail?id=73609#c77 But I was encouraged there to create a bug on its own.
,
Dec 6 2016
Repeating my comment from the other bug: "We don't 100% know when audio will leave the speaker. Probably we could make the estimate better, but you'll never get it perfect for the first frame of audio." Typically the advice for figuring out the true value for this (if you need it as accurate as possible) is a requestAnimationFrame that checks currentTime > 0. I'm surprised this is fairly accurate in other browsers though.
,
Dec 8 2016
,
Dec 8 2016
,
Dec 16 2016
,
Dec 16 2016
My read of the spec is that these things aren't required to be perfectly sync'ed. Still, its nice to do better. I don't have any simple suggestions but I could imagine ways to estimate. The first time we play audio on a given system we really don't know how long it will take to play out on the speaker. But we could determine this after the first render call (especially now that we have the delay + *delay_timestamp*). We could then save this info (potentially to disk) for the next OnBufferingStateChange(HAVE_ENOUGH) - rather than posting the task as soon as the queue is full, post a delayed task with delay = the average observed delay from previous playbacks. Delayed tasks aren't guaranteed to wait a precise time, and there's still the delay of firing the "playing" event once scheduled, but I suspect they do better than the 200 - 1100 msec noted in the report. Buuuut this is pretty elaborate and I'm not sure it would do anybetter than the currentTime check Dale suggested. Really, the most accurate playout time can be known via WebAudio. We've almost got a change landed to implement getOutputTimestamp() https://codereview.chromium.org/2060833002/ See here for example usage https://webaudio.github.io/web-audio-api/#widl-AudioContext-getOutputTimestamp-AudioTimestamp
,
Dec 20 2016
,
Jan 18 2017
give to chris as per c#6. Chris, it's your call to fix it or not.
,
Jan 24 2017
Wontfix as complexity tradeoffs are IMO not worth it. Workarounds from comments 2 and 6 should unblock reporter. Yell if thats not the case. Alternatively, yell if anyone has a more clever idea on how to implement. |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by phistuck@chromium.org
, Dec 6 2016Summary: Media event 'playing' should be fired when sound/video begin rendering, not when bytes first arrive (was: Media event 'isplaying' should be fired when sound/video begin rendering, not when bytes first arrive)