Delivering x264

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

Jim Simon

  • Posts: 841
  • Joined: Fri Dec 23, 2016 1:47 am

Re: Delivering x264

PostWed Feb 21, 2018 9:57 pm

Sorry about the confusion, Bryan.

As the GH4 project was a one off and all my professional work is done using CinemaDNG from the Pocket, I did switch over to testing that exclusively.

However, after your question I did go back check the GH4 media. There is a visible change when switching from Video to Full, as I would expect. There is also visible change for ProRes, which is nice.

But...that still leaves the question of why no change for CinemaDNG? I'd prefer to work and deliver in full range on my projects.
Offline

Jim Simon

  • Posts: 841
  • Joined: Fri Dec 23, 2016 1:47 am

Re: Delivering x264

PostWed Feb 21, 2018 10:05 pm

Here's an additional oddity.

With the GH4 media that was shot Full range (0-255), I do see a difference if I change the Clip Attributes. This is good. I can decide which level I want to work in.

But things get weird during export.

Clip = Full, Export = Full - They do not match (Huh?)
Clip = Full, Export = Video - They match (Huh?)
Clip = Video, Export = Full - They don't match (Expected)
Clip = Video, Export = Video - They match. (Expected)

So, the original clip and the export only match when the export is set to Video, regardless of what the clip is set to. How's that possible?
Offline

Jim Simon

  • Posts: 841
  • Joined: Fri Dec 23, 2016 1:47 am

Re: Delivering x264

PostWed Feb 21, 2018 10:32 pm

With some additional testing on CinemaDNG, I get similar results. The export only matches the original when set to Video level, despite what the Clip Attributes is set to.

The difference here is that the two Video exports match each other, whereas they were slightly different when using the GH4 media. (The Video export from a Full range clip was slight different from the Video export of a Video clip.) This means that Resolve is treating CinemaDNG as Video level, regardless of what the Clip Attribute is set to.

That explains why I saw no difference when changing it.

But it also raises the question of how do we get CinemaDNG to Full range. As a RAW format, I'd expect that to be the norm. Or at least...possible.
Offline

Andrew Kolakowski

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

Re: Delivering x264

PostWed Feb 21, 2018 10:46 pm

For CDNG it's irrelevant as you can't export back to RAW.
When you export to ProRes etc. whatever you set during export this needs to be matched on import - either full or limited and if this is done then all should be good. Resolve for all YUV based formats assume rather limited range even if e.g. for DNxHR flags say differently.
Offline

Jim Simon

  • Posts: 841
  • Joined: Fri Dec 23, 2016 1:47 am

Re: Delivering x264

PostWed Feb 21, 2018 11:04 pm

Andrew Kolakowski wrote:For CDNG it's irrelevant as you can't export back to RAW.


I'm not expecting to export back to RAW. I'm wanting to work and export a Full range signal from my CinemaDNG media.
Offline

Jim Simon

  • Posts: 841
  • Joined: Fri Dec 23, 2016 1:47 am

Re: Delivering x264

PostWed Feb 21, 2018 11:07 pm

John Paines wrote:Once debayered, CDNG is going to be mapped to 16-235, no?


It appears so. How do we change that?
Offline

Jim Simon

  • Posts: 841
  • Joined: Fri Dec 23, 2016 1:47 am

Re: Delivering x264

PostWed Feb 21, 2018 11:08 pm

Bryan Worsley wrote:Out of interest, what are your MeGUI x264 settings ?


program --bluray-compat --preset slower --tune film --crf 16 --keyint 12 --ipratio 1.0 --pbratio 1.0 --colorprim bt709 --transfer bt709 --colormatrix bt709 --sar 1:1
Offline

Bryan Worsley

  • Posts: 215
  • Joined: Fri Apr 15, 2016 11:26 am
  • Location: Montreal, Canada

Re: Delivering x264

PostThu Feb 22, 2018 3:52 am

Jim Simon wrote:Here's an additional oddity.

With the GH4 media that was shot Full range (0-255), I do see a difference if I change the Clip Attributes. This is good. I can decide which level I want to work in.

