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

[whatwg] Video playback quality metric

From: Philip Jägenstedt <philipj@opera.com>
Date: Tue, 10 Feb 2009 10:18:00 +0100
Message-ID: <op.uo4pgawgatwj1d@spock.linkoping.osa>
On Mon, 09 Feb 2009 22:13:09 +0100, Jeremy Doig <jeremydo at google.com>  
wrote:

> Measuring the rate at which the playback buffer is filling/emptying  
> gives a
> fair indication of network goodput, but there does not appear to be a  
> way to
> measure just how well the client is playing the video itself. If I have a
> wimpy machine behind a fat network connection, you may flood me with HD  
> that
> I just can't play very well. The cpu or video card may just not be able  
> to
> render the video well.Exposing a metric (eg: Dropped Frame count,  
> rendered
> frame rate) would allow sites to dynamically adjust the video which is  
> being
> sent to a client [eg: switch the url to a differently encoded file] and
> thereby optimize the playback experience.
> Anyone else think this would be good to have ?

While I think this kind of thing might be useful, I would be careful about  
requiring any kind of detailed metrics like dropped frames or effective  
frame rate to be exposed via DOM, as getting this information reliably  
over different devices, platforms and media frameworks would be quite  
difficult. How about an event which the user agent can optionally fire to  
indicate that it cannot play at the requested rate due to  
processing/memory constraints (rather than network)? This would (I think)  
provide the same functionality but put less burden on implementors.

There is already a placeholder for non-fatal errors in the spec, perhaps  
this could be included with that in some fashion?

-- 
Philip J?genstedt
Opera Software
Received on Tuesday, 10 February 2009 01:18:00 UTC

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