explanation of rendering codecs-intermediate-final needed

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

joshua newman

  • Posts: 39
  • Joined: Thu Dec 14, 2017 11:49 pm

explanation of rendering codecs-intermediate-final needed

PostSat Feb 17, 2018 9:50 pm

I've been reading some forum post on here and doing lots of reading online and seem to be either getting more confused or getting conflicting info, more than likely probably both:)
Can someone please give me an explanation of codecs in re3gards to rendering, retaining quality, what intermediate codecs are and used for.
I'll explain my situation and see if someone can provide insight. I shoot short 2-5 minute videos for my business and for hobby. I primarily use Resolve as my all in one program, but am open to other programs to help, I've seen ffmpeg and handbrake mentioned. I use a DJI Phantom 4 pro and OSMO Pro with X5 micro 4/3 camera and 15mm F1.7 lens. I have been shooting in H.264, I have the option to shoot in H.265. I typically shoot in 3840x2160 24fps and will export in either the same or 1080HD in a MP4 H.264 out of resolve. I import, do my editing and color and export out and upload. Is there a step or process that I can do that would generate higher quality when upload onto youtube or vimeo. I know they both really compress things when uploaded so I wanted to give it the best video possible before uploading. Should I do an intermediate codec like DNxHR, would that help or cause more issues? I have a really high bandwith internet connection so I usually upload fast.
I have been racking my brain researching this and treying to figure out the best way. Any help from people that use this program instead of just general articles I read online would be helpful. Thank you
Intel I7 7700k 5.1Ghz
Win10Pro-DaVinci Resolve 14.1.1
64GB Ram-3 x 1TB Samsung 960 EVO M.2 (Boot, Scratch, Render)
3 x 2TB Samsung 850 EVO SSD
2 x EVGA 1070 FTW Hybrid 8GB
Offline

Andrew Kolakowski

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

Re: explanation of rendering codecs-intermediate-final neede

PostSat Feb 17, 2018 10:27 pm

If you have fast internet and uploading ProRes, DNxHR, Cineform is not an issue then you don't have to bother with h264.

h264 is also fine, but only if bitrate is high enough. If encoder is poor then bitrate has to be really high (as for h264 terms)- eg. 50Mbit+ for HD.
If you take your e.g.. 170Mbit HD ProRes and make a good h264 at e.g. 100mbit (long GOP) then they will be close in quality. What you can do with h264 is to make e.g. 30Mbit version which will hold quality well (if good encoder is used). You can't do this with ProRes as quality will degrade quite a lot. This is the difference. h264 can be "any" quality- from very low to even mathematically lossless, but "normally" h264 files are rather low bitrate as they are used for final delivery and have to deal with bandwidth limits. Intermediate codes have only few quality levels (you can make more if you really want), carefully chosen by industry. Their main role is to reduce size compared to uncompressed files (so files are manageable), be fast to decode (they are fairly simple and I frame only) and offer 'visually lossless' quality. h264 uses more advanced math and long GOPs, which allow to deliver 'good' quality at 30Mbit for HD or still watchable at e.g. 8mbit.
What you don't want to do is to send to youtube this low end h264 files as youtube will re-encode them. You need to send something decent, so end result looks the same for the eye as if you would send uncompressed master. Resolve h264 encoder is not top end, so you either have to use fairly high bitrate or encode using other h264 encoder, like x264 which is very good.
Quite simple- there is nothing magical here.
Offline
User avatar

Cary Knoop

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

Re: explanation of rendering codecs-intermediate-final neede

PostSat Feb 17, 2018 10:33 pm

These are the values I typically use:

- UHD 8bit long GOP H.264 between 40-60Mbps
- HD 8bit long GOP H.264 between 15-25 Mbps
- 10 bit HDR I would add 20% of the above bit rates.

Take about 60% of those bit rates for H.265.
Offline

Andrew Kolakowski

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

Re: explanation of rendering codecs-intermediate-final neede

PostSat Feb 17, 2018 10:37 pm

Cary Knoop wrote:These are the values I typically use:

For UHD 8bit long GOP H.264 between 40-60Mbps
For HD 8bit long GOP H.264 between 15-25 Mbps

Take about 60% of those bit rates for H.265.

For HDR I would add another 20% more.



I used more like 30Mbit+ depending on master nature for HD (using x264). Noisy/grainy quite often were 50Mbit+. No way 15Mbit can offer transparent quality for noisy master.
UHD more like 100Mbit+.
If you have fast internet there is no reason to use such a low bitrates.
Offline
User avatar

