Poor H264 encoding quality in DaVinci

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

Bryan Worsley

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

Re: Poor H264 encoding quality in DaVinci

PostTue Apr 25, 2017 2:51 pm

Al Spaeth wrote:.....and await your empirical results to see how much better x264 encoding is from DNx/Cineform vs Resolve 14 mp4. Thanks :)


You're not hearing me. I have no intention of going back at Resolve 14 beta. Resolve 12.5.5 is stable and adequate for my present needs.
Offline

Al Spaeth

  • Posts: 329
  • Joined: Thu Sep 17, 2015 9:48 pm
  • Location: South Africa

Re: Poor H264 encoding quality in DaVinci

PostTue Apr 25, 2017 3:14 pm

Time will tell :)
Resolve 15.3 free Win 10 64bit
Offline
User avatar

Survivor_Films

  • Posts: 218
  • Joined: Wed May 14, 2014 7:48 pm
  • Location: London

Re: Poor H264 encoding quality in DaVinci

PostTue Apr 25, 2017 6:11 pm

I just tested the MP4 encoding in R14 on its 'best' settings and it's not really usable for any kind of delivery - horrible macro-blocking in the shadows and smearing of grain - here's a comparison:

(I've brightened the bottom version so you can see more clearly against a bright backdrop)

Image

In terms of size comparison, the Resolve version of this encode was 59.4MB - x264 was 61.2MB.
Offline

Bryan Worsley

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

Re: Poor H264 encoding quality in DaVinci

PostWed Apr 26, 2017 1:13 am

There you go Al, probably more meaningful than mere numbers.
Offline

Bryan Worsley

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

Re: Poor H264 encoding quality in DaVinci

PostWed May 03, 2017 2:23 pm

Andrew Kolakowski wrote:
Bryan Worsley wrote:
Bryan Worsley wrote:
Edit: After further testing, I've changed my view on that. With 8-bit 420 inputs, exporting to a 10-bit 422 format (say DNxHR-HQX) does ANYWAY make for higher precision in applied color transforms ('grades'), irrespective of whether optimized media are generated (in the same format and resolution) and applied on the timeline or not. Furthermore, exporting the optimised media itself does not improve on that. So really the only benefit in generating 10-bit 422 optimized media for 8-bit 420 sources is for timeline performance....as well as the gratification of seeing smoother scope profiles on the timeline as transforms are applied. That's good.


Converting 8bit to 10bit is not going to make your footage "more grading resistant" or give any advantage in Resolve in terms of quality. This would only be true for some advanced 8bit->10bit conversion, but this is not what Resolve does.


Andrew Kolakowski wrote:.... but it doesn't really matter if you use 8bit intermediate or 10bit. Calculations are done at 32bti float, so data once decode gets always converter to this format and then back to some other when send to the codec for the export.
Resolve is not a transcoder, where you can avoid some not needed conversion steps (e.g. RGB<->YUV or 8bit<->10bit). Resolve has to normalise all incoming data to 32bit float format.
As I already mentioned for this reason Resolve is not the best choice when you need to convert YUV based formats to other YUV based ones as it will always force conversion to 32bit float 4:4:4.


I understand better what you were saying now. Here's one of a set of tests I ran, again purely to inform myself on the subject from an in-use perspective (sort of), but maybe of general interest.

I took an 8-bit greyscale ramp and rendered out from Resolve (all at Full Data Levels) to Uncompressed 422 10-bit and 8-bit. And then analysed the files with the AVISynth Histogram filter:

http://avisynth.nl/index.php/Histogram

I used FFMS2Mod for decoding with and without dithering and converted to 8-bit 420 with ConvertToYV12. So 'without dithering' was via YUY2 and 'with dithering' was facilitated by the 'enable10bithack' option, coupled with f3kdb_dither, via YV16. I know you are well familiar with all of this AVISynth stuff Andrew, so don't need to go into further details and post the scripts.

Here are the results obtained with the Histogram plugin - first in 'Levels' mode which displays the YUV Histogram:

http://i.imgur.com/KQEiupF.png

...and then in 'luma' mode which, quote ".....will amplify luminance, and display very small luminance variations. This is good for detecting blocking and noise, and can be helpful at adjusting filter parameters. In this mode a 1 pixel luminance difference will show as a 16 pixel luminance pixel, thus seriously enhancing small flaws"

http://i.imgur.com/mZBemNm.png

I then ran the same tests, this time applying contrast S-curve (strength 1.4) in Resolve.
The YUV Histograms:

http://i.imgur.com/vav6cHP.png

And in amplified 'luma' mode:

http://i.imgur.com/4MUlE72.png

The point this illustrates ? No, exporting a graded 8-bit source as 10-bit 422 does not in itself make for greater 'grade resistance' i.e. less tendency to introduce or exacerbate (existing) banding/posterization artifacts when the tonal curve is pushed - what I referred to (rightly or wrongly) as 'precision'. What does give the perception of 'grade resistance' however is when dithering is applied in the conversion back to 8-bit 4:2:0.

And here (as relevant to the thread topic) are the results obtained when that uncompressed 10-bit 422 render (where contrast had been applied) was transcoded to x264 (CRF 10) with ffmpeg (CLI), which does apply dithering by default in the conversion of 10-bit 422 to 8-bit 420. And for comparison, the same project rendered out to Resolve's own H264 format at Best quality:

http://i.imgur.com/Hs7H4Z4.png
http://i.imgur.com/QL6thyV.png

I should be stressed of course that the AVISynth Histogram 'Luma Mode' analysis is amplifying trace anomalies that may or may not be obvious to the naked eye, but this does support the observation made by Survivor_Films:

Survivor_Films wrote:I just tested the MP4 encoding in R14 on its 'best' settings and it's not really usable for any kind of delivery - horrible macro-blocking in the shadows and smearing of grain - here's a comparison:

(I've brightened the bottom version so you can see more clearly against a bright backdrop)

Image



BTW - this was all done with Resolve 12.5.5; I know what you are going to say Al - it would be interesting to repeat the tests with Resolve 14 beta and compare H264 mov and mp4, but as I stated:

Bryan Worsley wrote:I have no intention of going back at Resolve 14 beta. Resolve 12.5.5 is stable and adequate for my present needs.


And this was primarily for my own interest.
Online

Andrew Kolakowski

  • Posts: 9207
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Poor H264 encoding quality in DaVinci

PostWed May 03, 2017 3:48 pm

All looks as expected.
You used CRF=10, this is crazy high quality and as far as this preserves dithered gradient well , higher CRF values most likely will bring banding back.
What dithering have you used- Floyd-Steinberg/Sierra?
Offline

Al Spaeth

  • Posts: 329
  • Joined: Thu Sep 17, 2015 9:48 pm
  • Location: South Africa

Re: Poor H264 encoding quality in DaVinci

PostWed May 03, 2017 3:50 pm

Thanks Bryan - I think - as you are way over my head so I won't ask you to repeat it with 14. ;)
My only hope is that Resolve improves their h.264 encoder.
Resolve 15.3 free Win 10 64bit
Offline

Bryan Worsley

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

Re: Poor H264 encoding quality in DaVinci

PostThu May 04, 2017 2:08 am

Andrew Kolakowski wrote:All looks as expected.
You used CRF=10, this is crazy high quality and as far as this preserves dithered gradient well , higher CRF values most likely will bring banding back.


Quite honestly I used CRF=10 simply because in some other tests with native HD-AVC clips it gave bitrates in the same ballpark as Resolve H624 Best Quality. I should maybe have checked the bitrates in this case, because there was a big difference. Here's the same test with x264 encoded at CRF=18.

http://i.imgur.com/aQHDmz3.png
http://i.imgur.com/D8jXe41.png

With the 8-bit Uncompressed 422 render, the resulting x264 bitrate was 419kbps and with the 10-bit Uncompressed render, 530kbps. But the Resolve H264 render at Best quality was just 151kbps and nothing could be done to increase it; switching to maximum bitrate mode only dropped it to 120kbps. To get a comparable bitrate with x264 (from the 8-bit Uncomp.422 render) would need CRF=24 and I'd never go that low with HD. So perhaps not surprising that the Resolve H264 render shows so much blocking in this particular case.

Andrew Kolakowski wrote:What dithering have you used- Floyd-Steinberg/Sierra?


In the tests using FFMS2Mod, yes, Floyd-Steinberg - the default for f3kdb_dither

As for ffmpeg, I have no idea what default dithering algorithm it uses.
Offline

Chris Hagemeier

  • Posts: 5
  • Joined: Sun May 07, 2017 4:52 am

Re: Poor H264 encoding quality in DaVinci

PostSun May 07, 2017 5:03 am

Hi,

I used to cut my videos with Premiere Pro. However, I never liked it very much and so I have cancelled my CC subscription. I switched to the Resolve 14 beta recently, and I quite like it.

For the final encoding I switched to Handbrake (x265), the encoding quality is very good (despite beeint rather slow). As mezzanine codec for the Resolve export I have to use a Handbrake compatible format... Currently I'm using MOV uncompressed 422 10Bit, the original footage is 4k 50p filmed on a GH5.

Problem is the huge file size of my Resolve exports. Is there a better option for my intermediate export codec than the above mentioned one? Most important for me is to not loose any quality in the handbrake encoding template.

Or do I simply have to buy larger hard drives?

Greetings, sorry for my pigeon english,
Chris
Offline

Bryan Worsley

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

Re: Poor H264 encoding quality in DaVinci

PostSun May 07, 2017 5:24 pm

So the above tests illustrate that with 8-bit inputs, exporting to 10-bit 422 does not in itself confer higher 'grade resistance' but may have value when dithered conversion back to 8-bit serves to alleviate banding/posterization artifacts that may be introduced or exacerbated by the grading.

But what about transcoding 8-bit sources to 10-bit 422 for input? The received wisdom again is that there is nothing to be gained by it, and especially in systems that process with 32-bit float:

https://forum.blackmagicdesign.com/viewtopic.php?f=3&t=34469
https://forum.blackmagicdesign.com/viewtopic.php?f=3&t=4355
https://forums.creativecow.net/thread/277/39122
https://forums.adobe.com/thread/1839443


If that is indeed the verdict, great, I would be more than happy to dispense with transcoding and move to native input, at least for HD-AVC sources. But what still perplexes me is why the scope profiles are always smoother with 10-bit 422 transcodes compared to 8-bit 422 transcodes or native 8-bit 420 input.

Using the same test as above I took that same 8-bit greyscale ramp and transcoded to Uncompressed 8-bit 422 (2vuy) and Uncompressed 10-bit 422 (v210) with ffmpeg to ensure that the full luma range was preserved. As before I loaded the files into Resolve (at Full Data Levels), applied a contrast s-curve (strength 1.4) and rendered out to both 8bit and 10-bit Uncompressed 422. And then examined the AVISynth YUV Histograms and amplified 'Luma' profiles after conversion back to 8-bit YV12 using FFMS2Mod as the decoder, with and without dithering of the rendered 10-bit 422 renders (as described above). Here are the results:

Without dithering:

YUV Histograms:
http://i.imgur.com/nFmJlex.png

Amplified Luma profiles:
http://i.imgur.com/n8V8TFK.png

And then with dithering:

YUV Histograms:
http://i.imgur.com/VY0a82J.png

Amplified Luma profiles:
http://i.imgur.com/Tt5SDnP.png

And then another set where I brought the Uncompressed 422 transcodes into Resolve at Video Levels and applied highlight pull-down and shadow lift (with the log wheels) to bring the full 0-1023 data range into 'video' 64-940 range.

Without dithering:

YUV Histograms:
http://i.imgur.com/QvAqCKC.png

Amplified Luma profiles:
http://i.imgur.com/RcLHegJ.png

And with dithering:

YUV Histograms:
http://i.imgur.com/59J0zck.png

Amplified Luma profiles:
http://i.imgur.com/cbYpHJ4.png

In both sets it's difficult to ignore that the observation that when the 10-bit 422 transcode was used for input, the resulting YV12 profiles were much smoother with markedly less luma spiking (i.e. banding), irrespective of whether dithering was applied in final conversion or not.

So what's happening there? Is it possible that noise in the 8-bit source is itself introducing some dithering in the conversion of 8-bit to 10-bit 422 ?

There's even a suggestion in this article that Resolve deliberately applies dithering when transcoding 8-bit to 10-bit formats:

https://www.provideocoalition.com/transcode-before-color-premiere

Is that actually true and, if so, by what means - adding some noise ?

I'm not trying to make any particular point here by the way - just wanting to better understand what is actually observed in practice.
Online

Andrew Kolakowski

  • Posts: 9207
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Poor H264 encoding quality in DaVinci

PostSun May 07, 2017 7:01 pm

8bit gradient exported as 8bit and converted with ffmepg as 10bit uncompressed file. Both versions look identical in AE even after heavy curve. ffmepg does not try to re-scale data, just inserts 8bit into 10bit as is, which is good for this test.
We have the same 8bit gradient in 8bit and 10bit uncompressed files now.

1. I've imported them to Resolve, applied crazy curve and results look identical, which proves that Resolve does nothing special to 8bit files at all, compared to 10bit source.

2. I've exported this processed Resolve footage as 8bit and 10bit. Imported back to AE and checked- they look about identical. Any difference comes from the fact that Resolve has to convert internal 32bit data into 8 or 10bit depending on chosen codec, so this will look slightly different.

3. Now the same, but I've exported 8bit gradient from AE into 8bit and 10bit uncompressed. They look slightly different. Processed these through Resolve and exported back and this original difference was "preserved"+ slightly more added during Resolve export (as in 1st case). Maybe overall 10bit one looks "better", but this is about meaningless difference.

There is nothing special at all how Resolve treats 8bit v10bit data or how it convert it during export. It doesn't do any sort of dithering etc. at all. That's a shame as internally its 32bit float data could be nicely dithered just before export (even if delivery is 10bit).

I think you "discovered" that when you have 8bit data and keep processing and exporting it back to 8bit data at some point it will be different (worse after many conversions) then if you would convert this 8bit data into 10bit and then keep applying same processing, but exporting to 10bit. This is expected and not Resolve related at all.

Lets say 8bit is precision to whole digit (=8bit export). In the same time we're allowed to do float intermediate math (like Resolve internal engine). Think about 2 step processing ( export->import->export):
1. (1+6)/2=3.5, but on export this is 4 (whole digit precision)
2. take back result: (4+7)/2=5.5, but on export we get 6 as final value.

Now lets do the same with 1 digit after . precision (imagine this is 10bit precision):
1. (1+6)/2=3.5 and on export we also get 3.5
2. take back result: (3.5+7)/2=5.25, but on export we get 5.3

If we were now to normalise both files into 8bit (single digit precision) they would give 6 and 5 result, so different (with 5 been more correct), which means "10bit route" is more precise.

This is why 8bit inside 10bit after many calculations/exports back to 10bit will give different result than when we start with same data as 8bit and export to 8bit format. Key element here is 8bit export (as internal processing is always 32bit float). We keep heavily rounding results during this 8bit exports. This is why good masters should be always keep at higher bit depth than later possible delivery formats (also in case we want to do changes). It also shows that internal processing should be also done at hight precision then source files are (exports will be).

Question is- how quickly this is visible in real files, with real type of grading (not pushing data into limits with crazy YUV curve)? I don't think that during typical work you will ever see real difference.
Offline

Bryan Worsley

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

Re: Poor H264 encoding quality in DaVinci

PostSun May 07, 2017 7:37 pm

Thanks Andrew. I'll take some time to go through and fully understand your explanation and reasoning, but I get the gist.

Just to note though that the 8-bit and 10-bit Uncompressed 422 files used for input in these tests were encoded directly with ffmpeg from the same 8-bit RGB24 ramp clip (original png image converted to 5 sec avi clip); the 10-bit 422 file was not derived from the 8-bit 422 file.

Andrew Kolakowski wrote:... ffmepg does not try to re-scale data, just inserts 8bit into 10bit as is...


Yes, I wondered about that.

Andrew Kolakowski wrote: I don't think that during typical work you will ever see real difference.


Well that is a fair point. When I came to apply these tests to actual clips it was rather more difficult to pick-out significant differences with the 'amplified luma' analysis, except to note that there was less posterization/blocking on darker shallow gradients (shadows cast on buildings etc) when dithering was applied on final conversion of 10-bit 422 renders to YV12.
Offline

Bryan Worsley

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

Re: Poor H264 encoding quality in DaVinci

PostMon May 08, 2017 1:27 am

Bryan Worsley wrote:Just to note though that the 8-bit and 10-bit Uncompressed 422 files used for input in these tests were encoded directly with ffmpeg from the same 8-bit RGB24 ramp clip (original png image converted to 5 sec avi clip); the 10-bit 422 file was not derived from the 8-bit 422 file.


Aha, but if I first convert the 8-bit RGB24 ramp clip (with ffmpeg) to raw Planar 420* (pix_fmt yuvj420) and derive the Uncompressed 422 transcodes from that, the 8-bit and 10-bit 422 files produce nigh-on identical results. For example - the YV12 Histogram and amplified Luma profiles obtained in the test where Contrast (1.4) was applied in Resolve:

http://i.imgur.com/Nt4QIYy.png
http://i.imgur.com/8kPnN5y.png

So why did the 10-bit 422 transcode derived from the original 8-bit RGB24 Ramp show a different behaviour ?

Edit: Note* - MediaInfo actually reported the raw Planar 420 file to be 9.6 Bit (??). Even so, taking the 8-bit Uncomp.422 file that was derived from the original 8-bit RGB24 ramp and transcoding it to 10-bit Uncomp. 422 produced exactly the same result. So I'm clear on that point now.

I'm just puzzled why the 10-bit 422 encoded directly from the 8-bit RGB24 ramp showed a different behaviour.
Online

Andrew Kolakowski

  • Posts: 9207
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Poor H264 encoding quality in DaVinci

PostMon May 08, 2017 10:03 am

I don't see any real difference in your enhanced preview grab.

"I'm just puzzled why the 10-bit 422 encoded directly from the 8-bit RGB24 ramp showed a different behaviour."

Maybe because conversion from RGB to 8bit YUV will give slightly different result than to 10bit YUV, but this is rather meaningless difference (it just looks different).
Offline

Bryan Worsley

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

Re: Poor H264 encoding quality in DaVinci

PostTue May 09, 2017 12:11 am

Andrew Kolakowski wrote:"I'm just puzzled why the 10-bit 422 encoded directly from the 8-bit RGB24 ramp showed a different behaviour."

Maybe because conversion from RGB to 8bit YUV will give slightly different result than to 10bit YUV, but this is rather meaningless difference (it just looks different).


I was just interested why that should be when 8-bit and 10-bit 422 transcodes derived from the raw 420 ramp clip were, to all intents, identical. And you see a difference also when the original rgb24 clip is loaded in Resolve and transcoded or rendered out to 8-bit and 10-bit Uncomp.422.

Here are the Resolve Histogram profiles produced when those 422 transcodes/renders are imported (back) into Resolve and a Contrast curve is applied:

http://i.imgur.com/EvFcUzZ.png

Surely if the imported RGB24 clip is normalized to 32-bit float YRGB like any other input (as you indicated earlier), one would expect the derived 8-bit and 10-bit 422 transcodes/renders to behave the same ?

Anyhow, not exactly of earth shattering importance.

Perhaps more interesting was finding that when the imported RGB24 ramp clip (set for Full Data levels) was transcoded to Uncompressed 422.mov using the Resolve transcode function, the full luma range (0-255 = 0-1023 10bit) was preserved and not compressed to broadcast safe/video range (16-235 = 64-940 10bit), as occurs with native 4K/HD AVC clips - although not when optimized media are generated:

https://forum.blackmagicdesign.com/viewtopic.php?f=21&t=55098&start=100#p333885
Offline

Chris Hagemeier

  • Posts: 5
  • Joined: Sun May 07, 2017 4:52 am

Re: Poor H264 encoding quality in DaVinci

PostWed May 17, 2017 6:32 am

How far can the poor Davinci Resolve h264 encoding quality be mitigated by using higher bit rates? I am editing GH5 footage in resolve and would like to directly finalize my home videos within resolve (no external encoder).

Since I am using Kodi for playback of the encodes, high bit rates are of no issue (e.g. 100Mb/s).

Cheers,
Chris
Offline
User avatar

Frank Glencairn

  • Posts: 1801
  • Joined: Wed Aug 22, 2012 7:07 am
  • Location: Germany

Re: Poor H264 encoding quality in DaVinci

PostMon May 22, 2017 6:48 pm

Bryan Worsley wrote:I took an 8-bit greyscale ramp and rendered out from Resolve


Using a grayscale still image, to judge a long GOP codec just doesn't cut it, since color and motion plays a huge roll.
http://frankglencairn.wordpress.com/

I told you so :-)
Online

Andrew Kolakowski

  • Posts: 9207
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Poor H264 encoding quality in DaVinci

PostMon May 22, 2017 8:32 pm

Chris Hagemeier wrote:How far can the poor Davinci Resolve h264 encoding quality be mitigated by using higher bit rates? I am editing GH5 footage in resolve and would like to directly finalize my home videos within resolve (no external encoder).

Since I am using Kodi for playback of the encodes, high bit rates are of no issue (e.g. 100Mb/s).

Cheers,
Chris


At 100Mbit for HD differences may start disappearing, but I would not be surprised that things like noisy source will still look worse than e.g. 30Mbit x264.
Online

Andrew Kolakowski

  • Posts: 9207
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Poor H264 encoding quality in DaVinci

PostMon May 22, 2017 8:35 pm

Bryan Worsley wrote:
Andrew Kolakowski wrote:"I'm just puzzled why the 10-bit 422 encoded directly from the 8-bit RGB24 ramp showed a different behaviour."

Maybe because conversion from RGB to 8bit YUV will give slightly different result than to 10bit YUV, but this is rather meaningless difference (it just looks different).


I was just interested why that should be when 8-bit and 10-bit 422 transcodes derived from the raw 420 ramp clip were, to all intents, identical. And you see a difference also when the original rgb24 clip is loaded in Resolve and transcoded or rendered out to 8-bit and 10-bit Uncomp.422.

Here are the Resolve Histogram profiles produced when those 422 transcodes/renders are imported (back) into Resolve and a Contrast curve is applied:

http://i.imgur.com/EvFcUzZ.png

Surely if the imported RGB24 clip is normalized to 32-bit float YRGB like any other input (as you indicated earlier), one would expect the derived 8-bit and 10-bit 422 transcodes/renders to behave the same ?

Anyhow, not exactly of earth shattering importance.

Perhaps more interesting was finding that when the imported RGB24 ramp clip (set for Full Data levels) was transcoded to Uncompressed 422.mov using the Resolve transcode function, the full luma range (0-255 = 0-1023 10bit) was preserved and not compressed to broadcast safe/video range (16-235 = 64-940 10bit), as occurs with native 4K/HD AVC clips - although not when optimized media are generated:

https://forum.blackmagicdesign.com/viewtopic.php?f=21&t=55098&start=100#p333885


Those histograms won't look the same, but this doesn't mean much. Look at real difference. Fact that some gradient is bit shifted or has slightly different look is not proving much.

These different behaviours on full range will be related to actual codecs implementation. Resolve may always pass the same data to codec, but end result may be still different.
Offline

Chris Hagemeier

  • Posts: 5
  • Joined: Sun May 07, 2017 4:52 am

Re: Poor H264 encoding quality in DaVinci

PostSun May 28, 2017 8:33 pm

The release notes for the beta 3 state an improved h264 encoding. How is this meant? Improved speed or quality?

Or maybe both?
Offline
User avatar

Cary Knoop

  • Posts: 1437
  • Joined: Sun Mar 12, 2017 6:35 pm
  • Location: Newark, CA USA

Re: Poor H264 encoding quality in DaVinci

PostSun May 28, 2017 9:26 pm

Andrew Kolakowski wrote:These different behaviours on full range will be related to actual codecs implementation. Resolve may always pass the same data to codec, but end result may be still different.

Indeed.

For instance BTB and WTW data placed outside the 0-1023 ranges will be clipped for ProRes and the DnX family of codecs even when video level is set at the output but it will be retained when you use H.264 or Grassvalley and select video levels.

See for instance an example for H.264:
Offline

Eugene Chebotarev

  • Posts: 29
  • Joined: Sun Oct 18, 2015 5:01 pm

Re: Poor H264 encoding quality in DaVinci

PostTue May 30, 2017 12:03 am

Chris Hagemeier wrote:The release notes for the beta 3 state an improved h264 encoding. How is this meant? Improved speed or quality?

Or maybe both?


The only note about beta 3 I found in regards to H264 is "Improved H.264 performance for DaVinci Resolve Studio on Windows"

I can confirm a noticeable performance improvement when editing H264 footage in beta 3.

As for encoding quality I see no change at all.
Offline

Michael Lin

  • Posts: 1
  • Joined: Sat Jun 17, 2017 2:54 pm

Re: Poor H264 encoding quality in DaVinci

PostSat Jun 17, 2017 3:15 pm

Did a comparison today and found that Resolve's h.264 output does look pretty bad. I also tried outputting a DnxHR HQ file and using that to compress 2 different versions with FFmpeg and they both looked similar. I don't think the "best setting" file looked much better.

File sizes:
1.86GB Davinci Resolve 12.5 1920x1080 h.264 12000kb
5.30GB Davinci Resolve 12.5 1920x1080 h.264 best setting
0.82GB FFmpeg from Resolve DnxHR HQ 1920x1080 h.264 12000kb
1.64GB FFmpeg from Resolve DnxHR HQ 1920x1080 h.264 crf=22
Attachments
Comparison - Resolve vs FFmpeg.png
Comparison - Resolve vs FFmpeg.png (1010.46 KiB) Viewed 16388 times
Offline

Karl Shone

  • Posts: 6
  • Joined: Wed May 06, 2015 1:30 pm

Re: Poor H264 encoding quality in DaVinci

PostFri Aug 18, 2017 12:57 pm

I love DR, comparatively, the timeline slider could do with some work, anyway I'll buy DR, but for the benefit of those that like me will read as much from this post as seems possible and spend even more time trying out ffmpeg, x254, Vlc and Handbrake to produce a better MP4 here's my experience so far.

People download the actual mp4 file I make, with outdoors natural light encoding can struggle, tending to render the foliage sharp and skin blockey.

Shooting on a aps type Nikon Dslr with a manual Carl Zeiss 25mm lens and sync a Gopro Hero5 in 2.7k by clapping. Editing/rendering using two i7 machines with 64gb ram and decent GeForce cards. Sitting side by side with network cable, one outputting on a 4K contrasty Samsung the other a larger Sony Bravia (looks best more colours).

Basically 1 day to shoot edit and upload, following the thread here I render the essential master DNxHD 1080p 220/185/175 10bit with AAC at 20 mins per half hour then use Handbrake to produce the mp4 from that at more or less the same rate. Ending up with an acceptable unblocky video @400mb per half hour
Offline
User avatar

Charles Bennett

  • Posts: 6160
  • Joined: Sat Nov 05, 2016 11:55 am
  • Location: United Kingdom

Re: Poor H264 encoding quality in DaVinci

PostSat Aug 19, 2017 12:01 am

Up until version 14.06 I have been rendering the output as an mp4, but have now gone back to h264 under the Custom tab. It does appear to be much better than the previous version in 12.5. I set the bit rate to match the camera originals which is 35000kbs. Even on moving foliage there is no discernable blocking or softness. This is a humble jpeg screen grab. Original is 1080 50p.
h264 Capture.jpg
h264 at 35000kbs
h264 Capture.jpg (226.16 KiB) Viewed 16041 times
Resolve Studio 18.6.6 build 7
Dell XPS 8700 i7-4790, 24GB RAM, 2 x Evo 860 SSDs, GTX1060/6GB (546.01 Studio Driver), Win10 Home (22H2), Speed Editor, Faderport mk1, Eizo ColorEdge CS230 + BenQ GW2270 + Samsung SA200, Canon C100mk2, Zoom H2n.
Offline

Eugene Chebotarev

  • Posts: 29
  • Joined: Sun Oct 18, 2015 5:01 pm

Re: Poor H264 encoding quality in DaVinci

PostSun Aug 20, 2017 4:30 am

I can confirm, H264 encoding quality went up noticeably in one of the beta's and now results are quite acceptable and comparable to other encoders. Thanks BMD!
Offline
User avatar

Jean Claude

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

Re: Poor H264 encoding quality in DaVinci

PostSun Aug 20, 2017 8:38 am

Eugene Chebotarev wrote:I can confirm, H264 encoding quality went up noticeably in one of the beta's and now results are quite acceptable and comparable to other encoders. Thanks BMD!


+1 :)
"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
User avatar

