Media Flow Controller internally decomposes this request into the relevant configured namespace and, if the virtual player type assigned to that namespace matches the SmoothFlow player type (Type 4), then, by recognizing the state of
sf =
4, Media Flow Controller initiates SmoothFlow processing for the asset referenced in the retrieved Asset Description file. SmoothFlow processing is only done when a SmoothFlow process request from the publisher, in the form given above, is received, or when there is a cache miss in real time. If the pre-staging is to an attached NFS library, then the publisher can see the listing of the files published using their FTP client. If the pre-staging is to Media Flow Controller directly, then they can use the
namespace object list all command to see the listing.
This XML file, called the SmoothFlow Control file, is created by the Media Flow Controller SmoothFlow processor when SmoothFlow processing is successfully initiated; it provides the information the player needs to request different bitrates in response to changes in bandwidth. Your client player must know how to read it. You can imbue your client player with this intelligence through the Juniper Networks SmoothFlow SDK or API, available through Juniper Networks Customer Support (not necessary when using the Juniper Networks SmoothFlow Reference player). This file is requested with SmoothFlow state 2 (
sf=2). The Smoothflow Control File should not be copied from other assets—each one is unique and generated by the publishing process for that particular asset. The file is output to the The schema for this file:
<profile_name> p1 </profile_name>
<profile_name> p2 </profile_name>
<profile_name> p3 </profile_name>
•
|
sf_version (optional)—Version of Smoothflow being used in Media Flow Controller
|
•
|
n_profiles—Number of available profiles for a given media asset
|
•
|
profile_name—Identifier string for a profile; this needs to be sent if the client wants to request a specific profile
|
•
|
br—Bitrate of the profile
|