Review: Wowza Media Server 2
If only all servers could be this easy to configure.
For those who aren't used to setting up streaming servers, the idea is often daunting, especially with multiformat servers that run on Windows, Red Hat Linux, or Mac OS X platforms.
When I started the review process, I set aside several hours to configure the server for basic video on demand (VOD). Yet, once the software was downloaded and installed, and a licence key added, I was able to get the entire VOD setup running for multiple simultaneous devices in less than an hour.
I found 90% of the information I needed for the simple setup in the online self-help guide (www.wowzamedia.com/quickstart_2_1_2.html; also shown in Figure 1). The "Wowza Media Server 2 Quick Start Guide for Version 2.1.2" mimics the included "User Guide" PDF. I chose the online version since I'd downloaded a clean install of the 2.1.2 version, which was released in late July.
Simple Setup
From the quick-start guide, I was able to follow the simple instructions to set up the server for VOD playback within 25 minutes. I then went on to load both Wowza's included VOD content-an MP4 file and an M4V file-and a few of my own MP4 files into a single content folder.
My test equipment, since I was on the road, was a borrowed desktop machine that fitted the server criteria Wowza recommends, as well as two laptops, an iPhone 3GS, and a Verizon MiFi. The MiFi gives me both limited external connectivity, with enough bandwidth to do a single live stream on Verizon's data network, as well as an integrated five-unit Wi-Fi access point.
Once I had everything set up, I followed the steps to stream Wowza's provided MP4 and M4V content on the iPhone 3GS, a Flash Player 10.1 playback within one laptop's web browser, and an RTSP stream on another Mac via QuickTime Player.
It was too simple, which made me think I might have done something wrong, so I started poking around in the folders of the media server installation (under the root-level Library folder on the Mac) to see what I could find.
Missing Manifests?
What I didn't find confused me a bit more: there were no playlist files or manifests, as they're often called. I looked in each of the installed folders and didn't find the playlists, yet the stream I was viewing on the iPhone was clearly using one, since I had to add "/play list.m3u8" to the end of the URL after the MP4 or M4V file name.
To understand the missing manifests so that I would know how to prepare one for my own content, I went to the next level of support: the Wowza forums. The forums have quite a bit of useful information, but they don't have robust search capability, so I used Google to try various search parameters.
A posting in the forum (www.wowzamedia.com/forums/showthread.php?t=8588) solved the problem for me: Wowza Media Server itself creates the various playlists. In fact, Wowza can't use the m3u8 playlist that is created when content is segmented for adaptive bitrate (ABR) playback on an iPhone or iPad. More on that in a minute.
Wowza's creating the manifests does have benefits: not only can MP4 files be used, but the heavy lifting of the segmentation and playlist creation is done by the Wowza server, allowing for a much simpler URL string setup.
If your VOD file sits at the top level (within the content folder) it's possible to just create a URL string that looks like this:
[protocol]://[wowzaserver]:1935/vod/mp4:file name.mp4
The URL string is fairly straightforward, with the protocol header being anything from RTSP to RTMP to HTTP, depending on which device, player, or delivery protocol is used.
Wowza defaults to port 1935 to serve up content, and any files that are set to be served up are designated by the application as being in the VOD folder (even though they're really in the Content folder).
The designation in the URL string that comes just before the filename ("mp4:") designates that the file the server will need to address is H.264-based, regardless of its three-letter extension.
Minimal Prep; Multiple Protocols
The only prep work that one needs to do for single-bitrate files is to make sure the URLs are available for any protocol or device on which
the original H.264-based MP4 or M4V file will be played:
• Apple iPhone URLs add "playlist.m3u8" after
the rest of the URL, like this: http://[wowza
server]:1935/vod/mp4:filename.mp4/
playlist.m3u8. This is true regardless of
whether the iPhone will be doing adaptive
bitrate or just single bitrate file playback.
• Flash video playback, using Wowza's sample
Flash player, is slightly different in that the
server and stream information are split
apart. The Flash player prompts server
information ("rtmp://localhost/vod" works if
you're playing content on the Flash player
from the same server) and then the stream
information ("mp4:filename.mp4").
• Microsoft Silverlight Smooth Streaming
is also played back from an included
Silverlight player, a new addition to the 2.1.2
version server download. Both the Flash and
Silverlight sample players are helpful for
testing and familiarity purposes.
• Silverlight adds a "/Manifest" to the end of
the URL string to designate that the manifest
is available for playback, so the URL looks
like this: http://[wowzaserver]:1935/vod/
mp4: sample.mp4/Manifest (see Figure 2).
• RTSP playback is very straightforward:
rtsp://[wowzaserver]:1935/vod/mp4:
filename.mp4
When it comes to stream output, it's easy to see where Wowza Media Server really shines. Because what's most interesting about Wowza Media Server is all the preparation work you won't have to do before putting a VOD file into the Content folder.
For other multiprotocol servers, all the manifests and playlists need to be created ahead of time so that the server can simply serve up each set of files and manifests to the appropriate device. Wowza, on the other hand, uses standard MP4 or M4V files and then creates the manifest or playlist during the stream serving process.
For ABR, however, Wowza makes use of a SMIL file, which must be prepared ahead of time (Figure 3). Readers from the early days of streaming will remember SMIL as the language used by RealPlayer to designate which of several files should be chosen for playback with the player or browser. Streaming servers often offered up between three and five different bitrates that were referenced by the SMIL file, so this method of delivery was often known as multibitrate (MBR) streaming. Only one stream was chosen at the outset, though, and playback was locked to that bitrate regardless of what type of network congestion ensued.
ABR uses the same number of bitrates as MBR, but it can use any of the different bitrates throughout the course of playback. To do so, the files must be segmented into 2- to 10-second chunks, and then the server designates which bitrate will play back for that period of time.
Wowza not only changes protocols (from HTTP to RTMP to RTSP) but also creates segments for sets of files that share all the same parameters, with the exception of the bitrate. To do so, Wowza is using SMIL as an aid to its on-the-fly segmentation for ABR playback.
In the version I tested, Wowza Media Server 2.1.2, the server supports segmentation of Apple and Microsoft content for iPhone and Silverlight players, respectively.
"Wowza performs all the necessary segmentation," Alex Dobrushin, chief marketing officer of Wowza Media Systems, told me after I'd finished up my single-bitrate protocol conversion testing and was moving into multiple bitrate tests. "That is the key to Wowza's unified workflow. The same standard MP4 file can be streamed simultaneously to Flash RTMP or HTTP, Silverlight, QuickTime (RTSP), iPhone, etc."
To take advantage of Wowza's ABR capabilities, the server looks for two or more files that vary by bitrate but that share key frames synchronised, on the assumption that key frame synchronised files were encoded at the same time.
"The server will use the transport and perform the segmentation as appropriate for the given player," Dobrushin says. "Provide the files and Wowza server will take care of the rest-it will do segmenting as appropriate."
This is all quite clever. Wowza's version of serving up files puts the intelligence in the server, allowing the human work to be focused on choosing what bitrates make the most sense for overall playback.
Wowza also eliminates a decision point when it comes to types of file formats and extensions for H.264-base files, as Wowza supports FLV, M4V, MOV, MP4 extensions. These standard MP4 files, each at their own single bitrate, can be streamed to any protocol that supports raw H.264 streams; that's the essence of protocol conversion.
In addition, files that share the same keyframe parameters but have different bitrates can all be loaded into Wowza without the need to address segmentation beforehand. This means that the SMIL file can be edited easily in a text editor should an additional bitrate be required for a new device's optimal bitrate.
The company has also made available a preview of Adobe's Dynamic Streaming, also known by its original code name, Zeri.
"Just to be clear," Dobrushin says, "the current Wowza preview of Zeri [in a downloable zip file] supports VOD dynamic streaming and single bitrate live streaming. The final will support dynamic live streaming as well."
Subfolder Snag
So back to the testing. Now that I understood how Wowza Media Server created its own manifests as well as the need for SMIL files for ABR content, I put my stand-alone and grouped files into subfolders and added SMIL files.
When I tried to play the content back, though, it wouldn't play in Flash player, on the iPhone, or in QuickTime.
Up until this point, I'd spent less than an hour on setup, streaming single-bitrate files to VOD, and checking up on questions about manifests. It took about another 12 minutes to download the multiple-bitrate example files and their corresponding SMIL file, and about another 3 minutes to create my own SMIL file. So, at the most, I'd spent 75 minutes from download to streaming multiple single-bitrate files.
Then I ran into two snags. The first involved subfolders, which I'd inadvertently created as a problem for myself by consciously intending to keep different types of files in different folders. The second was Silverlight playback.
The same forum post I'd found earlier also solved the subfolder question for me: reading further down the forum post, I found that the use of a subfolder requires an application instance that must be called out within the URL string, in the form of a "definst" after the "vod/" and before the "/subfolder1" or "/subfolder1/ subfolder2" portion of the URL.
"Combining connection info and stream in a single RTMP URL string would yield [a] URL that looks like this: rtmp://[wowza-address]/vod/ mp4:filename.mp4," Wowza support team member Richard Lanham wrote in response to a question about subfolders. "Using JConsole, you will see [a] _definst_ designation, to define an application instance."
This goes back to my earlier comment about the content being in a Content folder, but the URL uses a VOD folder designation instead. Wowza Media Server is defining an instance in which it automatically looks at the Content folder if VOD is designated as a folder in the URL string.
"If the video is located in a subfolder (in /content/subfolder/filename.mp4), and you try to designate just the subfolder (rtmp://[wowza-address]/vod/subfolder/mp4:filename.mp4) it won't work," Lanham wrote. "To make it work, the _definst_ must be placed between /vod/ and the file name."
In other words, in our example, we'd see the URL looking like this: rtmp://[wowza-address]/ vod/_definst_/subfolder/filename.mp4.
"In cases where application instance is not explicitly specified, Wowza takes care of it," Lanham wrote, "but in cases where subfolders are involved, you have to specify the application instance to disambiguate application instance from folder path. Or it won't work."
Within 15 minutes, I was up and running multiple-bitrate files, complete with the original SMIL file I'd created, as ABR for iPhone and QuickTime on the Mac OS X laptop.
Silverlight Setback
The final step I had to do for Wowza Media Server 2.1.2 was to get Silverlight Smooth Streaming running. The quick-start guide made it sound simple, but it took several hours for two primary reasons: first, I had to create an XML file and stick it in a particular file, then restart Wowza. While this isn't a daunting task, since I've done XML, PHP, and HTML code by hand, I inadvertently forgot to convert the copy and paste from the quick-start guide to plain text, so the formatting from the browser came with it.
When it was placed in the particular folder and Wowza restarted, I was then able to check to see if the file returned the text when I typed in the XML file's location. It did, although it was in a long string instead of the way XML typically displays. After emailing a few rounds with tech support, I discovered that the formatting was causing an issue with Wowza's ability to read the XML. I was instructed to copy the same XML file from another location.
Once that copied file was in place, Wowza was restarted and the URL was typed in-the screen returned blank. That led to the second discovery: Safari doesn't return XML content like Firefox and Internet Explorer do, since the Safari Webkit renderer thinks it's supposed to be hidden code (which is the true for all Webkit-based browsers).
So after all of that, the copied file worked fine. Why that wasn't the first approach, instead of creating another XML file, is still a mystery to me, although I understand from Wowza CTO Charlie Good that the company's goal is to keep the initial Wowza Media Server setup as clean and secure as possible.
Tech support was very helpful in the matter, so while it took a few extra hours to nail down that problem, I was still able to do all the VOD tests-including Smooth Streaming-in less time than it takes to set up a single-format server. That's pretty impressive.
Closing Thoughts
In closing, I wondered whether the use of SMIL files was short-lived now that the Apple playlist M3U8 format has been submitted for consideration as a standard, and also now that so many encoding systems already create a manifest for H.264 files.
"The choice to use SMIL was to try to normalise the multibitrate setup process across all the streaming technologies," says Dobrushin, in answer to this question. "The way it works now, a single SMIL file can be used for iPhone, Silverlight, and Flash HTTP streaming. M3U8, on the other hand, is very Apple specific."
This approach, to me, sums up Wowza's philosophy: break the streaming process down to its basics, with an H.264 file in any format, which can then be streamed to any other format or protocol. Then generate playlists on-the-fly for single bitrate files, and use the common-denominator SMIL file to tie together multiple bitrate files, which Wowza then segments on-the-fly. It's a process that looks simple to the content delivery technician and seamless to the end user but, like any good technology, is highly complex just beneath the surface.