Yes, another h.264 post, but new concern for Resolve 15

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

David Andrade

  • Posts: 8
  • Joined: Sat Aug 26, 2017 4:51 am

Yes, another h.264 post, but new concern for Resolve 15

PostFri Dec 14, 2018 6:22 pm

Ok, so, after much research and forum diving it appears that alas, Resolve doesnt have, at this time, the best encoder for h.264 files.

This seems to be the general understanding, even if the encoding appears to have improved according to some users.

But here is my concern:

Usually, the response is: "Well, in a professional program such as Resolve, you shouldn't be using a h.264 codec for....." - so on and so forth.

But I have TWO, yes two, counterpoints.

1. Then why include it? It's as if you're trying to have your cake and eat it too. It makes no sense to include a codec, not have any reasonable value to it, and then argue that it shouldn't be there in the first place. Ok, but if that's the case, why is it there? Furthermore, in the most recent versions of Resolve, they've included a YouTube option on the export screen. Again, if we "all should be avoiding it, because we all (I am just paraphrasing here) know it's not the best" - then why is there not only still an option for h.264, but an export for Youtube?

To be fair, the h.264/mp4 export may have been there in the past, maybe not for delivery (even to youtube) and potentially just for a quick render for viewing. But again....there's a YouTube option now. And YouTube doesn't need 80Mbps data rate files, but that brings me to my second point.

2. Resolve went from a coloring application, to almost a full fledged editing platform, audio interface included. It appears that they are trying to compete with the likes of Premiere Pro, correct? We can all agree? So with that being the case, it may make sense to "beef up" the h.264 encoding, in my opinion.

If none of this sounds familiar, I invite you to perform a quick search on this. I guess my point is that the days of arguing that Resolve is too professional for this is a blind justification at this point. I am NOT trying to suggest that Resolve is a bad program. I love it. I use it all the time. But am I overlooking something here? I've ran some tests, and I cannot break 8Mbps on an export, no matter what, for 1080p footage. Before anyone suggests this, I have used Handbrake before. but I am not asking for suggestions.....I am just making a casual observation that the Resolve of yesteryear isnt the same one from today.

Do we know why this is the case? Is it a matter of getting some developers to create a "better" encoder? Cost?
Offline

ohimbz

  • Posts: 55
  • Joined: Wed Nov 14, 2018 8:54 am
  • Location: Romania
  • Real Name: Musetoiu Florin

Re: Yes, another h.264 post, but new concern for Resolve 15

PostFri Dec 14, 2018 7:11 pm

I`m not sure why would you think H264 shouldn`t be an option for Resolve... I came from Premiere to Resolve because of how fast it is and the fact that i don`t have to pay a subscription.

Removing H264 from export would make this software useless to me, i deliver all my work in H264, and using another encoder from a loossless export from Resolve breaks the "how fast Resolve is"

But what i`ve seen with it is that i have to set Data Levels - Full in the advanced field in Delivery ... otherwise i see random artefacts on the final file.
Ryzen 3700X
G.Skill 16GB 3200 CL14
GTX 1080Ti
Resolve 16
Offline

Ole Kristiansen

  • Posts: 182
  • Joined: Tue Nov 28, 2017 8:37 pm

Re: Yes, another h.264 post, but new concern for Resolve 15

PostFri Dec 14, 2018 7:23 pm

"I've ran some tests, and I cannot break 8Mbps on an export, no matter what, for 1080p footage."

Free or Studio version of Davinci Resolve 15 ?
Attachments
Davinci Resolve h264.png
Davinci Resolve h264.png (130.92 KiB) Viewed 4075 times
Offline

David Andrade

  • Posts: 8
  • Joined: Sat Aug 26, 2017 4:51 am

Re: Yes, another h.264 post, but new concern for Resolve 15

PostFri Dec 14, 2018 7:29 pm

ohimbz wrote:I`m not sure why would you think H264 shouldn`t be an option for Resolve... I came from Premiere to Resolve because of how fast it is and the fact that i don`t have to pay a subscription.

Removing H264 from export would make this software useless to me, i deliver all my work in H264, and using another encoder from a loossless export from Resolve breaks the "how fast Resolve is"

But what i`ve seen with it is that i have to set Data Levels - Full in the advanced field in Delivery ... otherwise i see random artefacts on the final file.


I wasn't suggesting that they remove it. The reason I worded it that way was because of the responses that others have given in the past.

"so dont use h.264...it's not professional" - but that sidesteps the fact that Resolve INCLUDES h.264 as a codec. So my argument to them was if its not professional, then why does Resolve have it.

I personally see a benefit to having it included. My comment was more geared to those who insinuated that we should avoid it.
Offline

David Andrade

  • Posts: 8
  • Joined: Sat Aug 26, 2017 4:51 am

Re: Yes, another h.264 post, but new concern for Resolve 15

PostFri Dec 14, 2018 7:51 pm

Ole Kristiansen wrote:"I've ran some tests, and I cannot break 8Mbps on an export, no matter what, for 1080p footage."

Free or Studio version of Davinci Resolve 15 ?


Mine is the studio version.

I am willing to admit any oversight on my end. Can you let me know what you used for settings?

Regardless of what I entered under "kbps" it always came out under the 10Mbps threshold. Again, I am willing to concede that I overlooked something, and I admittedly didn't enter 1000000 kbps to see what happened, but with my previous results, I didn't expect it would have any impact.

Also I must note that I tried both under Media Management and the export screen.
Offline

Ole Kristiansen

  • Posts: 182
  • Joined: Tue Nov 28, 2017 8:37 pm

Re: Yes, another h.264 post, but new concern for Resolve 15

PostFri Dec 14, 2018 8:08 pm

