- From: Steve Lacey <sjl@chromium.org>
- Date: Thu, 27 Jan 2011 16:09:19 -0800
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