But things get weird during export.

Clip = Full, Export = Full - They do not match (Huh?)
Clip = Full, Export = Video - They match (Huh?)
Clip = Video, Export = Full - They don't match (Expected)
Clip = Video, Export = Video - They match. (Expected)

So, the original clip and the export only match when the export is set to Video, regardless of what the clip is set to. How's that possible?


Like Andrew said:

Andrew Kolakowski wrote:When you export to ProRes etc. whatever you set during export this needs to be matched on import - either full or limited and if this is done then all should be good. Resolve for all YUV based formats assume rather limited range even if e.g. for DNxHR flags say differently.


That pattern of results would be explained by your re-importing the exports at 'video' levels.

Jim Simon wrote:The difference here is that the two Video exports match each other, whereas they were slightly different when using the GH4 media. (The Video export from a Full range clip was slight different from the Video export of a Video clip.)


I assume we are talking about the same clip here and by 'Full range clip' and 'Video clip' you are just referring to the data level assigned on import. If so:

The 'Video export from a Full range clip' will be compressed to 16-235 (64-940) range
The 'Video export of a Video clip' will be clamped to 16-235 (64-940) range

As I commented earlier:

Bryan Worsley wrote:Something to be aware of also - if you were to import and 'pass through' (i.e. without any manipulation of levels on the Color page) your full range footage at 'Full' data levels and export at 'Video' levels it will get compressed (proportionately) to 16-235 (64 - 940) range on export, not clamped/clipped


And that explains why:

Jim Simon wrote:Clip = Full, Export = Video - They match (Huh?)


The export in this case will be compressed to 16-235 (64-940), so when re-imported at 'video' levels, the scope profiles will 'match' (or be very similar to) those of the original full range clip imported at 'full' levels.
Offline

Bryan Worsley

  • Posts: 215
  • Joined: Fri Apr 15, 2016 11:26 am
  • Location: Montreal, Canada

Re: Delivering x264

PostThu Feb 22, 2018 4:33 pm

Jim Simon wrote:
Bryan Worsley wrote:Out of interest, what are your MeGUI x264 settings ?


program --bluray-compat --preset slower --tune film --crf 16 --keyint 12 --ipratio 1.0 --pbratio 1.0 --colorprim bt709 --transfer bt709 --colormatrix bt709 --sar 1:1


Interesting choice of settings, for 24p I assume ? You do realize that it severely restricts CRF rate control from working it's magic and will push the bitrate up markedly compared to unrestricted CRF 16. Any particular reason why you chose to set the I-P and P-B frame quantizer ratios at parity ? Rapidly changing scenes with a lot of fast motion maybe ? Lowering the ipratio can reduce the potential for temporal fluttering at higher bitrates, but the general recommendation is to leave both parameters at default. And/or was this a profile recommended for a particular playback device - for optimal navigation/freeze frame control maybe ?

FWIW - this is what I use (for 1080/30p) for Blu-ray and NAS-served streaming over LAN:

Code: Select all
program --level 4.1 --output-depth 8 --bluray-compat --preset slow --tune film --crf 18.0 --keyint 30 --open-gop --b-adapt 2 --slices 4 --qpmax 69 --vbv-bufsize 30000 --vbv-maxrate 40000 --me umh --trellis 1 --fake-interlaced --colorprim bt709 --transfer bt709 --colormatrix bt709 --sar 1:1
Last edited by Bryan Worsley on Thu Feb 22, 2018 5:18 pm, edited 5 times in total.
Offline

Andrew Kolakowski

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

Re: Delivering x264

PostThu Feb 22, 2018 4:46 pm

Jim Simon wrote:program --bluray-compat --preset slower --tune film --crf 16 --keyint 12 --ipratio 1.0 --pbratio 1.0 --colorprim bt709 --transfer bt709 --colormatrix bt709 --sar 1:1


Those setting are bit strange. Short GOP of only 12 frames, CRF=16, yet BD compliant restrictions, IP, PB settings- all bit strange.
Offline

