[whatwg] Media elements statistics

On Thu, Jan 27, 2011 at 3:53 PM, Chris Pearce <chris at pearce.org.nz> wrote:
> 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?

Being able to determine the bitrate that's currently being decoded has
been a request from devs (for similar reasons that devs on the FOMS
list have I expect). Raw data seems generally useful.

>
> 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?

Right now I include the frames dropped in the decoded count. It's
kinda orthogonal to frames decoded/dropped as one (bytesdecoded) gives
the performance for decoding and the frame counts give performance of
presentation.

>
>> 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?

Thanks!

>
>
> 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
>>
>
>

Received on Thursday, 27 January 2011 16:09:19 UTC