Poor H264 encoding quality in DaVinci

All what I said was- watch your RGB to YUV conversion in ffmepg (because you said you feed DPX into ffmpeg) as this is not problems free.
Whatever workflow you use it's irrelevant to the fact that this problem exists in ffmpeg (including latests build) and this is just my warning for the people.

The dark and mysterious world of codecs can be confusing.
In an effort to improve my understanding, a couple of more questions please.

x264 is an encoder only. How does Resolve decode h.264 for timeline edit (create missing frames)?
What is "two-pass" encoding. I've seen it used for BluRay as well. Is there any real quality difference.
What happens in the two passes?

H.264 has many file types (wrappers). If I want to convert a Resolve rendered UHD h.264 MOV to MP4 I can use a converter which re-encodes it, takes time (7fps) and, I assume, could lose some quality in the conversion process.

or I can use VLC to re-wrap it by
Select Media->Convert/Save, select files, Convert->Save, click "Create New Profile" icon, change container to MP4, mark keep original video and audio tracks and save the profile.
Re-wrap with VLC is almost instant. MediaInfo show a small change in the new file size(MOV=352MB MP4=347MB), same bitrate, - but I assume rewrapping is not the same as renaming and changing the file type from MOV to MP4????

Al

PS - How do I attach an image to my post?????

If ffmpeg is not perfectly optimized for DPX, that does not mean it fails with every codec or even that codec. But, there are multitudes of perfectly lossless pathways through ffmpeg (even libx264 has a lossless mode).

