Re: Issue with "bytes" Range Unit and live streaming

On 4/20/16 1:40 PM, Thorsten Lohmar wrote:
> 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
Switching to HLS or DASH is not an option for every application, of 
course. And that certainly implies an additional layer of complexity 
when one just wants to provide access to a progressively-updated 
representation.

Media streaming aside, there's always been awareness of 
progressively-updated representations in HTTP (IMHO). All we're really 
trying to do with this draft is enable a Range request that accommodates 
progressively-updated representations. I see this as a simple oversight 
with the bytes Range Unit that we're trying to remedy in a 
least-impactful way - one that many people have recognized but has not 
yet been addressed by an RFC.

Happy Wednesday,

cp

>
> 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


-- 

craig pratt

Caspia Consulting

craig@ecaspia.com

503.746.8008

Received on Wednesday, 20 April 2016 21:36:41 UTC