Choosing the Number of Renditions and Encoding Sets

I recently received an email inquiry that asked, "on average for multiple devices, how many different renditions/encoding sets do you recommend?" The answer was complex enough that I figured I would answer it in a blog post. 

There are multiple interlocking considerations, as you would suspect. Let's start with Quality and Compatibility.

Quality and Compatibility 

1. The starting point for any multiple screen delivery inquiry is Apple Technote TN2224, which presents Apple's vision as to how to create one set of files that plays on computers, iOS devices, and a Apple TV, an OTT box. Here's the most important part, which you can click to see at full resolution in a separate browser window. 

TN2224.png

Apple's recommendations in TN2224. 

Essentially, Apple recommends encoding with the Baseline profile for compatibility with older iOS devices, Main for newer devices and High profile for the newest iOS devices. 

As you can read here, Google recommends encoding using the Baseline profile for all Android devices. That's because, unlike Apple, Google doesn't know the playback capabilities of all Android devices since most are made by third parties. In point of fact, most Android devices can play Main and High profile; Google is just presenting the most conservative view. 

To complete the picture, computers can play any profile, as can all other OTT boxes.

So the first big issue is whether you should encode multiple sets of files; one as shown in TN2224 for iOS, one using all Baseline for Android, and one using all High profile for the highest possible quality on computers and OTT devices. Or, should you create one set of files a la TN 2224 and distribute them to all targets. Beyond the potential Android compatibility issue, which I think is negligible, the issue comes down to the quality difference between files encoded using the Baseline and High profile. 

That's an issue I explore in this video, which is from a course on Encoding for Multiple Screen Delivery on Udemy. Basically, I encoded files using the configurations shown in TN 2224, but the High profile, and compared the quality to the files encoded using the profiles suggested in the Tech Note. 

The main points in the videos are:

- with high motion videos, there are substantial quality differences between the Baseline and High profile, but much less so between the High and Main profile. 

- With lower motion files, there's almost no difference. 

- With higher motion files, the file that shows the largest most significant difference is the 640x360@600 kbps file. However, few computers would actually play this file; most are on broadband connections that would soon upgrade (at least) to the next highest quality file, which is 640x360@1200 kbps. So most viewers who actually see that file are on older mobile devices who wouldn't benefit from the higher quality file. Turning that around, if you did customize a separate group of streams using the High profile solely for computers, the experience wouldn't be significantly improved. 

Despite this logic, in my experience, most larger companies create multiple groups of streams with customized parameters, encoding a single file into 40-50 variations. Most smaller companies create one core set of files and package that set differently for the respective targets. 

Other Considerations

Beyond quality and compatibility, there are multiple other issues to consider. These include:

Encoder flexibility. With an encoding tool like Telestream Vantage (and many more), it's simple to encode one set of files and package them into multiple output packages for different targets. Ditto for streaming servers like the Wowza Streaming Engine, which can input files in one format, and transmux them to another. If your encoder can't do that, and forces you to encode separately for each output package, by all means, customize your encoding for each platform. This means High profile for each package targeted solely towards OTT or computers. 

Encoding volume. If your volume is low, it's not going to break the bank to customize each package for their specific target. At $0.03/minute for H.264 encoding, which is Amazon's price (some services, like Zencoder, go lower), it costs about $17.00 to encode a single hour of video to nine output streams. So if you're encoding a few hours per week of video, it's not going to break the bank to customize each encoding group for the target, particularly if you don't need to buy an additional encoding tool to do the work. If you're encoding multiple streams 24/7, the costs tend to add up, particularly if you need to buy another $26,000 hardware encoder to get the work done.  

Overall, my take is that the quality of service won't be dramatically improved if you customize each package for the viewing target. If you can create one core set of files that you can package separately, I say try it. If you can't, and have to customize for other reasons, then use the High profile whenever creating files that won't be sent to mobile. 

No onto how many streams per package. 

Number of Streams Per Package

A much simpler question which I address in the YouTube video below, also from my Udemy course. Basically, there is no magic number, but you should:

- Customize mobile streams first, since they're the most problematic.

- The create streams for playback on your website, ensuring that each window size on your website has at least one stream. 

- Then create streams for OTT and full screen playback, with budget the determining factor as to the data rate and resolution of the highest quality streams. 

I also cover this pretty extensively in my book, Producing Streaming Media for Multiple Screen Delivery. Note that you get a PDF copy of the book with the aforementioned Udemy course. 

I hope you found the foregoing useful, and invite your comments below. 


Comments (0)

Post a Comment
* Your Name:
* Your Email:
(not publicly displayed)
Reply Notification:
Approval Notification:
Website:
* Security Image:
Security Image Generate new
Copy the numbers and letters from the security image:
* Message: