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

As of the spec now, we will look at the resource as a whole. Agree we need
to think about this case. This is a good topic for our next call.

Arvind

On Wed, May 9, 2012 at 11:43 AM, Mark Watson <watsonm@netflix.com> wrote:

>
>  On May 9, 2012, at 11:30 AM, Arvind Jain wrote:
>
> Thank Mark.
> It certainly makes sense to include performance of media elements into the
> Timing specifications. ResourceTiming will shortly be in CR so it's best to
> put together a new spec for this use case. We could either do this in
> ResourceTiming2 spec (no work has started on that front yet) or have a
> MediaResourceTiming specification (probably better option).'
>
>
>  The existing spec says in 4.1 that it already applies to media elements.
>
>  I would argue that the lack of byte ranges in the name is a flaw
> already, since media elements commonly issue byte range requests, for
> example when seeking.
>
>
>  Re. your questions, the PerformanceResourceTiming object is made
> available after the resource has been downloaded.
>
>
>  So, then, I guess it would be a significant change to make the objects
> available earlier and provide "progress" type information. Perhaps that
> could be a feature for the next version ?
>
>  …Mark
>
>  In case of http pipelining, you are right, the pipelining delay will be
> included in (responseStart -  requestStart). Wonder what folks think of
> adding an indicator re. pipelining.
>
>  Arvind
>
> On Wed, May 9, 2012 at 10:31 AM, Mark Watson <watsonm@netflix.com> wrote:
>
>> 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.
>>
>>
>>
>
>