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

Hi Craig,

Thanks very much for that. As others have noted, this has come up before; having a concrete proposal helps move the discussion forward.

I've recorded the draft on our "Potential Future Work" page:
  https://github.com/httpwg/wiki/wiki/WatchList

I'll respond in other parts of the discussion, but one quick bit of feedback; it's not a good idea to use the substring "bytes" in a new range-unit, because some implementations will be scanning for that anywhere in the header (Rodger Combs gave us a heads-up about those bugs in the previous discussion, and it's an unfortunately common pattern with other parts of the stack too).

Cheers,



> On 15 Apr 2016, at 9:26 AM, Craig Pratt <craig@ecaspia.com> wrote:
> 
> Hello all,
> 
> We have a use case where we are "live streaming" media over HTTP. As with other (non-segmented) HTTP streaming applications, our live streaming solution has the HTTP client perform a GET on a URI representing the live audio or video content stream and with the server progressively returning data using chunked transfer coding. The data returned to the server is "live" so long as the client reads data as quickly as it's generated - with TCP flow control allowing the client's reading of the response data to be paced to the live chunk generation of the HTTP server.
> 
> More recently, use cases have appeared that require a combination of random access and live streaming. For example, an HTTP media server may want to support streaming of an in-progress recording - with the HTTP client using HTTP byte Range requests to access any point within the already-recorded content. But we've run into issues supporting both live content transfer and HTTP byte Range requests on the same resource. There's no good way that we've found to get to this "live point" and also support random access. The use case requires a byte range that ends at an indeterminate point, e.g.
> 
>     Range: bytes=1234567-*
> 
> However, the ABNF for the bytes Range Unit doesn't allow for this form of request.
> 
> Rather than coming up with a proprietary solution, we are proposing a new Range Unit called "bytes-live" as a potential solution to this issue. Support for this new "bytes-live" Range Unit could be exposed by servers (using the Accept-Ranges header) for content that support both byte-wise random access and live streaming. e.g. A server that supports both the standard HTTP/1.1 bytes Range Unit and bytes-live would include the header:
> 
>     Accept-Ranges: bytes bytes-live
> 
> An HTTP client can use Range requests with the standard "bytes" Range Unit to transfer stored content from a representation. And when the bytes-live Range Unit is supported, an HTTP client can request a byte range that starts or ends at the live point of the content representation. For example, a client could request the transfer of bytes starting at byte 1234567 and transitioning to the live point once all stored content has been transferred using:
> 
>     Range: bytes-live=1234567-*
> 
> We believe the bytes-live Range Unit could have multiple applications outside of our immediate use cases. For instance, internet-connected video cameras with on-board storage could use bytes-live to support streaming of continuously recording content with lower latencies than can be achieved using HLS, MPEG-DASH, or other segmented video streaming techniques. And there are also applications with on-demand transcoding.
> 
> The draft RFC can be found here https://tools.ietf.org/html/draft-pratt-httpbis-bytes-live-range-unit-00. Please let me know what you think - and if there are other solutions we haven't considered.
> 
> Regards,
> 
> craig
> -- 
> craig pratt
> Caspia Consulting
> craig@ecaspia.com
> 503.746.8008
> 
> 
> 
> 

--
Mark Nottingham   https://www.mnot.net/

Received on Tuesday, 19 April 2016 07:19:50 UTC