Choosing a live streaming encoding tool used to be simple: You typically would encode a single stream for delivery to your desktop viewers, and budget was the most important buying criteria. When buying today, of course, you’ve almost certainly expanded your target viewers to include both mobile and desktop clients, with adaptive streaming preferred over single file delivery.
You have a host of new workflow options to consider, from live cloud or server-based transrating to server or CDN-based transmuxing. You also may have several new requirements, from digital rights management to closed captions to advertising insertion.
To help guide your decision making, in this Buyer’s Guide I’ll present the questions you should ask before buying a live encoder for on-premise streaming. The alternatives discussed will include hardware and software encoders, but not truly portable encoders such as on-camera encoders or touchscreen-based hardware encoders. Though I’ll touch on cloud transcoding, a separate Buyer’s Guide will focus on cloud encoding and transcoding.
Contents
Six Questions: Live Encoders
- Who is the service provider, and what encoder does it recommend?
- What platforms will you be serving, and will you distribute single or adaptive streams?
- What features do you need surrounding your video?
- What functions do you need your encoder to perform?
- What’s your workflow?
- Which is the best fit?
Ask Your Service Provider
If you’re using a live streaming service provider such as Livestream or Ustream, your first stop should be to check its list of compatible software programs and hardware devices. Significantly, both Livestream and Ustream offer free software encoders that are fully integrated with their distribution platforms, ensuring both ease of use and comprehensive platform and feature support. If your requirements dictate the purchase of a hardware encoder, you’ll want to buy an encoder that similarly integrates into the distribution platform of your selected service provider.
Single or Adaptive Streams?
Assuming that you’re not using a live streaming service provider, you have to start by defining the delivery requirements for the event, beginning with the platforms that you’re targeting and how many streams you plan to deliver. Then, you can work backward to identify the optimal workflow — and encoder — to produce the required streams for the required targets.
Additional Features
Beyond the target platforms and the number of streams, you also have to consider the features surrounding your video. For example, will closed caption support be a requirement? What about digital rights management or advertising insertion? Few stand-alone software encoders can handle these requirements, or even low-end hardware encoders.
Additional Functions
Most hardware and software encoders are single-function encoding engines. However, several software programs can perform valuable production functions, such as multiple camera switching, title insertion, or playback of disk-based files. On the hardware side, there are some multiple camera production systems that can also output a live encoded stream. If you’re looking to integrate production and encoding functions, get this on the table first, since it will severely limit the hardware and software products that you can consider.
Define Your Workflow
This is where the analysis gets complicated. A few years ago, a producer seeking to distribute adoptive streams to multiple platforms — say four streams each to Flash and iOS — had to produce all required streams for both platforms in real time. Typically, this involved multiple sets of expensive rack-mounted hardware encoders.
Around 2010, the real-time ability to convert one set of adoptive streams to meet the requirements of another delivery platform became commonplace. This process, which is called transmuxing, involves rewrapping (but not re-encoding) H.264 video streams into the container format necessary for another target platform and creating any required metadata files. Transmuxing has become a standard feature on most media servers and is also offered by some content delivery networks.
For example, a streaming server might input four streams bound for Flash delivery via RTMP-based Dynamic Streaming and then change the container format of the video streams into the MPEG-2 transport stream required for delivery via HTTP Live Streaming (HLS) and create the necessary M3U8 manifest files. If you build transmuxing into your workflow, you won’t need separate encoders for each format.
In 2011, the first live transcoders hit the market, available either as stand-alone servers or in the cloud. Live transcoders can input a single high-quality stream and then create the necessary file iterations for the adaptive streaming group. In our example, the transcoder would input one file and produce four files at different quality levels, or three files if the input file was going to serve as the highest quality file in the adaptive group. These files could be configured as necessary for delivery to multiple target platforms, whether HLS, RTMP-based Dynamic Streaming, or any other adaptive format.
If you build transcoding and transmuxing into your live streaming workflow, you no longer need multiple-file encoding capabilities on premise. Rather, you need an encoder capable of supplying a single high-quality stream to the transcoding facility, which virtually all hardware or software encoders can do. You also significantly reduce your outbound bandwidth requirements because you’re sending a single stream out of the facility, not multiple streams.
Choosing whether to integrate transmuxing and trancoding into your workflow involves multiple factors. Of the two, transmuxing is more compelling; since there are really no negatives, it’s hard to imagine when you wouldn’t want to use it.
Live transcoding is newer and less proven, and it’s unclear whether quality will suffer because the lower bitrate streams are produced from a previously compressed file, rather than the original source. Outbound bandwidth is obviously a key decision-making factor here; if it’s limited, and you need to distribute multiple streams, sending a single stream out of the facility and then transcoding that stream into your adaptive group may be your only option.
If outbound bandwidth isn’t an issue, budget becomes the next consideration. If you’re a quality-at-all-costs operation, buying a hardware encoder capable of producing all the required streams is likely your best option. If funds are short, producing a single stream for downstream transcoding may be the most affordable option, particularly if you produce relatively few live events.
Overall, before even choosing a class of encoding tool, you should plot out the workflows you’ll use to produce your videos to their final form, including the container formats and metadata requirements of your actual distribution files, as well as any ancillary features. You should also identify the input requirements for the selected transcode/transmux tools, since these will become the required outputs of your selected encoder.
Find the Best Fit
By this point in the analysis, you should be pretty far along on your requirements list, understanding the number of streams that your encoder needs to produce and ancillary features that it must support. This should help you focus on a category of products, whether it’s a software encoder, mid-level stand-alone hardware encoder, or industrial-strength, rack-mounted encoder. Within this category, you should identify the most affordable product that can produce the required streams, deliver all the ancillary features, and connect to your relevant inputs, whether IP or video.
If you’re caught between categories, say choosing between a software encoder or inexpensive hardware encoder, or wavering between multiple inexpensive hardware encoders or a single industrial strength product, here are some high-level considerations.
First, as between hardware and software encoders, there’s a general perception that hardware encoders are more reliable. To a great degree, this relates to the platform that the program is installed on — not the software program itself. That is, if you install a software encoder on your marketing director’s notebook, it may be impacted by any program later installed on that computer. Since most hardware encoders are single-function devices, the platform itself is much more stable.
Second, as between a single industrial-strength encoder or multiple less powerful and cheaper encoders, if you’re producing adaptive streams, it’s best practice to encode all streams in an adaptive group on a single encoder. There are certain parameters such as key frames, chunk sizes, and audio parameters that should remain consistent among all files, and encoding on a single encoder is the easiest way to make this happen.