Video: The Case for Custom Encoding, Part 1: Bitrate

Streaming Learning Center’s Jan Ozer makes the case for custom, per-title encoding on the Netflix model, focusing on bitrate issues in part 1 of this 2-part series from his Streaming Media West presentation.

Following the model established by Netflix in December 2015, Jan Ozer argues against content providers applying a standard encoding ladder to all of their content because of the inefficiencies and waste that approach builds into the process. In Part 1 of this 2-part series, he outlines his process for handling the custom bitrate side of the equation from mobile on up; in Part 2 he deals with resolution.

Read the complete transcript of Ozer’s remarks in this clip:

Jan Ozer: In December 2015, Netflix came out with per title encoding. They said, “We’re no longer going to use a standard encoding ladder for all of our videos because it’s inefficient.” An encoding ladder is good for one video. For low-motion videos it’s probably too high a data rate. For high-motion videos it’s probably too low a data rate. They said, “We’re not going to use one any more. We’re going to use a custom encoding ladder for each video that we encode and distribute.”

This is what I go through with my clients. It’s what I go through with my own videos.

When I’m creating an encoding ladder I choose the lowest rate for mobile. I say, “How low do I want to go?” Then I choose the highest supported data rate, and that’s a cost issue. How much can my monetization support from a cost perspective? Then I choose a data rate of around three megabits per second. I want that to be a pretty high-quality stream because if you look at the Netflix publishes and ISP index every month, and if you look at the average sustainable stream for most of their ISPs that they report on, it’s typically between 3.8 and 3.2 megabits per second. I want a stream that’s going to look good at that rate.

Then I fill in the blanks going between 150% and 200%. If I started at 200 kilobits per second, that’s my low stream, 4.6 megabits per second, that might be my high stream. This is the target for the high sustainable throughput, this guy over here. Then I run the numbers backwards. This is 200 and something percent, this is 200%, this is 1.6. This is around 1.33, this is around 1.5, and this is around 1.5 as well. This is nothing magical, but that’s the process I go through.

About Jan Ozer

I help companies train new technical hires in streaming media-related positions; I also help companies optimize their codec selections and encoding stacks, and evaluate new encoders and codecs.

Check Also

Streaming Media 101: Training for App & Player Development/Testing Professionals