What Difference Composites Reveal About Your Compressions

MISTAKE ALERT: We are aware that there are a couple of issues with this video. While the methodology for comparing outputs is sound, comparing a single pass output to a mulit-pass one is an unfair comparison. We were not trying to stack the deck against Resolve but that was the result of this unintentional mistake. The logic behind that decision was that we would use the default settings from Resolve for H.264 output and then build a file of comparable size to compare. Though the file sizes are comparable, the comparison is unfair. A multipass encode done in Resolve added almost identical noise to the signal as a multipass compression done in Media Encoder.
While editing in DaVinci Resolve is a terrific experience, you have to be careful when you get to the Deliver Panel. Not all exports are created equally and in this video, we demonstrate how different those exports can be. This demonstration isn't a qualitative one. No sir! We use math to prove that a render completed in Adobe Media Encoder will have significantly less noise than an H.264 render completed in DaVinci Resolve.
If you enjoyed this video and want to learn more about who we are and what we do, please check out our website: thayuphoto.com

[@Pixelsphere_Studios]

The "quality drop" is likely because your settings are on a variable bitrate instead of constant bitrate. It's compressing details that it doesn't detect enough change in efforts to keep file sizes smaller. Changing rate control to constant and setting the bitrate to something like 24,000 for HD and 48,000 for 4K should minimize the issue if not resolve it.

[@jonathan.v]

But then you will have a bigger file, so all in all it's still better. right?

[@michaprzychodni9379]

It should (Da Vinci) resolve it 😎😎

[@Pixelsphere_Studios]

@@jonathan.v It may indeed be larger. By how much I couldn’t tell you without testing. But the constant bitrate still won’t nearly be the size of a prores file.

[@Pixelsphere_Studios]

@@michaprzychodni9379 Was a halfway intentional pun ;)

[@sarukravitz4981]

Interesting idea, but I'm not sure if this proves anything without being more rigorous. You might just be testing whether 2 pass is better than 1 pass (which it generally should be.) The Multi-pass encode check box is right there on the Custom Export panel. If you're going to set a specific bitrate in AME, why not do the same in Resolve? Profile? Keframe interval? Etc. An apples-to-apples comparison is called for. It might be that DV's MP4 output is subpar, but I'm not sure this test revealed that.

[@JJKoester]

Totally fair feedback. The guide for this was an export at Resolve's default settings and then an export from Media Encoder that was comparable in file size. I understand the push back on this method. My hope is that I covered our methodology so that anyone could copy it and apply it to their own exports. There's simply too many combinations of codecs and bit rates for me to test them all so I figured I'd cover the basics and leave the conversation open. Thank you for your feedback and I totally understand why you feel that this methodology isn't conclusive.

[@toddgattfry5405]

@@JJKoester Kinda sounds like the first statement "you should never export to H264 in divinci resolve" might be misleading?

[@robcombs996]

I agreed. Perhaps add "... with default settings" to your title in order to make it less misleading but still informative. I would have still clicked it. Otherwise, great video! I just subscribed! Thanks!

[@JJKoester]

​@@toddgattfry5405 A legitimate case could be made and and I don't disagree. We will be doing a follow-up video and updating this one as well. Thanks for your patience on those changes.

[@JJKoester]

@@robcombs996 We're going through the comments and will be updating the title/description of this video soon. We really appreciate the feedback and are taking it seriously.

[@DarrenMostyn]

The files are the same size yes, but you set DR to automatic so we have no idea what bit rate - you specified in mE the bit rate. This also means DR didn't do 2 pass encode - what were the 2 files bit rate in the end..? ME vs DR ? Good test, but I think fairer if you set REsolve to 4000 Mb/s same as ME setting first. Interesting using darken to test - like that. Good video.

[@AdamSzarmack]

Was thinking the same thing. He didn’t specify a matching bit rate when rendering from DR so this test is flawed.

[@TheYahn]

Definitely try the Handbrake media encoder, it can get you a better quality H264 export with a significantly smaller file size when rendered via CPU, I was shocked to discover what a big difference it can be.

[@JJKoester]

We will do a followup comparing different pieces of software. Compressor, Media Encoder, Handbrake, VLC and Shutter Encoder are all candidates for this episode and we'd be happy for any other software requests if you know them. Thanks for jumping in on the comments!

[@JeradBenge]

@@Zizos Handbrake has an extensive GUI for every platform it's on now.

[@rockatanescu]

As others said, there's a multi-pass option in Davinci Resolve (not sure if it's available for the free version) and the "auto" settings for quality and encoding profile definitely have an impact on the result. There are other considerations as well, like the encoder used as not everybody is using Apple hardware. Otherwise, very interesting video.

[@JJKoester]

There are basically infinite combinations of settings that I could compare in this video so I went with Resolve's default ProRes settings, their default H.264 settings and an overly-compressed H.264 setting. The goal with the ME encode was to match file size. I do appreciate the feedback and will continue doing these little tests. Thanks for jumping into the conversation!

[@raw-viking]

The multi pass option and HW acceleration (plus every other option as far as I know) is available in the free version too.

[@afti03]

Thank you dear Jesse! what a tip! i needed this and will take it into consideration!

[@everettstone6574]

The export setting you use between Media encoder and resolve are totally different. There's no suprise that a 2 pass vbr encode is going to be better than a 10 mbs single pass encode.

[@JJKoester]

