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
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
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
\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.
mdatatom. 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
moofbox for every chunk.
AKAM-ENC-CONTENT-CAP-TIMEin 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
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.