Creating On Demand Stream Links
Category: On Demand Streaming  
Creating Links in Reverse Proxy Mode
When using Reverse Proxy mode, the customer has a choice in how they create their On Demand stream links. Customers can elect to directly embed the Level 3 provided hostname or they can use their own hostname.
Static portion of the RTMP/MMS link/[DirectoryPath(s)]/file name
Protocol://[Level_3_provided_hostname]/[Level_3_SubscriberID]/[file_name]
e.g. mms://level3mediawm.fplive.net/level3media/directory1/sampleFile.wmv
mms://video.foo.com/level3media/directoy1/sampleFile.wmv
will go forward to
Customers can directly embed the customer specific hostname as well as any directory path that would be required to access the content at the customer’s origin server. Since Level 3 may not have the content item in its local storage, it will need the pathway to get to the content at the origin server. It is not necessary to embed the origin hostname in the URL path as that information is contained within the Level 3 streaming configuration. If the edge server does not have the content, Level 3 will fetch the content at the customer’s origin Web server using the directory path provided in the end user URL. Similarly, customers can just as easily delegate a vanity hostname, e.g. video.foo.com, via a CNAME delegation, see Integrating with Internet Traffic Manager, as well as the directory path to that would lead to the media file on the origin server. The Level_3_provided_hostname is the customer specific Level 3 generated sub-domain from the fplive.net domain. The Directory Path(s) is location where the file is located on the customer’s HTTP Web server. If the content is located in the root directory, then there should not be any path in the streaming URL. The file_name is the name of the streaming asset that is to be played.
Integrating with Internet Traffic Manager
Level 3 makes use of its Internet Traffic Manager (ITM) to provide global load balancing capabilities across the streaming platform. The fplive.net hostname is simply pointed to resolve to the ITM platform via a CNAME such that it can provide real-time decision logic on which available Level 3 stream cluster is the closest to the end user. Since the fplive.net hostname is nothing more than an abstraction to the streaming IP addresses, this provides Level 3 with some operational efficiencies to add and remove streaming servers into the platform without the customer having to make any modifications to their streaming links. Some customers may want to obfuscate the fact that Level 3 is powering their streams. In such instances, customers may wish to create their own vanity streaming hostnames and then CNAME that hostname over to the Level 3 provided hostname. As a reminder, you will need to have a specific vanity hostname per format type. W3C best practices dictate that double CNAMEing is not prudent; however, this practice will not affect most end users and is used quite commonly. e.g.
video.example.com CNAME 1d examplewms.fplive.net
If using a vanity hostname, the customer will still need to use the Content_Location directory path when constructing their URIs; however, the double CNAME will effectively hide the fact that Level 3 is powering the streams. The media player will only display the customer’s vanity hostname and not display the chased hostname to *.fplive.net back to the media player. NOTE: if an end user were to query the vanity hostname using DIG, the fplive.net domain will be returned in the answer as the nameserver will chase the CNAME in order to return an answer to the end user. Level 3 recommends that customers using their own vanity hostnames use a TTL in their DNS entry of at least 1 day to minimize DNS lookup times for the end user.
Windows Media
The Level 3 streaming platform uses native Microsoft Windows Media Streaming Servers and as such is able to leverage a wide variety of streaming protocols. Customers are free to use whichever protocol they prefer. The most common protocol is mms.
To construct a Level 3 Windows Media streaming link there are five (5) key components:
Protocol://Level 3 Hostname + Level 3 Streaming Customer ID + Content Location + Media Asset
mms://level3mediawm.fplive.net/level3media/sampleFile.wmv
-or-
rtsp://level3mediawm.fplive.net/level3media/sampleFile.wmv
The Level 3 streaming platform will pass through any optional query string parameters1 that the customer may have embedded into their stream link.
Adobe Flash
As with Windows Media links, constructing a Level 3 Flash streaming link requires five (5) core components; however the integration of these components is different:
Protocol://Level 3 Hostname + Level 3 Subscriber ID + Directory Path + Media Asset
With Flash streaming, the customer must specify the resource location. This is typically the static portion provided by Level 3.
Format:
resource=rtmp://[level3_hostname]/[Level3_SubscriberID] e.g. resource=rtmp://level3mediafs.fplive.net/level3media
Filename includes the customer-added Directory Path structure and the Media Asset (the file name itself). Place the optional file directive before the directory path:
filename= [{optional file directive}:directory path + file name]
where ‘file name’ follows this format: sampleFile.flv
If the directory path is included in the connect string, then use this filename format:
resource=rtmp://[level3_hostname]/[Level3_SubscriberID]/[Directory Path]
filename=[{optional file directive}:file name]
Flash Media service playback is a two-stage process.
♦ At stage 1, the player connects to the application (resource) on a server. See Adobe Flash Streaming Integration for more information.
♦ At stage 2, the media asset is played back.
By design, at stage 1 player should use the resource path (rtmp://[level3_hostname]/[Level3_SubscriberID]) and at stage 2 a full path and asset name (directory path + filename). For your convenience, Level 3 Flash Media service also accepts other ways of dividing the RTMP URL but the Level 3_SubscriberID must be always used at stage 1 and the media asset file name at stage 2.
Adobe Flash Helper Directives – Format Type
By default, the Level 3 Flash Media service (FMS) assumes that the streamed file asset is in some form of a FLV file; therefore, it is not necessary to specify the .flv format type in the stream path if the asset is a FLV supported content type. Depending on how the customer’s player is developed, it may still need to denote the .flv file extension, but the streaming URL does not need to include a flv helper directive.
When dealing with H.264 encoded (mp4 and its variants) or mp3 encoded content, it is necessary tell the FMS server that it is dealing with a content item other than FLV supported file. To this end, it is necessary to insert a helper file in the URI path immediately before the file asset name. The helper file is not considered part of the origin path and is extrapolated at the edge Flash Media Server before any backhand pass to the customer’s origin server location so it is not necessary to modify the actual file asset name or directory structure.
The helper directives are expressed in any one of the following supported file formats: flv:, mp3: or mp4:. The default format if unspecified is flv:. Again, it is not necessary to include the flv: file extension in the URI path. Below is an example of the application of the helper directive inserted before the file name.
Streaming URL submitted into the SWF container:
rtmp://level3mediafs.fplive.net/level3media/mp4:hdvideo.mp4 rtmp://level3mediafs.fplive.net/level3media/mp4:anotherhdvideoexample.mov rtmp://level3mediafs.fplive.net/level3media/folder1/mp3:audio.mp3
Path to origin server:
It is a best practice to have the file extension and file type directive in the URL. This is to ensure that if you have assets that are named the same; the CDN platform knows which asset to retrieve from the origin server. The request to the origin server will make use the of file extension listed in the URL. If there is a format type directive listed but no file extension, the edge FMS box will assume that the file extension is that of the helper directive in the URL path. If the format type directive is not present and your content is H.264 encoded or mp3 encoded, the file may fail to play.
location of the helper directive in the RTMP URL
It’s important to place the helper directive correctly in the RTMP link, especially when the asset is in a subfolder. The helper directive should be passed to the server at the beginning of the media asset string (including the full path).
rtmp://[level3_hostname]/[Level3_SubscriberID]/[helper:]/[full_path_to_asset]
Sample MP4 RTMP link:
rtmp://level3mediafs.fplive.net/level3media/mp4:folder1/folder2/sampleFile.mp4
However, some Adobe Flash players accept a full URL and automatically divide it into two parts. In this case it’s crucial to know how the link is divided to put the helper in the right place. Some players might divide links in the desired way (the helper directive must be placed before the path to the media asset), but it is common to use only the file name at stage 2 (the helper directive must be placed just before the file name). It also might happen that player uses one part of the path at stage 1 and the other part at stage 2, but the helper directive still must be placed at the beginning of the ‘filename’ string used at stage 2. If in doubt, please contact the player application developer to ask which part of the RTMP URL is used at which stage.
Adobe Flash Streaming Integration
Customers can use an Adobe Flash player provided by Level 3 or use one of their own preference. For more information on using the Level 3 player, see Level 3 Media Player Configuration Tool. You can insert the player code in a web page, which then calls the player from a Level 3 server. The code provided by the Media Player Configuration Tool includes this call.