Blackmagic Forum

(Nvidia cards only)

The below takes any input supported by FFMPEG and converts it into lossless h264 for 8bit or lossless h265 for 10bit, both with 24bit PCM audio.

Chroma subsampling will stay the same as input. If you want to force 444 add -pix_fmt yuv444p for 8bit and -pix_fmt yuv444p16 for 10bit. I can't think of a situation that might be sensible, though.

If you want the audio format to stay untouched use -c:a:0 copy instead of -c:a:0 pcm_s24le

Add -g 1 to use I frames only. It increases bitrate by about 35% on high motion footage for me, but seeks instantly in Resolve.

8bit source :

Code: Select all

ffmpeg -i in.whatever -c:a:0 pcm_s24le -c:v h264_nvenc -preset lossless out.mov

10bit source:

Code: Select all

ffmpeg -i in.whatever -c:a:0 pcm_s24le -c:v hevc_nvenc -preset lossless out.mov

If the source is not 10bit you will get 8bit. For me it's about 8 times faster than encoding ProRes HQ.

I don't think free Resolve version will read lossless h264 files.
Your command is also only for those with Nvidia GPU.

Use of long GOP h264 as intermediate files format for Resolve is not very good choice. Way better to use DNxHR or ProRes. Bitrate of h264 lossless will be higher than ProRes or DNxHR, so not sure what are you trying to gain by using it (GPU encoding?).

Andrew Kolakowski wrote:Use of long GOP h264 as intermediate files format for Resolve is not very good choice. Way better to use DNxHR or ProRes. Bitrate of h264 lossless will be higher than ProRes or DNxHR, so not sure what are you trying to gain by using it (GPU encoding?).

They are meant as source, not as intermediate files. I can't work with full 4k60p intermediate formats on my system. I need lower res optimized media or proxies anyway. Given that I want the source to be lossless.

Yes, I like fast GPU encoding very much for that use case.

It's I,P based (at least x264 is) so still long GOP. They are easier to seek than I,P,B based GOPs, but not as fast as I frame only.
Your thread title is very misleading as this method won't work for so many people.
You also don't say anything about a need for Resolve Studio.

Andrew Kolakowski wrote:It's I,P based (at least x264 is) so still long GOP. They are easier to seek than I,P,B based GOPs, but not as fast as I frame only.

You are right, always good to be proven wrong, best way to learn.

Bitrate depends on what source you have. Things like 2D animation and screencasts easily produce 15x the bitrate using Cineform than lossless H264.

Only very clean and "simple texture" files (so mainly CGI, static screen recording) will compress well in lossless mode. Anything from camera shot will be between 1.5x to 3x compressed, so much bigger than ProRes HQ (which is around 5:1).

Andrew Kolakowski wrote:Only very clean and "simple texture" files (so mainly CGI) will compress well in lossless mode. Anything from camera shot will be between 1.5x to 3x compressed, so much bigger than ProRes HQ (which is around 5:1).

My intention was to bring sources lossless into Resolve. Of course, lossy codecs produce lower bitrates with anything that’s actually filmed by a camera. For that very reason they are lossy. If losing quality before even starting Resolve is what you want that's the way to go. I have to work with screencasts from time to time and for that use case lossless h264 is just perfect.

Andrew Kolakowski wrote:Your thread title is very misleading as this method won't work for so many people.

Nvidia’s market share is 85% so it should work for quite a few. Anyway, fixed the title . Thanks for feedback.

Figured that adding -g 1 gives all I frames. It increases bitrate by about 35% on high motion footage for me, but seeks instantly in Resolve.

ProRes HQ 4:2:2 10 bit (-c:v prores_ks -profile:v 3) gives about the same bitrate as h264 lossless 4:2:0 8bit on high motion footage shot from a running car for me. That's close enough for me to not bother with lossy intermediate codecs other than lower res proxies or optimized media.

Especially given that h264 lossless encodes 8 times faster (on my XP9750) than ProRes HQ.

-g 1 means 1 frame GOP, so I frame only.
You have similar bitrate as your lossless is 4:2:0. In case of 4:2:2 or 4:4:4 it will change a lot.
I'm just surprised you have good decoding performance with h264 lossless. It should be slower than ProRes, DNxHR (maybe it's GPU decoded).

I'll have to try this, I've been transcoding to DNx for easier workflow, but then all that stuff was being cut in Media Composer which really doesn't use the gpu for much of anything.

Andrew Kolakowski wrote:I'm just surprised you have good decoding performance with h264 lossless. It should be slower than ProRes, DNxHR (maybe it's GPU decoded).

H264 4:2:0 8bit 4k60p lossless all I frames uses about 56% CPU when looping the timeline, ProRes HQ 4:2:2 10bit about 51%. Not much of a difference. ProRes is smoother to scrub with the mouse, but H264 is good enough for me. No issues with fast cuts or fast forward / reverse playback JKL. No, it's not GPU accelerated. I'm not aware of a GPU supporting lossless for decoding.

Would be interesting to try to match ProRes HQ bitrate with lossy H264 all I frames and compute visual scores for both. I'm curious if it would rank higher than ProRes. Then it might be quite a nice alternative all GPU enc/dec.

