- From: <bugzilla@jessica.w3.org>
- Date: Tue, 11 Oct 2011 22:52:31 +0000
- To: public-html-bugzilla@w3.org
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