On Thu, Jan 27, 2011 at 4:18 PM, Steve Lacey <[email protected]> wrote:
> On Thu, Jan 27, 2011 at 3:38 PM, Chris Double <[email protected]> > wrote: > > On Fri, Jan 28, 2011 at 12:22 PM, Steve Lacey <[email protected]> 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