Gary Coombs

  • Posts: 82
  • Joined: Mon Jan 16, 2017 5:26 am
  • Location: Atlanta, Georgia, USA

Re: Poor H264 encoding quality in DaVinci

PostWed Sep 27, 2017 3:12 am

Eugene Chebotarev wrote:Ok, I do realize I've supplied too little technical info. I'm encoding from 4K 16-bit Lossless CinemaDNG footage. Using H.264 typically for media delivery over Internet where size does matter while quality is still very much important. I got excited when I saw that H.264 encoding was implemented straight into Davinci only to find how poorly it was done, that's relative to any NLE. Footage encoded into H.264 from Davinci looses sharpness while other NLE's preserve sharpness and details even at much, much lower bitrate settings.

Anyone finding H.264 quality to be a problem with Resolve Studio 14 (release)?
I just started working with video this year and using the modest hardware below I'm finding real-time H.264 rendered footage to be very acceptably sharp.
Asus ZenBook Pro Duo
Windows 10 Pro 64-bit
15.6” OLED 4K (3840 x 2160) 16:9 Touch
Intel® Core™ i9-9980HK
32GB 2666MHz DDR4
NVIDIA® GeForce RTX™ 2060 6GB GDDR6
Latest Resolve Studio
Offline
User avatar

Uli Plank

  • Posts: 21278
  • Joined: Fri Feb 08, 2013 2:48 am
  • Location: Germany and Indonesia