You set the Quality to Automatic: Best
or Restrict to - higher than 10000 Kb/s
Encoding Profile: High
Offline

David Andrade

  • Posts: 8
  • Joined: Sat Aug 26, 2017 4:51 am

Re: Yes, another h.264 post, but new concern for Resolve 15

PostFri Dec 14, 2018 8:13 pm

Ole Kristiansen wrote:You set the Quality to Automatic: Best
or Restrict to - higher than 10000 Kb/s
Encoding Profile: High


I did. Hmmm, clearly I need to run more tests. (probably include more variables, such as possibly different footage, which different "starting" codecs - not that it "should" matter. The one I was running tests on was encoded with prores)

Are you using a Mac/Windows? Unsure if that impacts anything, but wanted to ask, regardless.
Offline

Jim Simon

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

Re: Yes, another h.264 post, but new concern for Resolve 15

PostFri Dec 14, 2018 8:39 pm

David Andrade wrote:This seems to be the general understanding


Maybe, but I would disagree with that understanding.

I used to use x264 when I was editing with Premiere Pro. I found it superior to the MainConcept encoder Adobe uses.

When I switched to Resolve, I no longer found it necessary to use x264. I find the High setting quite acceptable for client delivery. (And the Best setting is even better.)
Offline

David Andrade

  • Posts: 8
  • Joined: Sat Aug 26, 2017 4:51 am

Re: Yes, another h.264 post, but new concern for Resolve 15

PostFri Dec 14, 2018 8:47 pm

Jim Simon wrote:
David Andrade wrote:This seems to be the general understanding


Maybe, but I would disagree with that understanding.

I used to use x264 when I was editing with Premiere Pro. I found it superior to the MainConcept encoder Adobe uses.

When I switched to Resolve, I no longer found it necessary to use x264. I find the High setting quite acceptable for client delivery. (And the Best setting is even better.)


This is good to hear. I admittedly fell into the trap of just accepting that it wasn't the greatest.
There were recent reports of this. I ran my own tests, and left it at that, assuming that I would continue to get the same results "as everyone else"

But after reading some of these replies, it appears that I have some more tests to run.
Offline

RCModelReviews

  • Posts: 464
  • Joined: Wed Jun 06, 2018 1:39 am
  • Real Name: Bruce Simpson

Re: Yes, another h.264 post, but new concern for Resolve 15

PostFri Dec 14, 2018 9:23 pm

Most of my stuff goes on YouTube and I have found that the (free) H264 encoder is good enough in most cases. If you pay your $300 and get the studio version then you'll love the extra options: hardware-based encoding (NVENC) and X265. Using hardware based X265 I get around 125fps encoding speed with a GTX1060/6 card and the quality is more than good enough for YouTube. It's great not having to wait around for a render to complete ;-)
Resolve 15 Studio, Fusion 9 Studio
CPU: i7 8700, OS: Windows 10 (1709) 32GB RAM, GPU: GTX1060/6
I'm refugee from Sony Vegas slicing video for my YouTube channels.
Offline

Dieter Scheel

  • Posts: 100
  • Joined: Tue Feb 14, 2017 11:15 am
  • Location: Germany

Re: Yes, another h.264 post, but new concern for Resolve 15

PostFri Dec 14, 2018 11:06 pm

David Andrade wrote:"so dont use h.264...it's not professional" - but that sidesteps the fact that Resolve INCLUDES h.264 as a codec. So my argument to them was if its not professional, then why does Resolve have it.


You confuse delivery codec with editing or source codec. It is considered unprofessional to use low-bitrate h.264 material for editing or compositing because the codec is not NLE-friendly and each encoding (or trancoding) makes the visual quality worse. Cineform, ProRes or DnxHD are codecs that are NLE-friendly and the visual quality for each generation of encoding is alsmost stable.

But export codecs is a different beast - thats the codec which then makes the video file which you deliver to your customers or post on Vimeo or Youtube.

Using h.264 for editing is not really a good idea, especially on low-end computers. Using h.264 for delivery (aka export) is, of course, highly recommended - it is one of todays standard codecs.
Resolve Studio 16.1, Linux Mint 19.2, 32GB RAM, i7-6700K, RTX2070 8GB (435.21), Intensity Pro (11.4)
Offline
User avatar

Cary Knoop

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

Re: Yes, another h.264 post, but new concern for Resolve 15

PostFri Dec 14, 2018 11:14 pm

Dieter Scheel wrote:You confuse delivery codec with editing or source codec. It is considered unprofessional to use low-bitrate h.264 material for editing or compositing because the codec is not NLE-friendly and each encoding (or trancoding) makes the visual quality worse. Cineform, ProRes or DnxHD are codecs that are NLE-friendly and the visual quality for each generation of encoding is alsmost stable.

H.264 is not equivalent with low bitrate. With the same encoding quality, H.264 is just as good on regenerations as the codecs you mention.

With respect to it being "unprofessional to use low bitrate H.264 material", if that's all you get then that is all you have. Transcoding it will improve editing performance (cutting clips, moving clips, timeline seeking etc), but it has zero impact on quality or grading performance.
Offline

Dieter Scheel

  • Posts: 100
  • Joined: Tue Feb 14, 2017 11:15 am
  • Location: Germany

Re: Yes, another h.264 post, but new concern for Resolve 15

PostFri Dec 14, 2018 11:35 pm

Cary Knoop wrote:H.264 is not equivalent with low bitrate. With the same encoding quality, H.264 is just as good on regenerations as the codecs you mention.

Well, what I mean is that h.264 and the format how the frames are arranged is not edit-friendly. Of course, if you up the bitrate then you will not get that much picture degradation. But other codecs like Prores and
DnxHD are better suited in regard of being edit-friendly and have minimum compression artefacts.

