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

[Craig Pratt <[e-mail]>]

On 4/15/16 5:36 AM, Amos Jeffries wrote:

On 15/04/2016 11:26 a.m., 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.

Please be careful not to rely on the chunks arriving at the client in
the same sizes as were sent.

The chunked encoding is a hop-by-hop feature so any HTTP intermediary
which they travel through may re-code the chunk sizes according to its
own output needs.

Cheers
Amos

Most definitely - the client cannot make any presumption about the framing. In the renderers I've worked with, the chunk framing is removed before the AV renderer get the content.

The chunk size can affect the performance of the streaming, however. A single large chunk can cause a client to stall and introduce latency that persists for the duration of the streaming session. But clients are typically able to handle these "late" arrivals since they can also be caused by congestion.

What we're trying to prevent with this EC is requiring the client to continuously perform GETs to receive new chunks if/when the live content also supports random access. We want the client to simply be able to block on the socket while waiting for the data to arrive in the same way it would for a non-random-access live stream.

cp

--

craig pratt Caspia Consulting [e-mail] 503.746.8008