Re: Poor H264 encoding quality in DaVinci

PostWed Sep 27, 2017 5:23 am

My modest 2017 iMac is doing better than realtime and sharpness normally is not the biggest problem with H.264 encoding. Macro-blocking in shadows and on fades is the worst offender.

I can confirm that H.264 encoding in 14 got quite acceptable.
No, an iGPU is not enough, and you can't use HEVC 10 bit 4:2:2 in the free version.

Studio 18.6.5, MacOS 13.6.5
MacBook M1 Pro, 16 GPU cores, 32 GB RAM and iPhone 15 Pro
Speed Editor, UltraStudio Monitor 3G, iMac 2017, eGPU
Offline

Jim Simon

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

Re: Poor H264 encoding quality in DaVinci

PostWed Sep 27, 2017 3:22 pm

Anyone finding H.264 quality to be a problem with Resolve Studio 14 (release)?


I'm still on the free version, and after testing various formats with an editor, we settled on H.264 QuickTime as deliverables for her to edit in FCP X. No concerns with quality.
My Biases:

You NEED training.
You NEED a desktop.
You NEED a calibrated (non-computer) display.
Offline
User avatar

Gary Coombs

  • Posts: 82
  • Joined: Mon Jan 16, 2017 5:26 am
  • Location: Atlanta, Georgia, USA

