This concerns the current draft on the Media Playback Quality interface as published here – we as a research group are very interested in this topic in general, and have specific comments as to how the interface could be enhanced to support further metrics and ultimately better fit the concept of “playback quality”. As of now, the interface specifies metrics that basically relate to player performance in the sense of decoding performance (i.e., whether the player is able to decode and display all frames coming in), but not so much “quality” in the sense of what a user really perceives (e.g., a video that is blurry due to being low-resolution or heavily compressed).
It is my understanding that the Media Playback Quality interface replaces what has been suggested years ago by the WhatWG in the “Video Metrics” project. However, these metrics have either not been fully implemented by all browser vendors (e.g. Firefox has not implemented videoDecodedBytesCount, and development on it has stalled years ago), or are even considered for deprecation (e.g. WebKit deprecating the same attribute here).
The WhatWG at the time stated:
Service providers, especially commercial service providers, need to manage and monitor the performance of their service, for example to detect problems before they cause a deluge of Customer Service calls or identify whether, where and when the service is providing the quality of experience expected by customers.
Knowing the actual bitrate of a decoded video is very important in order to get an accurate estimate of the visual quality of the video being played back, when no actual bitstream is available to the client. Without means to estimate how much a video has been compressed, any diagnosis of video playback quality will have to fall back to looking at how long the video has stalled during playback, which is not giving the full picture. A relevant scenario in which this metric would be useful is monitoring video streaming quality using instrumented clients that play HTML5 video. Here, one would like to know the actual bitrate at which a given stream is coded.
Of course, a video service provider itself knows how they coded their video segments, and may characterize the video quality easily already before transmission. For a third party wanting to characterize the performance of a video service though, it is impractical or even infeasible (be it legally or technically) to download the corresponding video bitstream for further analysis. Hence, a simple method to expose the video’s bitrate (e.g., by offering the bytes decoded) would be preferable.
Exposing the current bitrate to the player would also simplify calculations for adaptive streaming implementations.
The WhatWG have proposed two specific attributes that exactly fit this use case: downloadRate and videoBitrate – the latter being of particular interest, and very close to what we are trying to achieve.
Would it be possible for us to contribute to a specification that allows calculating video bitrate (and similarly, of course, audio bitrate) based on the Media Playback Quality interface?