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

AFAICT, the existing ABNF for byte ranges *does* already support what 
you are looking for, without having to introduce a new unit type:

     byte-range-spec = first-byte-pos "-" [ last-byte-pos ]

Simply omit the * and leave the second value empty:

Range: bytes=1234567-

RFC 2616 Section 14.35.1 says:

"If the last-byte-pos value is absent, or if the value is greater than 
or equal to the current length of the entity-body, last-byte-pos is 
taken to be equal to one less than the current length of the entity- 
body in bytes."

RFC 7233 Section 2.1 says:

"If the last-byte-pos value is absent, or if the value is greater than 
or equal to the current length of the representation data, the byte 
range is interpreted as the remainder of the representation (i.e., the 
server replaces the value of last-byte-pos with a value that is one less 
than the current length of the selected representation)."

Since the media is being recorded while streaming, the client can 
randomly jump around within the recorded portion of the media all it 
wants. Once jumped, it would simply be receiving media from the 
recording, not the live feed.  To jump back to the live feed, simply 
omit the "Range" header.

Remy Lebeau
Lebeau Software

On 4/14/2016 4:26 PM, Craig Pratt 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
>
>  
>
>
>  
>
>
>