- From: Steve Lacey <sjl@chromium.org>
- Date: Mon, 7 Feb 2011 13:55:37 -0800
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 Monday, 7 February 2011 13:55:37 UTC