Cary Knoop

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

Re: explanation of rendering codecs-intermediate-final neede

PostSat Feb 17, 2018 10:40 pm

Andrew Kolakowski wrote:UHD more like 100Mbit+.

That won't make any difference after YouTube re-encodes.
Offline

Seth Goldin

  • Posts: 668
  • Joined: Wed Nov 04, 2015 7:43 pm

Re: explanation of rendering codecs-intermediate-final neede

PostSat Feb 17, 2018 10:57 pm

To get a sense of what codecs to use, when, and why, I recommend David Kong’s definitive article: https://blog.frame.io/2017/02/15/choose ... ght-codec/


Sent from my iPhone using Tapatalk
https://www.sethgoldin.com
Offline

Andrew Kolakowski

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

Re: explanation of rendering codecs-intermediate-final neede

PostSat Feb 17, 2018 11:12 pm

Cary Knoop wrote:
Andrew Kolakowski wrote:UHD more like 100Mbit+.

That won't make any difference after YouTube re-encodes.


100mbit for UHD is not that lot when you want 'transparent' h264 master. I don't see any reason going lower if internet speed is not an issue. It makes me stop thinking and worrying if I could do better. I rather prefer over-do-it in this case :)
Offline
User avatar

Cary Knoop

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

Re: explanation of rendering codecs-intermediate-final neede

PostSat Feb 17, 2018 11:14 pm

Seth Goldin wrote:To get a sense of what codecs to use, when, and why, I recommend David Kong’s definitive article: https://blog.frame.io/2017/02/15/choose ... ght-codec/

I strongly disagree with the author that you should upload ProRes 422 to YouTube. ProRes 422 is an all-intra codec, that is totally not necessary and you will be wasting bandwidth.
Offline
User avatar

Cary Knoop

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

Re: explanation of rendering codecs-intermediate-final neede

PostSat Feb 17, 2018 11:15 pm

Andrew Kolakowski wrote:100mbit for UHD is not that lot when you want 'transparent' h264 master. I don't see any reason going lower if internet speed is not an issue. It makes me stop thinking and worrying if I could do better. I rather prefer over-do-it in this case :)

Well who is talking about a master?
But, hey, if it makes you feel better I'd say go for it!

I suppose I prefer to stick wit "low-life" bit rates. :)
Offline

Andrew Kolakowski

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

Re: explanation of rendering codecs-intermediate-final neede

PostSat Feb 17, 2018 11:38 pm

Yes, I have my own term which is "h264 transparent master" :D and this is used for tasks like youtube upload.
Offline

Andrew Kolakowski

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

Re: explanation of rendering codecs-intermediate-final neede

PostSat Feb 17, 2018 11:41 pm

Cary Knoop wrote:
Seth Goldin wrote:To get a sense of what codecs to use, when, and why, I recommend David Kong’s definitive article: https://blog.frame.io/2017/02/15/choose ... ght-codec/

I strongly disagree with the author that you should upload ProRes 422 to YouTube. ProRes 422 is an all-intra codec, that is totally not necessary and you will be wasting bandwidth.


If I'm on "company internet" (meaning symmetric speed line) then it may take you longer to create h264 file than for me upload (most likely already exported) ProRes, DNxHR master. Creating h264 is waste of time in this case.
You always adjust workflow to your needs- never try to follow company A or B workflows even if they may be very good (your needs may be very different).
Offline

joshua newman

  • Posts: 39
  • Joined: Thu Dec 14, 2017 11:49 pm

Re: explanation of rendering codecs-intermediate-final neede

PostSun Feb 18, 2018 2:42 am

Andrew Kolakowski wrote:If you have fast internet and uploading ProRes, DNxHR, Cineform is not an issue then you don't have to bother with h264.

