Apple’s HTTP Live Streaming and Adobe’s HTTP Dynamic Streaming both adapt to different and dynamically changing network speeds by selecting video segments (or chunks) from different encoding profile. So how does the client playing back the video know which segment (chunk) to deliver? The client calculates the available network bandwidth availability by comparing the download time of a segment with its size.
Using a manifest file (A manifest file is basically a metadata ‘pointer’ that points at the video asset. Manifests include file types like .smil or .asf) .m3u8 or .f4v) that references profile bitrates (or resolutions or codecs) of available video. HTTP Live Streaming or the other adaptive bit rate methods can determine if it needs to ‘adapt’ to changing bandwidth conditions and downshift the quality of the video, or the opposite, increase the quality based on bandwidth availability.
This list of available segments that can be switched to (the official word is ‘profile’ – so the list of available profiles that can be switched) is called a ‘manifest’. The client’s bandwidth calculation is repeated at every ‘chunk’ or video segment download. The client can adapt to changing network bandwidth or other conditions every few seconds.
In addition, CPU load or inability to play a resolution (e.g. too big of a width) can affect the client’s choice of ‘profile’. Bandwidth negotiation has been around for quite awhile. Windows Media Services was good at it, Real was good at it, Darwin Streaming Server was good at it. HLS delivery? Seems OK, there’s lots of opinions out there, so you’ll need to find out if adaptive bit rate streaming is effective yourself.
15 karma points