Deliver video over HTTPS to make use of content distribution networks
- Video content encoded in multiple chunks
- Each chunk encodes ~10 seconds of video
- Each chunk independently decodable
- Each chunk made available in many different versions at different encoding rates
- A manifest file provides an index for what chunks are available
- Clients fetch manifest, download chunks in turn
- Standard HTTPS downloads
- But monitor download rate, and choose what encoding rate to fetch next – adaptive bitrate
- Playout chunks in turn, as they download
DASH Latency
Multi-second playout latency common, due to:
- Chunk duration
- Must download complete chunk before starting playout
- Download and decompress chunk n
- Start playing chunk n and while playing download chunk n+1
- No packets lost → latency equals chunk duration
- Playout buffering
- Encoding delays for live streaming
- TCP
- TCP retransmits after triple duplicate ack, which takes time and delays the download:
- 4x packet transmission latency, + 1x network RTT
- Reduced window
- TCP retransmits after triple duplicate ack, which takes time and delays the download:
- Chunks and Video Compression
- Each chunk of video is independently decodable
- Can’t compress based on previous chunk, because previous chunk depends on the network capacity → unpredictable
- Each chunk therefore starts with an I-frame, followed by P-frames
- I-frames are large: often 20× size of P-frames
- If chunks are smaller duration → contain fewer P-frames compared to number of I-frames; video compression ratio goes down
- Trade-off between chunk size and compression overhead
- Large chunks require less data, but add latency
- Small chunks reduce latency, but need more data
- Overheads become excessive for chunk duration ≲2 seconds
- Each chunk of video is independently decodable