W3C home > Mailing lists > Public > whatwg@whatwg.org > February 2011

[whatwg] Media elements statistics

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Sun, 13 Feb 2011 23:12:25 +1100
Message-ID: <AANLkTimvGiiMh_r6K_biuYSjMnAHFQDduOpMe+9SdVap@mail.gmail.com>
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
>>
>
Received on Sunday, 13 February 2011 04:12:25 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:30 UTC