YouTube h.265 CRF & SSIM

Get answers to your questions about color grading, editing and finishing with DaVinci Resolve.
  • Author
  • Message
Offline

Dan Sherman

  • Posts: 948
  • Joined: Fri Jul 01, 2016 11:07 pm

YouTube h.265 CRF & SSIM

PostSun Feb 18, 2018 5:19 am

Its been coming up a lot lately, so I decided to throw together a test that demonstrates the relationship between constant quality encoding and what ultimately ends up on YouTube.

Steps:
  1. Rendered a 1080p clip out of resolve as DNxHR 444 10-bit.
  2. Trans-coded the clip to h.265 444 10-bit, using various CRF values ranging from 0 (lossless) to 50 (horrendous).
  3. After uploading all the clips to YouTube and allowing it to process them, I pulled down all of the h.264 420 8-bit files that youtube uses to stream.

To quantify the quality of each file, I used ffmpeg to calculate its SSIM. It's not the best metric available, but it's far from the worst.

The following graph shows the SSIM of the h.265 uploads, and the YouTube h.264 streams compared to the DNxHR master. The graph shows that as you approach lossless, you hit a YouTube re-encoding brick wall, and that uploading higher quality files, is just wasting bandwidth.

ssim.png
ssim.png (16.62 KiB) Viewed 2635 times



The following graph again shows the YouTube brick wall, as the bitrate stays relatively constant regardless of quality of the upload.

bitrate.png
bitrate.png (14.47 KiB) Viewed 2635 times
X99-A II, 6850K 4.2 GHz, GTX 1070 FE (431.36), DDR4-2400 CL12-14-14 4x8 GB
Win 10 Pro 1809, Resolve Studio 16.1.0b.017
Offline

PeterMoretti

  • Posts: 918
  • Joined: Sat Aug 03, 2013 12:12 am

Re: YouTube h.265 CRF & SSIM

PostSun Feb 18, 2018 5:29 am

Am I interpreting correctly that a CFR of 20 is about as good as you can meaningfully go?

And THANK YOU so much for the work and for sharing!!
Resolve 14.3 Studio. GTX 970 with GeForce 390.77 driver. Desktop Video 10.9.10. Intensity Shuttle USB 3.0. Windows 10 Pro.
Offline

Dan Sherman

  • Posts: 948
  • Joined: Fri Jul 01, 2016 11:07 pm

Re: YouTube h.265 CRF & SSIM

PostSun Feb 18, 2018 5:45 am

PeterMoretti wrote:Am I interpreting correctly that a CFR of 20 is about as good as you can meaningfully go?

And THANK YOU so much for the work and for sharing!!


It depends on the clip itself. If it's a mostly static shot 22 might be fine. If you're working on Michael Bay's next film, you might need to go to 17 or 18.


as a side note, the crf values for h.264 and h.265 are not equivalent. For h.264 visually lossless is considered to start at 18, while it's 24 for h.265.
X99-A II, 6850K 4.2 GHz, GTX 1070 FE (431.36), DDR4-2400 CL12-14-14 4x8 GB
Win 10 Pro 1809, Resolve Studio 16.1.0b.017
Offline

Martin Schitter

  • Posts: 899
  • Joined: Tue Apr 28, 2015 10:41 pm

Re: YouTube h.265 CRF & SSIM

PostSun Feb 18, 2018 12:41 pm

AFAIK youtube intentionally doesn't utilize more advanced forms of variable bandwith control (e.g. CRF) on reencoding to minimize the computational cost.
Last edited by Martin Schitter on Sun Feb 18, 2018 12:45 pm, edited 1 time in total.
Offline

Andrew Kolakowski

  • Posts: 5821
  • Joined: Tue Sep 11, 2012 10:20 am

Re: YouTube h.265 CRF & SSIM

PostSun Feb 18, 2018 12:45 pm

You don't want to analyse bitrate in 2nd graph (youtube uses fixed profiles as far as I understand), but quality. By doing so you can find at what source bitrate you start being so close with final youtube quality against uncompressed upload that there is no point raising upload bitrate any further.
You would have to do it for e.g. x264 and Resolve h264 encoder separately as they are not as efficient.

Those quoted CRF values are "chosen" by x264/5 developers, but they are for "final encode/quality".
We want to use something lower here as we doing intermediate step master. I'm using more like CRF=15 for x264. In terms of final quality I'm more happy with e.g. Blu-ray bitrates- they allow to get very decent end user quality. For web those bitrates are still problematic (to high).
SSIM/PSNR etc are only half good as it's very difficult to make metric which reliably represent visual perceived video quality. Netflix latest one is probably the most accurate.

