Streaming Media Supplement sa2150 and sa2250

45
Chapter 4 Understanding Media-IXT and WMT
Understanding multi-bitrate clips and WMT
Given the situation where an origin WMT server has got a multi-bitrate clip, say a movie encoded for streaming
at three different bitrates (20kbps, 100kbps, and 300kbps), the question arises as to how Media-IXT handles
caching of such a clip.
The answer is that since a Windows Media Player client requests only one version (one bitrate) at a time, Media-
IXT serves and caches only that bitrate in response to that request. If the client connection changes (for example,
drops from T1 to 56.6K) while streaming is in progress, Media-IXT stops serving and caching the initial bitrate
and continues at the new one. So, unlike the origin WMT server, Media-IXT does not cache all the different
versions of a clip that make up a multi-bitrate clip, except in response to requests by Windows Media Players.
When a player plays a clip through UDP, Media-IXT sometimes appears to not cache the file until the third time
the file is accessed. This appears to be a bug, but is not. Here is what produces this situation, which we see only
with multi-bitrate clips:
• The different bit-rate versions of a multi-bitrate clip are in effect different clips.
• If version A has been cached, then version B is accessed for the first time, version B does not play from
cache that first time.
• If the end user is unaware of the different bit-rate versions, and thinks of versions A and B as the same clip,
the end user may conclude (erroneously) that Media-IXT failed to cache the clip.
Only sequential accesses of different bit-rate versions of multi-bitrate clips produce this behavior.
Understanding hierarchy and WMT
Understanding Media-IXT hierarchies depends on knowing the answers to two questions:
• Which Media-IXT is to be a child and which is to be a parent?
• Which caches should serve as parents for each child cache?
Configuring Media-IXT for hierarchical proxy caching is done in two stages:
• First, edit the records.config file to enable parent caching on each child cache.
• Then, edit the parent.config file on each child cache to redirect streaming media traffic to specific
parent caches.
Remember to make no changes on parent caches. All configuration is done on child caches.
Understanding live passthrough, live splitting, and
hierarchical live splitting for WMT
Live passthrough works like a configuration using live splitting, but where only one client is connected.
Understanding live splitting and WMT
In non-hierarchical forward or reverse proxy deployments, Media-IXT splits a single live stream from the origin
WMT server into multiple live streams to client Windows Media Players.
The live splitting scenario begins when the user of a web browser with Windows Media Player, viewing an
HTML page containing links to live content, clicks on one of the links.
1. The browser sends a request for the WMT metafile corresponding to the live content chosen by the user.
2. Media-IXT receives the request, obtains the WMT metafile from the HTTP server, rewrites the contents of
the metafile, then serves the metafile to the browser.
3. The web browser receives the metafile and sends it to Windows Media Player.