[whatwg] Media elements statistics

[Silvia Pfeiffer]

You can always chuck it in the whatwg wiki
http://wiki.whatwg.org/wiki/Main_Page. :-)
Silvia.


On Sat, Feb 12, 2011 at 7:02 PM, Steve Lacey <sjl at chromium.org> wrote:
> crickets...
>
> I'll work on a proposal spec for this ;-)
>
> On Mon, Feb 7, 2011 at 1:55 PM, Steve Lacey <sjl at chromium.org> wrote:
>
>>
>>
>> On Thu, Jan 27, 2011 at 4:18 PM, Steve Lacey <sjl at chromium.org> wrote:
>>
>>> On Thu, Jan 27, 2011 at 3:38 PM, Chris Double <chris.double at double.co.nz>
>>> wrote:
>>> > On Fri, Jan 28, 2011 at 12:22 PM, Steve Lacey <sjl at chromium.org> wrote:
>>> >>
>>> >> 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:
>>> >
>>> > Raw bytes sounds good.
>>> >
>>> >> 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.
>>> >
>>> > Moving them to the video and audio element would mean you can't get
>>> > the audioBytesDecoded on a video element which is what I'm assuming
>>> > you want by having the two values.
>>>
>>> Yeah - I'd also add audioBytesDecoded to the audio element, which is
>>> an unpleasant dupe.
>>>
>>> >
>>> > Note that the Mozilla implementation I proposed has had a counter
>>> > proposal by another mozilla developer and is being developed further.
>>> > See:
>>> >
>>> > https://bugzilla.mozilla.org/show_bug.cgi?id=580531
>>>
>>> Thanks. Taking a further look at that.
>>>
>>
>> Reviving thread...
>>
>> I have an initial patch in webkit (http://trac.webkit.org/changeset/77394)
>> and the chromium work is underway - I wonder what might be a good approach
>> to drive the apis closer together towards a real spec that everyone is happy
>> with?
>>
>> There seems to be a lot of general agreement here (at least in principal
>> :-) that this is needed. We'll be doing a bunch of experimentation once this
>> has landed in chromium.
>>
>> Cheers!
>> Steve
>>
>