And no- you don't need to adjust CRF to source nature. CRF mode adjusts bitrate to source nature keeping relative quality the same for difference sources and this is beauty of it. By setting CRF value you choose what quality you want- then you don't worry if you have noisy or crazy clean master. It will do its magic (one will end up with e.g. 30Mbit, other 60Mbit average bitrate).
Offline

Dan Sherman

  • Posts: 948
  • Joined: Fri Jul 01, 2016 11:07 pm

Re: YouTube h.265 CRF & SSIM

PostSun Feb 18, 2018 4:58 pm

Andrew Kolakowski wrote:Those quoted CRF values are "chosen" by x264/5 developers, but they are for "final encode/quality".


Andrew Kolakowski wrote:And no- you don't need to adjust CRF to source nature. CRF mode adjusts bitrate to source nature keeping relative quality the same for difference sources and this is beauty of it. By setting CRF value you choose what quality you want- then you don't worry if you have noisy or crazy clean master..


I have to say I disagree with the second quote, as it's to broard a statement.

Just as you said in the first quote, the crf values where chosen by developers. The choices they made where based on perceived quality, and thus aren't absolutes. What one person might perceive as excellent quality might only be considered ok by someone with better visual acuity.

Not to mention the crf target is for the entire frame, thus a certain amount of "averaging" is going on across the frame and scene. By that I mean if you have a scene that is say 90% static and 10% high motion, you might hit the target crf overall, but still have some blocking in the 10% section. If that's ok will depend on how you perceive quality. Thus the CRF will very some based on the mature of the footage and who is working on it. Unless, you always crank the crf, but that can lead to really big files.


As an aside, you can blend your master and upload to visually see where its breaking down because the the bitrate or crf (depending on what encoding method you prefer) isn't good enough.
https://stackoverflow.com/questions/257 ... -in-ffmpeg
X99-A II, 6850K 4.2 GHz, GTX 1070 FE (431.36), DDR4-2400 CL12-14-14 4x8 GB
Win 10 Pro 1809, Resolve Studio 16.1.0b.017
Offline

Andrew Kolakowski

  • Posts: 5821
  • Joined: Tue Sep 11, 2012 10:20 am

Re: YouTube h.265 CRF & SSIM

PostSun Feb 18, 2018 5:34 pm

For such a detailed "issues" inside single frame you have many other options in x264. This is fine tuning which in 95% cases is not needed, specially when you use CRF at fairly low values. x264 is very good with it- this is actually where its main strength comes from- many different auto adapting algorithms for frame type decision, bitrate distribution over frame etc. It's in most case enough to use 'preset' and 'tune' option.

I'm just talking about CRF as a mode. CRF mode is about giving you same perceived quality regardless if file is difficult or easy to encode (which is done by adjusting bitrate). If you transcode 10 random source files at given CRF they all meant to come up as 'equally compressed' (which again- is not that easy to measure) compared to their source files.
You pick value (which controls what quality level you want) and then you don't have to worry about adjusting it because master is noisy or clean- it will adapt bitrate by itself as this is exactly what it was made for.
If you use bitrate mode then you have to adjust it for every source based on its nature. For 1 source 20Mbit may be already plenty, but for another you may need 50mbit. You have to then as operator keep "tracking" it. I had really nice real life examples at my last work place. Very clean (ARRI, RED based) masters were coming at e.g. 25Mbit average, but once artists added bit of grain even 60mbit was needed to preserve "original" quality (of course youtube will destroy this grain, but I want to send transparent master).

This is why I suggest CRF mode for such a intermediate masters. Set low enough value (e.g. 15) and you don't have to worry about it to much regardless your file nature: clean or noisy. If file comes up to big, raise CRF or treat it as special case and use maximum bitrate you can afford (due to your bandwidth limits).

Those difference maps are still not very representative and hard to judge (except that you can tell that A is better than B). Visual quality, specially how human perceives it is very hard to measure.
Offline
User avatar

Jean Claude

  • Posts: 2973
  • Joined: Sun Jun 28, 2015 4:41 pm
  • Location: France
  • Warnings: 1

Re: YouTube h.265 CRF & SSIM

PostSun Feb 18, 2018 6:14 pm

