[media-source] Clarify/remove 'stalled' and 'progress' events for MediaSource

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