This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
We have found that in a system which is sufficiently large scale, things which "cannot possibly happen", do happen. For example, media data which has been checksummed at the server and delivered over reliable connections sometimes suffers from data corruption, causing errors in the video decoder. Another possibility is that a media file is not in fact compliant to the codec profile that it claims to be, although in our system this is either less common or doesn't cause errors. We would like to be able to detect and report on these cases. One proposal would be to add an 'erroredFrames' counter to the MediaPlaybackQuality object. Errored frames may either be rendered (with errors) or dropped based on the media player implementation. We should discuss whether dropped errored frames (where the error is due to the input data, not lack of time to complete decoding) should be included in the dropped frames counter.
Aren't those thing generally called "corrupted frames" ?
Marking all pre-Last Call bugs
I like Silvia's suggestion of using the word corrupt instead of errored. How about this: partial interface MediaPlaybackQuality { readonly attribute unsigned long corruptedVideoFrames; } This counter is incremented when a corrupted frame is detected. This may be pre or post decode. Corrupted frames increment totalVideoFrames just like dropped frames do. If the corrupted frame is not displayed then it increments the droppedVideoFrames counter just like it would if the frame was not corrupted. I think keeping "dropped" and "corrupted" counters independent allow the application to determine how exactly the corruption is affecting the user experience. (ie lower frame rate vs. visible artifacts)
Changes committed https://dvcs.w3.org/hg/html-media/rev/1ac9c2205a7b