Re: Poor H264 encoding quality in DaVinci

PostWed Sep 27, 2017 4:47 pm

Jim Simon wrote:
Anyone finding H.264 quality to be a problem with Resolve Studio 14 (release)?


I'm still on the free version, and after testing various formats with an editor, we settled on H.264 QuickTime as deliverables for her to edit in FCP X. No concerns with quality.

That's another reason I decided to go ahead and purchase Resolve Studio. With Studio 14 I can work without needing to jockey around between different apps. I can go back and forth between editing and color correction instantly.
Asus ZenBook Pro Duo
Windows 10 Pro 64-bit
15.6” OLED 4K (3840 x 2160) 16:9 Touch
Intel® Core™ i9-9980HK
32GB 2666MHz DDR4
NVIDIA® GeForce RTX™ 2060 6GB GDDR6
Latest Resolve Studio
Offline
User avatar

Uli Plank

  • Posts: 21278
  • Joined: Fri Feb 08, 2013 2:48 am
  • Location: Germany and Indonesia

Re: Poor H264 encoding quality in DaVinci

PostWed Sep 27, 2017 11:58 pm

Jim, I'd never use a transcode to H.264 for editing, only for final delivery. It's bad enough that we have H.264 as an acquisition codec these days. But another generation loss? Not for me.

