Open wolenetz opened 7 years ago
@jdsmith @mwatson2 WDYT? An alternative to the app providing some identifier would be for the user agent to generate (a unique) one and return it from the appendBuffer() call before the asnch append processing completes. However, that additional return value could be a breaking change, but simply making an appendBuffer() overload that takes an additional ID parameter wouldn't be a breaking change.
FWIW, this is a problem I've been working on for a little while but that is far from trivial (at least with our media playback architecture). Linking a demuxing error to the appendBuffer ID is one thing.
Knowing which frame from which media segment is related to a decoding failure down the chain is another (especially with things like out of process decoding in the way).
It would certainly be a very useful information to provide...
Consider the apparently common case (as reported in discussions during 2017 FOMS/Demuxed conferences) where an MSE web app receives some kind of error from the media element or MSE API, but would like to know more details about which specific appendBuffer operation the error arose from later in processing. For instance, a decode error associated with an append of chunk "A" could perhaps have that "A" exposed in the MediaError and/or via some MSE-specific query. This allows other non-error cases, such as potentially servicing queries like "from which appendBuffer call is the currently composited frame?", and providing more easily understandable debug error messages in implementations, such as in chrome://media-internals in Chromium.