All this reminds me of the ProRes test grid that circulates on the web (don't have the link currently). Some programs introduce shifts, others are fine. Similarly, DR stinks at h.264 decoding. But none of these issues are indictments of any of the programs. You just need to learn your way around them. For example, I hate the fact that DR crashes on the M2TS files generated by one of my cameras, but I have a workaround. That is how professionals operate, not by FUD.

x264 is an encoder only. How does Resolve decode h.264 for timeline edit (create missing frames)?
What is "two-pass" encoding. I've seen it used for BluRay as well. Is there any real quality difference.
What happens in the two passes?

In the spirit of time, I will try to answer this question only.

I think we already answered that DR uses Microsoft's mpeg drivers for h.264 decoding and encoding. Interpolating "missing frames" is what decoding is all about. I recommend you read a primer on I, P, and B frames.

As for two-pass encoding, that is mainly for when you are targeting optical media delivery and you need to stay within specific bitrate and file size limitations. For example, DVD has a max bitrate of ~9 Mbps and a max size of ~4 GB. If you do the math, this means you can only fit about an hour of video on a DVD at the max bitrate when using CBR. If your movie is 90 minutes, you could lower the CBR to 6 Mbps to fit, but then you might bitrate starve some scenes with a lot of action while some scenes may not even need 6 Mbps. This is where two-pass encoding comes in. It is an optimization routine where the encoder figures out which scenes need lots of bitrate and which don't. This is the first pass. The second pass then performs the final encode allocating the bitrate as mapped from the first pass, all while making sure the file size does not exceed the target. The last thing you want is to spend several hours encoding a video for DVD, and the file is too large. The end result, which is called VBR, is a better looking encode versus what CBR could offer. Is it necessary for Bluray given the fatter bitrate and larger disc size? Maybe. Depends on the film. But 2-pass VBR encoding is slower than a one-pass strategy like CRF for x264 which allocates bitrate based on a target quality. Therefore, if you are delivering to the web where file size is not a constraint, that is often a better choice.

If ffmpeg is not perfectly optimized for DPX, that does not mean it fails with every codec or even that codec. But, there are multitudes of perfectly lossless pathways through ffmpeg (even libx264 has a lossless mode).

Well, read my message- it's very specific in terms of what is problematic. ffmpeg possibilities are huge and some parts work well, other not as you said. I did not say ffmepg is crap, don't use it (actually quite opposite) I've described very specific case, purely because you said that you feed ffmepg with DPX.

It's not about lossless modes at all, but ffmpeg being accurate for specific conversion tasks.

I've described very specific case, purely because you said that you feed ffmepg with DPX.

I think you are confusing me with Craig. I don't use DPX.

I've described very specific case, purely because you said that you feed ffmepg with DPX.

I think you are confusing me with Craig. I don't use DPX.

Ups, sorry. Yes.

I think you are confusing me with Craig...

and andrew is confusing all of us!

sure -- i got the point, why he is criticizing some issues in ffmpegs internal color transformations. but i still think, it would be more useful, to report this issues to the ffmpeg bug tracker and developer mailing lists. here in in this forum, it's just strengthen some vague general prejudices about the quality of open source software and hardly finds listeners, who can differentiate between en/decoding qualities and those other processing pipeline related tasks.

nevertheless it's an useful information, and some of us may have some benefit of being aware of it.

Feed YUV based source for x264 transcodes (or use zscale filter) and you are fine for this task
Nothing to be scared of or worry about

Sony MPEG4 is not a h264 replacement. It's an intermediate codec, the same what you have on SR tapes. It's on the ProRes, DNxHR level. 450Mbit (422) mode is very high quality, 225Mbit around ProRes HQ.

Good to know. thank's

OK at the risk of confirming my ignorance of codecs one more question please.

My input is h.264 mp4 HD, 2k and 4k
I need h.264 mp4 output.
Resolve doesn't do it and if Resolve's QT implementation of h.264 MOV is inferior what workflow do you guys suggest for best mp4 quality?
What format should I choose for export from my timeline and then convert to h.264 mp4 using Handbrake's x264 encoder for best mp4 quality?

Thanks

I usually use MeGUI for x264 encoding myself, but personally I would (and do) go with Cineform.avi (YUV 10-bit), assuming that you are exporting HD.

From my own quality metric tests (round tripping back to 4:2:0 YV12) , Cineform at High (Filmscan 1) quality gives consistently higher scores than DNxHD 10-bit or 8-bit, at least the Resolve implementation. You could nudge the quality up to near lossless (beyond 'visually lossless') with Best (Filmscan 2) quality but at the expense of much larger intermediary file sizes.

OK at the risk of confirming my ignorance of codes one more question please.

My input is h.264 mp4 HD, 2k and 4k
I need h.264 mp4 output.
Resolve doesn't do it and if Resolve's QT implementation of h.264 MOV is inferior what workflow do you guys suggest for best mp4 quality?
What format should I choose for export from my timeline and then convert to h.264 mp4 using Handbrake's x264 encoder for best mp4 quality?

Thanks

Cineform, DNxHD/R, ProRes...

....ProRes...

He's on Win10 x64...or was that wishful thinking ?

Generic answer

Thanks Andrew & Bryan

Resolve for Dummies:-
I normally use DNxHD (Win 10) Optimized Media for better timeline performance.
Would it be better/faster to render out using my Opt. Media files to DNxHD or render using my original h.264 files to DNxHD or Cineform?

Al

I assume you can render using optimised media as in this case most of the export will be just copying existing data. Keep codec the same as optimised media to make it faster.

Resolve for Dummies:-

Don't belittle yourself. The very fact that you are asking such questions shows otherwise.
BTW - is that book out ? I was looking for a copy

Thanks Bryan but but I'm just beginning to realise how little I know after many years of HD editing since I started using Resolve and got exposed to a forum of Pro video editors. I didn't even know there was a possible quality difference when encoding h.264 AVC.
Desktop editing from DV days to HD was painless as hardware followed Moore's law. Now with 4k and beyond, AVC and HEVC compression is testing the desktop limits for NLE software using long GOP codecs so I was introduced to the world of intermediate codecs like Cineform, GV HQX, and now Dnx. I do understand why they ease the timeline workload but it seems cumbersome having to decode files to low res proxies or much larger (10x) high res edit friendly codecs just to get realtime edit playback. As codecs appear to be mathematical I've often thought a GPU optimized might help as editing is still cpu bound and only effects have been gpu optimized.
I have no idea what a studio workflow must look like using pro cameras with RAW or low compression formats requiring huge storage and high transfer speeds. A 30 min 4k/UHD documentary for broadcast must be quite a challenge - then there's backup!

Cameras use hardware compression and I wonder if NLE software might be able to use the hardware decompression in latest Intel CPUs to accelerate AVC/HEVC decoding on the timeline.
Magix, who now own Vegas, are claiming 360 4K 10 bit HEVC editing on a Kaby Lake CPU.

Here is more on the graphics hardware encode/decode capabilities.
http://www.anandtech.com/show/10959/intel-launches-7th-generation-kaby-lake-i7-7700k-i5-7600k-i3-7350k/6

Final render software encoding will be better quality than hardware but render speed is less important than smooth timeline editing.

4k consumer cameras and SUHD TVs are affordable to us all but having to buy a $10k 10 core workstation to edit is beyond my reach.

In terms of performance here is an interesting Ryzen vs Intel benchmark for PremPro cc.
https://www.pugetsystems.com/labs/articles/Premiere-Pro-CC-2017-AMD-Ryzen-7-1700X-1800X-Performance-909/

It would be interesting to see similar results with Resolve.

Thanks for your patience with us newbies.

Al

GPU are good when you can run many (I mean a lot, e.g. 2000) of simultaneous processes in parallel to speed up some task. Unfortunately typical video codecs are not designed for this and even 16 simultaneous decoding task are difficult. Read here:
http://www.nvidia.com/object/what-is-gpu-computing.html
What current GPUs have to help with some video tasks are special (basically separate) unit which are designed from ground just for video tasks acceleration. There are also possibilities to move some parts of video decoding/encoding tasks into generic GPU processing (OpenCL etc), but these have huge limitations.

Overall problem is quite simple: you want amazing video at tiny size, so it gets compressed a lot using very advanced math which is computing intensive (h264, h265...). Because we jumped with frame size a lot it means data is growing massively, so we need better and better compression (or bigger storage). These codecs can shrink source e.g. 50-100x and still deliver fairly good visual quality.

Another side are uncompressed formats with image sequences included, e.g. DPX, EXR etc. These normally don't require any (or much of CPU decoding) as they are uncompressed. Frames can be read and pushed directly to GPU for processing. Great, but we end up with crazy bandwidth (e.g. 2Gbytes/sec) needs and file sizes!

Intermediate codecs are in-between. They are smaller than uncompressed (typically e.g. 5x compressed), but also in the same time math is fairly simple, so they don't need high decoding CPU power. It's up to user to find his golden spot. Big places use in most cases e.g. DPX, EXR and invest a lot in storage and network.

It's up to user to find his golden spot.

And that includes deciding yourself whether the quality of H264 output from Resolve meets your needs or not. If it is simply that Resolve outputs H264.mov and you need mp4, as you indicated earlier:

My input is h.264 mp4 HD, 2k and 4k
I need h.264 mp4 output.
Resolve doesn't do it and if Resolve's QT implementation of h.264 MOV is inferior what workflow do you guys suggest for best mp4 quality?

... converting ('re-wrapping') mov to mp4 is a trivial matter, accomplished with a simple ffmpeg command line, if you are so inclined, and easily done with VLC player: e.g.

Edit: You could also do it with Handbrake:

https://www.groovypost.com/howto/convert-mov-mp4-m4v-mkv-files-transcode/

Thanks Bryan,

I did mention in my post above on Mar 07 that I'm using VLC to "re-wrap" my h.264 MOV to MP4.
"Re-wrap with VLC is almost instant. MediaInfo show a small change in the new file size(MOV=352MB MP4=347MB), same bitrate"
It is super fast compared to converting with Handbrake and in theory re-wrap should have no quality loss.
So, my next question on best workflow is:
1) If I render out to a "near lossless" intermediate codec like Cineform or Dnx from my original MP4 camera clips (as recommended above) and then convert to h.264 MP4 using Handbrake's x.264 there should be a small quality loss due to the two file conversions involved.
2) If I use Resolve to render out my h.264 MP4 to Resolve h.264 QT MOV and simply re-wrap it to MP4 using VLC will the quality be any worse? It is an easier and faster workflow for me.

