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

[Craig Pratt <[e-mail]>]

Thanks Göran.

Clarifications in-line.

cp

On 4/15/16 12:03 PM, Göran Eriksson AP wrote:

Hi,

Have a similar use case in a slightly different context. I find the draft
and discussion useful.

A few questions inline.

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

<bhs> Yes the client can make an open-ended request. The problem is the
server has no means of providing an open-ended response.

You mean response must contain content length?

[cp] Remy answered this: Content-Length is not expressly required (since that would prevent chunked and other transfer encodings). But the Content-Range header can only communicate a fixed response.

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)."

<bhs> Correct. The server is required to provide an actual value for
last-byte-pos. And that value is based on the current length. If the
server is recording
the content from a live stream, whatever value the server provides will
no longer be the last byte almost as soon as the value is sent. The
actual endpoint is constantly increasing.

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.

<bhs> The use case is not one of the client recording the stream. It is
of the server recording the stream. Let me see if I can explain the use
case better.
The user is watching content on a client that is being streamed from a
server. The server is recording the content from a live stream.
The client has limited
memory and can only buffer about 15 seconds worth of content.
The user pauses watching the content and comes back after 1 minute to
resume. The client sends the server a request to provide content from the
paused byte position
to “-“. 
The server is required to provide a response that has an actual last byte
value. The only last byte value the server has is the one for the precise
moment of
the request. After a minute, the server has a minute more of content but
has provided the client with the content up to that responded last byte.

Isn’t the server providing the client with a new manifest with the latest
‘last byte’ every 15 seconds or so? Or are you after a solution where this
approach is not used, instead with an “open request” in the request
template?

Would be good to know what kind of media player behaviour is assumed here,
especially the manifest part of it.

[cp] The media player in this case doesn't assume the presence of a manifest or any other kind of segmented content representation. Think of a single transport stream or fragmented MP4 (iso bmff) (represented by a single URI) that grows over time.

Shouldn’t the server stop sending bytes once it gets to the value of its
responded last-byte-pos? Even though
it has now a whole lot more bytes and we know that the user just wants
to keep watching? Should the client be expected to make continual
requests to keep up with the ever-increasing endpoint?
The purpose of this proposal is to allow the server to provide an
open-ended response, so the server can send bytes that it didn’t have at
the time of the original
request.

Barbara

--

craig pratt Caspia Consulting [e-mail] 503.746.8008