See also: IRC log
<trackbot> Date: 16 May 2012
Jatinder: We have Mark from Netflix here today to discuss audio and video requirements for a performance metric.
Mark: We wanted the JavaScript
aspect to determine the throughput rate of video and audio
elements, so we can make decisions and update the user
experience. We saw what you have in Resource Timing and we
noticed that it covers both the video element and XHRs. Two
things I noticed were we use for adaptive streaming is byte
range request, which in itself is a http request and we would
like to see that data captured, and the progress of the
request, so if
... the data arrives.
Arvind: One of the fundamental differences is today Resource Timing is made available once the entire resource has been downloaded. Seems like you are asking for a progress indicator.
Mark: Yes, I think that's a part of it.
Arvind: I think this would
require a significant change to the Resource Timing spec. Let
me understand the use case, as chucks of the video is getting
downloaded, you will make a decision and change the bitrate.
Can't you do this already using the media source API? You would
make a XHR request and then you would see when it comes
back...
... Do we support XHRs in Resource Timing?
Jatinder: Yes
Arvind: We should have a XHR for every AJAX call we would make? I would expect that it would. It would include the range request
Mark: It seems like the name
attribute is the unique identifier. For XHRs, we would want the
URL and byte range together as the name attribute?
... The range request would seem like the basic data that you
need.
Karen: We haven't discussed partial responses. We may want to include that as well?
Mark: We may want to include the header data, but you may open a can of worms from a privacy point of view.
Arvind: With the resource timing,
you will also see multiple resource timing objects for each
chunk.
... Quite a few issues. Let's talk about them one at a time.
The first is that for multiple ajax xhr calls, you will get
multiple resource objects. We may want to include http headers
into the resource timing. However, there were issues with
that?
Tony: Yes, there could be privacy / fingerprinting issues with keeping that data around.
Karen: We should think about this in more detail before closing on it.
Arvind: Agree, let's chat more about this and close on it in the future.
Mark: If you had an event that would fire when each resource timing object was added, so you can determine which resource corresponds to which byte range. We can do this without giving the header information.
Alois: Is the goal really to determine the bandwidth so you can make decisions? Shouldn't we focus on how to get that data.
Mark: I would recommend providing
JavaScript with as much information happening on the lower
level network so it can make decisions. Seems like you have
provided most of the low level information. One information
missing seems like the byte arrival of data. You can imagine
providing a property that would let you know how many bytes
have arrived so far.
... I will have to go right now, however, I can join in another
future call to discuss some more.
Tony: There's also one point that we should clarify is that this is after the fact analysis. It was never designed to provide real time progress data, UAs can add the data at anytime they wish, not real time.
Jatinder: I also agree that these APIs were designed for post processing analysis. Shouldn't the elements they are trying to download be extended to provide this type of progress data?
Arvind: We should talk about this
more next week. Besides the progress issue, there is also the
naming issues.
... The naming issue of XHRs seems like an immediate issue that
we need to address in the Resource Timing.
... For things where we have multiple downloads for the same
entity, the API already provides all the data, we should
determine if we want to distinguish between them. Let's chat
about them next week.
... Seems like we have two issues: progress indication and
distinguishing between multiple chunks.
Sigbjorn: What would we do for a native video element?
Arvind: We should be give a single resource, I believe.
Jatinder: What about when the
video isn't auto-playing? What about a seek?
... What does the dev tools do today?
Arvind: I believe its a single element (one line item) instead of multiple items.
Tony: I think we need to determine whether we should treat it as a single element or have multiple http requests.
Issue Determine how audio, video and embed elements appear in the timeline
Action Determine how audio, video and embed elements appear in the timeline
<trackbot> Sorry, couldn't find user - Determine
Action Jatinder Determine how audio, video and embed elements appear in the timeline
<trackbot> Created ACTION-104 - Determine how audio, video and embed elements appear in the timeline [on Jatinder Mann - due 2012-05-23].
Jatinder: As three browsers have implemented this API and two have them unprefixed, customers have started to use, and the API is useful and meets the goals it set out for, and UAs will not remove this API, we want to keep this spec to document the behavior and keep the test cases to ensure interoperability.
Tony: I do not want to pull out the current Navigation Timing, as vendors have unprefixed it and we want to continue to ensure the spec is standarized.
Arvind: In our last discussion, two weeks back, we agreed that the Navigation Timing 2 should state that Navigation Timing 1 should be implemented. If that is the case, we should standarize Navigation Timing.
Alois: As a developer, we would check the new API and the old API, so we would use both of them.
Arvind: If our goal is to have
all browsers to implement the old API, then we should
standarize the spec.
... We should get Philippe's opinion on this matter as
well.
Jatinder: Considering Philippe will be back in a month and we aren't planning on moving the spec to PR until that point, we should close on this discussion at that point.
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) No ScribeNick specified. Guessing ScribeNick: JatinderMann Inferring Scribes: JatinderMann Present: JatinderMann Alois Sigbjorn tonyg WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 16 May 2012 Guessing minutes URL: http://www.w3.org/2012/05/16-webperf-minutes.html People with action items:[End of scribe.perl diagnostic output]