Thanks Andrew,
Regarding performance I strayed off topic from h.264 quality so I will start a new thread.


Al

So, my next question on best workflow is:
1) If I render out to a "near lossless" intermediate codec like Cineform or Dnx from my original MP4 camera clips (as recommended above) and then convert to h.264 MP4 using Handbrake's x.264 there should be a small quality loss due to the two file conversions involved.
2) If I use Resolve to render out my h.264 MP4 to Resolve h.264 QT MOV and simply re-wrap it to MP4 using VLC will the quality be any worse? It is an easier and faster workflow for me.

Using ffmpeg or x264 has many more encoding options than using Resolve's built-in encoder. So option 1 is the best (HandBrake uses ffmpeg).

Deleted - Duplicate post

Thanks Bryan,
I did mention in my post above on Mar 07 that I'm using VLC to "re-wrap" my h.264 MOV to MP4.

Sorry, missed that. So much for the speed-reading course

"Re-wrap with VLC is almost instant. MediaInfo show a small change in the new file size(MOV=352MB MP4=347MB), same bitrate"

That's just the container.

It is super fast compared to converting with Handbrake and in theory re-wrap should have no quality loss.

Correct.

(HandBrake uses ffmpeg).

True, but it's actually is a mencoder front-end:

http://stackoverflow.com/questions/5914078/ffmpeg-vs-mencoder

So, my next question on best workflow is:
1) If I render out to a "near lossless" intermediate codec like Cineform or Dnx from my original MP4 camera clips (as recommended above) and then convert to h.264 MP4 using Handbrake's x.264 there should be a small quality loss due to the two file conversions involved.
2) If I use Resolve to render out my h.264 MP4 to Resolve h.264 QT MOV and simply re-wrap it to MP4 using VLC will the quality be any worse? It is an easier and faster workflow for me.