Hello,

There is an excellent quality measuring instrument:
MSU Video Quality Measurement Tool

http://www.compression.ru/video/quality ... _tool.html

(Even the Free version is interesting, unfortunately not Professional Bit Depth Support> = 10 bits ... :? )
"Saying it is good, but doing it is better! "
Win10-1809 | Resolve Studio V16.1 | Fusion Studio V16.1 | Decklink 4K Extreme 6G | RTX 2080Ti 431.86 NSD driver! |
Offline

Andrew Kolakowski

  • Posts: 5821
  • Joined: Tue Sep 11, 2012 10:20 am

Re: YouTube h.265 CRF & SSIM

PostSun Feb 18, 2018 7:19 pm

Yes, it has been been on the market for years now.
Offline

Sam Steti

  • Posts: 1390
  • Joined: Tue Jun 17, 2014 7:29 am
  • Location: France

Re: YouTube h.265 CRF & SSIM

PostTue Feb 20, 2018 8:56 am

Hey Dan,
Well done; so I guess you now upload clips that you were focused on their CRF only, instead of tweaking their bitrates ?
Legacy MacPro 8core Xeons, 32 Go ram, 2 x gtx 980 ti, 1SSD for system, 2 SSDs raid0 for footage and caches, OSX ElCap and High Sierra, Resolve 15.3 Studio
Offline

Dan Sherman

  • Posts: 948
  • Joined: Fri Jul 01, 2016 11:07 pm

Re: YouTube h.265 CRF & SSIM

PostTue Feb 20, 2018 3:39 pm

Sam Steti wrote:Hey Dan,
Well done; so I guess you now upload clips that you were focused on their CRF only, instead of tweaking their bitrates ?


Yep, when you encode in CRF mode, the encoder varies the bit rate automatically to reach the desired crf value.

This article gives a good overview of all the possible encoding methods.
http://slhck.info/video/2017/03/01/rate-control.html
X99-A II, 6850K 4.2 GHz, GTX 1070 FE (431.36), DDR4-2400 CL12-14-14 4x8 GB
Win 10 Pro 1809, Resolve Studio 16.1.0b.017
Offline

Sam Steti

  • Posts: 1390
  • Joined: Tue Jun 17, 2014 7:29 am
  • Location: France

Re: YouTube h.265 CRF & SSIM

PostTue Feb 20, 2018 5:42 pm

Dan Sherman wrote:
Sam Steti wrote:Hey Dan,
Well done; so I guess you now upload clips that you were focused on their CRF only, instead of tweaking their bitrates ?


Yep, when you encode in CRF mode, the encoder varies the bit rate automatically to reach the desired crf value.

This article gives a good overview of all the possible encoding methods.
http://slhck.info/video/2017/03/01/rate-control.html
Yes I know that (I was into that field even before post-prod), but I'm surprised you're ok to rely on it (only), for one generally prefer defining a bitrate, or in some case a final file size.
Finally, you may know the direct connection between CRF and bitrate if you're used to and/or have the right piece of software to show the math behind the curtain, but just a CRF and go... Though I admit that since we talk about Youtube, I can understand :lol:
Legacy MacPro 8core Xeons, 32 Go ram, 2 x gtx 980 ti, 1SSD for system, 2 SSDs raid0 for footage and caches, OSX ElCap and High Sierra, Resolve 15.3 Studio
Offline

Andrew Kolakowski

  • Posts: 5821
  • Joined: Tue Sep 11, 2012 10:20 am

Re: YouTube h.265 CRF & SSIM

PostTue Feb 20, 2018 5:46 pm

You can't really predict end average bitrate. For one source it will be eg. 20Mbit, for another 70Mbit.
It all depends how difficult to compressed is your source. I don't think there is a way to simulate it as you need all data from motion analysis etc in order to do so meaning- you need to simulate encode.

CRF is a mode where you don't care about end bitrate. You care about how "strongly" your final file will be compressed. You control it by setting desired CRF value. If you want file to be quite transparent to the source then it's around 15 for x264. Bitrate is a 2nd matter here. If you want file to be close to lossless then you set it to e.g.. 5.
It's very opposite mode to bitrate based one. It's very useful in some case, same way as bitrate mode in others.
Offline

Dan Sherman

  • Posts: 948
  • Joined: Fri Jul 01, 2016 11:07 pm

Re: YouTube h.265 CRF & SSIM

