A Transcoding Question

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

Charles Bennett

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

A Transcoding Question

PostSat Nov 27, 2021 12:16 pm

My source footage is HD 50fps h264 at 35Mbps. When transcoding is there any advantage using DNxHR HQ over DNxHR LB apart from file size?
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

ZRGARDNE

  • Posts: 684
  • Joined: Sun May 16, 2021 12:32 am
  • Real Name: Zeb Gardner

Re: A Transcoding Question

PostSat Nov 27, 2021 12:58 pm

Are you talking optimized media just for timeline edits?

You should not use the LB files for critical color grades or final exports.

I personally use half res LB files for timeline, then switch back to natives (h.265) for color grade and export, you are never going to get smooth playback with a grade, so no need for optimized media.
Offline
User avatar

Charles Bennett

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

Re: A Transcoding Question

PostSat Nov 27, 2021 3:36 pm

Thanks Zeb. At the moment I just edit and grade the HD h264 as is and it plays back with no problems. I can also run at half resolution with the timeline set to UHD.
I asked more out of curiosity. Rather than optimized media I was thinking more of a transcode using Shutter Encoder with the DNxHR used as the editing and final rendering media.
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

TheBloke

  • Posts: 1905
  • Joined: Sat Nov 02, 2019 11:49 pm
  • Location: UK
  • Real Name: Tom Jobbins

Re: A Transcoding Question

PostSat Nov 27, 2021 4:52 pm

This table from Avid gives a handy overview:
Image

So LB is intended as a proxy format and is compressed much more than the others. SQ might be OK for delivery, but really you'd want HQ if possible. Then HQX and 444 are the 10+ bit formats, with 444 the only option with alpha channel and no chroma-subsamping. But those aren't likely needed when your source is H264/5.

I've never done any side-by-side visual comparisons between DNxHR LB/SQ/HQ or ProRes 422 Proxy/422/422 HQ so I can't say if SQ is maybe good enough or not. I always just choose DNxHR HQ / ProRes 422 HQ and call it a day (all my material is 8 bit).
Resolve Studio 17.4.3 and Fusion Studio 17.4.3 on macOS 11.6.1

Hackintosh:: X299, Intel i9-10980XE, 128GB DDR4, AMD 6900XT 16GB
Monitors: 1 x 3840x2160 & 3 x 1920x1200
Disk: 2TB NVMe + 4TB RAID0 NVMe; NAS: 36TB RAID6
BMD Speed Editor
Offline
User avatar

Sarasota

  • Posts: 95
  • Joined: Sun Apr 07, 2019 8:46 am
  • Location: Sarasota, FL
  • Real Name: Terrance Glatz

Re: A Transcoding Question

PostSat Nov 27, 2021 5:26 pm

If you're ever interested in comparing codecs, also give Grass Valley HQX a try... I've been using it for a while and quite happy with it.

White Paper :
https://wwwapps.grassvalley.com/docs/Wh ... ro_HQX.pdf

Codec Download :
https://www.edius.net/hqx.html
Resolve Studio 18.5.1 | Asus Proart MB | i9 10850k | 128gb ram | Gigabyte RTX 3080 | Decklink Studio 4k 6G | *1x RME UFX+ | 1x MOTU 24i/O | 2x MOTU 896MK3 | 1x MOTU 828MKII | Win 11 Pro | Display Driver: 546.33 SD | Audio Drivers: v1.21-TB
Offline

stesin

  • Posts: 139
  • Joined: Sat Oct 24, 2020 4:25 pm
  • Location: Cyprus
  • Real Name: Andreas Stesinou

Re: A Transcoding Question

PostSat Nov 27, 2021 7:10 pm

Charles Bennett wrote:My source footage is HD 50fps h264 at 35Mbps. When transcoding is there any advantage using DNxHR HQ over DNxHR LB apart from file size?
Yes, definitely. LB profile is inferior IQ. DNxHR HQ is fine for 4:2:0 pix fmt source footage.

More details here viewtopic.php?f=21&t=147285
Blackmagick DaVinci Resolve Studio 17.4.6
Blackmagick Speed Editor USB cable connected
Linux Ubuntu 22.04 (5.18.14)
Asus G750 i7-4860HQ 32GB RAM
NVidia 980M 8Gb (510.85.02 CUDA: 11.6)
2x166GB SSDs in RAID0 - DVRS Caches
1x4TB Samsung EVO 870 SSD
Offline
User avatar

Charles Bennett

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

Re: A Transcoding Question

PostSat Nov 27, 2021 9:48 pm

Thanks guys.
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: 21280
  • Joined: Fri Feb 08, 2013 2:48 am
  • Location: Germany and Indonesia

Re: A Transcoding Question

PostSun Nov 28, 2021 2:31 am

