Linked by Thom Holwerda on Wed 23rd Dec 2015 22:36 UTC
Multimedia, AV

Netflix is working on a new video compression strategy, and they've published a very detailed blog post about it.

We've spent years developing an approach, called per-title encoding, where we run analysis on an individual title to determine the optimal encoding recipe based on its complexity. Imagine having very involved action scenes that need more bits to encapsulate the information versus unchanging landscape scenes or animation that need less. This allows us to deliver the same or better experience while using less bandwidth, which will be particularly important in lower bandwidth countries and as we expand to places where video viewing often happens on mobile networks.

The technical details go way over my head, but the basic premise seems to make sense to a layman such as I.

Order by: Score:
Comment by shmerl
by shmerl on Wed 23rd Dec 2015 23:02 UTC
shmerl
Member since:
2010-06-08

Isn't that what Daala is using with lapped transforms already? Except it goes even further. It's not encoding per title, it's dynamic encoding for anything. I.e. compression applied more strongly to areas which are less noticeable and less so to areas which are more noticeable. Same idea is used in Opus for audio.

Edited 2015-12-23 23:02 UTC

Reply Score: 3

RE: Comment by shmerl
by _LH_ on Wed 23rd Dec 2015 23:17 UTC in reply to "Comment by shmerl"
_LH_ Member since:
2005-07-20

Sorry but you are completely missing the point. Using some jargon, the idea here is constant quality instead of constant bitrate. All MPEG-like encoders (even JPEG) have a switch called quality or quantizer. Typically when you want to encode video at a certain bitrate, the quantizer changes from frame to frame because each frame has different difficulty for compression. What Netflix is doing now is that they do not intend to reach any given bitrate for videos but rather have a constant quality/quantizer across different titles. If this means that some slo-mo animation will get half the bitrate of a fast-action title, then so be it.

Reply Score: 3

RE[2]: Comment by shmerl
by meme on Wed 23rd Dec 2015 23:25 UTC in reply to "RE: Comment by shmerl"
meme Member since:
2006-04-03

They are basically doing what video enthusiasts and movie pirates have been doing all along (two pass encoding - the first finds out, which frames need many or not so many bits, the second pass does the encoding).

Reply Score: 5

RE[3]: Comment by shmerl
by kurkosdr on Thu 24th Dec 2015 00:18 UTC in reply to "RE[2]: Comment by shmerl"
kurkosdr Member since:
2011-04-11

They are basically doing what video enthusiasts and movie pirates have been doing all along (two pass encoding - the first finds out, which frames need many or not so many bits, the second pass does the encoding).


Not even close. Pirate releases have fixed target sizes, aka fixed overall bitrates (for movies of the same duration)

Netflix is taking about different overall bitrates depending on the content/scene complexity even for movies of the same duration.

Not sure if they do 2-pass encoding, they can do the optimization they talk about with or without it, but even if they have two pass encoding, expect the variations between parts of the movie to be smaller than pirate releases because they want to avoid bitrate peaks, because they want to stream the videos over internet connections,which have more or less unchanging bit/s. In plain English,if they have 9mbits overall bitrate,they want it to be streamable over a 10mbit connection,and a 11mbit scene is not going to help (buffer underun). So even if they do 2pass, expect the variations to be smaller than what pirate releases have.

Edited 2015-12-24 00:23 UTC

Reply Score: 2

RE[4]: Comment by shmerl
by WereCatf on Thu 24th Dec 2015 02:03 UTC in reply to "RE[3]: Comment by shmerl"
WereCatf Member since:
2006-02-15

Not even close. Pirate releases have fixed target sizes, aka fixed overall bitrates (for movies of the same duration)


Actually, both constant bitrate and 2-pass VBR can be used to targeting a specific filesize. With CBR the encoder simply uses the same bitrate at all times and as such there is no such a thing as 2-pass CBR, and with 2-pass VBR you can specify target filesize you'd wish to reach and the second pass will then use the data from the 1st one to try and reach that target.

Also, as an aside, there are both pirates who target specific filesizes and pirates who target specific quality; not just one or the other.

Not sure if they do 2-pass encoding


CQP is similar to CBR in the sense that there is no such a thing as 2-pass CQP; the quantizer stays the same frame-for-frame, but the bitrate varies, like with CBR the bitrate stays the same frame-for-frame, but the quantizer varies.

Technically, though, they are doing an out-of-codec 2-pass in the sense that they go over the file to figure out how high the bitrate would end up being with CQP, section-for-section, and then create encoding-presets based on that and scale the settings down if the section-over-section bitrate would be over budget.

In plain English,if they have 9mbits overall bitrate,they want it to be streamable over a 10mbit connection,and a 11mbit scene is not going to help (buffer underun)


