- From: <bugzilla@jessica.w3.org>
- Date: Wed, 07 Dec 2011 21:01:53 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=14970 --- Comment #7 from Ian 'Hixie' Hickson <ian@hixie.ch> 2011-12-07 21:01:52 UTC --- > The idea is that if a user complains to a publisher that their experience is > bad that the publisher has a means to track down exactly what is causing that > poor experience. Ah well that's an interesting use case that wasn't brought up before. If that's the use case, it seems like the best API would be something that returned a list of components involved in the display of the video, and for each one gave some sort of performance metric. The components could be UA defined, since different UAs could have different components, but could e.g. be "network", "decoding", and "display". Each one would then have an attribute saying what fraction of the media stream it was handling per unit time, and an attribute saying whether this performance was constrained by hardware limitations (e.g. pegging the CPU, the cache, the network or GPU bandwidth), or whether it was constrained by software limitations (e.g. the decoding can only happen at the display rate because the software doesn't know how to buffer decoded frames), or whether it was being artificially constrained to maintain a good user experience (e.g. the download could go faster but is being throttled by the client because the user might want to use the bandwidth for other things). So e.g. if the network was downloading a 30 minute video as fast as i could at a rate that would take 15 minutes, it would have the value "2" (twice real time) and "hardware" (it's going as fast as it can). We'd probably want some sort of indicator of regularity, too, e.g. to report cases where the decoding is happening at an ideal 25 fps, but actually doing 50 frames one second and zero the next. -- Configure bugmail: https://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 Wednesday, 7 December 2011 21:01:58 UTC