I think you'll find that x264 files from Handbrake are significantly better h.264 output than Resolve produces at similar data rates -- a difference far more significant and obvious than any loss from converting to an intermediate codec. And you can use much lower data rates in Handbrake than in Resolve, for same or better quality, if file size is of issue.

1) would be my choice.

I think you'll find that x264 files from Handbrake are significantly better h.264 output than Resolve produces at similar data rates -- a difference far more significant and obvious than any loss from converting to an intermediate codec. And you can use much lower data rates in Handbrake than in Resolve, for same or better quality, if file size is of issue.

I think there is consensus on that. I was just encouraging Al to satisfy himself on that score.

It's up to user to find his golden spot.

And that includes deciding yourself whether the quality of H264 output from Resolve meets your needs or not.

I think there is consensus on that. I was just encouraging Al to satisfy himself on that score.

I can't seem to make anyone happy here, lately.... In all honesty, I didn't get to your post, it was a direct response to Al. Maybe time for my forum vacation....

Heck John, no please don't get me wrong. I merely said that to avoid any misinterpretation of my earlier comment i.e. that I was inferring the quality of H264 rendering is up to snuff.

Actually, I was about to write "Yes I quite agree with you.....

But then thought to myself "Well, from the foregoing discussion, I think that's pretty much been established, and what prompted this thread in the first place" and so changed it to "I think there is consensus on that". I wasn't trying to be smug, although I can see how it could come across that way.

So perhaps I should be more circumspect in the way I phrase things.

No harm done ?

I think you'll find that x264 files from Handbrake are significantly better h.264 output than Resolve produces at similar data rates -- a difference far more significant and obvious than any loss from converting to an intermediate codec. And you can use much lower data rates in Handbrake than in Resolve, for same or better quality, if file size is of issue.

1) would be my choice.

Thanks John,
"the more I learn, the less I know" as the saying goes. I understand x264 is the best decoder but always thought higher bitrate (data rate?) = equal better quality at least up to the source file h.264 bitrate - and had no idea Handbrake x264 can produce same quality at lower data rates and thus smaller file sizes than Resolve. (The file size challenge I was referring to was that of the decompressed intermediate codec and possible higher transfer rates needed for edit).
This is great info for me and I'm pretty sure it's not in the Resolve manual
To take it one step further would I be incorrect to assume that my next desktop upgrade need not be an $1800 10 core i7 cpu which may still struggle with 4k h.264 on the timeline - but maybe a cheaper 4 core i7-7700k with another 1 TB SSD for my resolve projects and convert everything to an intermediate codec prior to edit like DNx or Cineform to get both improved timeline performance and render out to the same codec for better quality and use Handbrake for my h.264 mp4??
Projects may be larger to archive but HDD space is cheap.

John/Bryan - I feel I'm to blame for any misunderstanding here. I sincerely appreciate your replies and any confusion is due to my lack of codec knowledge. As I mentioned before, this is my first exposure to a pro editors forum and I'm amazed at the depth of knowledge shown in this thread. Thanks again
Al

Forget about h264 if you want to work with Resolve.
h264 is not a good choice anyway as a NLE/grading working format.
As you said- disks are relatively cheap, so build bigger/faster storage and transcode to ProRes, Cineform or DNxHR (or use optimised media/smart caching).

Thanks Andrew -
Seems like Cineform is first choice for the timeline and output.
I posted a few more questions in the Resolve performance thread.
Al

I put together some test data, in part to validate my own workflow for HD-AVC source material, which I thought might be of interest in this context.

I used quality metrics (SSIM, PSNR) to compare the "pass-through" quality efficiency of rendering to Resolve QT H264 (at different quality levels) vs exporting to Cineform (FilmScan 1) as an intermediate for external encoding to x264 (with MeGUI):

https://www.datafilehost.com/d/82ac051e

The table footnotes hopefully provide adequate explanation of the test set-up.

The results well illustrate the superior quality efficiency of x264, especially at the type of bitrates one would normally target for final delivery; bearing in mind that an Unrestricted Constant Quality (CRF) x264 profile was used for these tests and so was not subject to the added constraints that are applied when encoding for certain delivery platforms, such as Blu-ray and other hardware.

For anyone not familiar with SSIM and PSNR quality measures, here's a little background from the AVISynth plugin documentation:

https://avisynth.org.ru/docs/english/externalfilters/ssim.htm

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

Of course, at the end of the day what matters is the perceived visual quality of the delivered product, but I have always found SSIM to be a very useful measure for quantifying fine differences in quality efficiency. Generally speaking at SSIM scores of 0.9 (90%) and above we are in the 'visually lossless' domain, 100% being lossless.

