- From: chcunningham via GitHub <sysbot+gh@w3.org>
- Date: Tue, 07 Jun 2016 21:38:01 +0000
- To: public-html-media@w3.org
chcunningham has just created a new issue for https://github.com/w3c/media-source: == Clarify/remove 'stalled' and 'progress' events for MediaSource == Note on priority: Happy to see any spec change pushed to MSE vNext. v1 is nearing cut date and IMO this isn't critical. 'Stalled' makes good sense for non-MediaSource playbacks where the UA is responsible for the fetching the media. For MSE, the web app does the fetching and MSE is unaware that the fetch is being made and cannot know whether its progressing or stalled. The MSE spec states that "the download" or "bytes received" (in resource fetch algorithm) refer to data passed in via appendBuffer() and appendStream()". With this model, it is not possible for MSE to experience a stall (appends don't stall). MSE spec makes no special mention of 'stalled' and when to emit (if ever) is ambiguous given the lines about "the download" and "bytes received" above. At the moment Chrome raises stalled if an MSE app goes 3 seconds without appending. This [leads to confusion](crbug.com/517240). I propose that we should not emit stalled for MSE (similar to the decision to not emit suspend for MSE in [Issue 24](https://github.com/w3c/media-source/issues/24)). When to emit 'progress' is also not clear. Raising this during an append is not as confusing as Chrome's behavior for 'stalled', but one could argue that raising progress is still confusing (given that app control the fetch) and also not useful for app developers. Apps know when they've called append and they can clearly know the outcome/completion of that append by other events/states (e.g. updateend event, SourceBuffer.buffered). I propose that we should also not bother to emit progress. This is also a call for app developers to point out MSE use cases for these events that I may have overlooked. One argument that I've heard is that some players may have UI that relies on these events dating back pre-MSE implementation. If this is a real concern then we have to decide on an implementation for these events that is meaningful. Showing a stall indicator because no append has been made in the last 3 seconds is not a great UI. Apps may append less frequently than that and still deliver a perfect playback experience. Additionally, apps would be better served basing any network UI on the network fetch they make prior-to appending to MSE. Please view or discuss this issue at https://github.com/w3c/media-source/issues/88 using your GitHub account
Received on Tuesday, 7 June 2016 21:38:02 UTC