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