- From: wolenetz via GitHub <sysbot+gh@w3.org>
- Date: Wed, 20 Jun 2018 22:43:07 +0000
- To: public-html-media@w3.org
wolenetz has just created a new issue for https://github.com/w3c/media-source: == Spec is too rigid on requiring initial HAVE_CURRENT_DATA transition occur synchronously within coded frame processing == Spec is too rigid on requiring initial HAVE_CURRENT_DATA transition occur synchronous during coded frame processing. In practice, implementations (like Chrome and IIUC, Firefox) separate HTMLMediaElement.readyState transition from HAVE_METADATA to >= HAVE_METADATA based on being able to decode some or all coded frames to reach currentTime before transitioning the readyState. Further, such decode-based-transition is commonly done after firing 'updateend' on the corresponding SourceBuffer. This enables web apps to continue to append more media data to the SourceBuffer without awaiting the implementation's decode pipeline figuring out that it can actually play something at it's currentTime. Further, Chrome has some HTMLMediaElement decoder resource scheduling code that suspends decodes under-the-hood in some cases, delaying initial reaching of HAVE_CURRENT_DATA, to optimize scarce resource utilization (decoder, for example). Likewise, not blocking 'updateend' for such MSE-extended elements allows apps to append more media. @jyavenard, I suspect relaxing the coded frame processing step to reflect what implementations have chosen to do, is probably the best way forward. What do you think? Please view or discuss this issue at https://github.com/w3c/media-source/issues/215 using your GitHub account
Received on Wednesday, 20 June 2018 22:43:09 UTC