h264 is also fine, but only if bitrate is high enough. If encoder is poor then bitrate has to be really high (as for h264 terms)- eg. 50Mbit+ for HD.
If you take your e.g.. 170Mbit HD ProRes and make a good h264 at e.g. 100mbit (long GOP) then they will be close in quality. What you can do with h264 is to make e.g. 30Mbit version which will hold quality well (if good encoder is used). You can't do this with ProRes as quality will degrade quite a lot. This is the difference. h264 can be "any" quality- from very low to even mathematically lossless, but "normally" h264 files are rather low bitrate as they are used for final delivery and have to deal with bandwidth limits. Intermediate codes have only few quality levels (you can make more if you really want), carefully chosen by industry. Their main role is to reduce size compared to uncompressed files (so files are manageable), be fast to decode (they are fairly simple and I frame only) and offer 'visually lossless' quality. h264 uses more advanced math and long GOPs, which allow to deliver 'good' quality at 30Mbit for HD or still watchable at e.g. 8mbit.
What you don't want to do is to send to youtube this low end h264 files as youtube will re-encode them. You need to send something decent, so end result looks the same for the eye as if you would send uncompressed master. Resolve h264 encoder is not top end, so you either have to use fairly high bitrate or encode using other h264 encoder, like x264 which is very good.
Quite simple- there is nothing magical here.


That is a wealth of knowledge. Can you dumb it down a little for me:) Pretend like your explaining it to a kid, I'm still trying to grasp all the nuances of digital recording and development. If i am limited to the format I record, H.264 or MPEG4, those are my options out of camera, what do I do. WOuld I just import into Resolve, do my editing and grading then render out into DNxHR or Cineform and am I able to upload from that or am I missing a step somewhere? Where does the x264 encoder come into play? I know this seems like totally crazy questions, it just always seems like once I feel like I'm finally getting a grasp on this I read something and it opens a whole can of worms. I appreciate everyones time, it's greatly appreciated.
Intel I7 7700k 5.1Ghz
Win10Pro-DaVinci Resolve 14.1.1
64GB Ram-3 x 1TB Samsung 960 EVO M.2 (Boot, Scratch, Render)
3 x 2TB Samsung 850 EVO SSD
2 x EVGA 1070 FTW Hybrid 8GB
Offline

joshua newman

  • Posts: 39
  • Joined: Thu Dec 14, 2017 11:49 pm

Re: explanation of rendering codecs-intermediate-final neede

PostSun Feb 18, 2018 2:45 am

Seth Goldin wrote:To get a sense of what codecs to use, when, and why, I recommend David Kong’s definitive article: https://blog.frame.io/2017/02/15/choose ... ght-codec/


Sent from my iPhone using Tapatalk



Thank you, I will get into that and I'm sure it will be very helpful, hopeful it doesn't generate another round of questions:)
Intel I7 7700k 5.1Ghz
Win10Pro-DaVinci Resolve 14.1.1
64GB Ram-3 x 1TB Samsung 960 EVO M.2 (Boot, Scratch, Render)
3 x 2TB Samsung 850 EVO SSD
2 x EVGA 1070 FTW Hybrid 8GB
Offline

joshua newman

  • Posts: 39
  • Joined: Thu Dec 14, 2017 11:49 pm

Re: explanation of rendering codecs-intermediate-final neede

PostSun Feb 18, 2018 5:13 am

Seth Goldin wrote:To get a sense of what codecs to use, when, and why, I recommend David Kong’s definitive article: https://blog.frame.io/2017/02/15/choose ... ght-codec/


Sent from my iPhone using Tapatalk


I read the article and watched the video and it explained it all, I wish I would have found this a long time ago. Thank you very much.
Intel I7 7700k 5.1Ghz
Win10Pro-DaVinci Resolve 14.1.1
64GB Ram-3 x 1TB Samsung 960 EVO M.2 (Boot, Scratch, Render)
3 x 2TB Samsung 850 EVO SSD
2 x EVGA 1070 FTW Hybrid 8GB
Offline

Dan Sherman

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

Re: explanation of rendering codecs-intermediate-final neede

PostSun Feb 18, 2018 5:51 am

joshua newman wrote:WOuld I just import into Resolve, do my editing and grading then render out into DNxHR or Cineform and am I able to upload from that or am I missing a step somewhere? Where does the x264 encoder come into play?


  1. Import your clips into Resolve, then cut,slice, grade, etc as you see fit.
  2. Render a master out of resolve using dnxhr, prores, or Cineform etc. If you have a high speed internet connection dnxhr and prores can be uploaded directly to YouTube, I don't believe cineform is supported.
  3. If you have a slower internet connection use a tool like ffmpeg or handbrake to transcode your master to h.264, h.265, and then upload that.

The last video I uploaded to YouTube started out as a 4k 135GB DNxHR hQ master (larger than the largest upload YouTube allows), and I trans-coded that to h.265 to get an 11GB upload.
AMD 7950X | AMD 7900XTX (23.20.24) | DDR5-6000 CL30-40-40-96 2x32 GB | Multiple PCIe 4.0 X4 NVME | ASUS x670e HERO | Win 11 Pro 23H2 | Resolve Studio 18.6.5 B7
Offline