PostTue Feb 20, 2018 7:32 pm

@Sam Steti

I don't blindly upload a video, I watch it first and make changes if needed.
X99-A II, 6850K 4.2 GHz, GTX 1070 FE (431.36), DDR4-2400 CL12-14-14 4x8 GB
Win 10 Pro 1809, Resolve Studio 16.1.0b.017
Offline

Dan Sherman

  • Posts: 948
  • Joined: Fri Jul 01, 2016 11:07 pm

Re: YouTube h.265 CRF & SSIM

PostTue Feb 20, 2018 7:35 pm

Andrew Kolakowski wrote:CRF is a mode where you don't care about end bitrate. You care about how "strongly" your final file will be compressed. You control it by setting desired CRF value. If you want file to be quite transparent to the source then it's around 15 for x264. Bitrate is a 2nd matter here. If you want file to be close to lossless then you set it to e.g.. 5.
It's very opposite mode to bitrate based one. It's very useful in some case, same way as bitrate mode in others.


I don't know why this is so hard for so many people to understand. it's very simple and strait forward, yet so many seem completely incapable of understanding the concepts.
X99-A II, 6850K 4.2 GHz, GTX 1070 FE (431.36), DDR4-2400 CL12-14-14 4x8 GB
Win 10 Pro 1809, Resolve Studio 16.1.0b.017
Offline

Sam Steti

  • Posts: 1390
  • Joined: Tue Jun 17, 2014 7:29 am
  • Location: France

Re: YouTube h.265 CRF & SSIM

PostWed Feb 21, 2018 4:07 pm

I don't think so many people don't get it, it's very basic.

However, I prefer good 2-passes variable bitrates (from 4000 to 8000 depending on a lot of variables) and fine-tuned x264 options (like 8x8, cabac, ...), because I perfectly know "what's good" for the ProRes masters I export. And even if not every app show the direct connection between CRF and bitrates, you can easily guess by experience or have it revealed by some others apps.
So even if you maybe don't care, there is a real connection, and experience take you to rather tweak bitrates + options instead of relying on a single CRF choice...
This is the reason why I asked, because very surprised that a CRF only choice could be enough for you before encoding.
Legacy MacPro 8core Xeons, 32 Go ram, 2 x gtx 980 ti, 1SSD for system, 2 SSDs raid0 for footage and caches, OSX ElCap and High Sierra, Resolve 15.3 Studio
Offline

Andrew Kolakowski

  • Posts: 5821
  • Joined: Tue Sep 11, 2012 10:20 am

Re: YouTube h.265 CRF & SSIM

PostWed Feb 21, 2018 4:28 pm

Detailed tweaking is not needed once you pass eg. 30-40Mbit for HD. Use of preset + tuning is enough.
4-8Mbit target for HD is very different story. And you send this to youtube?
2 pass mode has no advantage over CRF if you don't target any specific size/bitrate. Read comments from x264 developer about it ( https://forum.doom9.org/showthread.php?t=143904 ).
2 pass is good when additional restrictions are needed (size, VBV etc). This is all irrelevant for creating files to send to youtube. You may want to use it if you have very low upload speed and have to fight hard with file size.
Offline

Sam Steti

  • Posts: 1390
  • Joined: Tue Jun 17, 2014 7:29 am
  • Location: France

Re: YouTube h.265 CRF & SSIM

PostWed Feb 21, 2018 6:20 pm

Hey, my H264 files are not only for YT, and I don't wanna brag but I've been doing encoding for 20 years now, even more since mp4/h264, and am also friend of x264 developers and close friend of the VLC team (involved in the same matters)... Don't "worry" for me ;)
And btw, of course 2 pass ways have advantages if you make VBR files
Legacy MacPro 8core Xeons, 32 Go ram, 2 x gtx 980 ti, 1SSD for system, 2 SSDs raid0 for footage and caches, OSX ElCap and High Sierra, Resolve 15.3 Studio
Offline

Andrew Kolakowski

  • Posts: 5821
  • Joined: Tue Sep 11, 2012 10:20 am

Re: YouTube h.265 CRF & SSIM

PostWed Feb 21, 2018 8:07 pm

We're not talking about "encoding for your special needs", but strictly about something to send to youtube.

