24 October 2011
Some previous experience working with Flash Media Server is recommended. Prior knowledge of web design concepts and using HTML to play Flash video online is helpful.
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.
Here are all of the articles in the series (links will become active as the articles are published):
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:
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.
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:
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
<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
<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.
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.
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.
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.
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.
Now that you have linked to the SWC file, take a look at the code that uses the OSMF video player.
import org.osmf.media.MediaPlayerSprite; import org.osmf.layout.ScaleMode; import org.osmf.media.URLResource;
All this does is import the classes necessary for this example, which are contained in the .swc file.
The next line is important:
var manifestResource:URLResource = new URLResource("http://localhost/vod/Waterfalls_hds.f4m");
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:
var mediaPlayerSprite:MediaPlayerSprite = new MediaPlayerSprite(); mediaPlayerSprite.scaleMode = ScaleMode.LETTERBOX; mediaPlayerSprite.x = 32; mediaPlayerSprite.y = 74; mediaPlayerSprite.width = 736; mediaPlayerSprite.height = 506;
The final code block adds the OSMF player to the Stage and points it to the manifest:
this.addChild(mediaPlayerSprite); mediaPlayerSprite.resource = manifestResource;
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:
The next installment will move into the mobile space and show you how to stream videos to Apple iOS devices.
This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License. Permissions beyond the scope of this license, pertaining to the examples of code included within this work are available at Adobe.
Tutorials & Samples
|11/30/2015||Continued Support for Adobe Flash Media Live Encoder?|
|11/08/2015||Blackmagic ATEM TVS and Flash Media Live Encoder|
|11/27/2015||Media Server using rtpm input from another server?|