Again, h.264 is good for watching or streaming a movie or TV show but not for editing. Technically you can but you shouldn't. But that might be only me, you can, of course, use whatever suits your needs :)

With respect to it being "unprofessional to use low bitrate H.264 material", if that's all you get then that is all you have. Transcoding it will improve editing performance (cutting clips, moving clips, timeline seeking etc), but it has zero impact on quality or grading performance.

That's exactly what I was saying. If h.264 is all you got for editing then you have to use it - no matter what bitrate or picture quality. But for all subsequent steps you should transode it to a better suited codec. That won't make your material visually better but it will make it easier for editing with almost no visual loss.
Resolve Studio 16.1, Linux Mint 19.2, 32GB RAM, i7-6700K, RTX2070 8GB (435.21), Intensity Pro (11.4)
Offline

RCModelReviews

  • Posts: 464
  • Joined: Wed Jun 06, 2018 1:39 am
  • Real Name: Bruce Simpson

Re: Yes, another h.264 post, but new concern for Resolve 15

PostSat Dec 15, 2018 2:16 am

Dieter Scheel wrote:Again, h.264 is good for watching or streaming a movie or TV show but not for editing. Technically you can but you shouldn't. But that might be only me, you can, of course, use whatever suits your needs :)

Sadly, it is forced upon many of us who aren't using cinema cameras.

Most "consumer/prosumer" cameras tend to use H264/5 as the codec when they write their files to storage.

While it *is* possible to transcode into another "professional" format before editing, that's just another step and a rather pointless (additional) transcode. ie:

H264->ProRes-->edit -->H264

versus

H264 -> edit ->H264

The more encoding/decoding that takes place, the worse the result n'est pas?
Resolve 15 Studio, Fusion 9 Studio
CPU: i7 8700, OS: Windows 10 (1709) 32GB RAM, GPU: GTX1060/6
I'm refugee from Sony Vegas slicing video for my YouTube channels.
Offline

Dave Andrade

  • Posts: 44
  • Joined: Wed Apr 20, 2016 2:11 pm

Re: Yes, another h.264 post, but new concern for Resolve 15

PostSat Dec 15, 2018 2:44 am

So, I've done some more testing and it appears to be dependant on the footage.

I used a longer clip and now I am getting 40something Mbps.
Having said that, using Handbrake, I can set the data rate to 80Mbps and it will come out as....80Mbps. And I am referring to the file that was well below the 10Mbps data rate I mentioned initially.

I guess its a moot point if the quality is all the same. If cramming 80Mbps of data into a 10 second clip, for example, doesnt improve anything over one with 8Mbps, then...."who cares".

Unfortunately, nothing I said before changes.

Premiere lets you set amounts and it gets "in the ballpark". Handbrake lets you set amounts and it's pretty much dead on. But Resolve lets you choose "best" and you get what you get. Is this what others are experiencing too?
Offline

Bryan Worsley

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

Re: Yes, another h.264 post, but new concern for Resolve 15

PostSat Dec 15, 2018 4:34 am

In Resolve, the 'Quality > Restrict To' bitrate setting is not a target (i.e. Average) bitrate, it is a limit that is placed on the Maximum bitrate - hence 'Restrict To'. When you choose 'Automatic > Best', that constraint is relaxed. In Handbrake and Premiere you are choosing a target (average) bitrate. MediaInfo reports the resulting average bitrate of the encoded stream.

Edit: As an illustration. I exported a 1080/50p clip (10sec) with high-complexity/hard to compress content to H264.mp4. First export I set the Quality to 'Automatic > Best'. Second export I set the Quality to 'Restrict To 80000 Kbps' (80Mbps). In both cases, the encoding profile was set to 'High'. Here are the reported bitrates:

Auto > Best i.e. Unconstrained
MediaInfo - Average: 261 Mbps (High@L4.2, 2 Ref Frames)
Elecard StreamEye - Average: 261.5 Mbps, Maximum: 268.5 Mbps, Minimum: 253.2 Mbps

Restricted to 80Mbps
MediaInfo - Average: 78Mbps (High@L5, 2 Ref Frames)
Elecard StreamEye: Average: 77.5 Mbps, Maximum: 82.7 Mbps, Minimum: 69.9 Mbps

As you can see when encoded without constraint the resulting bitrate is very high.

And then the same clip source clip (ProRes HQ) encoded to H264 (x264) with Handbrake. Target Average Bitrate - 80000 Kbps. Encoder Profile - High, Level - Auto. Two-pass. Turbo first pass. Preset - Slow.

MediaInfo: Average 80 Mbps (High@L5, CABAC/5 Ref Frames)
Elecard StreamEye: Average: 80Mbps, Maximum: 96.7 Mbps, Minimum: 72.7 Mbps

But look what happens when encoded in Constant Quality (Constant Rate Factor) mode down at CRF=2

MediaInfo: Average 427 Mbps (High@L5, CABAC/5 Ref Frames)
Elecard StreamEye: Average:429 Mbps, Maximum: 443.3 Mbps, Minimum: 418.4 Mbps
Offline

Jim Simon

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

Re: Yes, another h.264 post, but new concern for Resolve 15

PostSat Dec 15, 2018 5:06 pm

Dave Andrade wrote:Resolve lets you choose "best" and you get what you get. Is this what others are experiencing too?


That's because those are Constant Quality options, which is a better way to encode than either CBR or VBR.
Offline

Bryan Worsley

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

Re: Yes, another h.264 post, but new concern for Resolve 15

PostSat Dec 15, 2018 5:17 pm

Precisely, really the only case for targeting a particular (average) bitrate is to achieve a more or less predictable file size.
Offline

MishaEngel

  • Posts: 1073
  • Joined: Wed Aug 29, 2018 12:18 am
  • Real Name: Misha Engel