BTW Al, I was going to include results for x264 encoded with Handbrake, using the same x264 profile as in the MeGUI tests, but I'm having an issue opening the x264 files (m4v remuxed to mp4) with the AVISynth decoder used in these tests. If I manage to sort that, I'll post the results.

Thanks Bryan
Wow that's an analysis I didn't know was possible.
I understand your workflow which is what I was planning to do.
I did a visual test - MP4>Cineform>Resolve (no editing)>Cineform>MP4 on a 4k 8bit source clip.
I used Vdub Filter Mod as suggested by Andrew with Cineform set to Medium and pixel format set to YUY2 (8 bit). Then Cineform>h.264 using Handbrake's x264.
I visually compared result to source and it "looked good" (subjective) - but I see your tests show SSIM is below 90 with Cineform set to Medium indicting a quality loss.

Look forward to your final results.

Would it be possible:
1) to compare the Cineform workflow you used to h.264>Resolve>Resolve QT H.264 MOV>Re-Wrap to MP4 to see how poor Resolve h.264 really is?
2) to compare Resolve h.264 output with the same clip to Pr Pro output?
3) to compare to Resolve using Optimized Media DNx > Output to Dnx > DNx >h.264 to your Cineform workflow? ie - instead of transcoding camera source use h.264 media, optomize to DNx format the render out to DNx (I'm not sure which Dnx option as an intermediate would give best results).

I still have a workflow problem using much the larger Cineform files in my Media Bin.
The saved resolve Project is Much larger than if I had the h.264 files in my bin.
To archive the project I need my source MP4 files, Vdub batch conversion settings, my Cineform source files from Vdub, the saved Resolve edit project, the Cineform rendered out file and the Handbrake h.264 MP4 - which gets kid of messy and needs a lot of space.

Workflow using Optimized Media seems easier in 3) above as I only have to backup my much smaller h.264 source, my saved Resolve project, and my output files.
If I need to return to my archived project, all I need to do is open my saved project in Resolve and re-generate Optimized Media??
Seems the obvious solution would be for Resolve to add Cineform as an optimize option.

My thinking may be wrong - so please correct me.

Thanks again for all your work.

Al

No harm done ?

No worries; I unwisely jumped into this thread long after the movie had spooled, and had no idea of the ground it had covered. And the question seemed so innocent.....

I put together some test data, in part to validate my own workflow for HD-AVC source material, which I thought might be of interest in this context.

I used quality metrics (SSIM, PSNR) to compare the "pass-through" quality efficiency of rendering to Resolve QT H264 (at different quality levels) vs exporting to Cineform (FilmScan 1) as an intermediate for external encoding to x264 (with MeGUI):

https://www.datafilehost.com/d/82ac051e

The table footnotes hopefully provide adequate explanation of the test set-up.

The results well illustrate the superior quality efficiency of x264, especially at the type of bitrates one would normally target for final delivery; bearing in mind that an Unrestricted Constant Quality (CRF) x264 profile was used for these tests and so was not subject to the added constraints that are applied when encoding for certain delivery platforms, such as Blu-ray and other hardware.

Excellent report Bryan, thanks for sharing!

For added constraints (maximum momentary bitrate, maximum file size) X264/ffmpeg works great as well by using 2 pass encoding and additional settings.

Wow that's an analysis I didn't know was possible.

I assure you it's easy to do, especially if you are already set up for AVISynth processing. Actually, you can do the same with ffmpeg and generate the SSIM and PSNR values simultaneously, but I found some variance between ffmpeg builds and so still prefer to do it this way. It is rather time consuming though.

I understand your workflow which is what I was planning to do.

That's largely why I posted the data; I thought it might help you better understand the reason why this approach has been advised.

I did a visual test - MP4>Cineform>Resolve (no editing)>Cineform>MP4 on a 4k 8bit source clip.
I used Vdub Filter Mod as suggested by Andrew with Cineform set to Medium and pixel format set to YUY2 (8 bit). Then Cineform>h.264 using Handbrake's x264.
I visually compared result to source and it "looked good" (subjective) - but I see your tests show SSIM is below 90 with Cineform set to Medium indicting a quality loss.

No, I transcoded and rendered to Cineform at High quality (FilmScan1) in these tests. The only 'Medium' there was one of the series of quality settings I tested for Resolve QT H264 output.

That said, even at HD resolution, Cineform at Medium quality will still give very good results and generally speaking you would be hard-pressed to notice a difference between Medium and High (FilmScan 1), and even less so (if at all) between High and Best (FilmScan 2). The reason why Andrew recommend Medium quality for your 4K material, I would assume, is because you stand a better chance of managing the transcodes on the Resolve timeline. As for setting the (compresssor) pixel format to YUY2 (8-bit) in VDub FilterMod - that's necessary because it will default to the default decode pixel format (YUV420-709) otherwise and throw an error; Cineform only accepts rgb16, rgb24, rgb32, YUY2 or v210 input.