We didn't compare the 2-pass VBR to a 10 mb/s output. We compared it to the default settings from Resolve. After further testing, what we did was unfair and we will do a followup video correcting our mistake. Thank you for the comment and we're looking forward to making a video with more complete information.

[@kneerunjun]

Here from r/davinciresolve where you’d shared this. Just wanted to say that I found your video really insightful, and loved your clear and crisp presentation! Subbed and I hope to see more technical videos like this one :) Have a great day!

[@JJKoester]

Welcome to the channel! Here's hoping we can keep the content quality high enough to hold your interest. I really appreciate the comment and the subscribe.

[@JimRobinson-colors]

Nice video - I can't help but wonder where h.265 falls in this experiment. By my eyes, h.265 for export using main10 and a decent amount of kb/s when compared to the ProRes for size, appears to be a good compromise. I also wonder what the clips would look like when using free tools like Handbrake or Shutter Encoder. Do they suffer the same loss as you are showing in Resolve? I wonder. Good job with this - one of the best I have seen for testing quality and size.

[@marcioantonho]

You know that you can actually do a h264 HQ VBR 2-pass encoding in Resolve same way as you did it on Media Encoder, Right?! 😉 Never say "never"... but I got your point! Well said, though, by clarifying (at 08:00) that h264 isn't suitable for source or grading material! Great explaining on how to pin-spot the differences! 😃 Subscribed! 🤟

[@JJKoester]

I've poked around in the H.264 encode settings in Resolve and haven't found the VBR 2-pass settings. I'll poke more. I admit to a bit of hyperbole in the title but I still believe that people should be doing an archival output and then building delivery outputs from that and H.264 isn't archival. I'm not trying to be obstinate. Our pipeline simply didn't have an H.264 output from Resolve long before we did these tests. Thanks for the comment and the sub!

[@TomCut74]

@@JJKoester Multi-Pass Encode in Resolve

[@JJKoester]

@@TomCut74 Thank you for the nudge! We've found it and continue our experiments.

[@hamradiowithkevin]

Jesse, excellent demonstration and helpful, I appreciate the work you put into this video.

[@gkochanowsky]

Good to know that rightly or wrongly, somebody is looking at these sorts of things.

[@JJKoester]

Gotta look at 'em wrongly if you want to figure out how to look at 'em rightly. We're doing a rebuild of our tests based on the feedback and hope to do a morely rightly made test soon.

[@lookeast3047]

You have an uptick and a new subscriber - thank you!

[@Squiders]

Wow that’s a really impressive way of demonstrating the issues with Resolve’s H264. I had heard about handbrake, but never knew just how bad Resolve’s H264 encoding was. The only thing stopping me from using handbrake is render time. How long does it take to render a 4K video to DNxHD then handbrake to H264, versus just rendering to H264 in Resolve?

[@JJKoester]

I was also surprised at how much this test revealed about the different compressions. Handbrake has come up in the comments a bit on other boards and I'll run some tests there as well. I've never used it because I've always had Media Encorder and that seems to work well. About render times, I don't usually care how long it takes because the computer is doing all the work and I can play some Castlevania.

[@olegkauz7606]

Resolve can run H264 exports slightly slower and achieve ME results or better (same file since and so on). But you need to adjust the settings. Export speed under “file” makes a big difference (something like 75% is much cleaner), but there are more settings.

[@olegkauz7606]

Out of the box Resolve goes all in on export speed (with H264, H265 and so on). ME is slower and cleaner. But there are different options and settings to exchange speed for quality.

[@BlakeCDMedia]

Not the first find I've read to slow DR down to get better quality. Hopefully it sticks for me to try next render. Cheers

[@VozMadridista]

Very useful. Thank you!

[@JJKoester]

Thanks for jumping in on the comments! We really appreciate it!

[@BrunoZuga]

I think that biggest problem for H.264 video quality in Resolve is "Hardware acceleration", especially on Mac M1 chips. Hardware encoding on M1 chips is optimized for speed, not for quality. Out of all hardware codecs probably the best are the two latest NVIDIA generation chips. Intel chips are not far behind, however. I take NVIDIA's H.264 hardware encode over MAC Mini M1 H.264 hardware encode every time. I've done dozens of cross platform comparison tests for low bit-rate (under 8Mbps) H.264 in Wirecast for streaming. Conclusion? Taking into account same software runs on both platforms. NVIDIA's Hardware encode is visibly better no need to pixel peep. Unfortunately NVIDIA H.264 encoder is not available non MAC. Thus unchecking "Use hardware acceleration if available" on Resolve export panel (on Mac Mini M1) might improve H.264 video quality.

[@danielgoncalves3143]

This is very interesting… going to look into this

[@isaacjohnsonfilms]

Can confirm unchecking "Use hardware acceleration if available" does improve the quality.

[@BlakeCDMedia]

Was wondering why my gaming H.264 outputs looked like trash from such a great program. Cheers 🍻

[@JJKoester]

Gaming is something that kind of fascinates me in how it challenges compression algorithms. So many games compete in graphical complexity with fast movement and wild particle effects, all of which run roughshod over H.264. The Killer Instinct game on X-Box looks like it was build in direct defiance of compression algorithms. We hope that you'll consider subscribing as we continue our journey with compression settings and hopefully we can help you get better looking videos!

[@raymike]