Re: Yes, another h.264 post, but new concern for Resolve 15

PostSat Dec 15, 2018 6:25 pm

Staxrip is the way to go for me for x(h).264 and x(h).265, it scales 95..100% on all 16c/32tr we have and when we want to, it can make use of hardware encoding/decoding for intel, AMD and NVidia GPU's. At the moment software encoding gives the best quality vs.size ratio and hardware encoding AMD/NVidia is just blazing fast.

Biggest missing part is that it can't encode Cineform (to my knowledge).
Offline

Bryan Worsley

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

Re: Yes, another h.264 post, but new concern for Resolve 15

PostSat Dec 15, 2018 10:53 pm

The Handbrake 'nightly builds' also have nvenc support, but I rarely use it myself. For transcoding to Cineform I use VirtualDub2 which has a native implementation of the Cineform SDK. On last inquiry about the prospect of integrating the Cineform encoder SDK in FFMPEG, the response was not enthusiastic - code compatibility issues.
Last edited by Bryan Worsley on Sun Dec 16, 2018 3:47 am, edited 2 times in total.
Online
User avatar

Marc Wielage

  • Posts: 6054
  • Joined: Fri Oct 18, 2013 2:46 am
  • Location: Hollywood, USA

Re: Yes, another h.264 post, but new concern for Resolve 15

PostSun Dec 16, 2018 2:09 am

David Andrade wrote:But here is my concern: Usually, the response is: "Well, in a professional program such as Resolve, you shouldn't be using a h.264 codec for....." - so on and so forth.

I've never said that H.264 (or H.265) is a bad distribution format. The problem is when you try use it for editing and color. Many online sources want to ultimately wind up with an H.264 or H.265 file for final delivery, and that's totally fine.

If you're not happy with the H.264 options currently available in Resolve, you could try using Avid Media Encoder or Apple Compressor, each of which works very well. In a pinch, you can also use Handbrake, which is free.

I agree with you that it would be nice if the range of options and picture quality of H.264 was better out of Resolve, and maybe that will eventually happen. My observation is that both Vimeo and YouTube generally re-encode everything you send them anyway, so I generally upload something simple like ProRes 422 LT and let the site do the H.264 encoding for me. There are some who make the argument that if you upload 4K, you stand a better chance of getting a higher bitrate even when the video is viewed in HD. For critical client viewing, I generally use Frame.io and upload 422LT, and the client has the option of downloading the actual unchanged 422LT file to view it on a better monitor.
marc wielage, csi • VP/color & workflow • chroma | hollywood
Offline

Dave Andrade

  • Posts: 44
  • Joined: Wed Apr 20, 2016 2:11 pm

Re: Yes, another h.264 post, but new concern for Resolve 15

PostMon Dec 17, 2018 1:59 pm

Thanks all!

I appreciate all the input.

As I mentioned before, I did fall in the trap of just accepting that others' experience with the h.264 export was just the way it is/was. I did have one export that wasn't the best quality, but looking back, that may have been an error with my selections, which I probably incorrectly attributed to Resolve.

I am going to run a few more tests, review the footage and check for macro-blocking and all that and probably upload something to my YouTube channel soon.

I'd love to see more users migrate to Resolve for editing, but I wasn't sure if the h.264 would be a hurdle. It appears that it isn't, which is good.
Offline

Jim Simon

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

Re: Yes, another h.264 post, but new concern for Resolve 15

PostMon Dec 17, 2018 4:01 pm

Dave Andrade wrote:probably upload something to my YouTube channel soon.


I agree with Marc on this one. H.264 is what you give to the client. Cineform, DNx and ProRes are better options for YouTube, Vimeo, etc.
Offline
User avatar

Cary Knoop

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

Re: Yes, another h.264 post, but new concern for Resolve 15

PostMon Dec 17, 2018 5:35 pm

Jim Simon wrote:H.264 is what you give to the client. Cineform, DNx and ProRes are better options for YouTube, Vimeo, etc.

Could not disagree more, there is no point in sending all-intra high bitrate encodings to YouTube you won't get anything out of it.

If you send H.264 50-60Mb/s for UHD and 12-18Mb/s for HD you should be fine, anything over that is waste.

For Vimeo it is similar except if you allow downloading (not possible with YouTube) and want to provide a higher quality source.
Offline

Ole Kristiansen

  • Posts: 182
  • Joined: Tue Nov 28, 2017 8:37 pm

Re: Yes, another h.264 post, but new concern for Resolve 15

PostMon Dec 17, 2018 6:24 pm

I believe in something else......

Some of the sharpest HD and UHD/4K content on Youtube mainly comes from an intra-frame workflow from beginning to end. Then upload an intermediate codec !
Offline

Dave Andrade

  • Posts: 44
  • Joined: Wed Apr 20, 2016 2:11 pm

Re: Yes, another h.264 post, but new concern for Resolve 15

PostMon Dec 17, 2018 7:06 pm

I think what Cary is saying is that the trade-off isnt there.

In other words, the longer wait times for the upload aren't translated into that much extra sharpness in the end result.

And sorry for the confusion. I meant a video about this subject. Not an actual video FOR YouTube. (although to be fair, I will probably end up editing it and exporting it out of Resolve, anyway)
Offline
User avatar

Craig Marshall

  • Posts: 938
  • Joined: Sun Apr 07, 2013 4:49 am
  • Location: Blue Mountains, Australia

Re: Yes, another h.264 post, but new concern for Resolve 15

PostMon Dec 17, 2018 9:17 pm

RCModelReviews wrote:... Most "consumer/prosumer" cameras tend to use H264/5 as the codec when they write their files to storage.

While it *is* possible to transcode into another "professional" format before editing, that's just another step and a rather pointless (additional) transcode. ie:

