- From: Mark Watson <watsonm@netflix.com>
- Date: Mon, 18 Jun 2012 20:53:06 +0000
- To: Steven Robertson <strobe@google.com>
- CC: Aaron Colwell <acolwell@google.com>, "Sunyang (Eric)" <eric.sun@huawei.com>, "public-html-media@w3.org" <public-html-media@w3.org>
On Jun 18, 2012, at 1:42 PM, Steven Robertson wrote: > On Mon, Jun 18, 2012 at 12:41 PM, Mark Watson <watsonm@netflix.com> wrote: >> If we are going to provided download progress information for adaptive >> streaming though this API, then ideally it should have the following >> properties: >> - progress information should be associated with the URL/byte range >> - the HTTP response time should be available and separated from any time >> spend doing redirections, CORS pre-flights etc. >> - the bytes received information should be provided in the form of triples >> (reception start, reception end, bytes received) so that the script does not >> average over time periods where the client was (deliberately) not receiving >> data (or, equivalently, we could have reception start/stop/progress events >> that come with timestamps). > > +1. > > Will implementations have the option of initiating multiple requests > per source in parallel (to reduce startup latency)? I would guess that many implementations will use the existing browser HTTP stack. Browser HTTP stacks already do any number of fancy things to optimize page downloads, including parallel connections. The consequence is that scripts should not make assumptions about the order and concurrency of downloads. …Mark > > Steve >
Received on Monday, 18 June 2012 20:53:37 UTC