Beginning Flash Media Server 4.5 – Part 6: Using HTTP Dynamic Streaming

This article is the sixth in a series of beginning-level tutorials about Adobe Flash Media Server 4.5. This particular tutorial gets you started using Flash Media Server 4.5 to stream video over HTTP, rather than the RTMP standard used to this point in the series, and how to use both the HTTP and RTMP protocols to stream videos that target a device's bandwidth limitations using multi-bitrate manifest files.

In many respects, HTTP Dynamic Streaming (called HDS for the rest of this article) is Adobe's response to Apple's Adaptive Bitrate Streaming and Microsoft's IIS Smooth Streaming technologies. Common to all three is the ability to deliver media through HTTP Internet connections and deliver the media file best suited to the user's current bandwidth. An Android device has seriously less bandwidth available to it than a PC with an Ethernet cable plugged into it. The end result is smooth media playback on a multitude of devices ranging from smartphones to desktop computers.

To understand how HDS works, step away from the technology and consider the following imaginary scenario:

ABC Video Services has just completed work on a one-minute video and, instead of using a video cassette to package the tape, the boss, Pete, has a brainstorm. "How about we forget about cassettes," says Pete, "and deliver the video to the user in a more efficient manner?"

The guys in the studio are a bit taken aback by this radical idea because everyone knows "this is the way we have always done it." Pete is not accepting this argument and makes the following case:

"Why not cut the tape into ten six-second pieces and feed them, sequentially, into the device playing the video?"

Sam, who is a bit of a traditionalist, thinks this is a really dumb idea, but Pete is his boss, so he doesn't want to say so. He thinks about it for a minute and has a rebuttal he thinks will kill this idea in its tracks. "Pete," he says, "that sounds interesting, but it won't work. The client is going to get a bunch of tape strips that all look the same. How do we know the client won't mess up the order of the tape pieces?"

"Really easy," says Pete. "We give the customer a file that tells the device which strip gets played at what time. All we have to do is to package up that file and the strips and send it to the client. All the client has to do is open the instruction file, read it, and everything else goes as planned."

That is not how HDS was born, but it captures the essence of the technology.

So how does HDS relate to Pete's idea? HDS is made possible by the Apache modules that you installed along with Flash Media Server (FMS). In this case, FMS serves as a packager to create content fragments that are served up by Apache, over HTTP, to a Flash-compatible video player. To deal with Sam's objection, another file called a manifest, with the F4M extension, is also created through this same process. Basically, the video being requested is first sliced into a number of fragments to be served as segment files using the F4F extension. Fragments themselves do not have an extension. A manifest contains the basic video information, the location of each fragment, and, most important of all, the order in which these fragments are to be streamed into the user's device.

Where does FMS 4.5 fit into this process if the whole thing is streaming through an HTTP connection? Flash Media Server 4.5 contains two types of real-time packaging: live and Just-In-Time (JIT). In either case, the manifest and F4F files are created upon request and sent over HTTP to the client for playback. For example, if Sam has a smartphone and wants to watch the video he just edited, all he needs to do is to open his device's browser and go to the web page containg the SWF file for the video. When the SWF file opens, it simply requests the F4M manifest file, which starts the fragments flowing into the device's browser in the proper order.

Being the contrarian he is, Sam immediately sees an issue with this scenario. "Guys, I'm on a 3G network. It's slow; I don't have the bandwidth you guys have with an Ethernet connection. This is going to be a bad experience."

Thankfully, Pete is there. "Sam," says Pete, "settle down. That is a non-issue. The manifest is going to hand the playlist off to the SWF file, which will check your connection and, if your bandwidth is low, check the manifest and grab the specific video files optimized to that bandwidth. We call it 'multi-bitrate streaming,' and you are going to love it."

Speaking of which, it's time to show Sam some love.

Though the HDS terminology sounds rather "techie," the process of creating an HDS application is dead simple:

1. Download and uncompress the exercise files for this installment of the series. You will see a video of a waterfall in the folder. This video is already in the format required by HDS: F4V with H.264 video and AAC audio codecs applied.
2. Place the file in Program Files/Adobe/Flash Media Server 4.5/webroot/vod, as shown in Figure 1. With the files in place, you can now start to use HDS.

