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

[Craig Pratt <[e-mail]>]

Hey Thorsten,

Well, if we can demonstrate that a new Range Unit can be added safely 
with this draft, maybe adding some application-specific Range Units will 
be an easier sell.

The two RUs I'd see as being good candidates would be a time-based unit 
and a cleartext range unit - both of which have application in media 
streaming. And both can still accommodate caching (e.g. the 
TimeSeekRange response in DLNA includes the byte range corresponding 
with the response body).

Both of these could enable some pretty interesting possibilities in 
DASH/HLS as well. e.g. A DASH/HLS-aware server could field requests made 
against a manifest - allowing the manifest processing logic to live in 
the HTTP server instead of the client and reducing the amount of HTTP 
connections and chatter in the process.

Anyway, a conversation for a different day...

Happy Wednesday,

cp

On 4/20/16 3:22 PM, Thorsten Lohmar wrote:
> HI there,
>
>> 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.
> [TL] Yes, Understood, that this is not for all cases a solution.
>
>> 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.
> [TL] Yes, I think that I understand your use-case and your proposed now. I don't have a strong opinion, whether to solve the use-case on HTTP layer or not.
>
>> Happy Wednesday,
>>
>> cp
>>
>>> From: [e-mail] [mailto:[e-mail]] On Behalf Of
>>> Matthew Kerwin
>>> Sent: Wednesday, April 20, 2016 10:17 PM
>>> To: Thorsten Lohmar
>>> Cc: [e-mail]
>>> Subject: RE: Issue with "bytes" Range Unit and live streaming
>>>
>>>
>>> On 21/04/2016 6:14 AM, "Matthew Kerwin" <[e-mail]>
>> wrote:
>>>> On 21/04/2016 5:37 AM, "Thorsten Lohmar"
>> <[e-mail]> 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
>>
>> [e-mail]
>>
>> 503.746.8008
>>
>>
>>
>>
>>
>>
>>


-- 

craig pratt

Caspia Consulting

[e-mail]

503.746.8008