Andrew Kolakowski

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

Re: Delivering x264

PostThu Feb 22, 2018 5:15 pm

Bryan Worsley wrote:FWIW - this is what I use (for 1080/30p) NAS-served streaming over LAN to a BD player:

Code: Select all
program --level 4.1 --output-depth 8 --bluray-compat --preset slow --tune film --crf 18.0 --keyint 30 --open-gop --b-adapt 2 --slices 4 --qpmax 69 --vbv-bufsize 30000 --vbv-maxrate 40000 --me umh --trellis 1 --tff --colorprim bt709 --transfer bt709 --colormatrix bt709 --sar 1:1


You can remove those "strong" BD restrictions as even if it's decode by BD player it's not anymore a BD format coming from disc. Those players can in most case do much more than BD spec allows.

--bluray-compat most likely can go
--vbv-bufsize 30000
--vbv-maxrate 40000
both can be probably raised (e.g. try both at 62500 which is 4.1 level limit). Then CRF may be lowered a bit for even better quality- if it's really needed.
Last edited by Andrew Kolakowski on Thu Feb 22, 2018 5:32 pm, edited 2 times in total.
Offline

Dan Sherman

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

Re: Delivering x264

PostThu Feb 22, 2018 5:20 pm

I can't speak for GH4 footage, but if i take my GH5 footage directly into resolve, You can see a big difference when you change the levels.
Offline

Andrew Kolakowski

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

Re: Delivering x264

PostThu Feb 22, 2018 5:24 pm

Latest Resolve should read full range flagging in GH4/5 footage (if you changed it in camera). I think this was implemented, no? Maybe I'm messing with something else :)
Offline

Bryan Worsley

  • Posts: 215
  • Joined: Fri Apr 15, 2016 11:26 am
  • Location: Montreal, Canada

Re: Delivering x264

PostThu Feb 22, 2018 5:29 pm

Andrew Kolakowski wrote: --tff turns interlaced encoding- should be not needed


Posted the wrong profile - that one was for 60i, not 30p. Edited my last post accordingly.

Andrew Kolakowski wrote:You can remove those "strong" BD restrictions as even if it's decode by BD player it's not anymore a BD format coming from disc. Those players can in most case do much more than BD spec allows.


I do use the same profile for BD disc, hence the bluray-compat restrictions.
Offline

Jim Simon

  • Posts: 841
  • Joined: Fri Dec 23, 2016 1:47 am

Re: Delivering x264

PostThu Feb 22, 2018 6:57 pm

Bryan Worsley wrote:That pattern of results would be explained by your re-importing the exports at 'video' levels.


I'm such a dolt.
Last edited by Jim Simon on Thu Feb 22, 2018 7:24 pm, edited 1 time in total.
Offline

Jim Simon

  • Posts: 841
  • Joined: Fri Dec 23, 2016 1:47 am

Re: Delivering x264

PostThu Feb 22, 2018 7:01 pm

Bryan Worsley wrote:Any particular reason why you chose to set the I-P and P-B frame quantizer ratios at parity ?


I want the I, P and B frames at the same quality. I don't want to reduce the RF for P and B frames.
Offline

Jim Simon

  • Posts: 841
  • Joined: Fri Dec 23, 2016 1:47 am

Re: Delivering x264

PostThu Feb 22, 2018 7:04 pm

Andrew Kolakowski wrote:Short GOP of only 12 frames, CRF=16, yet BD compliant restrictions


I use my Blu-ray settings for MP4 delivery. The only difference is that Blu-ray comes out as .264 files for authoring, whereas USB delivery muxes video and audio into one file.

The Blu-ray and the MP4 look the same. Both look damn good.
Offline

Jim Simon

  • Posts: 841
  • Joined: Fri Dec 23, 2016 1:47 am

Re: Delivering x264

PostThu Feb 22, 2018 7:05 pm

Dan Sherman wrote:I can't speak for GH4 footage, but if i take my GH5 footage directly into resolve, You can see a big difference when you change the levels.