3. Open the sample media player found in Flash Media Server 4.5/samples/videoPlayer/videoPlayer.html.
4. In the Stream URL area, enter http://localhost/hds-vod/Waterfall.f4v.f4m and click the Play Stream button. As you can see in Figure 2, the video starts to play.

You may be wondering: "What happened?" The first thing you need to know is that the path is the key. The F4M extension tells FMS that you want a manifest file for this stream. The hds-vod mapping starts the Just-In-Time (JIT) process by pointing to the path on the server holding the files that need to be packaged. Flash Player opens the package, grabs the information it needs around the stream from the manifest, and starts requesting the fragments listed in the manifest that are needed to play the video.

You also may have noticed, if you have been working through this series, that the RTMP protocol was replaced with HTTP. Forget to add "http://," and you will get an error message in the player that essentially tells you, "Sorry, but I can't find what you are looking for."

On top of using RTMP instead of HTTP, the HDS process is a lot different from anything presented so far in this series. Flash Player needs a lot of logic contained in the manifest file to parse the manifest and then play the fragments in order. Flash Media Playback, Strobe, and OSMF already have this ability "baked" into them, which makes them ideal for HDS situations. They deliver on-demand streams through HTTP to Android devices, Flash Player 10 or later, and AIR applications. The requirement for iOS devices is slightly different, and will be covered later in this series.

As one of this series' authors is fond of saying to his students: "Trying to shove an HD video playing on your computer through your device is like trying to push a watermelon through a worm." With the rise of mobile, you have no guarantee that the video you encoded to play in a bandwidth-rich environment is always going to play in such an environment. Mobile networks have limited bandwidth, and I am sure many of you have opened videos on your Flash-enabled devices and experienced that watermelon moving through the worm.

The solution to encode the same video at varying bit rates. In this example, the Waterfall video is encoded with bit rates of 500, 1000 and 1,500 kbps using Adobe Flash Media Encoder. In this section, I am going to demonstrate multi-bitrate (MBR) streaming using RTMP and HDS.

RTMP and MBR

Just as in the previous exercise, you have a number of files to be streamed from FMS. In this case, they are separate F4V files that will be tied to available bandwidth, not the fragments. In either case, you still need a manifest file. The difference here is that you need to create the manifest file that loads the appropriate video based on available bandwidth. That's the bad news. The good news is that a simple manifest file is really easy to create. In fact, I have included one in the RTMP_MBR folder. Take a look at it:

1. Open the Waterfall_rtmp.f4m file in a text editor or Adobe Dreamweaver CS5. When it opens, you will see, as shown in Figure 3, that it really is nothing more than a flavor of an XML file with the F4M extension.

Note: The sample file provided is based upon the rtmp_sample1_manifest.f4m file found in the Program Files\Adobe\Flash Media Server 4.5\webroot\vod folder that was created when you installed FMS on your PC.

The important areas here are the <streamType> and <media> tags. There are three possible values for <streamType>. If you are using a pre-recorded video, then recorded is what you need. If you are using Flash Media Live Encoder (FMLE), then you need to use live. If you are unsure, it is possible to cover your bets and use liveOrRecorded.

The <media> tag simply contains the name of the file to be loaded and the bit rate that determines which video is loaded. The logic for all of this is already in Flash Player.

2. Put everything where it belongs on the Flash Media Server 4.5. In the FMS folder in your Programs folder, navigate to …webroot/vod and place the manifest in this folder, as shown in Figure 4. It needs to be here because this example uses the RTMP "flavour" of MBR.

3. Select the three videos in the RTMP_MBR folder and copy them, as shown in Figure 5, into …applications/vod/media. RTMP streams are fed out of the applications folder.

4. With the videos in place, you can now test a multi-bitrate feed. Navigate to the videoplayer.htm file found in …Flash Media Server 4.5\samples\videoplayer. When the player opens, in the Stream URL area, enter http://localhost/vod/Waterfall_rtmp.f4m. Click the Play Stream button and, as shown in Figure 6, the video plays.

Why HTTP if this uses the RTMP protocol? The manifest is being served from the local web root, which uses HTTP. The videos, on the other hand, are located in applications/vod, which is where media to be streamed using the RTMP protocol are stored.

When you clicked the Play Stream button, the play list in the manifest detected the bandwidth and started playing the Waterfall_1500.f4v file simply because the stream is being played locally and bandwidth isn't an issue.

HTTP Dynamic Streaming (HDS) and MBR