H264->ProRes-->edit -->H264

versus

H264 -> edit ->H264

The more encoding/decoding that takes place, the worse the result n'est pas?


Whilst that seems logical, it really depends on your workflow. For your particular business, working with a traditional 'Cinema' camera package might create more problems than it would solve so using modern cameras that record internally to Delivery codecs such as H264/5 is not an issue if the workflow is managed properly. There is software which will allow simple snipping of head/tail off H264 clips without re-rendering so these options might be a better proposition than Resolve for quick uploads where traditional multi-track editing is not required.

We work with a combination of cameras some of which record direct to ProRes 422 HQ and some which record direct to H264/5. In the case of the latter, we always transcode if only to get a clean, user assigned Timecode and embedded Reel Names so that cameras can be easily identified and a Conform from the client NLE to Resolve remains a painless exercise. We generally Master out of Resolve to an uncompressed file then make our various Deliverable from that using third party software.

IMO, any 'quality loss' from an immediate transcode from compressed H264/5 to a high bitrate editing codec is somewhat academic when compared to the advantages outlined and as for the time it takes, modern multi-threaded CPUs working with properly designed batch transcoders make it a non issue.
4K Post Studio, Freelance Filmmaker, Media Writer
Win10/Lightworks/Resolve 15.1/X-Keys 68 Jog-Shuttle/OxygenTec ProPanel
12G SDI Decklink 4K Pro/Calibrated 10bit IPS SDI Monitor
HDvideo4K.com
Offline
User avatar

Cary Knoop

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

Re: Yes, another h.264 post, but new concern for Resolve 15

PostMon Dec 17, 2018 9:33 pm

Ole Kristiansen wrote:I believe in something else......

Some of the sharpest HD and UHD/4K content on Youtube mainly comes from an intra-frame workflow from beginning to end. Then upload an intermediate codec !

The notion that spatio-temporal compression is less sharp or has cadence problems (as is often claimed) compared to spatial compression only with a similar quality rate is sheer nonsense.

Fact is that spatio-temporal compression actually needs far less bitrate than spatial compression for the same quality. Add to that that H.264/265 has far more refined spatial compression techniques than many all-intra codecs (ProRes, DNxHx) designed to optimize read and write speed instead of compression efficiency.

An NLE decodes every individual frame to an internal representation (in Resolve that is RGB float32) regardless if the codec uses temporal compression or not.

Also with respect to sharpness, almost all image compression techniques (DCT, Wavelet) compress the least sharp regions most and the sharpest region far less. Which make sharpness a rather bad criterium for comparing codecs and compression settings.

The disadvantage with spatio-temporal compression is that it is harder to edit (cutting, moving, timeline seeking etc) but it has no bearing on the quality.
Offline

Ole Kristiansen

  • Posts: 182
  • Joined: Tue Nov 28, 2017 8:37 pm

Re: Yes, another h.264 post, but new concern for Resolve 15

PostTue Dec 18, 2018 10:43 am

I do not think the best option is to record in h.264 - edit - re-encode in h.264 and then upload to YouTube - where again it will be re-encoded to h.264! That you do not agree - I'm fine!
Offline

Bryan Worsley

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

Re: Yes, another h.264 post, but new concern for Resolve 15

PostTue Dec 18, 2018 2:46 pm

Bryan Worsley wrote:The Handbrake 'nightly builds' also have nvenc support, but I rarely use it myself. For transcoding to Cineform I use VirtualDub2 which has a native implementation of the Cineform SDK. On last inquiry about the prospect of integrating the Cineform encoder SDK in FFMPEG, the response was not enthusiastic - code compatibility issues.


Maybe worth mentioning also that the current stable version (1.1.2) of Handbrake does not import Cineform or DNxHR files, but the 'nightly builds' do.
Offline

Dan Sherman

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

Re: Yes, another h.264 post, but new concern for Resolve 15

PostTue Dec 18, 2018 4:25 pm

If you are uploading Cineform, DNxHR, or ProRes you are just wasting time and/or bandwidth.

I posted results of testing I did a while ago for CRF h.265, but the findings apply to h.264 as well as constant bit-rate and muti-pass etc.
viewtopic.php?f=21&t=70234

for those that don't want to read the other thread the testing was as follows.

  1. Rendered a 1080p clip out of resolve as DNxHR 444 10-bit.
  2. Trans-coded the clip to h.265 444 10-bit, using various CRF values ranging from 0 (lossless) to 50 (horrendous).
  3. After uploading all the clips to YouTube and allowing it to process them, I pulled down all of the h.264 420 8-bit files that youtube uses to stream.

The following graph shows the SSIM of the h.265 uploads, and the YouTube h.264 streams compared to the DNxHR master. The important thing to note, is that beyond a certain point it doesn't mater what you give YouTube as their re-encoding just throws it out the window.
Image
X99-A II, 6850K 4.2 GHz, GTX 1070 FE (431.36), DDR4-2400 CL12-14-14 4x8 GB
Win 10 Pro 1809, Resolve Studio 16.1.0b.017
Offline
User avatar

Cary Knoop

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

Re: Yes, another h.264 post, but new concern for Resolve 15

PostTue Dec 18, 2018 4:32 pm

Excellent posting Dan!
Offline

Bryan Worsley

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

Re: Yes, another h.264 post, but new concern for Resolve 15

PostTue Dec 18, 2018 11:49 pm

Yes, nice test Dan.

Edit:
Dan Sherman wrote:[*]Rendered a 1080p clip out of resolve as DNxHR 444 10-bit.
[*]Trans-coded the clip to h.265 444 10-bit, using various CRF values ranging from 0 (lossless) to 50


