There is an issue with 24bit audio currently. Can you try setting it to 16 or 32 bit in DVR?
Beiträge von Vouk
-
-
Currently "zscale" in libav supports these values:
Codefilter <int> ..FV....... set filter type (from 0 to 5) (default bilinear) point 0 ..FV....... bilinear 1 ..FV....... bicubic 2 ..FV....... spline16 3 ..FV....... spline36 4 ..FV....... lanczos 5 ..FV.......
And that's what's selectable in Voukoder. I'm not sure what lanczos version is being used there.
-
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 ...
... 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.
CodeExported 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
- Add high bit depth mode pixel formats
- Get alpha channel working
- Get timecodes working for MOV
- Native DVR NVENC fails after Voukoder ran
"NVENC m_EncodeAPI.nvEncOpenEncodeSessionEx(&encodeSessionExParams, &m_pEncodeSession) return: 15"
-
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.
CodeColor 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.
-
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.
- ColorRange will be set in the next version
- Voukoder also needs this fields to be set. Unfortunately the values are not defined/documented in the DVR plugin SDK. So I don't know how to map these values.
- frameData.colorSpace (pIOColorMatrix )
- frameData.colorPrimaries (pIOPropColorPrimaries)
- frameData.colorTransfer (pIOTransferCharacteristics)
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.