The process of preparing a playlist for HDS is quite a bit different from the previous example, because you will be creating the manifest file yourself and will invoke the playlist directly instead of instructing the server to create it in real time. In this example, you will be using a tool named "the Configurator" which was installed when you installed FMS.

1. Navigate to the Adobe\Flash Media Server 4.5\tools\f4mconfig\configurator folder and open the f4mconfig.html file located there. When the file opens, as shown in Figure 7, you will see the interface for the Configurator.

Though it looks quite complex, just keep in mind you are about to do more copying and pasting than anything else. What the tool does is to add streams to a manifest file or playlist that you can then save for HDS use. You can then play that file in an OSMF or Strobe video player. The end result is that you will have created a video application or project which uses HTTP Dynamic Streaming to deliver an optimized video bit rate over standard HTTP connections.

Note: The M3U8 tab is used to create multi-bitrate playlists for streaming to Apple iOS devices, which will be covered in greater detail in the next installment of this series. Use the f4m tab for everything else.

2. Click the f4m tab and select the Stream URI field. Enter http://localhost/hds-vod/Waterfall_500.f4v.f4m.
3. Select the text you just input and copy it to the Clipboard.
4. Select the Bitrate field and enter 500.
5. Click Add and the path and bit rate you entered appear in the Playlist, as shown in Figure 8.

6. Select the Stream URI field again and paste the text from the Clipboard. Change the 500 in the filename to 1000, enter 1000 as the Bitrate field, and click Add. Repeat this step once more using 1500 as the values.
7. Click Save Manifest and, when the Save As dialog box opens, name the file Waterfalls_hds.f4m and save it to the HDS_MBR folder in your Exercise folder. Open the folder and copy the three videos and the manifest to the Clipboard.
8. Navigate to the Adobe\Flash Media Server 4.5\webroot\vod folder and paste the contents of the Clipboard into the vod folder.
9. Open the videoplayer.html file and enter http://localhost/vod/Waterfalls_hds.f4m. When you click Play Stream, you are, as shown in Figure 9, watching a video of the Sand River Falls in Northern Ontario.

Flash, OSMF, and HDS multi-bitrate streaming

To this point you have been using the player that ships with FMS 4.5. In this final exercise, you go out to the Internet to use the Open Source Media Framework ActionScript library to stream the video.

1. Open the HTTP_Manifest.fla located in the Flash folder contained in your Exercise folder. When the file opens, you will see the error message shown in Figure 10. Don't let it bother you. It is telling you it can't find the OSMF.swc file in your Flash folder. Click OK to close the error message.

2. Select the Stage and open the Properties panel.
3. Click the wrench icon beside the Script area. This will open the ActionScript Settings dialog box shown in Figure 11.

4. Click the Browse to SWC file button and navigate to the OSMF.swc file in the Flash folder. Click OK to add it and you are good to go.

Now that you have linked to the SWC file, take a look at the code that uses the OSMF video player.

5. Select the first frame of the actions layer and open the Actions panel. Start with the first code block:

All this does is import the classes necessary for this example, which are contained in the .swc file.
The next line is important:

You need to point to the manifest file on the FMS server. Also note that this uses HTTP and uses the hds-vod application found in the web root. (While this example uses HTTP, it's imprtant to note that RTMP is also fully capable of using multi-bitrate manifests to intelligently serve video through FMS!)

Now that Flash Player knows where to find the manifest, you need to add the MediaPlayerSprite object to actually show the video stream. This object also needs to be placed on the Stage and its dimensions set to those of the video. It also won't hurt to deal with scaling. This is all handled in the next code block:

The final code block adds the OSMF player to the Stage and points it to the manifest:

6. Close the Actions panel and save and test the project.

Adobe quite strongly recommends that OSMF be used for F4M manifest files because of the complexity involved. OSMF greatly simplifies the use of video within all manner of Flash projects.

This has been a rather fascinating installment in the series. You have been shown how to use HTTP Dynamic Streaming, how to use multi-bitrate streaming with both HTTP and RTMP, and how to use multi-bitrate streaming in conjunction with the Open Source Media Framework (OSMF) supported by Adobe and other industry partners.

Here are some more resources to check out from the Flash Media Server Developer's Guide:

• Stream on-demand media (HTTP)
• Stream live media (HTTP)

The next installment will move into the mobile space and show you how to stream videos to Apple iOS devices.