Yes, it is already.
And it is used by default, right?
P.S.: I already understood from the settings - yes.
Yes, it is already.
And it is used by default, right?
P.S.: I already understood from the settings - yes.
Hello!
Thank you for the "prototype," It definitely works!
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).
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.
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.
So I don't know how to map these values.
It is very likely that the values are described here: https://github.com/bbc/qtff-parameter-editor, Video Characteristics section.
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?
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?
It seems this is an error with the video levels (Limited / Full). I'll provide a fix soon.
I'm seeing this issue with creating ProresHQ files as well.
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.
enum values in the DVR SDK
What do you exactly call DVR SDK?
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.
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.
Yes, noticed that as well. It seems "prores_ks" does scale perfectly with cpu cores.
Makes me wonder why NLE renders never scale as nicely.
The new plugin works great with the full/limited range now for ProresHQ.
The only thing, when I inspect video properties, it says the color space is unknown. I believe this is what smirontsev was referring to.
Is this how Resolve sends out the colour/gamma information? Blackmagic talked about it here:
https://forum.blackmagicdesign.com/viewtopic.php?f=21&t=114047
sorry, if this is redundant information already.
Yes, noticed that as well. It seems "prores_ks" does scale perfectly with cpu cores.
I tried to render a batch of 32 individual clips with the plugin. I got them in the end, but my computer got 4 blue screens on the way (Dell Alienware 17R4). Never saw anything like this rendering uncompressed AVI
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.709
It's just strange DVR is using the 0-255 range as default (auto). AFAIK 16-235 is standard.
Krakozavr Strange. Can you provide logfiles? What are the exact steps for me to reproduce this issue?
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.
val = clrUYVY;
codecInfo.SetProperty(pIOPropColorModel, propTypeUInt32, &val, 1);
Did you try clrRGBA (or clrRGBAp)? Or you need to change something on the Voukoder side?
Investigating this ...
But I won't go RGB(A) in a first place. YUV is required for most encoders.
Ooops. No timecodes in mov.
Also, I have some conflicts with Resolve's NVIDIA encoder. This was seen in the early betas of the MainConcept plugin.
One of the discussions about this.
https://forum.blackmagicdesign.com/viewtopic.php?f=21&t=128517
I've been testing Voukoder on Davinci Resolve Studio 17 and worked fine. Exports have good quality. The only problem that I found is that I am not able to export Prores 4444 with actual transparency. I've setup a clip in the Color Page to have alpha by removing the background and adding an Alpha Output in the node window. I have this settings in the Deliver Page and in Voukoder. I've tried tweaking them but the result is the same: what sould be Allpha channel just displays black pixels. I've tried to put it over another video to check the transparency, but it doesn't show it.
In order of screenshots
1: My setup of the Clip to have transparency in the Color page
2: My settings on the Deliver Page
3: My Codec selection in Voukoder
4: My Codec settings in Voukoder
5: Codec information of the exported clip in VLC (Davinci Resolve's inspector tab also displays Prores 4444)
6: Testing transparency (I've put the clip over another and scaled it down so it can clearly be seen the lack of actual transparency)