Depends. If a low-bitrate section is followed by a higher-bitrate section the higher-bitrate section can already begin buffering while playing the lower-bitrate one and as such it wouldn't matter if the bitrate went over the limit temporarily. The length of these sections, the buffer - size Netflix uses for streaming on client-side and the order of high - and low - bitrate sections dictate the ladder the encoder will use, ie. the budget allowed.

Reply Score: 4

RE[2]: Comment by shmerl
by shmerl on Thu 24th Dec 2015 02:17 UTC in reply to "RE: Comment by shmerl"
shmerl Member since:
2010-06-08

Daala and Opus use dynamic (variable) bitrate and instead aim at certain perception quality level, so how exactly is that idea radically different?

Edited 2015-12-24 02:18 UTC

Reply Score: 4

RE[3]: Comment by shmerl
by WereCatf on Thu 24th Dec 2015 02:28 UTC in reply to "RE[2]: Comment by shmerl"
WereCatf Member since:
2006-02-15

You, Fishb8 above you and many others don't seem to grasp the idea. It's not the fact that Netflix is using CQP that's the big thing here, it's the analysis-part that's the important part; they have a lot of constraints to take into account, like e.g. they already have a large amount of players out there that they have to maintain compatibility with, the section-over-section bitrate cannot exceed the budget except for buffer-length, the sequence of the high- and low-bitrate sections is a big factor in deciding the budget and so on.

It's easy when you're watching content from a local disk or whatever where you have plenty of bandwidth available, and it's an entirely different thing when you are working with limited devices, limited bandwidth and limited transport-infrastructure -- you need a budget and predictability.

Reply Score: 5

RE[4]: Comment by shmerl
by FishB8 on Thu 24th Dec 2015 03:43 UTC in reply to "RE[3]: Comment by shmerl"
FishB8 Member since:
2006-01-16

All that functionality in conjunction with CRF has been available with ffmpeg+libx264 for quite some time. You can cap bitrates, limit bandwith variance, etc all while using CRF.

Also CRF (Constant Quality) != CQP (Constant Quantizer)

Perhaps the gist of the article is less about inventing / developing the functionality, and more about actually employing it.

Reply Score: 5

RE[3]: Comment by shmerl
by Alfman on Thu 24th Dec 2015 03:29 UTC in reply to "RE[2]: Comment by shmerl"
Alfman Member since:
2011-01-28

shmerl,

Daala and Opus use dynamic (variable) bitrate and instead aim at certain perception quality level, so how exactly is that idea radically different?


I agree. The headline is a bit misleading in setting the tone for something new to the industry, but the article itself is basically saying the technique is new for netflix.I imagine that most video encoders who are meticulous about encoding parameters will have gone through very similar steps to experiment with getting the most out of bandwidth distribution.

And why not, there's no need to waste bits on scenes that don't benefit much from them. If instead they can throw additional bits at more demanding scenes without changing the average bitrate, then it's pretty useful.

Edited 2015-12-24 03:32 UTC

Reply Score: 4

Comment by kurkosdr
by kurkosdr on Thu 24th Dec 2015 00:12 UTC
kurkosdr
Member since:
2011-04-11

What customers hear: "More bitrate for action movies, instead of providing the least bitrate they can get away with"

What Netflix means: "From now on, we 'll work on having the least bitrate we can get away with on slow movies too."

Edited 2015-12-24 00:13 UTC

Reply Score: 8

Comment by birdie
by birdie on Thu 24th Dec 2015 02:03 UTC
birdie
Member since:
2014-07-15

Seems like they've reinvented CRF (constant rate factor).

Surprise!

Reply Score: 1

Comment by FishB8
by FishB8 on Thu 24th Dec 2015 02:07 UTC
FishB8
Member since:
2006-01-16

I'm not sure why this is to be considered so novel. libx264 has had CRF encoding since forever. It's basically doing that analysis real time while encoding.

Reply Score: 5

Cartoons
by Seeprime on Thu 24th Dec 2015 05:49 UTC
Seeprime
Member since:
2014-05-02

Cartoons and movies with a lot of solid colors are being re-encoded for lower bitrates since they don't need to have the higher bitrate of a movie with action scenes and millions of colors. It'll be fine, especially if it lowers my bandwidth usage without sucking.

Reply Score: 2

In other words
by ezraz on Mon 28th Dec 2015 16:23 UTC
ezraz
Member since:
2012-06-20

Netflix is trying to figure out if they have to send you 5800k streams for everything, or if they can get away with sending you 2800k without you noticing. It will probably work.

Meanwhile, most modern people still believe that even 1000k is too much to bother with for music because they generally devalue audio data and overvalue video data.

I just wish someone would stream hi-res audio already. Tidal is close and Apple is rumored to be investigating it.

Proper stereo audio playback of good music takes between 800k-6000k bandwidth but we've been sold the lie that 256k is good enough.

Reply Score: 2