Needs event to notify when sourceBuffer needs more data

[stnishimura]

For a device like TV that has limited size of sourceBuffer and low processing power, it is important to be able to manage buffer with minimum resource consumed as possible, i.e. without using extra setTimeout or timeupdate event handling. "2.4.4 SourceBuffer Monitoring" specifies that ‘canplay’ event fires when readyState changes from HAVE_FUTURE_DATA to HAVE_ENOUGH_DATA but no event would fire when an opposite change occurs, while it is important for application (dash.js) to know when is the right time to put next segment.

This is one of the issues raised in the Web and TV IG meeting at TPAC 2015 by Hybridcast group.
https://www.w3.org/2011/webtv/wiki/images/6/66/Webtv_mse_eme_iptvfj_player_20151026.pdf

[jdsmith3000]

Triaging per the new MSE & EME Spec Issue Triage Process.

The requested feature will require development work beyond what's possible in the remaining time for MSE version 1.

[wolenetz]

FWIW, I agree this looks appropriately triaged to VNext.

[yfuna]

@stnishimura Can you make sure that V1's lacking the event you suggested won't be a major blocker for MSE services on Hybridcast terminals?

This triage looks appropriate in light of the triage process guideline. However, if you couldn't use MSE on low performance devices by missing this feature, which might be something we should give extra consideration.

[stnishimura]

Theoretically setTimeout and timeupdate event can handle this issue. However, these mechanisms may have difficulty to be applied to low end devices such as low end model of TVs. This difficulty will prevent deployment of content delivery using MSE to various devices.
On the other hand, it is quite natural for hybrid broadcast systems including Hybridcast to apply MSE based technologies to make the services common as much as possible to various types of devices. In addition, service providers of Hybridcast are about to launch such services.
Considering this situation, privately developed APIs or events may be required unless standardized mechanisms applicable to low end devices are defined in MSE V1, which is not preferable. I think it is required to define standardized way in MSE V1 on this issue to avoid development of those private mechanisms.

[yfuna]

@stnishimura : Thank you for your comment. Though I'm not sure if we can cover the feature in V.1 because we need to define the new API, create testing, and prepare two implementations by this June. (I for one think it's very difficult.) It would be useful to clarify what kind of API you need to resolve this issue and your thoughts on testing and implementations, regardless of the version in which this feature will get covered.

Would it be possible for you to provide us with such information?

[paulbrucecotton]

@stnishimura: Can you please respond here since yours is the only objection to this feature not being covered in MSE V1? If you cannot respond right away please give us some idea of when you will be able to reply.

[wolenetz]

Lack of clear API request response since #40 (comment) makes this appear lower priority currently as we triage scope for inclusion in V2. This seems backlog to me at the moment. A hypothetical API might be for an app to request that the SourceBuffer enqueue an event (say, possibleunderflow) if there is less than X seconds of media data buffered in the SourceBuffer beyond the current playhead. However, getting interop right here (what is playhead, do we adjust for playbackRate, etc) needs feedback from potential API users. Please add suggestions for API shape here.

[wolenetz]

A hybrid approach might be to get information in the "updateend" event describing the buffered state, so that the app can schedule accordingly with reduced polling.

[wolenetz]

This issue is part of a group of "introspection API" or similar API feature requests: #259, #209, #172, #40, #35.