Streaming Learning Center Where Streaming Professionals Learn to Excel
Related Articles
Real-time cloud transcoding is the future of live event streaming, and it’s here now from several companies, including Brightcove subsidiary Zencoder, which was among the first to announce a live transcoding product. In this review, I’ll describe how the service works, as well as my experience testing it via Brightcove’s Live Streaming service, which uses the Zencoder service to transcode incoming streams to multiple iterations and flavors.
Briefly, a live transcoding service accepts a single live stream in, which it transcodes to multiple streams for adaptive distribution to one or more target groups, such as Flash and iOS devices. You’ll see details on how this works later. I’m bullish on live transcoding because it solves two key problems faced by most live event producers.
Specifically, most event producers want to serve both high-bandwidth viewers on fast connections and powerful computers and low-bandwidth viewers on smartphones and tablets. To accomplish this, event producers typically deploy adaptive streaming technologies, which require multiple live streams configured for different bandwidths and playback platforms. As a practical matter, in today’s world, this means producing one set of adaptive streams configured for Flash playback for desktops, notebooks, and older Android devices, and another set of adaptive streams configured for HTTP Live Streaming (HLS) playback for iOS and recent Android devices.
If you want to produce those streams onsite, however, you’ll need a hardware encoder that costs $10,000 or more. Plus you’ll need the outbound bandwidth necessary to support the streams, likely in the 8Mbps–10Mbps range or higher. Both of these requirements are beyond the reach of many live event producers.
With live cloud transcoding, however, you send a single stream to the transcoding service, which creates the additional streams. You can easily encode the single transmitted stream with a free encoder such as the Adobe Flash Media Live Encoder, or inexpensive programs such as Telestream’s Wirecast, which I used in my tests. Transmitting a single stream drops the outbound bandwidth requirements to more reasonable levels. For example, I tested the Brightcove service using a 2.5Mbps outbound 720p stream, which was well within the capabilities of my $49 per month residential internet service. It’s also within the capability of many single line and muxed 4G solutions. In short, live transcoding services allow any streaming producer to produce a high-value experience from anywhere with 4G connectivity or faster with minimal capital expenditure (CAPEX) requirements.
Contents
Zencoder Service
Let’s discuss the Zencoder service, then transition over to Brightcove and my testing. In the words of my Zencoder contact, its Live service is “an early product, with pretty basic (but solid) functionality.” The service is completely API- (application programming interface) driven, with no user interface. As of Oct. 4, in addition to Brightcove’s own service, Zencoder could stream to entry points at Akamai, EdgeCast, Limelight, Amazon CloudFront, Adobe Media Server, Wowza Media Server, and YouTube Live. The only supported encoders were Wirecast, the Flash Media Live Encoder, XSplit, and Open Broadcaster Software (OBS).
The Zencoder service can output streams in RTMP and HLS configurations, and it can produce up to 20 output streams per incoming stream, with a rendition saved for on-demand viewing after the live event. Zencoder’s pricing starts at $10 per hour for the first 50 hours, with tiered pricing that drops to $4 per hour after 1,000 hours. Input and output streams are included when calculating hours, with HD inputs and outputs costing twice the normal rate.
To put this in perspective, my test configuration was one HD stream in, two HD and six SD streams out, which for a 1-hour webcast would cost 12 hours, or $120 at the highest possible rate. Note that these are Zencoder’s prices; Brightcove has a completely different pricing structure.
To use the Zencoder service, you have to supply your own server and player and submit encoding requests via Zencoder’s API. Since I’m not a coder or a server administrator, we decided to test the transcoding functionality by using Brightcove’s Video Cloud Live service, which worked well for us since Streaming Media magazine uses Brightcove to distribute its on-demand video.
Brightcove Video Cloud Live
If you’re a current Brightcove customer, the value proposition for the Video Cloud Live service is roughly this: You can use all the players and player-related infrastructure, including DRM and monetization, that you’ve created for Brightcove VOD for live events, plus all the back-end analytics. Once the event is over, the input stream is automatically retranscoded and made available for VOD delivery — no more uploading a separate file. In addition to multiple bitrate streaming in both RTMP and HLS formats, Brightcove offers live DVR so viewers can scan through the video at their leisure and return to the live feed at the click of a button.
Note that you have to be a Brightcove customer to use Video Cloud Live. In this regard, Video Cloud Live isn’t competing with Livestream or Ustream as much as providing a valuable feature for those already using the Brightcove Video Cloud or considering using the service.
Pricing for the new service depends upon the number of streams and their resolution, as well as volume. For $1,700, you get 20 hours of live streaming with a maximum of four SD streams. Unlike Zencoder, 20 hours is calculated without reference to the number of streams; it’s the actual duration of the live event. For $4,000, you get 20 hours of streaming with two HD and up to six SD streams. Under both plans, you have 12 months to consume the 20 hours of streams. Note that these are just the charges to create the streams; normal bandwidth charges apply. These are also the highest possible prices, which drop as your live event volume scales.
Brightcove announced Video Cloud Live back in May 2013, though in many ways, as you’ll see, the service felt nascent. For example, you can’t reach the service through your normal Brightcove Video Cloud login; you have to log in on a separate page. This isn’t tragic, of course, but it presaged the rough edges I would encounter when actually using the service. Overall, while the plumbing feels very sound, the interface could use some work.
Driving the Beast
Getting started is simple enough, with a simple wizard to drive the workflow. To create an event, you name it, add some metadata and tags, and choose a date and duration (Figure 1). Next you choose a player from live-compatible players existing in your Brightcove account.
Figure 1. Creating the event
Then you choose your output options, which control the number of output files and their configuration (Figure 2). The standard SD profile has two RTMP and two HLS streams, peaking at 854×480 resolution at 1100Kbps for RTMP delivery and 910Kbps for HLS. The standard HD profile has four RTMP/HLS streams each, peaking at 720p at 2500Kbps for both RTMP and HLS. While you can change parameters such as resolution and bitrate and add additional renditions, you can’t adjust H.264 specific parameters from inside the Brightcove user interface. This is probably OK for most users, but it may prove frustrating to those who like to tweak.
Figure 2. Choosing and configuring the transcoded streams
So far, this is all pretty straightforward, but here’s where the workflow gets a bit hinky. In order to view the server credentials (stream name and server URL), you actually have to click the Start Streaming button to start the event (Figure 3). This is confusing because (of course) you can’t actually start streaming until you have the credentials to plug into the encoder. Plus, if you click Stop Streaming, the event is over and you can’t recall it, which means a new event, new player embed codes, new everything. Even worse, once you click Start Streaming, you have only 30 minutes to actually start the live stream; otherwise the event expires.
This complicates scenarios such as on-location encoding, where a network professional might want to preconfigure an encoder before sending the video folks out to stream the event. A better approach is to simply make the server credentials available when you create the event, as most other services do.
I also found the transition from preview to live unnecessarily jarring. As most live event producers know, before the event, you want absolute assurance that the server is receiving the stream from your encoder, and that video and audio parameters are optimized for top quality. You want to see it and hear it before you go live.
Systems such as YouTube Live do a great job managing this “going live” transition, providing a live preview in the control room with a countdown clock in the live player. You have all the time you need to optimize audio and video settings in a completely private preview. When you’re ready to go live, you click the Start Streaming button. YouTube Live switches the stream over, easy peasy.
Figure 3. I had to start streaming to actually see the server credentials, which makes no sense
With Brightcove, there is no concept of a preview. Once you start streaming (which you probably did hours ago to get the server credentials), the player is live and your viewers see everything you’re broadcasting. I asked Brightcove about this, and the response was that most customers preview in a nonpublic page and then paste the embed code into the actual viewing page when they’re ready to go live.
I’m sure this works fine, but the implications are somewhat negative. Not only can’t you test the actually viewing page thoroughly before the event, you need a web professional available just before the event goes live to update the page. This may not be as simple as it sounds if the event is at 8 p.m. on a Sunday, and the encoding and video professionals don’t know how to run the content management system (CMS). It strikes me that the YouTube Live approach is simpler and easier, particularly given the embedding issues I’m about to describe.
Embed Woes
As with the other live streaming systems I’ve tested recently, my plan for Video Cloud Live was to test the system while producing an actual webinar, giving me a small universe of users to tax and test the system. I created and configured the event in the Brightcove system the night before, but I didn’t embed the player and test the system because I hadn’t figured out the optimal strategy for the preview/going live conundrum I just discussed.
I planned to embed the live stream into my own Streaming Learning Center website, which I’ve done dozens of times with VOD streams distributed by Brightcove, so I anticipated no problems. I’ve also used embed codes from five or six other live systems — including Livestream, Bambuser, Ustream, YouTube Live, PowerStream, and Multicast Media (now Piksel) — without any problem. However, when I embedded the Video Cloud Live embed code into my website, my Interspire CMS truncated the code and no player appeared on the page. I quickly tested my WordPress blog with the same apparent result.
Since this was about an hour from the start of the webinar, I switched to YouTube Live to host the event. To be clear, the typical Brightcove user has access to network-savvy professionals who likely could have resolved the issue in real time and would be far too smart to delay actual testing until an hour before the event. So I wouldn’t expect the typical Brightcove user to experience the same problem. On the other hand, I never resolved my CMS issue, even with input from Brightcove technical support, though I put that issue on hold once I discovered (well after my webinar) that Streaming Media’s homegrown CMS had no problems with the Brightcove Live embed codes. So this was yet another rough edge that unfortunately limited my ability to test the system as fully as I have others.
Test Results
That is really unfortunate, because once I got things up and running, the results were impressive. As background, to test the system, I simulated a live event using footage I had shot of local band Loose Strings a few months ago for a promo video (Figure 4). Again, I used Telestream Wirecast to capture and stream the footage to Video Cloud Live, with a ViewCast Osprey 820e capturing a component signal from the Canon XH A1 camcorder used to record the concert. The encoding station was an HP Z400 with an Intel W3680 four-core Xeon processor (eight with HTT enabled) sending a 720p, 30 fps stream encoded at about 2.5Mbps to the Zencoder transcoding server. On this system, average CPU load for the encoding hovered around 28%, which is well within the comfort zone.
Figure 4. The streaming control panel with the live stream and all iterations
During the simulated event, I tested playback on a variety of computers and devices. The streams played on all tested computers, with good quality, no interruptions, and perfect audio sync. Tested devices included an iPhone 4s (using both cellular and Wi-Fi), a first generation iPad (Figure 5), and a Samsung GALAXY S4.
Figure 5. Galax, Va.’s own Loose Strings band, a screen shot from the full screen playback on my iPad.
After the event, you can edit the stored feed using the simple trim controls shown in Figure 6. Once that trim is complete, Brightcove retranscodes the live event using the standard streams defined for on-demand delivery and then makes the event available for on-demand viewing.
Figure 6. Trimming the event after completion
So where does that leave us? The Zencoder transcoder and Brightcove delivery system work very well today, and I’m sure Brightcove will soon address the interface and embedding issues discussed previously. If you’re an existing Brightcove user seeking to supplement your video on demand content with live streams, Video Cloud Live should clearly be the first option that you try