I do the same when transcoding 8-bit 4:2:0 material to Cineform via AVISynth and 'regular' VirtualDub. I use AVISynth to convert decode YV12 to YUY2 and then 'Fast Recompress' in VirtualDub to avoid intermediary conversion via RGB. The only thing I find about Cineform.avi files encoded with VDub is that, for some reason, Resolve doesn't recognize them... but does after remuxing to mov. Have you found this ?

There was also an issue with VDub FilterMod where the Cineform configuration settings kept reverting back to default, but I see that has been fixed in the latest update (version 38919).

Look forward to your final results.

Yes, as regards:

BTW Al, I was going to include results for x264 encoded with Handbrake, using the same x264 profile as in the MeGUI tests, but I'm having an issue opening the x264 files (m4v remuxed to mp4) with the AVISynth decoder used in these tests. If I manage to sort that, I'll post the results.

Turns out the issue was not with the Handbrake x264 files per se. It was a bug in the MeGUI tool (File Indexer) that I use for automatically loading clips in AVS scripts which appeared in the last MeGUI update. Rolling back to the pre-update (for now), I've tested the Handbrake x264 files encoded at CRF 14, 16 and 18. Here's an amended table including the Handbrake results:

https://www.datafilehost.com/d/9ecc654a

As you can see, the Handbrake x264 give slightly lower metric scores than the equivalent MeGUI x264 encodes, but there could be any number reasons for that - x264 build, decode/conversion>YV12 efficiency ? I wouldn't read too much into it.

Bear in mind also that these tests were done with just one HD-AVC clip as the source and there are various factors that can wildly affect the outcomes, not least the content of the test material - the fidelity, complexity and degree of motion, all profoundly impact the compression/encoding efficiency especially with x264 in unrestricted Constant Quality (CRF) mode. Even something as bland as a slow pan across a pebble beach, or rolling surf can send the bitrate up.

So I wouldn't at all hold to this particular set of results as a reference for predicting what quality efficiency outcome (in terms of metric scores) can expected be at a particular encode quality setting.

Also, in these tests I used the original native HD-AVC clip as the reference clip for the metric analyses so as to represent the overall efficiency of the process chain. Taking the MeGUI x264 file encoded at CRF14 for example. There it gave SSIM and PSNR scores of 91.84 and 43.00. Had I used the Cineform export file as a reference the scores would actually be lower - SSIM 91.31, PSNR 42.70 - because the Cineform file needs to be decoded and converted to YV12 to perform the test. And if I encode the original HD-AVC clip directly to x264 at CRF14, the scores will obviously be higher - SSIM 93.69, PSNR 44.92. Yet I doubt very much that you would able to discern any visible difference between the two encodes; they are both very high quality.

In addition what these metrics can't account for is the psycho-visual element of x264 CRF "Constant Rate Factor" encoding, as explained quite nicely in layman's terms here:

http://slhck.info/video/2017/02/24/crf-guide.html

So it could be argued that these quality metrics actually underestimate the visual perception of quality. In fact x264 can be tuned for optimal SSIM or PSNR efficiency, but it is at the expense of fettered CRF encoding. I chose not to in these tests.

Would it be possible:
1) to compare the Cineform workflow you used to h.264>Resolve>Resolve QT H.264 MOV>Re-Wrap to MP4 to see how poor Resolve h.264 really is?

I did also create a parallel set of x264 encodes using the native HD-AVC source clip for input, but haven't yet run the metric tests on the full set. The several Resolve QT H264 files I have tested do give slightly higher SSIM values (around +0.01 or +1% higher) than the equivalent renders produced with the Cineform transcode for input, but that's only to be expected - there is inevitably a 'quality hit' when transcoding to Cineform and again when converting back to 8-bit YV12. The Cineform (FilmScan 1) transcode used in these tests, for example, gave an SSIM score of 96.62 and a PSNR score of 46.28 relative to the native source clip. Transcoding at FilmScan 2 (Best) quality level increased that to SSIM 98.09 and PSNR 47.61, which is way beyond 'visually lossless'.

What's more relevant is how the Resolve H264 and Cineform export>x264 encodes compare using the same Resolve input, and the results already show that.

Actually, if you look at the native clip>Cineform (FilmScan 1) transcode and the export Cineform file (FilmScan 1) produced when the native clip is used for input, they have exactly the same SSIM and PSNR scores and are nigh on bit identical 453,994,044 vs 453,994,054 bytes i.e. the intrinsic 'pass-through' efficiency of the Resolve engine is effectively lossless.