Strictly speaking, CRF=0 is not lossless though. True lossless x265 encoding requires the 'lossless' parameter (-x265-params lossless=1) which specifies Main@L8.5@Main profile. In lossless mode x265 uses qp=4 internally in its RDO decisions.

https://x265.readthedocs.io/en/default/lossless.html

I see also on your graph that the SSIM score for the CRF=0 x265 transcode is a teeny bit lower than 1.0 (lossless). Out of interest did you also upload the DNxHR 444 10bit file to YouTube and measure the SSIM of the downloaded video ?

CRF=0, on the other hand, is lossless with 8bit x264 encoding when the source and output pix_fmts are the same and the encoder profile is left at 'Auto' (default) because it automatically evokes qp=0 with 'High-444-Predictive Profile'. But 10bit x264 encoding at CRF=0 is not lossless; 10bit 4:4:4 defaults to 'Hi444PP', 10bit 4:2:0 defaults to 'High10' and 10bit 4:2:2 defaults to to 'High422', but qp=0 is not activated and so has to be asserted in the command (-qp 0) for lossless encoding to take place.
Last edited by Bryan Worsley on Wed Dec 19, 2018 5:56 am, edited 3 times in total.
Offline

Trensharo

  • Posts: 280
  • Joined: Mon Jul 23, 2018 1:20 pm
  • Real Name: Nate Doucette

Re: Yes, another h.264 post, but new concern for Resolve 15

PostWed Dec 19, 2018 4:56 am

Dieter Scheel wrote:
Cary Knoop wrote:H.264 is not equivalent with low bitrate. With the same encoding quality, H.264 is just as good on regenerations as the codecs you mention.

Well, what I mean is that h.264 and the format how the frames are arranged is not edit-friendly. Of course, if you up the bitrate then you will not get that much picture degradation. But other codecs like Prores and
DnxHD are better suited in regard of being edit-friendly and have minimum compression artefacts.

Again, h.264 is good for watching or streaming a movie or TV show but not for editing. Technically you can but you shouldn't. But that might be only me, you can, of course, use whatever suits your needs :)

With respect to it being "unprofessional to use low bitrate H.264 material", if that's all you get then that is all you have. Transcoding it will improve editing performance (cutting clips, moving clips, timeline seeking etc), but it has zero impact on quality or grading performance.

That's exactly what I was saying. If h.264 is all you got for editing then you have to use it - no matter what bitrate or picture quality. But for all subsequent steps you should transode it to a better suited codec. That won't make your material visually better but it will make it easier for editing with almost no visual loss.


Most NLEs decode H.264 with hardware ono the timeline and for playback, so this is not oan issue in them.

If I transcode H.264 to ProRes 422LT, I get higher CPU usage than just editing the H.264 directly, and the scrubbing performance isn't really significantly better - even for 4K.

So I don't even bother. I think this is mostly an issue with Free Resolve. Resolve Studio will use Hardware to decode these CODECs, and most NLEs outside of Media Composer (and Lightworks, I think) have already implemented this (Premiere Pro, Final Cut Pro X, VEGAS Pro, Edius Pro, Video Pro X, etc).

A lot of NLEs also do smart rendering where they won't even re-encode unedited frames. They just copy them over, so the renders are fast for unedited video parts even without hardware encoding.

Resolve has never been amazing at exporting H.264 :-P

And it's well known that ~25Mbps is pretty much the max t for YouTube 1080p uploads. Most people will encode at ~18-20Mbps. There are tons of YouTube videos about this... pun intended :-P However, you get better 1080p results when streaming on YouTube (Quality-wise) if you upload at a higher resolution ;-) YouTube tends to generate better 1080p streams off of those, so a lot of people will record at 4k, edit on a 1440p timeline, and upload that to YouTube instead.
Offline

Uli Plank

  • Posts: 5075
  • Joined: Fri Feb 08, 2013 2:48 am

Re: Yes, another h.264 post, but new concern for Resolve 15

PostWed Dec 19, 2018 5:52 am

Just a note here: since Resolve was initially a high-quality grading system, everything is decoded into a very large full-color space. Editing was added later and, obviously, it is still assumed that you'll do some kind of grading. That's why there is no 'smart render' provision. You shouldn't experience any massive degradation if you export a high-quality mezzanine codec and encode in a specialized program, as has been widely discussed in the forum.
But if you insist on 'smart render' of GOP formats, Resolve might not be for you.
Resolve Studio and Fusion Studio
iMac 2017 Radeon Pro 580 8 GB VRAM and 32 GB RAM
Mac mini 16 GB RAM plus eGFX Breakway Radeon RX 580
Offline

Trensharo

  • Posts: 280
  • Joined: Mon Jul 23, 2018 1:20 pm
  • Real Name: Nate Doucette

Re: Yes, another h.264 post, but new concern for Resolve 15

PostWed Dec 19, 2018 6:27 am

Uli Plank wrote:Just a note here: since Resolve was initially a high-quality grading system, everything is decoded into a very large full-color space. Editing was added later and, obviously, it is still assumed that you'll do some kind of grading. That's why there is no 'smart render' provision. You shouldn't experience any massive degradation if you export a high-quality mezzanine codec and encode in a specialized program, as has been widely discussed in the forum.
But if you insist on 'smart render' of GOP formats, Resolve might not be for you.

Smart Render only works on unedited frames, so Resolve initially being a grading system is completely arbitrary. Most NLEs have Color Correction and grading aspects built into them, yet still offer this, because sometimes you want to use the unedited frames in the project. Everything isn't a feature film :-P

What smart render does is prevent wasted time by copying the unedited frames from the project clips into the final deliverable without re-rendering them... this means that you aren't wasting time re-rendering those frames, which is beneficial especially when working on high resolution (4K+) footage. Quality is not a huge factor with Smart Render, since it's just one more generation, anyways...

