Chunked transfer encoding
To upload files more efficiently use HTTP chunked transfer encoding.
With chunked transfer encoding (CTE), the encoder sends data to the player in a series of chunks instead of waiting until the complete segment is available. CTE is available in HTTP 1.1.
In CTE, each chunk is preceded by its size in bytes. The transmission ends when a zero-length chunk is received.
This example shows data encoded using CTE. Note the Transfer-Encoding: chunked
header
HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked
5\r\n
Media\r\n
8\r\n
Services\r\n
4\r\n
Live\r\n
0\r\n
\r\n
The Content-Length
header is omitted in CTE and at the beginning of each chunk, you
should add the current chunk length in hexadecimal format, followed by \r\n
and the chunk, followed by
another \r\n
. The terminating
chunk is a regular chunk with zero length. It is followed by the trailer, which consists of
(may be empty) sequence of entity header fields.
Decoded data
moof
and mdat
atom. The mdat holds a single IDR
(instantaneous decoder refresh) frame, which is required to begin every segment. This figure
shows chunk encoding of a CMAF segment:
To achieve ultra low latency (ULL):
- Include HTTP 1.1 chunked transfer encoding in the header for each POST.
- Your encoder should be compliant with RFC 2616.
- You cannot define the content length in the header.
- Chunks should be uploaded immediately once available, not throttled at the beginning of the upload.
- There should be a
moof
box for every chunk.
AKAM-ENC-CONTENT-CAP-TIME
in the
HTTP header, which is passed to the ingest server and included in Akamai-Path-Timestamp
. The ingest
server does not add the encoder timestamp, if the encoder does not set AKAM-ENC-CONTENT-CAP-TIME
.Recommended options for the encoder:
- Allow control of the number of chunks per segment. This gives added flexibility to the end user.
- Provide a toggle switch to let the user enable CTE. This clarifies whether your post is chunked transfer or not.