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

Reply in-line.


On 4/20/16 1:14 PM, Matthew Kerwin wrote:
> On 21/04/2016 5:37 AM, "Thorsten Lohmar" < 
> <>> 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.
[cp] We can't use a different URI in our application (the UPnP CDS and 
DLNA RUIH guidelines only one URI per resource).

[cp] We can define a custom header. But (a) it appears that the feature 
we're describing has been requested many times over, (b) at least having 
an RFC enables caches to be implemented. Using a custom header or URI 
will require caching to be disabled by the origin server.

[cp] One point I haven't mentioned about caching with bytes-live: Since 
the bytes-live Range Unit is designed to work in concert with the bytes 
Range Unit (not superceded it), caching can still be performed by 
proxies that don't understand bytes-live. The read-through and hit ratio 
will be reduced. But there's still opportunities to cache.
> >
> > BR,
> > /Thorsten
> >
> Cheers


craig pratt

Caspia Consulting




Received on Wednesday, 20 April 2016 21:08:32 UTC