---

Frankly, the lack of ability to Transcode and Generate Optimized Media in the background is a much bigger issue for me than the lack of Smart Rendering. I'd also like an Ingest Workflow like Premiere Pro or Media Composer, where you can tell it to Generate Optimized Media or Transcode and Link to the new clip (with a specified target directory for them) on Import.

Part of the reason why so many people fall into the trap of trying to use H.264 directly in [Free] Resolve is because it's annoying to have to do all the other stuff manually, and have the NLE becomes unusable while generating the files; due to the lack of Background Processing for this stuff.

Unless, of course, I missed something.
Offline

Uli Plank

  • Posts: 5075
  • Joined: Fri Feb 08, 2013 2:48 am

Re: Yes, another h.264 post, but new concern for Resolve 15

PostWed Dec 19, 2018 2:00 pm

You missed FCP-X then ;-)
Resolve Studio and Fusion Studio
iMac 2017 Radeon Pro 580 8 GB VRAM and 32 GB RAM
Mac mini 16 GB RAM plus eGFX Breakway Radeon RX 580
Offline

Trensharo

  • Posts: 280
  • Joined: Mon Jul 23, 2018 1:20 pm
  • Real Name: Nate Doucette

Re: Yes, another h.264 post, but new concern for Resolve 15

PostWed Dec 19, 2018 4:45 pm

Uli Plank wrote:You missed FCP-X then ;-)

I meant "Unless I missed the option in DaVinci Resolve [settings] to turn this behavior [which seems to not exist] on."
Offline

Dan Sherman

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

Re: Yes, another h.264 post, but new concern for Resolve 15

PostWed Dec 19, 2018 6:34 pm

Bryan Worsley wrote: Out of interest did you also upload the DNxHR 444 10bit file to YouTube and measure the SSIM of the downloaded video ?


I did at the time, but i don't have the exact number anymore. however it did fall into .961 to .962 range like all the low crf uploads did.
X99-A II, 6850K 4.2 GHz, GTX 1070 FE (431.36), DDR4-2400 CL12-14-14 4x8 GB
Win 10 Pro 1809, Resolve Studio 16.1.0b.017
Offline

Jim Simon

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

Re: Yes, another h.264 post, but new concern for Resolve 15

PostWed Dec 19, 2018 8:37 pm

Cary Knoop wrote:there is no point in sending all-intra high bitrate encodings to YouTube you won't get anything out of it.



A visibly better end result is what I get out of it.
Offline

Jim Simon

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

Re: Yes, another h.264 post, but new concern for Resolve 15

PostWed Dec 19, 2018 8:40 pm

Dan Sherman wrote:If you are uploading Cineform, DNxHR, or ProRes you are just wasting time and/or bandwidth.


I've noticed I get better end results on YouTube with Cineform than with H.264.
Offline

Dan Sherman

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

Re: Yes, another h.264 post, but new concern for Resolve 15

PostWed Dec 19, 2018 11:12 pm

Jim Simon wrote:
Dan Sherman wrote:If you are uploading Cineform, DNxHR, or ProRes you are just wasting time and/or bandwidth.


I've noticed I get better end results on YouTube with Cineform than with H.264.


What type of h.264, all-I, ipb, constant bit rate, variable bit-rate, crf, 8-bit, 10-bit, 12 bit, 420, 422, 444? Just saying h.264, is like just giving the first ingredient in a recipe that has a dozen ingredients.



if you're just talking about h264 for YouTube out of resolve, well then yeah I don't use that either, because it's not very good Imo.

Also, you need to watch out for the placebo effect, and confirmation bias!
X99-A II, 6850K 4.2 GHz, GTX 1070 FE (431.36), DDR4-2400 CL12-14-14 4x8 GB
Win 10 Pro 1809, Resolve Studio 16.1.0b.017
Offline

Bryan Worsley

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

Re: Yes, another h.264 post, but new concern for Resolve 15

PostFri Dec 21, 2018 4:31 am

Inspired by Dan's test data I ran a similar series of tests myself, in part to validate my own practice.

1. Took an uncompressed (SGI) 2160/50p reference sequence ('Crowd Run'):

ftp://vqeg.its.bldrdoc.gov/HDTV/SVT_MultiFormat/2160p50_CgrLevels_Master_SVTdec05_/1_CrowdRun_2160p50_CgrLevels_MASTER_SVTdec05_/

2. Using VirtualDub2, transcoded the (10 sec) sequence (via v210) to Cineform 4:2:2 Filmscan 2 (= 'Best' in Resolve) avi.

3. Using FFMPEG, transcoded the Cineform file to x264 (8-bit 4:2:0) at CRF values ranging from 0 to 26. Command:
Code: Select all
 ffmpeg -i {Path}:\CrowdRun_CFFS2.avi -vcodec libx264 -threads 6 -tune film -preset slow -crf {value} -pix_fmt yuv420p -r 50/1 -x264opts colorprim=bt709 -x264opts transfer=bt709 -x264opts colormatrix=bt709  {Path}:\CrowdRun_x264.mp4

4. Recorded the bitrates and x264 profiles reported by Media Info. The CRF=0 encode defaulted to lossless High 4:4:4 Predictive@L5.2 (CABAC, 5 Ref frames). All of the other encodes defaulted to High@L5.2 (CABAC, 5 Ref frames).

5. Using FFMPEG, ran SSIM metrics on the x264 encodes with the Cineform file as reference. Recorded only the overall ('All') score.

6. Uploaded the Cineform and x264 transcodes to YouTube and used 4K Video Downloader to download the highest quality (original) 2160/50p VP9 (8bit 4:2:0) file. Recorded the bitrates of the downloaded files and ran SSIM tests, using the original Cineform file again as reference.