I'm also thinking that ProRes might not be a good choice for 4:2:0 sources as it only seems to do 4:2:2 and 4:4:4. So when converting to ProRes from a 4:2:0 source to import into Resolve you have an additional forced chroma up sampling which cannot be lossless to my understanding. So you end up interpolation chroma twice, once in ProRes then in Resolve to YRGB.

You can easily test h264 against ProRes.
Simply match bitrate and check results, eg. 175Mbif for 24p HD.
Keep g=1. In theory h264 should give higher PSNR. Going 4:2:0 to 4:2:2 in ffmpeg should be near lossless.

UHD ProRes takes around 15% CPU on my 10 core i9. 4:2:0 8bit lossless h264 made from it 50%. Quite a difference compared to your results, but my h264 is made with x264 not Nvidia.
Different encode with tune=fast_decode (eg. no CABAC) gives very different result. CPU usage drops to about 20%. It shows that some features of h264 spec are difficult to decode and if you skip them then files are way easier to play (although bitrate will be higher). Nvidia will be missing all advanced options as this is typical for GPU encoders.
Cineform was at about 15% like ProRes, but CPU drops 2x for half resolution proxy playback mode (and close to 4x for quarter resolution). ProRes at half/quarter drops to around 9%. Proxy mode playback has no effect on h246 lossless files as those are very complex to decode at fractional resolution. ProRes even if DCT based codec still has modes for fractional resolution decoding as its fairly simple codec.

I'm taking a similar approach to getting media into resolve - ffmpeg to put AVI dvvideo into MOV.

What are you doing for compressed lossless renders? I'd like to do this all from Resolve. I'm working with a lossless input, want to make my corrections to that, and output lossless compressed (ideally in a non-proprietary and common container/ codec, too).

Not really possible currently with Resolve. Let's hope this is going to change soon.

Hey thanks for posting these, I didn't know ffmpeg supported the NV encoders.

But for me any 444 lossless files I've encoded like this (H264 or 265) crash Resolve 16.3 beta as soon as I drop the file in on Windows 10. Well it visually vanishes, but the process is still in Task Manager and needs to be killed.

I tried both rendering to .mov and mp4. Does this work for you on Windows or Mac?

Having run more tests, the Resolve crashes seem to be caused by the 444 lossless encoding stored in MP4. Stored in .MOV they import and their audio plays, but the video is displayed as 'Media Offline'.

422 lossless .MOV works with H264, but not with H265, where again the file imports fine and audio plays, but the video is 'Media Offline'. And 420 lossless .MOV works in either flavour.

Is this expected behaviour? I would dearly love 444 lossless support for H264/5 as it's a great archival format that I sometimes need to be rework (eg. different layout, titles, teaser clips or 'touch-up' grade tweaks).

.. this is the only 444 lossless (and 24bit audio) encodings that work for me on Windows w. Studio 16.3 beta:

H264 lossless / PCM 24bit in .MOV container:

Code: Select all

ffmpeg -i "444_24bit_input.mov" -acodec pcm_s24le -c:v h264_nvenc -preset lossless output.mov

H264 lossless / AAC in .MP4 container (doesn't seem to support 24bit PCM, and Resolve doesn't handle FLAC in it):

Code: Select all

ffmpeg -i "444_24bit_input.mov" -c:v h264_nvenc -preset lossless output.mp4

(this uses a default 128kbps AAC bitrate, you may want to up this)

Resolve does not currently handle H265 444 lossless (tested 8bit sources only).

I've always avoided .mov since the gamma shift issues way back when. I don't know if they're still a thing, but .mov just makes me uneasy on Windows. MKV is a much better container (with much better codec support than MP4), and it's also supported in key places like YouTube. That (with FLAC support) would be my preferred option.

I have a batch file in

Code: Select all

shell:sendto

folder (on windows so that you can right click on a video an select convert.bat) with the following contents to convert my source files into a format readable by DaVinci Resolve. The resulting file does end up with an extension like file.mp4.mov but at least I know which files have been converted

Code: Select all

c:\path\to\ffmpeg.exe -i %1 -threads 8 -c:v dnxhd -profile:v dnxhr_lb -c:a pcm_s16le %1.mov

I'd rather use 422 with 10 bit than 444 in 8 bit.
I'm pretty sure that your footage is coming off a Bayer-sensor and not a 3-chipper. In that case 444 is pretty useless, but 10 bit are good if your source is better than 8.

Regarding gamma shifts with .MOV, did you read above "A new colorspace/gamma option named Rec.709-A"?

Uli Plank wrote:I'd rather use 422 with 10 bit than 444 in 8 bit.
I'm pretty sure that your footage is coming off a Bayer-sensor and not a 3-chipper. In that case 444 is pretty useless, but 10 bit are good if your source is better than 8.

Regarding gamma shifts with .MOV, did you read above "A new colorspace/gamma option named Rec.709-A"?

I use (lossless) 444 on processed / effected footage which can create 444 details. This is mainly for final master renders that I sometimes re-work in some small way.

I came from Premiere on Windows where I used UT(444) which is also a lossless codec + lossless FLAC audio for masters, unfortunately Resolve doesn't support those (yet).

OK, that makes sense.