OK, there are other flavors of H.264 with infra only, 422 and even 10 bit, but are you rendering into one of these? Might not be the most efficient solution, FCP-X loves ProRes!
No, an iGPU is not enough, and you can't use HEVC 10 bit 4:2:2 in the free version.

Studio 18.6.5, MacOS 13.6.5
MacBook M1 Pro, 16 GPU cores, 32 GB RAM and iPhone 15 Pro
Speed Editor, UltraStudio Monitor 3G, iMac 2017, eGPU
Offline

Martin Schitter

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

Re: Poor H264 encoding quality in DaVinci

PostThu Sep 28, 2017 11:38 am

Uli Plank wrote:I can confirm that H.264 encoding in 14 got quite acceptable.


PSNR/SSIM numbers concerning the actual compression quality of resolve 14 free/studio in comparison to x264 encoders would be very helpful, to verify this claim.
Offline

Jim Simon

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

Re: Poor H264 encoding quality in DaVinci

PostThu Sep 28, 2017 1:57 pm

Uli Plank wrote:Jim, I'd never use a transcode to H.264 for editing, only for final delivery.


I am of that same opinion. But FCP X does not handle Cineform or DNx, and I'm on Windows so ProRes isn't an option.

This is just wedding footage, and the Best quality option seems to produce quite acceptable results. Coming from CinemaDNG, I dare say it's better than what most H.264 cameras could produce.
My Biases:

