[Bug 12399] <video> Expose statistics for media elements

http://www.w3.org/Bugs/Public/show_bug.cgi?id=12399

--- Comment #17 from Ian 'Hixie' Hickson <ian@hixie.ch> 2011-10-11 22:52:28 UTC ---
bytesReceived, downloadTime, and networkWaitTime seem reasonable. I propose to
provide them on a MediaMetrics object hung off a HTMLMediaElement.metrics
attribute.

The others all seem to have the same use case, essentially "determine the
client's performance". It's not at all clear to me why one of these would be
better than the other, or how they would be used differently. 

If the goal is just to be able to determine if, given the current system load,
the browser can handle a given track or whether the page should step down to a
lower-quality track, surely you only really need playbackJitter. Even then
though, it's not at all clear to me that that's the right approach. Consider a
situation where a user's system can't decode a high quality video in real time,
but has plenty of RAM to decode it ahead of time and then present it to the
user with perfect fidelity. Or consider a system where the user is playing two
videos, one of which is trying to be nice and so lowers the video quality when
it notices high load, and the other is more aggressive and increases the video
quality whenever the load lightens up in any way. The net result will just be
that the aggressive one will show at the highest quality and the polite one
will show at the lowest quality. Surely what would be better is a way for the
browser to automatically step videos up or down, so that there's no risk of a
Web page being more aggressive than another. (It's more than just video, too;
consider a similar API for Web Workers where a worker increases the load when
it notices the total system load goes down, vs a video that politely lowers the
load whenever it has reason to think the load is high or increasing).

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Tuesday, 11 October 2011 22:52:32 UTC