Many thanks for that. I gave up on 264 early on, finding 265 worked a lot better. It appears to generate far fewer artefacts with a smaller file size. I mostly use Atom or pro res when I’ve got the space want to do more processing and don’t want to send it anywhere. KZbin appears to deal with 265 without a problem and Apple pro res if you don’t mind spending hours uploading. I shall now nick your testing method and take a closer look.

[@JJKoester]

I tried to give enough information about our process that anyone could replicate it if they wanted to. I'd love to hear how your tests go! Also, I'm looking forward to doing some benchmarks for H.265. I've heard a lot of good things about it but haven't jumped in yet. Thanks for commenting!

[@record7465]

I saw this problem earlier, but not so technically. Thank you, it was very interesting.

[@JJKoester]

Thank you for the kind words! We're always happy when the video is useful.

[@AJB2K3]

Dunno about the comparison the the transfer effect was amazing!

[@JJKoester]

This is my kind of comment! Concerns about the methodology will be addressed. We've improved it since that video.

[@SamuraiG]

I found H265 someones fails to create a usable render.

[@JJKoester]

There are a lot of comments that seem to be written by someone who is frustrated that we did this with H.264 instead of H.265. Honestly, we haven't had nearly as much success, both in exporting and in the clients' ability to post it to their platforms of choice, with H.265 as we have with H.264. Thanks for commenting!

[@rich8037]

This is interesting, but one problem with direct subtraction comparisons of lossy coders is that the difference isn't necessarily hugely informative because the whole point is that the error in the coded output is perceptually weighted. If you get basically no difference, as with ProRes, of course that is unequivocally a good thing, but for instance I have just done some comparisons between H.264 and H.265 (under various conditions of settings and bitrates) and the difference files look remarkably similar in every case, though I can see some pretty clear differences while simply viewing the encoded output.

[@JJKoester]

I tried to touch on things the difference composite reveals about the codecs that would be harder to detect with the naked eye, like where key frames are. I could have gone into more examples like how banding plays out in gradients and how RGB blocking happens across frames but I really wanted to get in and out with this one. You are correct that this isn't a great method for comparing compressions to each other. All it reveals is how similar or dissimilar a compression is to the source material. It won't give you that deep an understanding of why two compressions are dissimilar to each other. Thank you for the comment! To be clear, I'm not disagreeing with your point. I'm just trying to explain the thought process that went into this video.

[@LuckeGabriel]

I actually really like the effects of the adjustment clip with the difference mode. That's something I'm gonna have to experiment with for some trippy effects.

[@monsterandmaster]

I thought the same haha Could looks cool

[@JJKoester]

It could be really fun for a music video where you have the performer do the same thing several times in a row and then layer the footage and only reveal the differences. If we do something like that, we'll surely post it. Thanks for the comment!

[@truboston]

Absolutely! I always do render in prores and then use handbrake to make good h264.

[@JJKoester]

Thanks for the comment! We're actually working on a video now comparing outputs from different 3rd party pieces of software. Handbrake is definitely one of the contenders in that Battle Royale.

[@PhillipRPeck]

This is genius. Thank you! Definitely going to try this out with h.265

[@JJKoester]

I like it because it's a numeric quantification that feels intuitive and reads naturally to the eye. I'm excited to test other codecs and modules (look out, Handbrake, here we come!) to see how the results compare. Thanks for the comment!

[@imothy]

great tutorial, thanks for reading your comments too!

[@JJKoester]

Thanks for giving it a look and double thanks for the comment! When a KZbinr tells you that comments help their metrics, they aren't kidding.

[@DavidWinstead]

WOW man, great testing. I've been using DR ever since version 15 or 16 and never noticed what you showed but always thought something was different with my H264 encodes vs Adobe Encoder!! I'll be using you method from now on.... Thanks for sharing! You gained a new sub.

[@chumcool]

If there was ever anything in your life that you regretted the most, you need to remove it from the shelf and replace it with this video. Now, I’m not an h264 fan boy by any means, but i do know how to use it and this video demonstrates exactly the way Not to. If anything, what you’ve done here is created an example of what not to do. So… good job?

[@JJKoester]

That's a bit harsh but not entirely unfair. I can assure you without any qualifications that this video is not the greatest regret in my life. I regret being a poor partner to the women who were kind enough to love me in my late teens and early twenties. I regret thinking I had more time to meet my wife's mother and then learning that cancer moves quickly. But posting a video that compares a single-pass variable bit rate encoding to a two-pass variable bit rate encoding without correctly delineating those differences doesn't even crack the top ten of my list of regrets. Thank you for the comment, though. KZbin doesn't distinguish between positive and negative engagement so I'm grateful for the bump you've given this video.

[@chumcool]

@@JJKoester Sure thing.

[@RobertShaverOfAustin]

Your information is valuable to me because: 1. you showed me how to test the quality of my export media. Excellent tip. 2. you showed me that, if I want to archive a version of a project that deserves it, I will use DNxHD. (I did actually know that.) Your video work is good. Your explaining was okay but could be better. At the very end of your video you *finally* explain why I should be interested in your video. I was totally baffled why you exported the video in ProRes and then, using the ProRes file to "export" again via trans-coding it using Adobe Media Encoder. All of this information would have been more useful at the beginning of the video. Have you ever heard the teaching maxim; "Tell them what you are going to tell them, then tell them, then tell them what you told them." Why this isn't useful to me: 1. I do not have any Adobe products any more. 2. I do not have any Apple products any more. 3. For the kind of videos I make, DaVinci Resolve H264 is good enough for the videos I post on KZbin. Also your title for this video is quite click-bat style. I often don't watch videos with titles like that. I haven't subscribed yet. I'm going to checkout some more of your videos. I hope this is useful to you. I wish you all the best.