Yeah, I was doing things wrong. Bryan set me straight.
Last edited by Jim Simon on Thu Feb 22, 2018 7:07 pm, edited 1 time in total.
Offline

Jim Simon

  • Posts: 841
  • Joined: Fri Dec 23, 2016 1:47 am

Re: Delivering x264

PostThu Feb 22, 2018 7:07 pm

Andrew Kolakowski wrote:Latest Resolve should read full range flagging in GH4/5 footage (if you changed it in camera).)


You may be right. Auto and Full look the same with GH4 media shot Full range. Video looks different.
Offline

Jim Simon

  • Posts: 841
  • Joined: Fri Dec 23, 2016 1:47 am

Re: Delivering x264

PostThu Feb 22, 2018 7:23 pm

So I think I have things figure out with the GH4 media, but the CinemaDNG is still confusing.

1. Auto, Video and Full Clip Attributes don't make any visible difference for CinemaDNG clips.

2. The only way I can get parity with the original is to export at Video levels and Interpret that as Full (or Auto) when I bring it back in.

I'm so confused.
Offline

Jim Simon

  • Posts: 841
  • Joined: Fri Dec 23, 2016 1:47 am

Re: Delivering x264

PostThu Feb 22, 2018 7:44 pm

John Paines wrote:Set your data levels at "video" (don't leave it at "auto"). Looks to be a bug, auto shouldn't be defaulting to "full".


You may be onto something here.

When I set my Cineform AVI Export to Video levels, bring that back into Resolve and set Clip Attributes to Auto or Full, it matches the original. If I set the Clip Attributes to Video, it doesn't match the original.

Put another way, the export set to Video looks the same when Clip Attributes are set to Auto or Full. It changes when interpreted as Video.

So it does look like a bug with Data Levels for AVI files on the Deliver Page.
Offline

Andrew Kolakowski

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

Re: Delivering x264

PostThu Feb 22, 2018 7:52 pm

Yes, Cineform AVI case looks like a bug in Resolve.
I'm not 100% but almost sure (to lazy to try) it's all good on Mac for MOV (and you said it's also fine for MOV on PC).
Offline

Bryan Worsley

  • Posts: 215
  • Joined: Fri Apr 15, 2016 11:26 am
  • Location: Montreal, Canada

Re: Delivering x264

PostThu Feb 22, 2018 9:06 pm

Jim Simon wrote:So I think I have things figure out with the GH4 media, but the CinemaDNG is still confusing.


I've no experience with CinemaDNG and can't help you on that, but I'm glad things are clearer now with the GH4 media.
Offline

Norman Black

  • Posts: 14
  • Joined: Mon Oct 16, 2017 2:26 am
  • Location: Thousand Oaks, CA

Re: Delivering x264

PostThu Feb 22, 2018 9:31 pm

Jim Simon wrote:
Bryan Worsley wrote:Any particular reason why you chose to set the I-P and P-B frame quantizer ratios at parity ?


I want the I, P and B frames at the same quality. I don't want to reduce the RF for P and B frames.


Ok but ipratio 1.0 actually lowers the I-frame quantizer that would be used versus the default 1.4. Thus when a p/b frame references an I-frame one can actually be lowering quality since the I-frame is of lower quality with ipratio 1.0. Also there is some confusion about pbratio doing anything at all when mbtree is active. Mbtree is active in your selected preset (slower).

RF (rate factor?) is something different than quantizer which is what the ratio options adjust.

x264 is kinda p-frame centric with these ratio settings if I remember my Doom9 correctly.

I quantizer = Q / ipratio, B quantizer = Q * pbratio

Why change the very technical settings like ipratio/pbratio from the defaults? The x264 developers kinda know their thing. Of course they are general and not ideal for everything. One will have situational things where tweaking will be a good thing, but every situation is different. Who wants to render many times trying different things to find the absolute best for each situation. One man's opinion.
Resolve 15b3
Win 10 1803, i7-4770K @ 4.0 GHz, 16GB RAM
GTX 1080 8GB
Offline

Andrew Kolakowski

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

Re: Delivering x264

PostThu Feb 22, 2018 10:50 pm

Jim Simon wrote:
Bryan Worsley wrote:Any particular reason why you chose to set the I-P and P-B frame quantizer ratios at parity ?


I want the I, P and B frames at the same quality. I don't want to reduce the RF for P and B frames.


Hmm- there is a reason for those default settings and adjusting them strongly and creating new defaults for every source is very unlikely to have positive effect. I think you should stick to defaults. If you have specific source which shows e.g. I frame "pumping" then you can correct it by adjusting them.
As Norman said- x264 developers came to those settings after countless tests and reports from users (this is why doom9 community is so useful). There is no way you came with new better defaults "just like that" :)
Offline

Bryan Worsley

  • Posts: 215
  • Joined: Fri Apr 15, 2016 11:26 am
  • Location: Montreal, Canada

Re: Delivering x264

PostSun Feb 25, 2018 4:04 am

Norman Black wrote: Also there is some confusion about pbratio doing anything at all when mbtree is active. Mbtree is active in your selected preset (slower).


Just ran some tests with MeGUI (32-bit, version 2826, x264 build 2901) which confirm that modifying the pbratio setting has no effect (on the encoded average I, P and B quantizer values) when MBTree is enabled, as it is by default. Makes you wonder why the developers don't just grey-out the pbratio setting when MBTree is active.

Jim Simon wrote:On a positive note, it looks like Resolve's High MP4 preset is very close to my "Ludicrous Speed" MeGUI settings in overall bitrate and quality, so maybe I'll just use that.

Jim Simon wrote:
Bryan Worsley wrote:Any particular reason why you chose to set the I-P and P-B frame quantizer ratios at parity ?


I want the I, P and B frames at the same quality. I don't want to reduce the RF for P and B frames.


If you are happy with the quality of Resolve's H264.mp4, which is Constant Quantizer (CQ) in Auto Quality mode, I'd say stick with that. No sense in jumping through these external encoder hoops if it's not adding any perceived value for you. You can specify the key frame interval (GOP length), bearing in mind it's 'Closed' GOP only....but that's what your MeGUI x264 profile was set for. Also no CABAC encoding, only CAVLC.
Offline

Jim Simon

  • Posts: 841
  • Joined: Fri Dec 23, 2016 1:47 am

Re: Delivering x264

PostSun Feb 25, 2018 7:32 pm

Norman Black wrote:ipratio 1.0 actually lowers the I-frame quantizer that would be used versus the default 1.4.


I am using a Constant Quality (Rate Factor) setting, so I don't necessarily expect the Quantizer to remain constant.

What I don't want is for the P and B frames to be of reduced quality compared to the I-frame, which is what values greater than 1 achieve. I want all frames at the same quality.
Offline

Andrew Kolakowski

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

Re: Delivering x264

PostSun Feb 25, 2018 7:44 pm

It's normal for P,B frame to be bit lower quality. This is the way how long GOP encoding works.
Do you expect to take those bits from I frames and not suffer on quality? There is nothing for free. Those ratios were carefully chosen and as I said- there is no way you can come up with better default values which will work for every source. If anything only small adjustments may be needed for particular source.
Don't try to re-invet a wheel :)
Offline

Bryan Worsley

  • Posts: 215
  • Joined: Fri Apr 15, 2016 11:26 am
  • Location: Montreal, Canada

Re: Delivering x264

PostMon Feb 26, 2018 3:26 am

Jim Simon wrote:What I don't want is for the P and B frames to be of reduced quality compared to the I-frame, which is what values greater than 1 achieve.


All that setting both the ipratio and pbratio to 1.0 (which requires turning off MBTree) achieves at a given CRF value is some shift in the relative bit allocation - it will not produce I, P and B frames of equal metric quality.

Jim Simon wrote:I want all frames at the same quality.


You'll only get that with 'all I-frame' (intra) compression i.e. --keyint 1 --min-keyint 1
Previous

Return to DaVinci Resolve

Who is online

Users browsing this forum: Aaron Hinton and 10 guests