- From: Thorsten Lohmar <thorsten.lohmar@ericsson.com>
- Date: Wed, 20 Apr 2016 20:40:56 +0000
- To: Matthew Kerwin <matthew@kerwin.net.au>, "Craig Pratt (craig@ecaspia.com)" <craig@ecaspia.com>
- CC: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Hi Craig, Matthew, all, Yes, there are more than two solutions to the use-case. I think, Matthew solution is more a solution C than a solution B(ii). Of course, another solution (D) is to use the existing DASH-Live or HLS solution, which utilizes a sequence of segment requests with a manifest. And, these solutions are not exclusive. BR, /Thorsten From: phluid61@gmail.com [mailto:phluid61@gmail.com] On Behalf Of Matthew Kerwin Sent: Wednesday, April 20, 2016 10:17 PM To: Thorsten Lohmar Cc: ietf-http-wg@w3.org Subject: RE: Issue with "bytes" Range Unit and live streaming On 21/04/2016 6:14 AM, "Matthew Kerwin" <matthew@kerwin.net.au> wrote: > > > On 21/04/2016 5:37 AM, "Thorsten Lohmar" <thorsten.lohmar@ericsson.com> wrote: > > > > Hi Craig, > > > > > What *is* missing is the ability to get a continuous byte range on live content > > > that starts at an arbitrary offset and the ability to directly jump to the live > > > point. > > > > Yes, and there are two solutions to the issue: > > A. Enable it on HTTP Layer through the definition of a new range request method > > B. Enable working with existing HTTP procedures, i.e. client can workout the precise byte offsets. > > C. Use a different URL (e.g. a ?start= query parameter). It's less optimal for caching, but it works today without any new specs.. Sorry, that's B(ii) isn't it. > > > > > BR, > > /Thorsten > > > > Cheers
Received on Wednesday, 20 April 2016 20:42:24 UTC