2) to compare Resolve h.264 output with the same clip to Pr Pro output?

I'm not sure I follow what you are saying here. What's Pr Pro?
Edit: Ah, OK, Premiere Pro. Well that could apply to any NLE, but then you are comparing different process chains, not just the quality of H264 encoding per se - apples and oranges really. Surely the point is "if the quality of Resolve's own H264 rendering format is deemed sub-standard, what are the alternatives for external H264 encoding via an export intermediate" ? I guess you could use quality metrics (with the chosen export intermediate as reference) to compare x264 with Adobe's Main Concept H264 implementation via AME, if you were so inclined. Me not.

3) to compare to Resolve using Optimized Media DNx > Output to Dnx > DNx >h.264 to your Cineform workflow? ie - instead of transcoding camera source use h.264 media, optomize to DNx format the render out to DNx (I'm not sure which Dnx option as an intermediate would give best results).

I understand your incentive for wanting to do that (based on your further comments - below), but I'm afraid I wouldn't have the time to devote to such an exercise. Like I said, running these tests is quite time consuming.

If you want to get into metric testing yourself, here are ffmpeg commands for SSIM and PSNR

Code: Select all

#SSIM:
ffmpeg -i  [Test] -i [Ref] -lavfi  ssim="stats_file=ssim.log" -f null -
#PSNR:
ffmpeg -i  [Test] -i [Ref] -lavfi  psnr="stats_file=psnr.log" -f null -
#SSIM and PSNR simultaneously:
ffmpeg -i  [Test] -i [Ref] -lavfi "ssim="stats_file=stats_ssim.log";[0:v][1:v]"psnr="stats_psnr.log" -f null -
#SSIM and PSNR - no log file:
ffmpeg -i  [Test] -i [Ref] -lavfi  "ssim;[0:v][1:v]psnr" -f null -

#Where [Test] and [Ref] are the directory paths and names (with extension) of the Test and Reference clips.

Edit: There are also some software for video quality assessment:

https://superuser.com/questions/338725/compare-two-video-files-to-find-out-which-has-best-quality

I used an early version of the free MSU Quality Measurement Tool years back for SD material. But for HD/4K video you'd need the Pro version which will put you back $1000.

I still have a workflow problem using much the larger Cineform files in my Media Bin.
The saved resolve Project is Much larger than if I had the h.264 files in my bin.
To archive the project I need my source MP4 files, Vdub batch conversion settings, my Cineform source files from Vdub, the saved Resolve edit project, the Cineform rendered out file and the Handbrake h.264 MP4 - which gets kid of messy and needs a lot of space.

Workflow using Optimized Media seems easier in 3) above as I only have to backup my much smaller h.264 source, my saved Resolve project, and my output files.
If I need to return to my archived project, all I need to do is open my saved project in Resolve and re-generate Optimized Media??
Seems the obvious solution would be for Resolve to add Cineform as an optimize option.

I think the other members would be better qualified to speak to that. I've only recently started using Resolve and haven't even used Optimized Media.

Sorry for the long winded post, but I'm glad the test results I posted were helpful.

Excellent report Bryan, thanks for sharing!

For added constraints (maximum momentary bitrate, maximum file size) X264/ffmpeg works great as well by using 2 pass encoding and additional settings.

You're welcome.

Thanks, yes, I do use also ffmpeg (libx264). Sometimes though I might want to do a little post export processing with AVISynth filters/scripts (denoising/contra-sharpening for example), in which case I'm more inclined to use MeGUI. Either way, I'm pretty much sold on single-pass Constant Quality (CRF) x264 encoding these days. There again I'm usually not concerned with file size constraints.

My current Resolve Studio workflow...

Any h264 renders = testing purposes only, view and delete.

I usually render out 16bit tif sequences.

These numbered files need a "LRT_" prefix, for the following program to work...!

https://www.dropbox.com/s/lrx1smy061m4a ... o.jpg?dl=0

Lots of options...

kc

What H264 encoder does LRTimeLapse use - MainConcept ?

General
Complete name : T:\Sunrise_ProRes-444_4KUHD_23.976_UHQ++.mov
Format : MPEG-4
Format profile : QuickTime
Codec ID : qt 0000.02 (qt )
File size : 1.51 GiB
Duration : 11 s 679 ms
Overall bit rate mode : Constant
Overall bit rate : 1 107 Mb/s
Encoded date : UTC 2017-03-16 01:24:55
Tagged date : UTC 2017-03-16 01:24:55
Writing application : Lavf57.66.101