joshua newman

  • Posts: 39
  • Joined: Thu Dec 14, 2017 11:49 pm

Re: explanation of rendering codecs-intermediate-final neede

PostSun Feb 18, 2018 6:03 am

Dan Sherman wrote:
joshua newman wrote:WOuld I just import into Resolve, do my editing and grading then render out into DNxHR or Cineform and am I able to upload from that or am I missing a step somewhere? Where does the x264 encoder come into play?


  1. Import your clips into Resolve, then cut,slice, grade, etc as you see fit.
  2. Render a master out of resolve using dnxhr, prores, or Cineform etc. If you have a high speed internet connection dnxhr and prores can be uploaded directly to YouTube, I don't believe cineform is supported.
  3. If you have a slower internet connection use a tool like ffmpeg or handbrake to transcode your master to h.264, h.265, and then upload that.

The last video I uploaded to YouTube started out as a 4k 135GB DNxHR hQ master (larger than the largest upload YouTube allows), and I trans-coded that to h.265 to get an 11GB upload.


Thats a big file! Ok that makes sense. Do some people go from H.264 and transcode to say DNxHR 444 for grading, then convert back to H.264 for upload or does that result in to many compression issues, or do they record directly to DNxHR or similar better codecs with a external recorder? I guess I'm trying to figure out if it's better or if I would get better results grading in a codec that is better than H.264.
Intel I7 7700k 5.1Ghz
Win10Pro-DaVinci Resolve 14.1.1
64GB Ram-3 x 1TB Samsung 960 EVO M.2 (Boot, Scratch, Render)
3 x 2TB Samsung 850 EVO SSD
2 x EVGA 1070 FTW Hybrid 8GB
Offline

Dan Sherman

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

Re: explanation of rendering codecs-intermediate-final neede

PostSun Feb 18, 2018 6:26 am

joshua newman wrote:Thats a big file! Ok that makes sense. Do some people go from H.264 and transcode to say DNxHR 444 for grading, then convert back to H.264 for upload or does that result in to many compression issues, or do they record directly to DNxHR or similar better codecs with a external recorder? I guess I'm trying to figure out if it's better or if I would get better results grading in a codec that is better than H.264.



What you want to do, is minimize the number of trans-codes between source acquisition and what finally gets delivered to viewers.

If your camera encodes to h.264, then work with that directly in Resolve if your computer can handle it. If your computer can't handle it, then transcode to dnxhr, prores, etc and work with that inside resolve.

Don't go overboard with the trans-code though, if your camera records 8-bit 420 h.264, trans-coding it to dnxhr 444 (12-bit 444) is a waste of time and disk space, because the image quality isn't going to get any better. DNxHR SQ or DNxHR HQ is more appropriate.

external recorders that record in dnxhr and prores can yield better masters, but if your delivering to YouTube it won't mater, because YouTube will crush your footage when it re-encodes it for final delivery.

h.264 out of a good camera that was properly exposed and shot with good lenses, will be all but indistinguishable from something recorded externally on the same camera when it ends up on a streaming service. For web delivery an external recorders greatest benefit imo, is more artistic leeway in post.
AMD 7950X | AMD 7900XTX (23.20.24) | DDR5-6000 CL30-40-40-96 2x32 GB | Multiple PCIe 4.0 X4 NVME | ASUS x670e HERO | Win 11 Pro 23H2 | Resolve Studio 18.6.5 B7
Offline

joshua newman

  • Posts: 39
  • Joined: Thu Dec 14, 2017 11:49 pm

Re: explanation of rendering codecs-intermediate-final neede

PostSun Feb 18, 2018 6:34 am

Dan Sherman wrote:
joshua newman wrote:Thats a big file! Ok that makes sense. Do some people go from H.264 and transcode to say DNxHR 444 for grading, then convert back to H.264 for upload or does that result in to many compression issues, or do they record directly to DNxHR or similar better codecs with a external recorder? I guess I'm trying to figure out if it's better or if I would get better results grading in a codec that is better than H.264.



What you want to do, is minimize the number of trans-codes between source acquisition and what finally gets delivered to viewers.

If your camera encodes to h.264, then work with that directly in Resolve if your computer can handle it. If your computer can't handle it, then transcode to dnxhr, prores, etc and work with that inside resolve.