[@Clickumentary]

You hold a high bar for subbing creators! ;) It might be a bigger deal if you subbed + clicked notifications. Then you're really making a commitment lol

[@RobertShaverOfAustin]

@@Clickumentary I have more than 600 subs now. I'm trying to be more selective and I have a lot of subs for Davinci Resolve posters already. Still, I'll check out more of these videos. Thanks for the feedback.

[@Clickumentary]

@@RobertShaverOfAustin wow that's a lot of follows...such is the nature of social media. I hear you and really wasn't trying to be critical of your decision. I confess I also am a little wary of following too many DR creators.

[@JJKoester]

First, a sincere thank you for jumping in on the comments. I really appreciate the feedback. We've changed the title of the video and updated the description as well. Take your time on deciding to subscribe. We'd be happy to have you as an audience member and commenter but totally get it if the signal to noise ratio on this channel isn't the best fit. Cheers!

[@RobertShaverOfAustin]

@@Clickumentary I appreciate your followup and I didn't take the earlier one as critical. Let's get a drink sometime. :)

[@ATLJB86]

But studio users output in .265

[@JJKoester]

Not this one! I output in ProRes and then deliver to the client in H.264. We did a bit of noodling in H.265 but there were some compatibility issues along the line (their end) so we retreated back to the familiar comfort of H.264. We're looking forward to giving H.265 another go in 2023!

[@ATLJB86]

@@JJKoester Give it another go and make sure you incorporate render times because that’s where .265 shines! There is a reason it’s not in the free version 😎

[@JJKoester]

@@ATLJB86 We absolutely will test H.265 but please don't be surprised if we treat render times as an afterthought. Output quality is our north star. Again, thank you for the comment and for the nudge toward H.265. We're excited to get deeper into codecs in 2023!

[@sungill3855]

Very interesting take Jessie! I think you may have something here.

[@JJKoester]

We're off to a good start. The theory behind this video is rock solid but we did make a mistake with encode settings between Resolve and Media Encoder. This will be addressed in a future video. Thank you for commenting!

[@Jhoosier]

*Looks at 40 hours of H264 exports from Resolve* Oops Great video, well made and well explained. I'll try my next one using handbrake and see how that goes. Thank you.

[@shawnebrown]

You are one of the best at teaching! Thank you. This was fantastic..

[@JJKoester]

I'm glad it was useful! I was really excited to release this because as I tested, I was surprised at how much information was being revealed through these comparisons.

[@CmanXP]

Haha very informative video. Liked the subtle La Croix jab 👍

[@JJKoester]

I talk tough but I'm still drinking it. Cola La Croix is my jam.

[@Accentrick]

It doesn't even matter because KZbin is going to fck up your quality anyway.

[@JJKoester]

We deliver to all kinds of platforms including Instagram, Vimeo, Tik Tok and so on. But the platform we export to most commonly is the client and we want them to have the highest quality output possible and the ability to create variants easily. This is why we always go archival --> delivery instead of straight to delivery. Thanks for the comment!

[@ikbalaydin80]

Thank you so much for the video 🙏

[@JJKoester]

Thanks for jumping in on the comments! I'm glad the video was useful for you.

[@ikbalaydin80]

@@JJKoester i am glad you made this video .. thank you so much again Sir 🤗🙏

[@craigscorgie]

This is just a comparison of single pass VBR (which you did in Resolve) vs 2 pass VBR (which you did in Media Encode). If you selected "multi-pass encode" in Resolve, that would have been a more accurate comparison. Would be interested to see how that would have turned out.

[@TokenCast]

I liked it, but my biggest issue is trying to figure out. Why I have these wildly inconsistent pauses or crashes in my renders. Even in basic videos that are not ridiculously complex,. I will run into situations where something does not even ten minutes will always get stuck at seventy or thirty percent. Also? I'm curious why. When I use speed increase or decrease and clip duration increase or decrease It's a fifty fifty chance it'll Actually change the clip's duration or speed.

[@fromthenorth3541]

What would you suggest to import in 4K on PC? Is DNxHR 444 12bit a good option for a 3840x2160 Ultra HD setting?

[@RestartFPV]

Really good comparison, very helpful 👍

[@JJKoester]

I'm glad it was useful! Also, thanks for the comments. When KZbinrs say that comments help, they aren't joking. We really appreciate it!

[@benoitguitard2887]

Very interesting methodology, I am using the nvidia encoder on PC so I would try to perform this kind of test and maybe try H265 too

[@JJKoester]

We're going to get into H.265 soon. I noodled with it a bit but some of the platforms we upload to weren't ready for it so we just kicked the can down the road. Now that we've worked out a good testing methodology, we're excited to get back into H.265. Thanks for the comment!

[@gsridernet]