You NEED training.
You NEED a desktop.
You NEED a calibrated (non-computer) display.
Offline
User avatar

Charles Bennett

  • Posts: 6160
  • Joined: Sat Nov 05, 2016 11:55 am
  • Location: United Kingdom

Re: Poor H264 encoding quality in DaVinci

PostThu Sep 28, 2017 5:45 pm

I side with Gary on this one. Have a look at my earlier post in this thread which has a JPEG screen shot from an h264 render. One thing I would say is keep the bit rate high. I shoot, edit, and render at 35Mbps.
Resolve Studio 18.6.6 build 7
Dell XPS 8700 i7-4790, 24GB RAM, 2 x Evo 860 SSDs, GTX1060/6GB (546.01 Studio Driver), Win10 Home (22H2), Speed Editor, Faderport mk1, Eizo ColorEdge CS230 + BenQ GW2270 + Samsung SA200, Canon C100mk2, Zoom H2n.
Offline
User avatar

Uli Plank

  • Posts: 21278
  • Joined: Fri Feb 08, 2013 2:48 am
  • Location: Germany and Indonesia

Re: Poor H264 encoding quality in DaVinci

PostSun Mar 14, 2021 8:20 am

[quote="Al Spaeth"
Is there a h.264 (AVC) encoding quality problem in Resolve?
4k, HD?
Relative to what other NLEs encoding?
What encoder does Resolve use? x264 free encoder (used by Handbrake) is considered the best by many. MainConcept is also highly rated. Are two pass encoders better or necessary?
QT h.264 is rated among the worst encoders. See Img here http://imgur.com/a/B5jyE

What output file type is Eugene looking for? - Resolve only outputs h.264 Quicktime.
Why use 3rd party converters? I thought every conversion results in some quality loss.
My AVC export matches the bitrate and color depth to my source footage.
I need MP4 (file type is a codec wrapper) so I simply use a free utility to re-wrap Resolve H.264 to MP4 without using a converter.[/quote]

Point by point:
- Yes, there is an encoding quality problem with h.264 in Resolve, it' worse at the same bitrate for all resolutions compared to x.264 encodings.
- It uses encoders from the OS or hardware encoding if available. It is definitely not x.264.
– MainConcept (also used by Premiere) is better, even if not the best.
- Two pass encoding helps if there are long stretches of footage in your video with different types of content, like fast action sequences vs. talking heads shot from a static camera.
- You can put H.264 from many encoder into a QT wrapper, it's only a container. Says nothing about quality.
- Resolve can output H.264 and H.265 in both wrappers, MOV and MP4. At least this applies to Studio on the Mac.
- Every compression is some quality loss, it only depends how bad it is.
No, an iGPU is not enough, and you can't use HEVC 10 bit 4:2:2 in the free version.

Studio 18.6.5, MacOS 13.6.5
MacBook M1 Pro, 16 GPU cores, 32 GB RAM and iPhone 15 Pro
Speed Editor, UltraStudio Monitor 3G, iMac 2017, eGPU
Online

Andrew Kolakowski

  • Posts: 9207
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Poor H264 encoding quality in DaVinci

PostSun Mar 14, 2021 11:27 am

You now have MainConcept encoders in Resolve if you happy to pay. This is some solution if you want direct exports from Resolve.
You have x264 plugin as well but this is bit ‘not finished’ although video part itself should be fine.

Both work only in Studio (90% sure).
Previous

Return to DaVinci Resolve

Who is online

Users browsing this forum: Andrew Kolakowski, bmmatbon, govind, Johannes Hoffmann, robwuijster and 200 guests