Don't go overboard with the trans-code though, if your camera records 8-bit 420 h.264, trans-coding it to dnxhr 444 (12-bit 444) is a waste of time and disk space, because the image quality isn't going to get any better. DNxHR SQ or DNxHR HQ is more appropriate.

external recorders that record in dnxhr and prores can yield better masters, but if your delivering to YouTube it won't mater, because YouTube will crush your footage when it re-encodes it for final delivery.

h.264 out of a good camera that was properly exposed and shot with good lenses, will be all but indistinguishable from something recorded externally on the same camera when it ends up on a streaming service.


Thank you, that's what I wanted to know. That is how I have been doing it, shooting in H.264, editing in same codec in resolve and exporting and uploading that way too. My files all stay the same codec all the way through. I've been happy with it, i Just didn't know if that was the best and most effecient way to do it, it's my only basis since that is the first and only way I have been doing it. I guess if it ain't broke don't fix it. I am curious however what differences in editing using a different codec might yeild. My computer handles H.264 well, but it may be nice interesting to see if a another codec may operate easier and yeild the same results and quality image wise. Thank you for your replies, they've been very helpful. I've been doing a ton of reading but until you can actually have a question answered sometimes it's hard to grasp.
Intel I7 7700k 5.1Ghz
Win10Pro-DaVinci Resolve 14.1.1
64GB Ram-3 x 1TB Samsung 960 EVO M.2 (Boot, Scratch, Render)
3 x 2TB Samsung 850 EVO SSD
2 x EVGA 1070 FTW Hybrid 8GB
Offline

Andrew Kolakowski

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

Re: explanation of rendering codecs-intermediate-final neede

PostSun Feb 18, 2018 12:09 pm

There is no needed to convert h264 to intermediate codec if your computer handles h264 fine, but in the same time there is no harm either. It's just additional time and disk space (which many people try to avoid), but CPU needs are reduced substantially. For some people it's a must when working with UHD h264. Using intermediate codecs helps with timeline responsiveness on every machine. The faster machine you have the less difference you will notice. Transcoding intermediate codecs is not causing much of quality loss. The biggest loss (which is still small) is during 1st transcode- later it's marginal, even after 5 transcodes. When you transcode h264 many times using rather low bitrates (eg. 20Mbit for HD) then loos is quite big and this is exactly why you want to send to youtube something high bitrate as it will re-encode your file. You don't want to already over-compress it just for the uploading step.
All what you need is to make sure that intermediate steps are done at appropriate quality, so end result is "visually" the same as if you would use uncompressed.
Offline

joshua newman

  • Posts: 39
  • Joined: Thu Dec 14, 2017 11:49 pm

Re: explanation of rendering codecs-intermediate-final neede

PostSun Feb 18, 2018 5:00 pm

Andrew Kolakowski wrote:There is no needed to convert h264 to intermediate codec if your computer handles h264 fine, but in the same time there is no harm either. It's just additional time and disk space (which many people try to avoid), but CPU needs are reduced substantially. For some people it's a must when working with UHD h264. Using intermediate codecs helps with timeline responsiveness on every machine. The faster machine you have the less difference you will notice. Transcoding intermediate codecs is not causing much of quality loss. The biggest loss (which is still small) is during 1st transcode- later it's marginal, even after 5 transcodes. When you transcode h264 many times using rather low bitrates (eg. 20Mbit for HD) then loos is quite big and this is exactly why you want to send to youtube something high bitrate as it will re-encode your file. You don't want to already over-compress it just for the uploading step.
All what you need is to make sure that intermediate steps are done at appropriate quality, so end result is "visually" the same as if you would use uncompressed.


That makes perfect sense now that it's been explained. Thank you. My machine seems to handle H.2664 fine, but I have no basis besides using my laptop as another example. I built this computer with the main purpose for editing. I do plan on running some test doing some transcoding to see if it is a benefit to do so for my situation. I appreciate all the help explaining codecs and the process.
Intel I7 7700k 5.1Ghz
Win10Pro-DaVinci Resolve 14.1.1
64GB Ram-3 x 1TB Samsung 960 EVO M.2 (Boot, Scratch, Render)
3 x 2TB Samsung 850 EVO SSD
2 x EVGA 1070 FTW Hybrid 8GB

Return to DaVinci Resolve

Who is online

Users browsing this forum: FranzDev78, Greg Agiannidis, Uli Plank and 147 guests