- From: wolenetz via GitHub <sysbot+gh@w3.org>
- Date: Wed, 30 Nov 2016 23:13:00 +0000
- To: public-html-media@w3.org
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