[media-source] Consider adding API for app to know how much room is left in the SourceBuffer

wolenetz has just created a new issue for 
https://github.com/w3c/media-source:

== Consider adding API for app to know how much room is left in the 
SourceBuffer ==
User agent implementations have their own heuristics for MSE coded 
frame eviction, resulting in difficulty for apps that try to predict 
whether or not there's enough room for an appendBuffer() to succeed 
without yielding QuotaExceededError. This leads to complex web app 
code to moderate how much they fetch to buffer-ahead, when the signal 
of memory pressure from the user agent (QuotaExceededError) occurs 
only upon attempted appendBuffer of already-fetched media data.

Can we do better? This issue assumes yes and requests that we do so :)

Note #40 is an inverse of this (notify the app when there's enough 
room now available in the SourceBuffer).

Some ideas I have around this (certainly incomplete, meant as a 
discussion starting point):

* Simple API to request of SourceBuffer how many bytes beyond those 
currently buffered can be appended without triggering coded frame 
eviction. This approach has a couple complications of its own:
 * In muxed SourceBuffers, thresholds for eviction may already be 
approximated, since the actual proportion of bytes in each track is 
unknown until coded frame processing has completed *after* the 
appendBuffer is done, and the user agent implementation may impose 
per-track byte limits rather than an overall per-SourceBuffer or some 
other limit. Chromium does such approximation, and could give a 
precise answer to this proposed API. I'm unclear if other 
implementations would be able to do similar.
 * If the user agent dynamically adapts the memory limits (e.g., based
 on available system memory) at runtime, an answer from this proposed 
API might not be stable when the actual appendBuffer() occurs later. 
If this is the case, the spec for this would need to make it very 
clear that this "headroom bytes" may change, and I'm less certain of 
the value of this proposed API route.
 * Spec documentation would be needed to clarify that the response of 
this proposed API is invalidated when any appendBuffer() or remove() 
is done.
 * Note that compliant user agent implementations are not necessarily 
required to emit QuotaExceededError if an appendBuffer() is done of an
 amount greater than this proposed API returns, since coded frame 
eviction could remove enough to allow the larger append.
* And/or have this "headroom bytes" be included as an event parameter 
of the 'updateend' event (or similar MSE SourceBuffer events like 
'update' or 'abort', etc.) I believe this approach may lead to app 
confusion since these events are delivered asynchronously at some time
 *after* `SourceBuffer.updating` has become `false`. I've seen MSE 
users encounter difficulties with such asynchrony, and delivering this
 "headroom bytes" in a similarly delayed fashion could lead to the web
 app mistakenly assuming that value is still valid.

I'd really welcome other proposals for how to alleviate this MSE web 
application difficulty.
@jdsmith3000 @mwatson2 FYI - please chime in.


Please view or discuss this issue at 
https://github.com/w3c/media-source/issues/172 using your GitHub 
account

Received on Wednesday, 30 November 2016 23:13:07 UTC