From fd2e89db57a3f72f9914be3a20c3cd32e77ced1c Mon Sep 17 00:00:00 2001 From: Julian Reschke Date: Sun, 26 Nov 2017 17:10:25 +0100 Subject: [PATCH] Expand acronyms and cite HLS and DASH --- draft-ietf-httpbis-rand-access-live.xml | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/draft-ietf-httpbis-rand-access-live.xml b/draft-ietf-httpbis-rand-access-live.xml index 9af1e9a42..8b82eefe9 100644 --- a/draft-ietf-httpbis-rand-access-live.xml +++ b/draft-ietf-httpbis-rand-access-live.xml @@ -4,6 +4,7 @@ + @@ -170,7 +171,7 @@ For instance, HTTP clients have the ability to access appended content on an indeterminate-length resource by transferring the entire representation from the beginning and continuing to read the appended content as it's made available. Obviously, this is highly inefficient for cases where the representation is large and only the most recently appended content is needed by the client. - Alternatively, clients can also access appended content by sending periodic open-ended bytes Range requests using the last-known end byte position as the range start. Performing low-frequency periodic bytes Range requests in this fashion (polling) introduces latency since the client will necessarily be somewhat behind the aggregated content - mimicking the behavior (and latency) of segmented content representations such as HLS or MPEG-DASH. And while performing these Range requests at higher frequency can reduce this latency, it also incurs more processing overhead and HTTP exchanges as many of the requests will return no content - since content is usually aggregated in groups of bytes (e.g. a video frame, audio sample, block, or log entry). + Alternatively, clients can also access appended content by sending periodic open-ended bytes Range requests using the last-known end byte position as the range start. Performing low-frequency periodic bytes Range requests in this fashion (polling) introduces latency since the client will necessarily be somewhat behind the aggregated content - mimicking the behavior (and latency) of segmented content representations such as "HTTP Live Streaming" (HLS, ) or "Dynamic Adaptive Streaming over HTTP" (MPEG-DASH, ). And while performing these Range requests at higher frequency can reduce this latency, it also incurs more processing overhead and HTTP exchanges as many of the requests will return no content - since content is usually aggregated in groups of bytes (e.g. a video frame, audio sample, block, or log entry). This document describes a usage model for range requests which enables @@ -448,6 +449,16 @@ &RFC5234; + &RFC8216; + + + Information technology -- Dynamic adaptive streaming over HTTP (DASH) -- Part 1: Media presentation description and segment formats + + ISO + + + +