There is very significant difference in DaVinci Resolve in H264 export if multipass is used (only on MacOS available option) - I have my test video 40mbps 1080@60fps and multipass makes really big difference in certain scenes where otherwise is a lot of artefacts in the image. Unfortunatelly the export file is very different if exported in MacOS, Windows, CPU or GPU (I did every combination and MacOS multipass with Graphics acceleration was the best). For some reason only version 16 makes proper profile/level of video 4.2 every newer version (starting 17) makes trouble with exported filed to be played smoothly on multiple devices. Have Studio version as well...

[@moviemakerd]

Very ineresting metod for comparison (with difference mode) , but you compare apple and orange. Default settings in Davinci and two pass VR encoding in ME, that is wrong. So try to do again with same parameter in both programs . Regards

[@JJKoester]

Noted. There was a thought process to that - the goal was to use the default output settings in resolve and then build a file that matched the size. The intent was not a skewed test but that was the result. We'll be posting a new video soon. Thanks for the feedback!

[@TheIkeRai]

A brilliant practical explanation!

[@SW-Video]

I use 'Shutter Encoder' (free or donation) so I will give this a try. Sometimes a low bitrate for a short video for sending via email means needing the smallest file possible.

[@Pubcrawler644]

Ah I just click the KZbin tab and hit render

[@JJKoester]

Totally legit! I talk tough but the real metric we care about is getting movies to eyeballs. As long as you're having fun making movies and your audience is having fun watching them, you've got my support!

[@BeardsChips]

There is no specified bitrate in the "H264 "HQ"" Which you actually used Automatic but used a very specific for the Media Encoder file.

[@JJKoester]

This wasn't arbitrary. I wanted the Resolve codec to be default and then I wanted the Media Encoder output to be the same size as the Resolve encode or smaller. A bigger mistake was doing two-pass encode on the ME encode and not the Resolve encode. Thank you for the comment! We really appreciate the feedback.

[@BeardsChips]

@@JJKoester don't get me wrong, i feel like the Resolve internal renderer is underdelivering on H264, but on one you select a specific bitrate and on the other you don't ... that was my gripe

[@JJKoester]

@@BeardsChips Oh, I hear you! There are problems with this video and they are our fault. There was a thought process behind our methodology and it made sense going it but then we discovered that it was incorrect after release. I'm not discounting your opinion, just trying to explain the flawed logic.

[@StefanRingelschwandtner]

Nice.

[@JJKoester]

Thanks for the comment! I'm glad if this was useful for you.

[@SamuraiTin]

You didn’t talk about file size, the aim of h264 is to export with a good quality/size ratio. If you get a h264 file that is same size as prores or even larger to get same quality, then there is no point

[@JJKoester]

I disagree with this as H.264 is an inter-frame codec and ProRes is intra but I don't disagree so hard that it matters. Thanks for commenting and I do appreciate the feedback!

[@SamuraiTin]

@@JJKoester well hence there is no point to get h264 if your file size is same as prores.

[@Clickumentary]

Interesting, I would have never considered that great a difference. This is sort of more than I needed to know but might be helpful. I do use DNxHD to roto / magic mask clips to preserve alpha channel to ease burden on GPU. *actually this comments section has been most helpful!* Subbing for future drops of wisdom.

[@JJKoester]

Thanks for the comment! The main point of this video was to give a roadmap for testing outputs. We absolutely whiffed when comparing single-pass to multi-pass but the methodology is sound, we believe. The comments on this one are really invigorating, particularly for the pushback we got on the single/multi pass thing. It's a discovery process and we're really happy to have you along as we continue to improve our workflow. Cheers!

[@MAD_CHILLER]

DNxHD? No.. DNxHR. I’d also point out that on windows the Nvidia Encoder may provide highly different results.. as it is quantifiably more effective vs the software encoder.

[@JJKoester]

Thank you for catching that! Signature life-long Mac user mistake. I shot a little bit on DNx when the Blackmagic Cinema 2.5K camera came out but jumped back to ProRes after a day or two. Thanks for the comment!

[@ablae1234]

exporting for web 2022 and on is h265 or maybe av1 if it gets it act together

[@therealmichaelphelps]

So in Davinci Resolves export settings you set it to "default" yet in media encoder you set a bunch of very specific parameters. Is there not a "default" setting for media encoder?

[@JJKoester]

Yes, there are default export settings in ME but they are different from the export settings in Resolve. We are aware of the mistakes in this video and will be addressing them in a future video. Thanks for the comment and we apologize for the sloppy lab work in this one.

[@therealmichaelphelps]

@@JJKoester But i gotta say i appreciate you showing how h.264 isnt the best thing for transcoding in davinci resolve. But wouldnt it make sense for transcoding to DNxHR or DNxHD or prores anyways? The thing is some cameras dont need that, and especially the guys who are working with mobile footage theres no reason to take an 8 bit h.264 footage and re transcode it again into a different format. I wish you would have made that very clear that this is for transcoding footage to a more video editing friendly format. Some people dont even do that at all and just work with the raw footage depending on the camera of course.... anyways it was very interesting however! :)

[@sotonin]

yeah but all my 4k cameras record directly into H264. so what does it matter? doesn't to me.

[@JJKoester]

I wouldn't write off ProRes or DNxHR quite yet. As you move your footage through post, you're probably improving on it with color correction and other effects. For that reason alone, I could argue that you want to output as high quality as possible. That said, I'm going to speak candidly... If you look at our channel, most of our videos are doing 100-300 views or something like that. This is our first video to blow up and I'm a bit out of my depths here. I don't make these videos assuming that anyone will take them too seriously and suddenly, I have one video that people are taking super seriously. I really just hope that everyone makes movies, has fun doing it and that those movies make other people happy. Thank you for the comment and happy shooting!