Video
ID : 1
Format : ProRes
Format version : Version 0
Format profile : 4444
Codec ID : ap4h
Duration : 11 s 679 ms
Bit rate mode : Constant
Bit rate : 1 107 Mb/s
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (23976/1000) FPS
Chroma subsampling : 4:4:4
Scan type : Progressive
Bits/(Pixel*Frame) : 5.567
Stream size : 1.51 GiB (100%)
Writing library : Lavc
Language : English
Encoded date : UTC 2017-03-16 01:24:55
Tagged date : UTC 2017-03-16 01:24:55

That's ProRes

AVC Software Encoders

OK just found a simple comparison of AVC software encoders. Easy to see why x264 is considered best and Main-Media next:

https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC
See the section "Software encoders" and the table "AVC software implementations"

Note the Quick Time implementation appears to be one of the worst. Is that what Resolve is using??

Next - and a bit off topic - I have seen info claiming that h.265 HEVC produces better quality 1080p than h.264. I know it's half the file size as less than half the bitrate for same quality - but better quality??

Also saw a comparison of h.265 encoders HEVC vs VP9 and VP9 looks very good.
Why aren't NLEs using royalty free VP8 and VP9 for h.264 and h.265 more??
Al

Thanks again Bryan -
My apologies for all the questions but your comprehensive reply is greatly appreciated

I'm having a hard enough time learning Resolve but never dreamed an in-depth understanding codecs would affect the quality of my editing.

You guys all amaze me - Thanks again for the info and your time.

Al

The world fastest video codec leaving any other codec dimensions behind
https://www.cinegy.com/index.php/produc ... -8k-beyond

A gpu based codec for 8k and beyond??
Is this the timeline solution we've been waiting for?

Comments please

Thanks again Bryan -
My apologies for all the questions but your comprehensive reply is greatly appreciated

Well I'm glad you found it comprehensive. I thought it rather long-winded myself. I try to be brief but I'm often driven by this need to explain things to the full. Whether that's a blessing or a curse, I guess depends on the reader's perspective.

I'm having a hard enough time learning Resolve but never dreamed an in-depth understanding codecs would affect the quality of my editing.

I'm quite new to Resolve myself, but it does pay to have a firm grasp of these formats and how they behave in the particular system you are working with.

On that note:

3) to compare to Resolve using Optimized Media DNx > Output to Dnx > DNx >h.264 to your Cineform workflow? ie - instead of transcoding camera source use h.264 media, optomize to DNx format the render out to DNx (I'm not sure which Dnx option as an intermediate would give best results).

I understand your incentive for wanting to do that (based on your further comments - below), but I'm afraid I wouldn't have the time to devote to such an exercise. Like I said, running these tests is quite time consuming.

I am looking into this as and when I have time, largely because I too need to establish a manageable native 4K workflow. I'll post my findings and conclusions when I'm done, but there are some aspects of the behavior of Cineform and DNxHR that have come to light that I need to work through.

My inclination at this point - go with native 4K input and project, generate optimized media DNxHR-HQX at half-res (or less), and render out to DNxHR-HQX at original (project) res as your exchange intermediate for encoding to x264 with Handbrake or whatever. That's assuming of course that you do want to preserve 4K export. Don't even think about down-scaling as an HD project per se and rendering out 4K.

The world fastest video codec leaving any other codec dimensions behind
https://www.cinegy.com/index.php/produc ... -8k-beyond

A gpu based codec for 8k and beyond??
Is this the timeline solution we've been waiting for?

Comments please

Groan...what's this one now ? Lots of hype but no real specifics. Is it actually a "codec" i.e. a video compression format with encoder and decoder, or what ?

Not sure here is the best place to post this though - more a subject for the Off-Topic forum section ?

Also saw a comparison of h.265 encoders HEVC vs VP9 and VP9 looks very good.
Why aren't NLEs using royalty free VP8 and VP9 for h.264 and h.265 more??
Al

I think VP8 is really not a player in the field.

VP9 is a great delivery codec, and, as you say, is royalty free. But VP9 is very processing heavy and completely unsuitable as an editing codec.

The world fastest video codec leaving any other codec dimensions behind
https://www.cinegy.com/index.php/produc ... -8k-beyond

A gpu based codec for 8k and beyond??
Is this the timeline solution we've been waiting for?

Comments please

Groan...what's this one now ? Lots of hype but no real specifics. Is it actually a "codec" i.e. a video compression format with encoder and decoder, or what ?

Not sure here is the best place to post this though - more a subject for the Off-Topic forum section ?

It's modern codec- quite different than others and this should work well in Resolve as it's GPU based. You read file, push data to GPU for decoding and Resolve processing.
I'm just worried it will die if big names won't support it (and they won't as there is no money there for them).
Cinegy is quite well known company in broadcast world, but this maybe not enough.