It's a shame that they don't give us a 10 bit option as Apple does. That would be plenty for any 8 bit source.
Next to Grass Valley, you may want to try Cineform too.
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

ZRGARDNE

  • Posts: 684
  • Joined: Sun May 16, 2021 12:32 am
  • Real Name: Zeb Gardner

Re: A Transcoding Question

PostSun Nov 28, 2021 4:10 pm

Sarasota wrote:If you're ever interested in comparing codecs, also give Grass Valley HQX a try... I've been using it for a while and quite happy with it.

White Paper :
https://wwwapps.grassvalley.com/docs/Wh ... ro_HQX.pdf



Not sure I am sold it is any better or really any different than DNxHR HQX or Prores.

"The long-run performance of each codec is summarized in Table 5. It shows that HQX provides comparable quality to DNxHD and ProRes
422 over the long run, at comparable bit rates. It also shows that HQX permits turning the quality dial all the way up should a project merit it."

I guess if you are concerned with space you can tune to higher compression ratios that DNxHR\ProRes don't have.

I personally don't want to be bothered with the faff, DNxHR HQ for 8 bit, HQX for 10-bit, done.
Offline

stesin

  • Posts: 139
  • Joined: Sat Oct 24, 2020 4:25 pm
  • Location: Cyprus
  • Real Name: Andreas Stesinou

Re: A Transcoding Question

PostMon Nov 29, 2021 8:25 am

ZRGARDNE wrote:I personally don't want to be bothered with the faff, DNxHR HQ for 8 bit, HQX for 10-bit, done.
As of my current understanding and (limited) experience, I second this approach.

But there's one interesting boundary case where the different approach works better, see http://vanhurkman.com/wordpress/?p=3471

BTW under the hood DaVinci makes all the transforms and grading in it's internal uncompressed floating point format anyway. So it seems to me that pre-transcoding of the source footage from H.264/265 4:2:0 into something "better" makes no sense (if you are on paid Studio which ingests H.264/265).

How does it work? To avoid problems with H.264/265 decoding "on the fly" each time again and again while editing and grading, you generate optimized media which is good for timeline viewer to run buttery smooth on your hardware. I use DNxHR LB at ¼ timeline resolution for UHD, and at ½ resolution for FHD timeline for both optimized media and render cache format.

But if you are not limited with either NVME SSD space or CPU power, you may use uncompressed 16bit floating-point format, too. According to Alexis Van Hurkman, this format is optimal in terms of IQ. But be prepared to get your optimized media at a really huge disk space consumption level; H.264 UHD source clip size gets multiplied like ~100x of the size of the original).

For the final delivery rendering, you either use the source files -- if your optimized media and render cache are in a low-IQ codec. DaVinci will re-decode the source stuff and recalculate everything in it's internal format then export into whatever codec you wish.

In this scenario, the delivery workflow under the hood is:

Src H.264 re-decoding into -> internal uncompressed 16bit floating point representation -> do transforms+grading -> export to delivery codec.

If you have done heavy transforms and grading upon your 4:2:0 footage, this means that your delivery may need more bit space to reflect your work properly. So you may well need 10bit or 12bit 4:4:4 for delivering it, thus choose the proper codec for your delivered "master" file.

Or, in case you were using the uncompressed full-size 16bit floating-point format for your optimized media and render cache, you may well use these as a source for your final delivery as well, thus avoiding re-decoding of your sources from scratch altogether.

The workflow under the hood then is, as far as I understand:

Uncompressed 16bit FP optimized & cached media (pre-rendered already) -> delivery codec.
Blackmagick DaVinci Resolve Studio 17.4.6
Blackmagick Speed Editor USB cable connected
Linux Ubuntu 22.04 (5.18.14)
Asus G750 i7-4860HQ 32GB RAM
NVidia 980M 8Gb (510.85.02 CUDA: 11.6)
2x166GB SSDs in RAID0 - DVRS Caches
1x4TB Samsung EVO 870 SSD
Offline

ZRGARDNE

  • Posts: 684
  • Joined: Sun May 16, 2021 12:32 am
  • Real Name: Zeb Gardner

Re: A Transcoding Question

PostTue Nov 30, 2021 5:31 pm

stesin wrote: So it seems to me that pre-transcoding of the source footage from H.264/265 4:2:0 into something "better" makes no sense (if you are on paid Studio which ingests H.264/265).

For the final delivery rendering, you either use the source files -- if your optimized media and render cache are in a low-IQ codec. DaVinci will re-decode the source stuff and recalculate everything in it's internal format then export into whatever codec you wish.



Agreed if you 'Grade' is complex enough to be slower than the H.265 decode.