[@RandumbTech]

Can we back up even further? What are you shooting your source footage in All-I or Long GOP? I use Sony and currently have it set to XAVC S which I think is Long GOP. I tried XAVC S-I but did not see any difference and it consumes triple the storage. It would be great if you could do a comparison of those 2 types of recording formats as well. Great video - new sub here!

[@JJKoester]

Here's the bad news... We're shooting on a Blackmagic Pocket Cinema Camera and we shoot everything RAW. We were shooting on the A7Sii for a while but once we started working with intra-frame codecs like ProRes or RAW, we never looked back. The quality of the footage and efficiency in editing both shot through the roof and it was worth whatever the cost was in storage media to leave H.264 behind for acquisition and editing. When we get H.264 (from a drone or GoPro or something), the first thing we do is transcode to ProRes. Thanks for jumping in on the comments!

[@ÁzsiábaSzakadtam]

10000 for what? That's ridiculously low

[@JJKoester]

We went with two H.264 outputs from Resolve, their default settings and 10,000. We did the former because it is the software default and that seemed like a good place to start the conversation. We did the latter to exaggerate compression artifacts and make the result of the difference composite even more obvious. We would never do a 10,000 output for a client and don't recommend that bitrate outside of exaggerating test results for demonstration purposes. Thanks for the comment!

[@Flamamacue]

Very interesting. I've been tearing my hair out using Resolve creating reel/TikTok content for some brands & having everything completely murdered by compression. The platforms are very bad for it but there's plenty of really nice, sharp and clean looking content out there yet whenever I upload it looks like complete mush. Perhaps this may alleviate the issue

[@landonp629]

Media Encoder still does things Resolve doesn't do - so it's still installed on my PC. Multiple times I have ran into an issue where Resolve won't import a file format that I can convert with Media Encoder.

[@gssg2010]

This begs a question regarding BRAW instead of Prores. Resolve is optimized for BRAW and BMD cameras. Does this same H.264 issue repeat under those parameters?

[@semantica-james]

Have you tested the H dot265 export?

[@JJKoester]

We are working on that video now. Thank you for the suggestion and for your patience and we produce that one.

[@ODHunte]

Interesting video with some interesting techniques. I would say you missed a common technique which is to set the maximum bit rate to 90,000 rather than automatic or a terrible rate such as 10,000.. but still thanks for making the video and encouraging discussion

[@JJKoester]

Totally valid feedback! The reason we went with auto and 10K was for expediency's sake. The reality is that the number of export combinations we could have demoed was 10 shy of infinity. Instead of going down that rabbit hole, we focused on methodology so people who wanted to dive deeper had that option. Thanks for the comment!

[@ODHunte]

@@JJKoester yep makes sense.. good job

[@LizardMods]

So if I understood correctly your gripe is not against h264 just the fact that the way DaVinci Resolve does it is crap

[@herseem]

Even though I'm an amateur, as soon as you mentioned that the media encoder was using a 2-pass mode I knew this comparison was going to be flawed. Coming from Shotcut where I always use the highest quality settings for output which are slow to render, I noticed immediately that Resolve has fast render times on the default H264 settings. So I'm already assuming that the default settings are speed-optimised rather than quality-optimised. Did you just create this clearly-flawed video to be deliberately provocative? I've got to admit I did learn something useful about technique though.

[@kilikdudley]

Always H265 Main10 or ProRes for 10bit color

[@andreasgiobel6355]

Hi, I understand YT angle you have on the H.264 comp. As compared its a bit of oranges and appels, Mb are one thing. If you let Me do multiple passes, you by default give Me a better chance for Quality and Your encoding Profiles need to be same. If you use force in resolve under Advanced you *may* have a better result. I like the Options for Encoding in ME as they are more advanced/can be tuned more precise to fit your needs ;)

[@AdamSzarmack]

You should have entered 40000 kbps instead of 10000. That would have been a matching bitrate to what you entered in Media Encoder. Cool video but this test is flawed.

[@ruslanalpysbayev1209]

Hi. Can you recommend export settings from DR for instagram posting? If it's full hd 24 fps settings

[@mcneilbelle]

very good video

[@moodberry]

Really geeky, but I'm a geek anyway :) Enjoyed it. But one thing you said kind of unclearly was you said DNXHD should be used if on a PC. Why is that, and what would THAT comparison look like? Thanks.

[@JJKoester]

DNxHD/HR are native on the PC but Quicktime isn't. You can get ProRes working on a PC but I don't think it'll be installed from the jump so it's just more likely that non-Mac users would lean towards DNxHD/HR. There is no judgement being passed on that output module but there is a lack of experience with it on our end.

[@SantiFox]

Interesting video for sure, still don't think I wanna add a step to exports.

[@JJKoester]

We don't consider it adding steps to export because we always go to archival first (ProRes) and then do delivery second (H.264). But, we're export absolutists. Thanks for jumping in on the comments!

[@SantiFox]

@@JJKoester smart!!

[@Ronbc000]

I'm fairly certain 95% of Davinci users export in H264 for obvious reasons

[@JJKoester]

And they're absolutely allowed to. Some dork with a KZbin channel isn't the final word on anything. But, boy howdy, do I prefer to export to archival and build delivery videos from that.

