[whatwg] Media elements statistics

[Chris Pearce]

Hi Steve et al,

I'm working on a similar feature for Firefox: 
https://bugzilla.mozilla.org/show_bug.cgi?id=580531

Though we're implementing this more as a way of measuring the 
performance of our decoding and rendering pipeline, rather than 
providing playback/decode-rate stats.

> unsigned long audioBytesDecoded;
> unsigned long videoBytesDecoded;

Out of curiosity, why do you want this feature? What does it give you 
that @buffered and @currentTime does not?

Raw bytes reasonable to me, the feedback on the FOMS list regarding 
playback statistics showed webdevs liked that idea.

How would you handle frames dropped by the decoder in order to prevent 
it falling behind? Would you count their bytes as decoded?

> Another open question: what are sensible values if the information is
> not available. Zero seems wrong.

Return Number.NaN? Or provide some kind of ability to query whether 
there is audio and video?


Regards,
Chris P.

On 28/01/2011 12:22 p.m., Steve Lacey wrote:
> Hi,
>
> I'd like the raise this thread again:
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/027929.html
> (I wasn't on the list at that point, so starting a new thread here and
> cc'ing a couple of folks from it...)
>
> I work on the media stack in Chromium and we'd like to implement
> something pretty similar. So I'm looking for comments...
>
> The original suggestion for the video element looks good:
>
> [Video Element]
>
> // Frames decoded and available for playback.
> unsigned long decodedFrames;
>
> // Frames dropped during playback for performance reasons.
> unsigned long droppedFrames;
>
> But for the media element I'd like to propose raw bytes instead of a
> rate as this allows the developer to construct their own rates (if
> needed) based on whatever window they want. It would also be useful to
> separate audio from video. A suggestion might be:
>
> [Media Element]
>
> unsigned long audioBytesDecoded;
> unsigned long videoBytesDecoded;
>
> Though this seems a little strange to have these specifically on the
> media element as they reference particular media types. Another idea
> would be to move these to the video element and also add
> audioBytesDecoded to the audio element.
>
> Another open question: what are sensible values if the information is
> not available. Zero seems wrong.
>
> Thoughts?
>
> Cheers!
> Steve
>