Bitrate Switching
NOTE: This document is outdated, please refer to: VIDEO DELIVERY: HTTP PSUEDO-STREAMING
Purpose
This guide will help you understand the process of bitrate switching, why it’s necessary and how to set it up.
Introduction
Stream high-quality video from a low-speed connection (i.e. limited bandwidth) and you will inevitably experience the data buffer, often indicated by the maddening “buffering” signal. To solve this problem, the JW Player (v4, v5.1, but not v5.0) utilizes a feature known as bitrate switching. Through a server-independent mechanism, the player is supplied with multiple versions of the same video and selects the version that best matches a viewer’s screen size and bandwidth. So, those with a broadband connection can watch the HD version of your video, while those with dial-up access will get a low-quality, but still smooth-playing, version. Bitrate switching is automatic in the JW Player and requires no action from the viewer.
Contents:
How It Works
The JW Player implements bitrate switching in a very basic and pragmatic way:
- Bitrate Switching is automatically enabled when the player loads an XML playlist that contains multiple videos per playlist item (setup below).
- Each video’s quality level (i.e. bandwidth type) needs to have a width and a bitrate property set.
- Based on the streaming type, the player will switch numerous times—on startup, for instance.
- At the moment of the switch, the player matches the display width to the width of the different video quality levels, and matches the bandwidth of the connection to the bitrate of the different video quality levels.
- The player then selects for playback the highest-quality level whose width and bitrate fits within the display width and connection bandwidth.
- Bitrate Switching can be down with RTMP
The number of switching moments depends on the streaming type used:
The big advantage of dynamic streaming is that no re-buffering of the stream is required. Therefore it is the only streaming type that offers bitrate switching in the middle of playback. With all other streaming types, the player only switches levels at a moment the user is already interfering with playback himself (resizing the player or seeking in the stream).
Stream switching for RTMP based upon bandwidth only works if the server implements a checkBandwidth call. This is default in FMS 3.0+, and easy to set up with Wowza. If there's no checkBandwidth handler, streams will be switched based solely on the available display width.
Example Player
In the player below, you will find an example of bitrate switching for every streaming type. The display at the top of the video (the Quality Monitor plugin) shows the current display width, bandwidth and quality level. While testing, you'll see that the progressive-download example only switches on startup and that the RTMP examples require a little rebuffering after every switch.
You'll also note it takes the FMS3.5 example about 10 seconds to update the stream every time a switch is performed. This is as expected; the server first needs to wait for the next keyframe in the video to anticipate the switch and then for the second keyframe in the video to actually perform the switch.
Get the Flash Player to see this player.
Every example in this player uses four different transcodes of the Elephant's Dream video, ranging from Youtube quality to just below 720p HD:
- A version that is 320px wide and 400 kbps.
- A version that is 480px wide and 800 kbps.
- A version that is 720px wide and 1200 kbps.
- A version that is 1080px wide and 1600 kbps.
All four versions are MP4 files with H264/AAC-encoding, whereby the baseline encoding profile of H264 is used. An advantage of this profile over the better, main or high profiles is that it needs less CPU for decoding. CPU stress is still something to keep in mind, as the JW Player does not take it along as part of the bitrate switching mechanism.
Playlist Setup
Moving to the actual setup, it is good to know that video exported by any encoding software will work with bitrate switching. There's no alignment of keyframes or other special requirements. Both FLV and MP4 are supported. You are free to select the number of quality levels to use (3 to 5 recommended), and the bitrate of these levels (200kbps to 2000kbps recommended).
No specific FlashVars are needed to set up bitrate switching. All necessary data is placed in the XML playlist, which can be assigned to the player with the file FlashVar. Here is an example XML with just a single video, played as a regular progressive download:
<rss version="2.0" xmlns:media="http://search.yahoo.com/mrss/" >
<channel>
<item>
<title>Progressive download</title>
<link>http://www.bigbuckbunny.org/</link>
<description>Big Buck Bunny is a short animated film by the Blender Institute.</description>
<media:group>
<media:content bitrate="1500" url="http://bitsontherun.com/videos/Qvxp3Jnv-486.mp4" width="1080" />
<media:content bitrate="1100" url="http://bitsontherun.com/videos/Qvxp3Jnv-485.mp4" width="720"/>
<media:content bitrate="700" url="http://bitsontherun.com/videos/Qvxp3Jnv-484.mp4" width="480" />
<media:content bitrate="400" url="http://bitsontherun.com/videos/Qvxp3Jnv-483.mp4" width="320" />
</media:group>
</item>
</channel>
</rss>
Once the player sees multiple media:content entries, it'll automatically enable bitrate switching. Note that:
- Each media:content entry does need a width and bitrate (in kbps! see the MRSS specs) attribute.
- The first matching level will be selected. Therefore, insert the highest quality level at the top and then move down the list.
- The media:group element is optional, but the media:content element is required. The enclosure or jwplayer:file entries do not offer the required attributes and therefore cannot be used.
If you use a streaming server, you can add the familiar jwplayer:streamer and jwplayer:type entries to the playlist. For example, here is:
- An XML playlist for RTMP streaming
- The XML playlist of the example above, with all streaming types.
For more playlist-related info, check the playlists section of the formats wiki page.