[@joyoffilming9500]

Greai and very informative tutorial. Anyway, isn't there a 2pass switch in DR? I saw you activating the 2nd pass in the media encoder. Probably, this, in combination with constant high bitrate will close the quality gap a bit. And, you're atotally right: H.264 is not the best choice for archival purposes.

[@JustinHiggins]

Small b for bits, big B for bytes 🙂

[@JJKoester]

So, I got it right? I was pretty sure that was the rule but God knows I've eaten steak with my salad fork and pudding with a soup spoon.

[@JustinHiggins]

@@JJKoester Yep, you got it right.

[@Ninjutsu2K]

Amazing video and explanation, nicely done, one more subscribe.

[@JJKoester]

Thanks for the subscribe! Here's hoping we continue to make content that helps your workflow.

[@JeffBourke]

Oh no. The export options were one of the main reasons I upgraded to studio 😂😂😂😂

[@JJKoester]

The good news is that there are deeper export options than we highlighted in the video, including multi-pass VBR. Noodling with these will increase the quality of exports, so much so that we are working on a second video to correct incomplete (and occasionally wrong) information in this video.

[@jeffellis6544]

Noob question- is Media Encoder included with resolve or is that a third-party app ? Just learning video editing…

[@JJKoester]

Media Encoder is a member of the Adobe Creative Cloud family of apps. We're currently working on a more comparison-oriented video between different compression programs and hope to post it soon. Thanks for the comment! Noob questions are my favorite for two reasons. 1) Someone is exploring a new hobby/art-form/business/mode of expression and nothing is more exciting than that. 2) I can usually answer them.

[@puchika7091]

It means that you have to be making monthly payments. For adobe creative cloud 😉😬

[@JJKoester]

@@puchika7091 Yeah, and if all you're paying for is Media Encoder, it's not worth it at all. We're drifting away from the Adobe ecosystem but we're still tethered. The smaller the pool of tools that keeps us tethered gets, the more frustrating that subscription fee is.

[@Modpax]

also, does da Vinci do 2-pass? that is a serious difference.

[@JJKoester]

DaVinci does but it's not called 2-Pass Encoding. It's called Multi-Pass Encoding. While the methodology presented in this video for comparing is solid, the single/multi pass whiff is meaningful.

[@Modpax]

@@JJKoester thank you, good to know. I do use compressor, which I have always gotten amazing results from and it just compressed head and shoulders in speed for me over media encoder

[@thmallik]

I agree, I got the answer of my poor quality output from Da Vinci Resolve.

[@Keichan2501]

What if I want to use MP4 format? I can only export it to H.264 or 265. Do I use 265?

[@JeffBourke]

For me, not professional, the quality sacrifice is worth saving doing an entire transcode.

[@JJKoester]

I have to disagree with this comment. Our north star is quality, not export expediency for two reasons. The first is that the client doesn't experience the benefits of a quicker export but they do enjoy the benefits of a higher quality delivery. The second is that, since we don't have to do anything during exporting, we're also not affected by export times. We use the time to grab a cup of tea and read something dumb on the internet. Also, we keep RAW footage for a year after filming and our archival prints for as long as we can mount the drives they're on. If a client wants a change to their project and we don't have the RAW files, we'd rather be cutting up an archival print than a deliver one.

[@JeffBourke]

@@JJKoester well you kinda agree with me. For me, a non professional the convenience is key. The quality difference is not perceivable although as you demonstrated is mathematically there. I still keep base files for future. For client delivery then of course it is worth using the other encoder.

[@JJKoester]

@@JeffBourke I think it's safe to say that we agree with each other, just differently. 🙂 Honestly, whatever gets more movies made makes me happy! Thank you again for commenting and I hope I haven't chased you away.

[@JeffBourke]

@@JJKoester nah you covered a good point. I had actually wondered about this before because I have noticed that virtual dub renders h265 about double the file size for equal CRF to handbrake. I’m going to use your compare method so see what the actual difference is 👍

[@Vondoodle]

What .. never !

[@JJKoester]

Hardly ever!

[@P5YcHoKiLLa]

B = Byte, b = bit

[@JJKoester]

Thank you! I was 90% sure I got it right. Meanwhile, I totally whiffed on the single-pass/mulit-pass issue and the comments sure let me know.

[@haroldmorganTulsa]

You've made a couple mistakes. If you have in and out points set on your timeline, that carries over (at least in Windows). Second, you could be much more efficient in your render if you added all your versions into the que and then hit "render all".

[@JJKoester]

The in and out points carry over to the Deliver panel but you have to make sure you're export is set to in and out and not whole timeline. I hope I didn't make it sound like you have to reset in and out points when you get to the deliver panel. Also, once you make the switch to in and out, you don't have to do it again for every project or timeline. It's a software level setting, not project. About the queues, I stack up exports when I'm working with multiple timelines but I only do one export at a time from a single timeline. It's an old habit and I keep it alive because I'd rather stagger my exports than queue up a whole bunch and realize that there was something off in the source timeline. Thank you for the feedback! I'm always happy when someone jumps in on the comments to discuss workflow!

[@sb4photos]

H265.?

[@JJKoester]

Coming soon!

[@custommadename]

