[Bug 20760] New: <video> Expose statistics for tracking playback quality

https://www.w3.org/Bugs/Public/show_bug.cgi?id=20760

            Bug ID: 20760
           Summary: <video> Expose statistics for tracking playback
                    quality
    Classification: Unclassified
           Product: HTML WG
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Media Source Extensions
          Assignee: adrianba@microsoft.com
          Reporter: adrianba@microsoft.com
        QA Contact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-media@w3.org

Problem description: (as mostly described in bug 14970 and the existing
proposal already http://wiki.whatwg.org/wiki/Video_Metrics#Proposal)

For adaptive video streaming using the video element with the Media source
Extensions (MSE) it is important that the User Agent should expose video
quality metrics for the applications to make decisions on media stream quality,
e.g. bitrate and resolution, etc. This allows for the scenario where the
network is capable of transferring higher quality video than the device is
capable of playing and the application needs to step down to a lower quality.

Proposed changes: A subset of the existing proposal
(http://wiki.whatwg.org/wiki/Video_Metrics#Proposal).  The attributes
presentedFrames and playbackJitter should be able to cover the typical
scenarios used by the MSE.
Here is the proposed text for the <video> tag.  We'd like to have be added to
MSE for now since it’s important for this scenario but in future it might be
part of HTML 5.1. 

partial interface HTMLVideoElement : HTMLMediaElement {
  // new attribute
  MediaPlaybackQuality getPlaybackQuality();
};

interface MediaPlaybackQuality {
  readonly attribute double currentvideoframerate;
  readonly attribute Date systemTime;
  readonly attribute unsigned long presentedFrames;
  readonly attribute double playbackJitter;
};

The "currentvideoframerate" attribute represents the current framerate of the
active video track.  The UA should provide the frame value based on metadata in
the video stream.  The UA can expose the value as NaN when it is not
deterministic.  In that case, the app can use the presentedFrames to estimate
the actual video frame rate.

The "systemTime" attribute represents the current system time (in UTC) at the
point when the statistics were acquired.  This can be compared between calls to
precisely determine how playback quality is changing over time.

The "presentedFrames" attribute represents the number of frames of video that
have been presented for compositing into the page. The initial value of the
presentedFrames attribute should be 0 for this element.  The value of the
presentedFrames attribute should be set to 0 after running each instance of
media element load algorithm for this element.

Note: The presentedFrames could be used to calculate frames per second.  The
presentedFrames could also be used to measure the display quality that the user
perceives and can determine the performance of the rendering engine given the
performance of the network and decoding pipeline. If, for example, the system
receives sufficient data from the network, but the rate of presented frames per
second is below 15, we can assume that the user gets a poor presentation
because the rendering engine was too slow, the machine is likely overloaded or
not capable of rendering this video at this quality.  In this case, the
application should probably move to a lower bitrate (resolution or frame rate)
resource for the video.

The "playbackJitter" attribute represents the sum of all duration errors for
frames intended to be presented to the user, where: 
Ei = Desired duration of frame i spent on the screen (to nearest microsecond) 
Ai = Actual duration frame i spent on the screen (if the frame is never
presented to the user, then Ai == 0). 
then: 
playbackJitter = sum(abs(Ei - Ai))

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Thursday, 24 January 2013 16:27:50 UTC