Custom FFmpeg command line parameters in Voukoder will never be added / work, because Voukoder does not use FFmpeg as an external command line program. Voukoder is using "libav" - just like FFmpeg is using "libav" internally.
Still, I have added "s32p" as sample format to the alac encoder. It will be available in the next version of Voukoder.
Daniel, what is changed in 0.4.0?
What should we select here for ProRes?
Select "YUV (16 bit 4:4:4)" as this is the only color resolution that is higher than 4:2:2 10bit or even 4:4:4 10 bit.
Oops. I found use of this in dummy_container.cpp (from line 125 and below. If (isVideo) ... else
So, I concluded this is not being used for video. Sorry.
No worries. As there is no documentation available I just wanted to share what I've found out so far.
I'm able to get YUV 4:4:4 in 16 bit depth from DVR which can be converted down to all color formats supported by encoders in voukoder. It would ne nice to have planar 4:2:2 10 bit, but I was not able to get it. Still no alpha channel.
smirontsev Actually pIOPropBitsPerSample (not pIOPropBitDepth) is controlling the bit depth for video.
I'm back now. Let's take a look at the open topics:
MainConcept's plugin also has NVENC support. But I have no idea how they fixed en error. Closing NVENC session in the destructor?
That's handled by libav, but as far as I know everthing is properly closed. Also nvsmi.exe does not report an open nvenc session after voukoder is done.
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.
Yes, Both variants are support. I just want to avoid DVR is using full range as default but is using limited range instead. Of course the user can switch this to full range if needed.
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).
The pixel format selection in the plugin settings in DVR just defines how frame is being sent to voukoder. You'd have to set the target format of your video in voukoder itself. Voukoder can do any necessary conversion on the fly. But its performant to use the closest pixel format that matches the output format so voukoder does not have to do any conversion. (See my previous post comparing the speeds)
It makes also no sense to set DVR to yuv420 and set voukoder to export prores 4444. It will work, but the effective color resolution is still 420. Same with bit depth.
Still, whatever I set in codecInfo, when calling ...
uint32_t bitDepth;
p_pProps->GetUINT32(pIOPropBitDepth, bitDepth);... I always get bitDepth = 0. And the framebuffer looks like being 8 bit. Hmm...
Edit: Created a post in the BM forum: https://forum.blackmagicdesign.com/viewtopic.php?f=12&t=138829
I'll post my questions there. But I am on a hike during easter from now on (of course covid regulations compatible). I might have a look to the forum from time to time still.
smirontsev Do you know how I can get high bit depth pixel data? i.e. RGBA 16 bit / YUV in 10 / 12 / 16 bit. And ... is there really no way to get YUV with an alpha channel?
When I tried to set this in the codecInfo I either got "Color mode is not supported" or got 8 bit anyway.
Status update:
When getting yuv420 out of DVR and feeding it directly into NVENC (without conversion from uyvy422) I get a performance increase of 62%. Really nice.
Exported 1919 frames in 4 seconds. (avg. 393.96 fps) [YUV420p->YUV420p]
Exported 1919 frames in 7 seconds. (avg. 242.30 fps) [UYVY422->YUV420p]
Exported 1919 frames in 12 seconds. (avg. 152.90 fps) [YUV444p->YUV420p]With these low latencies (2538 us/frame) small changes might have a huge effect.
TO DO
Investigating this ...
But I won't go RGB(A) in a first place. YUV is required for most encoders.
Can you please attach a Voukoder logfile? There is a sticky topic explaining where you can find it.
Krakozavr Strange. Can you provide logfiles? What are the exact steps for me to reproduce this issue?
The only thing, when I inspect video properties, it says the color space is unknown. I believe this is what smirontsev was referring to.
This should be fixed in version 0.2.0 now. It is available in the regular voukoder download section.
Color range : Full
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709It's just strange DVR is using the 0-255 range as default (auto). AFAIK 16-235 is standard.
smirontsev Seems you are right! When changing the color space in project settings I get the right values using this mapping. 
Okay, please test the updated plugin:
Edit: You can find the latest version in the regular voukoder download section now.
Thank you for creating plugin, it's very much appreciated. It's kind of crazy to see all my threads hit 100% when it renders. I never seemed to get that to happen whenever I render in Resolve.
Yes, noticed that as well. It seems "prores_ks" does scale perfectly with cpu cores.
Looks plausible. I always got "1" when having a bt.709 project. I'm just wondering why that values in the bbc code matches up with enum values in the DVR SDK. Coincidence or some kind of standard?
Thank you for the "prototype," It definitely works!
Well, I have to admit it's more than a prototype already. 
Development was surprisingly easy. I just wanted it to be careful as the whole plugin was not thoroughly tested and basically just a quick hack of 2 days work.
I just tested it on Getty, and the great news - generated ProRes passed the Getty's automatic QualityControl on ESP. Before that day, only two converters out of many I tried have been passed: Acrovid FootageStudio 4K and ProDad Mercalli (which is not exactly a converter but can be used like this).
That's really awesome! Good to know.
Another question, will be color_range, colorspace, and color_primaries be supported?
static PropertyID pIOPropColorPrimaries = "clrPrimaries"; // int16_tstatic PropertyID pIOTransferCharacteristics = "clrTransfer"; // int16_t
static PropertyID pIOColorMatrix = "clrMtx"; // int16_t
Very good point. Thats whats currently still left and what I was looking in today.
And it is used by default, right?
Yes, I used "prores_ks" for voukoder as I was told it is the best implementation.
Vouk, will the prores_ks profile be implemented?
Yes, it is already.
Is the alpha channel already working? If so, how to check?
Currently UYVY422 is used to exchange frames between DVR and Voukoder. AFAIK this does not have an alpha channel. I still need to find out how I can use different color models / pixel formats.
It seems this is an error with the video levels (Limited / Full). I'll provide a fix soon.
I'm getting around half the speed from Resolve's Nvidia Encoding.
Resolve 1440p 60fps: ~240fps while encoding (4:01 for a 15min Vid)Voukoder 1440 60fps with h264 nvidia preset: ~114fps while encoding (7:56 for a 15min Vid)
Well, this is just a first prototype of 2 days work. Nothing has been optimized yet. But I don't think voukoder will ever be faster than the native DVR implementation. The goal is to have more encoders available in DVR - the existing encoder implementations seem to be quite good actually.
Currently the plugin gets the video as 422 and voukoder needs to convert it down to 420. That's something I can still optimize and it should give some more speed.
You have an active filter btw (gamma correction). Removing it gave me 40 more fps.
It runs stable, but I have to restart Resolve after using Voukoder, because the normal encoder wouldn't work anymore.
Looking into that.
Edit: This seems to be working after todays DVR update (17.1.1 Build 9)
My GPU also only gets 50% Usage while enconding with Voukoder. Maybe I did something wrong here? Normal Resolve encoding uses around 99% GPU.
If you set the preset to "slow" it uses 100% GPU.
Still: Voukoder is not the magical tool to make everything faster. But it might offer you more encoders and more options. And I guess DVR uses CUDA in a clever way to prevent lots of copy actions from/to host and gpu.