The lowercase b is bits. There are 8 bits, or ones and zeroes, in a byte - so you take that and see that 40Mbps is a finer measurement of the same amount of data as 5 MB/s. Sort of unrelated: Imagine if you had a video at 40 MB/s to stream! That would be pretty intense for the web connections of most of the people I know.

[@EdwardKilner]

Would have been more useful if you had said something and shown something about dnxhd. Newbie, but hate it when KZbinr sneaks in an unfamiliar term. Did subscribe though.

[@JJKoester]

That's totally legit. I am a life-long mac user so I don't use DNxHD at all. In fact, one of the comments corrected a mistake; I should have been talking about DNxHR but I got the name wrong. Our hope is that as you watch our videos, you continue to tell us when we've left information out. We try to keep the videos as tight as possible and that means we're more likely to breeze over a topic than we are to dive deep into it. We want the viewer to walk away with enough information to start poking around and running your own tests. We're always happy to dive deeper into any topic. Thanks for the comment and the subscribe!

[@EdwardKilner]

@@JJKoester Thanks for the comment. If you do a video on DNxHR, you can be sure I’ll pay close attention. Time expired on my current desktop, and I’m leaning to Resolve.

[@petrub27]

but you are apreciating the image quality on your own display, who knows what youtube is doing...

[@JJKoester]

KZbin is doing some terrible things to our videos. That's why we export to an archival format like ProRes before compressing to a delivery format like H.264. I can't be held accountable for our files once they leave the suite. We can only set them up for success and see how they fare in the world of aggressive compression.

[@pierrotbeck8559]

Nice demo, I use third party encoders for an another reason : I need to work on DVR, not waiting for an h264 rendering, so I’ I’m only encoding a prores and then put it to h264 renderings in différents nitrates, then back to work in DVR… Then you could say : DVR does renderings with dual exports (prores+h264) but there’s a problem : you cannot switch sound’s compression… PCM for prores is ok but I need AAC for the h264. If anyone has a tip about that, I’ll be glad. Pb

[@eddieharcourt6049]

Deliver vs Export?? Come on...

[@JJKoester]

I'm not sure I understand this question. Is it about the difference between archival export and delivery?

[@afti03]

(you have a typo in the description text after Adobe Media Encoder - less noise "that" an , instead of "than". feel free to delete this comment)

[@JJKoester]

Thank you for catching that. We've corrected the description.

[@karillaido]

Your testing is not correct, media encoder had less information to compress, starting with the proress and not the raw files. you should compare apples to apples.

[@JJKoester]

Thanks for jumping in on the comments. We're doing further tests and will be putting out more videos on this topic. We really appreciate you jumping in though and hope we haven't alienated you with our bit of sloppy methodology. Cheers!

[@KirkwoodImaging]

Now try Shutter Encoder.

[@JJKoester]

That's going to be a future video. We're excited to test more encoders.

[@KirkwoodImaging]

@@JJKoester I love it, CQ mode for H264 vids ends up with incredible quality and low file size.

[@le_wuerzingeer]

why 264, when 265 is newer, faster, smaller file sizes etc. but i am no pro but i thought 264 is the old shit. nevertheless nice and interesting video

[@JJKoester]

I'm a pro and I can confirm that H.264 is old shit. We did some deliveries early last year in H.265 and the client had trouble playing them back. The new shit was just a bit too new so we stuck with the old shit in 2022. We're excited to get into the new shit at the start of the new year and we'll definitely be running deeper tests with H.265. Thanks for the comment!

[@le_wuerzingeer]

@@JJKoester and a video with the results? i hope. greetings

[@JJKoester]

@@le_wuerzingeer That's the plan!

[@BurninSven1]

Resolve works good enough for anyone, there is and have been no better software that even can do all tat it can.

[@JJKoester]

We don't disagree on that point. Two years ago, we were 95% Premiere and 5% Resolve. Those numbers have flipped and it will be very hard to get us back to Premiere.

[@rickpinelli1586]

Where do I get the Apple Media Encoder? Thanks

[@JJKoester]

If you go to the App Store, there's an App called Compressor. Between that and Apple Motion, it's the best hundo you can spend on video software.

[@bermchasin]

@@JJKoester what If I want to spend zero hundos?

[@kamilnowak9750]

264 is supported by my gpu. 265 is not supported

[@JJKoester]

I hear a lot of good things about H.265 but it seems like I'm not alone feeling like not all of the pieces were put in place before it launched.

[@RovshanMamedov]

Thanks, I didn't know that. Some time ago I tried to switch to Davinci resolve, but quickly returned to Adobe Premiere. Turned out all these videos going out on youtube nowadays about how Davinci is better than Premiere is greatly exaggerated. I had lots of performance issues. Audio lagging behind, some times portions of audio didn't played at all while I was editing timeline. Also Davinci was failing register shortcuts. For example when I switch to cut tool pressing B it wouldn't register because PC was "catching up" with my last action:) Add to it that you can't customize your workspace! This is ridiculous! Davinci has cool ideas behind editing but it has a long way to go to match Premiere.

[@FilmProductionUSA]

You are correct in saying that Davinci quits playing the audio; it happens all the time with me as well. The only fix i found to get the audio to start working again is shutting Davinci down and starting it back up again.

[@IndioA]

sorry, i had never a problem with any sharpening lose on my 12 year old macpro export 6K BRAW to 4K H264

[@gabriel101x]

It's much worse if you're on Windows because then Resolve can't export h264 audio higher than 128kbps, it's a joke.