CRF is also VBR, actually very VBR as typically people don't put any limits on it, so it goes sup to given profile/level limits. Not sure what special does VBR here in 2 pass mode.
2 pass VBR can be treated as: 2 passes with different CRF. First pass uses "random" CRF value just to "detect" source nature and 2nd pass based on this info calculates new CRF in the way, so end result hits desired bitrate.
If you knew this 2nd CRF value somehow then you could just use this and forget about 2 pass at all.

Look how very VBR is CRF mode for some random source file:

CRF:
Image

2 pass VBR (no max specified, same settings) targeting same average bitrate:
Image

Look how similar they are (final file sizes were 99.9% the same). 2nd pass adjusted beginning slightly (probably CRF needs some time for algorithm to kick in with better "prediction").

PSNR values:
CRF: PSNR y:43.881457 u:47.754068 v:48.868065 average:45.544948 min:42.364842 max:50.672106
2pass: PSNR y:43.816892 u:47.713389 v:48.876026 average:45.492346 min:41.931316 max:50.913391

what have I gained using 2 pass mode? Nothing in this case as I didn't care much about size (whatever I end up with 38Mbit average or 25Mbit or 50Mbit), just wasted time for 2nd pass. Average PSNR is the same, min also (so no very bad quality frames).

Nothing wrong with using 2 pass VBR mode where it's needed (targeting e.g. Blu-ray disc etc), but for creating youtube upload "master" is about useless. We're using quite high bitrates so any quality difference (if there is any real one) will be totally meaningless anyway.
Last edited by Andrew Kolakowski on Thu Feb 22, 2018 12:00 am, edited 1 time in total.
Offline

Michael Del Papa

  • Posts: 159
  • Joined: Sun Feb 07, 2016 2:21 am

Re: YouTube h.265 CRF & SSIM

PostWed Feb 21, 2018 11:48 pm

Just cuz you have been doing something for 20 years and/or are able to name drop (although that carries a lot of cachet in LA) doesn't mean you know what you are doing or worse aren't spreading bad advice.

Whether you speak truth is the only thing that matters to me. While Andrew and I have disagreed in the past, everything he has said here is correct.

Multi-pass encoding is a necessary evil (not to be confused with advantageous) when faced with literal constraints like an authoring program potentially not accepting a bitstream. Even in a upload limited world I can't think of why I would waste cpu cycles on multi-pass.
Offline

Andrew Kolakowski

  • Posts: 5821
  • Joined: Tue Sep 11, 2012 10:20 am

Re: YouTube h.265 CRF & SSIM

PostWed Feb 21, 2018 11:58 pm

I don't think Sam is spreading "bad" message. He just talking more generic (or actually to specific) where this thread was mainly about youtube delivery.
As I keep saying- don't try to apply one workflow/rule etc to all scenarios.
Offline

Dan Sherman

  • Posts: 948
  • Joined: Fri Jul 01, 2016 11:07 pm

Re: YouTube h.265 CRF & SSIM

PostThu Feb 22, 2018 1:04 am

Andrew Kolakowski wrote: where this thread was mainly about youtube delivery.
As I keep saying- don't try to apply one workflow/rule etc to all scenarios.


Exactly!


I would go as far as saying, no mater what you graph against SSIM or PSNR, the graph will generally be shaped like this one.
Image

It doesn't matter what the codec is, or how it was encoded, you are always going to run into the YouTube re-encoding brick wall. After a certain point no matter what you do, it won't make a difference to what viewers actually see.

Imo, if you're serious about what you are delivering, then you need to dedicate some time to test and optimize your workflow. You also need to keep in mind what might be the best for you today might not be the case a year from now, as the target is always moving.
X99-A II, 6850K 4.2 GHz, GTX 1070 FE (431.36), DDR4-2400 CL12-14-14 4x8 GB
Win 10 Pro 1809, Resolve Studio 16.1.0b.017
Offline

Sam Steti

  • Posts: 1390
  • Joined: Tue Jun 17, 2014 7:29 am
  • Location: France

Re: YouTube h.265 CRF & SSIM

PostThu Feb 22, 2018 10:26 am

Dan Sherman wrote:Imo, if you're serious about what you are delivering, then you need to dedicate some time to test and optimize your workflow.
Thank you, I agree.
Legacy MacPro 8core Xeons, 32 Go ram, 2 x gtx 980 ti, 1SSD for system, 2 SSDs raid0 for footage and caches, OSX ElCap and High Sierra, Resolve 15.3 Studio

Return to DaVinci Resolve

Who is online

Users browsing this forum: cadeg_rsh and 43 guests