If you are simply doing some color tweaks and exporting to DNxHR, the H.265 decode may be the slowest step in the process. Particularly if you have 10 bit 4:2:2 which BM has not enabled hardware decoding, even though Nvidia supports. https://www.pugetsystems.com/labs/articles/What-H-264-H-265-Hardware-Decoding-is-Supported-in-DaVinci-Resolve-Studio-2122/

But with NR or anything complex, the export speed difference between H.265 source or DNxHR source will be minimal.
Offline

stesin

  • Posts: 139
  • Joined: Sat Oct 24, 2020 4:25 pm
  • Location: Cyprus
  • Real Name: Andreas Stesinou

Re: A Transcoding Question

PostTue Nov 30, 2021 8:36 pm

ZRGARDNE wrote:If you are simply doing some color tweaks and exporting to DNxHR, the H.265 decode may be the slowest step in the process. Particularly if you have 10 bit 4:2:2 which BM has not enabled hardware decoding, even though Nvidia supports. https://www.pugetsystems.com/labs/articles/What-H-264-H-265-Hardware-Decoding-is-Supported-in-DaVinci-Resolve-Studio-2122/
Yes, definitely you are correct speaking of 10bit 4:2:2 case. I specifically mentioned the exact 8bit 4:2:0 case; but with 10bit 4:2:2 pre-transcoding (or creating full-sized HQX optimized media, which is effectively the same) and working on it (including the final delivery) makes perfect sense. Uncompressed 16bit floating point too, but only if you can afford some 4TB NVME SSD for your scratch disk.
Blackmagick DaVinci Resolve Studio 17.4.6
Blackmagick Speed Editor USB cable connected
Linux Ubuntu 22.04 (5.18.14)
Asus G750 i7-4860HQ 32GB RAM
NVidia 980M 8Gb (510.85.02 CUDA: 11.6)
2x166GB SSDs in RAID0 - DVRS Caches
1x4TB Samsung EVO 870 SSD
Offline

CougerJoe

  • Posts: 330
  • Joined: Wed Sep 18, 2019 5:15 am
  • Real Name: bob brady

Re: A Transcoding Question

PostTue Nov 30, 2021 9:21 pm

ZRGARDNE wrote:
If you are simply doing some color tweaks and exporting to DNxHR, the H.265 decode may be the slowest step in the process. Particularly if you have 10 bit 4:2:2 which BM has not enabled hardware decoding, even though Nvidia supports. https://www.pugetsystems.com/labs/articles/What-H-264-H-265-Hardware-Decoding-is-Supported-in-DaVinci-Resolve-Studio-2122/



It' well known that neither Nvidia or AMD support HEVC 422 10bit GPU decoding, it was the biggest disappointment of the 3000 series Nvidia cards for me, It shows in the link you supplied that it's not available on anything other than the higher end 11 and 12 series intel IGPU's, and HEVC 422 10bit decoding is supported on those IGPU's in Resolve. Apple M1 supports it too but that's a different story

Image
Offline

stesin

  • Posts: 139
  • Joined: Sat Oct 24, 2020 4:25 pm
  • Location: Cyprus
  • Real Name: Andreas Stesinou

Re: A Transcoding Question

PostTue Nov 30, 2021 10:55 pm

But is it at all possible to use Intel 11-12th series IGPU together with NVIDIA 3xxx GPU simultaneously in DVR(S)?

viewtopic.php?f=21&t=151063 here is the evidence of the opposite :(
Blackmagick DaVinci Resolve Studio 17.4.6
Blackmagick Speed Editor USB cable connected
Linux Ubuntu 22.04 (5.18.14)
Asus G750 i7-4860HQ 32GB RAM
NVidia 980M 8Gb (510.85.02 CUDA: 11.6)
2x166GB SSDs in RAID0 - DVRS Caches
1x4TB Samsung EVO 870 SSD
Offline

CougerJoe

  • Posts: 330
  • Joined: Wed Sep 18, 2019 5:15 am
  • Real Name: bob brady

Re: A Transcoding Question

PostWed Dec 01, 2021 3:30 am

stesin wrote:But is it at all possible to use Intel 11-12th series IGPU together with NVIDIA 3xxx GPU simultaneously in DVR(S)?

viewtopic.php?f=21&t=151063 here is the evidence of the opposite :(


That's a different Intel Decoder which can't decode 422, they all seem to have UHD630, hopefully those people with UHD750 and 770 that decode 422 10bit HEVC don't have problems.
For those with UHD630 and before I don't see that there's any advantage in using the IGPU as a decoder, would not seem to have any advantage over the decoders on Nvidia and Amd gpu, although I don't know much about AMD gpu, I know they have the worst reputation when it comes to drivers

Return to DaVinci Resolve

Who is online

Users browsing this forum: Devin Terpstra, Google [Bot], shikawkee, Xrdgame and 201 guests