- From: <bugzilla@jessica.w3.org>
- Date: Mon, 18 Mar 2013 21:44:33 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20760 Jerry Smith <jdsmith3000@hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jdsmith3000@hotmail.com --- Comment #3 from Jerry Smith <jdsmith3000@hotmail.com> --- 1. The goal of the proposed metrics is to measure the playback quality of the entire media playback stack, including decoding as well as data appending/parsing and rendering process. Although the video decoder is offloaded to the hardware already for most modern platforms (incl. Windows PC), the video rendering process is still part of the rendering process of a web page by the user agent, which can control the overall composition process either explicitly or implicitly. So, the user agent can collect the statistics and report accordingly on how many frames are actually being presented as well as how much jitter. Jitter will have to measured based on the refresh rate of the display device, so it might not be zero when the refresh rate of the display doesn't have perfect match of the actual video frame rate. 2. We agree frame rate can change dynamically, so based on the proposal, the "currentvideoframerate" property reflects the frame rate at the time the quality metric is queried rather than as a static property on the media element itself. 3. Based on the MSE design, it is largely the app's responsibility to track the network bandwidth and data download rate. We agree the video decoder is not a bottleneck for most systems with hardware decoders, however video rendering can be affected by other operations as part of the overall web page rendering process. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Monday, 18 March 2013 21:44:35 UTC