Fwd: [Bug 12399] <video> add bytesReceived, downloadTime, and networkWaitTime metrics

Hi WebPerf,

It's been suggested in the HTML WG that measurement of download performance for <video> and <audio> media elements should be covered by the WebPerf work. These measurements are of interest to the Web & TV interest group as they could be used to drive video bitrate adaptation, in conjunction with the Media Source Extension [1] proposed for the media elements. In the current version of that extension, it would be XHR that is used to fetch the media. In a future version the media element may be provided with a sequence of ( URL, byte range ) pairs and so it would be the media element doing the fetching.

I took a look at the Resource Timing draft [2] and this looks like it has a lot of great information that could be used for this purpose. Five things sprang to mind, though:

- Adaptive streaming players frequently issue byte range requests. So, URL alone is not enough to identify the request. Should there be a syntax for the name of a resource timing entry for a byte range request which includes the byte range in the name ?
- It might be nice to have an easy way to collect the PerformanceResourceTiming objects for a given audio or video element. For example if there were an event that fired on the element each time one was created (when the request first starts).
- For adaptive streaming, the performance information needs to be available as the resource is being downloaded. I couldn't find in the document whether this was the intention ? Also, the expected behavior with respect to redirects is not completely clear: the UA doesn't know if there will be a redirect until the response arrives, so before that it would populate fetchStart, requestStart, responseStart etc. Should it clear all those when it sees a redirect and has to start again ?
- It would be good to have information about download progress - for example a bytesReceived field which returns the number of bytes received at the time it is read (this is what was proposed for the <video> element in the HTML bug referenced in the subject line [3]).
- UAs might use HTTP pipelining. In this case the difference between requestStart and responseStart is not the RTT + server response time that it usually is: it includes the time required to complete the previous requests on the connection. It would be good at least to signal when this is the case: i.e. when the request has been pipelined.

What is the status of the Resource Timing work ? Is it possible to consider the above comments for the current draft ? Or should I address these comments for a future version ? (is one planned?).

Best regards,

Mark Watson
Netflix

[1] http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html
[2] http://w3c-test.org/webperf/specs/ResourceTiming/
[3] https://www.w3.org/Bugs/Public/show_bug.cgi?id=12399

Begin forwarded message:

From: <bugzilla@jessica.w3.org>
Subject: [Bug 12399] <video> add bytesReceived, downloadTime, and networkWaitTime metrics
Date: May 8, 2012 7:29:48 PM PDT
To: <watsonm@netflix.com>

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

--- Comment #42 from Silvia Pfeiffer <silviapfeiffer1@gmail.com> 2012-05-09 02:29:47 UTC ---
(In reply to comment #40)
Silvia: So to confirm, you're agreeing that bytesReceived, downloadTime, and
networkWaitTime are not media-specific and that we should move them to a
WebPerf API rather than HTMLMediaElement?

I've spoken with some others and we agree that these three are not
media-specific and could be progressed in WebPerf.



We have also identified that a generic DroppedFrames measure for video is
important so Web Devs can get information about how good the quality of
playback is that the users are seeing. It basically signals how much "system
bandwidth" is available for video. Web Devs can gather these stats to make a
better informed decision on which bitrate resource to choose for start of the
next video's playback, they can switch to alternative lower bitrate resources
mid-stream, or inform the user to close other apps, and build a profile of
typical bandwidth cases to decide on which bitrates to encode resources into.
The DroppedFrames metric is already available in WebKit through the
webkitDroppedFrames attribute and in Firefox through (mozPaintedFrames -
mozParsedFrames).

--
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.