The results:

Image

Note: I prefer to express the SSIM scores as a percentage rather than a fraction.

The bitrates of the Cineform and x264 encodes are relatively high, but considering the high complexity content and the original uncompressed source this is not surprising.

Obviously x264 at CRF=0 is not lossless with respect to Cineform because the 10-bit 422 > 8bit 420 conversion is lossy.

As for the downloaded YouTube VP9 files, the pattern of results is not dissimilar to Dan's data with x265. I didn't go 'higher' (> lower quality) than CRF=26. Based on the SSIM scores there is a small incremental improvement in 'metric quality' going from CRF=26 to around CRF=14, but by CRF=10 it has 'maxed out' at 88.84, which is the same value obtained with the YouTube encode of the uploaded Cineform file. In other words, the maximum quality obtained on Youtube was less than that of a CRF=26 x264 encode.

Dan Sherman wrote:Also, you need to watch out for the placebo effect, and confirmation bias!

And now a subjective quality test (call it a festive quiz) for those with ESP. Here are links to the YouTube videos obtained with the uploaded Cineform file and two of the x264 transcodes, CRF=14 and CRF=26. I've labelled them arbitrarily A,B and C.





Obviously watch the original video in YouTube at 4K quality (2160 50p).

Which one looks best, and why ?
Offline

Dan Sherman

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

Re: Yes, another h.264 post, but new concern for Resolve 15

PostFri Dec 21, 2018 2:52 pm

Bryan Worsley wrote:And now a subjective quality test (call it a festive quiz) for those with ESP. Here are links to the YouTube videos obtained with the uploaded Cineform file and two of the x264 transcodes, CRF=14 and CRF=26. I've labelled them arbitrarily A,B and C.





Obviously watch the original video in YouTube at 4K quality (2160 50p).

Which one looks best, and why ?


Honestly, sitting in-front of a 23" 1080p monitor just watching YouTube feeds, I can't tell the difference.
X99-A II, 6850K 4.2 GHz, GTX 1070 FE (431.36), DDR4-2400 CL12-14-14 4x8 GB
Win 10 Pro 1809, Resolve Studio 16.1.0b.017
Offline

Trensharo

  • Posts: 280
  • Joined: Mon Jul 23, 2018 1:20 pm
  • Real Name: Nate Doucette

Re: Yes, another h.264 post, but new concern for Resolve 15

PostFri Dec 21, 2018 6:13 pm

Second video looks better. First and third have some extreme motion blurring and "jumpiness" going on. Especially the third video. Both of make my eyes physically hurt just looking at them.

Second video still blurs out while the camera is panning, but it looks better than the other two to me.
Offline
User avatar

Cary Knoop

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

Re: Yes, another h.264 post, but new concern for Resolve 15

PostFri Dec 21, 2018 8:08 pm

A is the CRF 26 upload
B and C are better and for all intents and purposes of similar quality (with C perhaps begin marginally better).

Here is a cropped and magnified (bi-cubic) ProRes triptych of A, B, and C composed out of the highest quality YouTube streams from A, B, and C:

https://www.dropbox.com/s/dr2hkqibms9s7 ... c.mov?dl=0
(download the file to view it in original quality!)

triptych.jpg
triptych.jpg (495.35 KiB) Viewed 3103 times
Offline

Bryan Worsley

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

Re: Yes, another h.264 post, but new concern for Resolve 15

PostFri Dec 21, 2018 10:32 pm

Yep,

A = x264 CRF 26
B = Cineform FS2
C = x264 CRF 14

But I can't say I notice a difference in motion cadence between the Cineform and x264 'converts' that Trensharo mentions. Was this watching the videos streamed on YouTube or did you download the files ?
Offline
User avatar

Cary Knoop

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

Re: Yes, another h.264 post, but new concern for Resolve 15

PostFri Dec 21, 2018 10:51 pm

Bryan Worsley wrote:But I can't say I notice a difference in motion cadence between the Cineform and x264 'converts' that Trensharo mentions.

Neither can I.
Offline

Dan Sherman

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

Re: Yes, another h.264 post, but new concern for Resolve 15

PostSat Dec 22, 2018 1:51 am

Bryan Worsley wrote:Was this watching the videos streamed on YouTube or did you download the files ?


This is the tool I use to pool down actual files.
https://www.h3xed.com/blogmedia/youtube-info.php

You have to be careful with YouTube, because even though you tell it you want one resolution it will some times display another one till it get enough of a buffer built. If you connection is bad it will actually jump between resolutions a lot.
X99-A II, 6850K 4.2 GHz, GTX 1070 FE (431.36), DDR4-2400 CL12-14-14 4x8 GB
Win 10 Pro 1809, Resolve Studio 16.1.0b.017
Offline

Bryan Worsley

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

Re: Yes, another h.264 post, but new concern for Resolve 15

PostSat Dec 22, 2018 5:11 pm

Thanks Dan. Yes, that's a very useful tool. Accessing the info requires 'Allow Embedding' to be turned on, which I didn't for these videos, and you need to rewrap the original WebM files, but that's no hardship. I like that it gives the frame rate variants for each resolution also. 4K Video Downloader does too, but it doesn't state the actual frame rate and you have to deduce it from the relative file size.

Yes, I wondered if Trensharo's observation about the motion characteristics might be bandwidth/buffer related, maybe reverting to the 25p variant, but if that were the case it would surely apply to all three videos.

I just can't see any difference in the motion cadence of the downloaded 2160/50p VP9 files from the Cineform and x264 uploads. But, one see's what one see's.
Next

Return to DaVinci Resolve

Who is online

Users browsing this forum: Google Feedfetcher, Marc Wielage and 52 guests