Davinci Resolve now allows for third party render

Quote from Vouk

Native DVR NVENC fails after Voukoder ran

MainConcept's plugin also has NVENC support. But I have no idea how they fixed en error. Closing NVENC session in the destructor?

Quote from Vouk

just strange DVR is using the 0-255 range as default (auto). AFAIK 16-235 is standard.

Actually 0-255 is very important . Formats like DCPs, prores 444, Image sequences, IMF master files are full range. Years ago, Resolve was more focused on only rendering master files.

Grading is done in full range. Resolve takes the limited range and expands it to full with YUV files. RAW files are RGB and is full range. Keeps everything consistent when grading. Also grading monitors are almost always in full range.

As you noticed, Resolve only goes to 16-235 for non-RGB deliverables like prores hq and h264.

Looking forward to trying out the new update.

Just an update. I downloaded version 0.3, and I still get unknown colorspace.

When I render an uncompressed MOV from Resolve, and render a prores out of Premiere, it shows ITU-R BT.709

Quote from Roger Singh

Just an update. I downloaded version 0.3, and I still get unknown colorspace.

When I render an uncompressed MOV from Resolve, and render a prores out of Premiere, it shows ITU-R BT.709

Connector: 0.3.0

Resolve: 17.1.1

Quote from smirontsev

Connector: 0.3.0

Resolve: 17.1.1

Are you filling in this area on the render page?

*Update* okay, when I filled out the tags in the advanced settings on the render page, the inspector showed the proper tags.

Vouk, can you compile me a list of your SDK questions so I'll can try to contact and send them to the Resolve product manager directly?

There is also a dedicated part for developers on the BMD forum:

https://forum.blackmagicdesign.com/viewforum.php?f=12

But answers are given only quite irregularly.

Perfect! Have a nice day off

Quote from Vouk

Do you know how I can get high bit depth pixel data

I don't know for sure. But the next code does not generate errors in s_RegisterCodecs (Pixel Format was not defined for plugin encoder fourCC) or when I try to render (Color mode is not supported). I choose 16 bit because for fourCC codecs it is 4/8/16/24/32 (https://www.fourcc.org/rgb.php). But I am not experienced in programs like this.

P.S.: pIOPropBitsPerSample is for audio, you know, right?

val = clrUYVY;
codecInfo.SetProperty(pIOPropColorModel, propTypeUInt32, &val, 1);

uint8_t hSampling = 2;
uint8_t vSampling = 2;
codecInfo.SetProperty(pIOPropHSubsampling, propTypeUInt8, &hSampling, 1);
codecInfo.SetProperty(pIOPropVSubsampling, propTypeUInt8, &vSampling, 1);

val = 16;
codecInfo.SetProperty(pIOPropBitDepth, propTypeUInt32, &val, 1);
val = 8;
codecInfo.SetProperty(pIOPropBitsPerSample, propTypeUInt32, &val, 1);

Quote from Roger Singh

Actually 0-255 is very important . Formats like DCPs, prores 444, Image sequences, IMF master files are full range. Years ago, Resolve was more focused on only rendering master files.

Grading is done in full range. Resolve takes the limited range and expands it to full with YUV files. RAW files are RGB and is full range. Keeps everything consistent when grading. Also grading monitors are almost always in full range.

As you noticed, Resolve only goes to 16-235 for non-RGB deliverables like prores hq and h264.

Looking forward to trying out the new update.

Resolve internal processing etc is meaningless here. Explained here:

https://forum.blackmagicdesign.com/viewtopic.php?…l+range#p711929

We need full range data as well, but be careful with it.

ProRes private frame headers have no tag (neither MOV container) to specify range. By design ProRes should be always limited range. You can send full range YUV data to it (ProRes also always stores data as YUV, even if you send RGB to it) and it will preserve it, but reading app will have no clue what is the real range of the file. Only by manual intervention (like we have in Resolve) you can force app to read it as full range. In some apps (like Premiere) it's all hard coded and there is no way to overwrite it. If I'm correct Premiere expects full range for 444 ProRes files and Resolve by default exports limited range, so you always need to set it manually in order to have good mapping between these 2 apps.

Within the time we should have few pixel formats supported:

- yuv420 10bit for h264/5 etc

- yuv422 10bit ProResHQ, DNxHR etc

- yuva444 12 bit (for things like ProRes 444, DNxHR 444)- does ffmpeg properly encode now 444 at 12bit or they just fixed decoder?

- rgba 16bit -for anything RGB based

I assume bit depth scaling is not the issue, so those higher values will cover smaller bits depths.

Key point is to have YUV data when codecs require YUV data. Let Resolve do proper RGB->YUV conversion based on project settings etc. You don't want to do RGB<-> YUV as this would require all the color space etc. math behind it. Resolve does it well, so better to use final data.

For ProRes you want to add extra bits to ffmpeg command ( I assume you're adding color space, etc. already), so it looks more like Apple encode:

-metadata:s "encoder=Apple ProRes 422" -c:v prorers_ks -vendor apl0 -bitexact -movflags write_colr

These should be correct encoder names:

Apple ProRes 422 Proxy
Apple ProRes 422 LT
Apple ProRes 422
Apple ProRes 422 HQ
Apple ProRes 4444
Apple ProRes 4444 XQ

for interlaced encoding (this will properly set ProRes private frame header as well) also add:

-vf "setfield=1, fieldorder=tff/bff" " -flags "ildct+ilme"

prores_ks is much slower but keeps bitrate in better control (still not perfectly as Apple encoder and affects quality a bit).

prores encoder is much faster, but it doesn't really restrict bitrate in the same way as Apple encoder. It will be most likely around 10-20% higher than Apple reference (but also quality is closer to Apple).

When it comes to PAL/NTSC aspect ratio just pass -aspect 16:9/4:3 and ffmpeg does set it properly by default based on frame size.

When you get timecode working then:

-timecode 10:00:00:00 -metadata:s reel_name=ABCD123

no sure if you can get reel name as variable.

Later we can add audio tracks language and name setting, which is useful.

Quote from Andy

For ProRes you want to add extra bits to ffmpeg command

Andy, the plugin does not use the ffmpeg executable and its command-line parameters. The library libav and API is using.

All those setting should be there as well, no? So it just needs mapping.

Quote from Andy

All those setting should be there as well, no? So it just needs mapping.

Not exactly. We do not have some kind of "file" for encoding with ffmpeg-like options. We need to "ask" Resolve (with C++ code) to get us the stream in the correct format. And this part of API is not documented at all. So, we can't "Let Resolve do proper RGB->YUV conversion based on project settings etc." until learn how to properly command Resolve via API. The second part - encoding to differents codecs - is not a problem then.

No way to get some documentation from BM?

I don't believe API has no documentation, but I can understand BM won't share it with "small developers". Poor approach though.

Yes, you need correct YUV data to encode for sure. You need levels to be correct as well. Fixing it by setting full range in codec flags is not very good workaround (sometimes not possible) as some apps don't read range flags.

I dont have "IOPlugins" folder, I only have 'plugins' folder so I extracted the files there and installed the software before and I dont see it on the delivery page, what went wrong?

Quote from rotem

I dont have "IOPlugins" folder

You definitely need to create IOPlugins folder.