Davinci Resolve now allows for third party render

    Zitat von Vouk

    Has that 444 16 bit mode is used for this export session?

    I believe it is correct.

    But I tried to recreate this issue without success. My renders come out clean in any mode (444 16bit in DaVinci; ProRes 422HQ, 444, 444HQ in voukoder).

    UPDATE: I processed the same tests as Anton, the author of the original screenshot, but I still can't reproduce his result. But he used DaVinci 17.0, and I use v. 17.1 - so it may be DaVinci's bug.

    3 Mal editiert, zuletzt von Krakozavr (20. April 2021 um 19:55) aus folgendem Grund: Update :)

    one annoying problem.

    Voukoder is ignoring low space ;)

    Yesterday I occasionally set a long batch (individual clips rendering) to a full disk.

    With regular render, DaVinci would stop render with an appropriate error message.

    But with Voukoder, it took full time for render (about an hour and a half for one batch and two hours for another) and finished without error messages, created 5 properly rendered clips (till disk space was exhausted) and 35 empty, 36K-size-each clips for all others ;)

  • Vouk 2. Juni 2021 um 10:49

    Hat das Label DaVinci Resolve hinzugefügt.

    Привет. спасибо за работу! У меня есть несколько вопросов.

    1. Why are these choices of bitness left in the Davichi interface, if all the same, if necessary, the codec does the bitness reduction itself?

    I left it at the default of 8 bits and got streaks of artifacts on the gradients. Why don't you always send the maximum color depth to the codec?

    2. кодек имеет возможность установить контейнер - avi, mkv или mov, но нет возможности изменить выбор по умолчанию. Например, я всегда кодирую mov. Хотелось бы, чтобы мне не приходилось каждый раз устанавливать это значение.

    Можете ли вы заставить кодек запомнить мой выбор?

    Еще раз спасибо за отличную работу.

    • Offizieller Beitrag

    1. Basically export speed is the reason. If you export a yuv420 (8 bit) it is significantly faster to use the 8 bit output mode in resolve. Otherwise each frames data has to be converted from yuv444 16 bit down to 8 bit first, and then sent to the encoder. If resolve delivers 8 bit already we can just pass it through to the encoder.

    2. It is a bit tricky because it just shows the available containers that support the current selected audio and video container. But I'll see what I can do.

    Zitat von flyingcreature

    2. кодек имеет возможность установить контейнер - avi, mkv или mov, но нет возможности изменить выбор по умолчанию. Например, я всегда кодирую mov. Хотелось бы, чтобы мне не приходилось каждый раз устанавливать это значение.

    Можете ли вы заставить кодек запомнить мой выбор?

    Yes, you can.
    Set everything as you wish, both in DaVinci and Voukoder, then save a delivery preset in DaVinci :)

  • Vouk 31. August 2021 um 20:35

    Hat das Label von Implementierung auf Fertig geändert.

  • Vouk 31. August 2021 um 20:35

    Hat das Label DaVinci Resolve entfernt.

    Regarding the DR plugin SDK - how are you guys able to override 'pIOPropColorModel' once it's set in s_RegisterCodecs? for example, clrNV12 @ 4:2:0

    Code
    // NV12 4:2:0
uint32_t val = clrNV12;
codecInfo.SetProperty(pIOPropColorModel, propTypeUInt32, &val, 1);

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


    The sample x264_plugin_encoder makes it look like you can override it in DoInit(HostPropertyCollectionRef* p_pProps) with the following


    Code
    // UYVY 4:2:2

uint32_t val = clrUYVY
p_pProps->SetProperty(pIOPropColorModel, propTypeUInt32, &vColorModel, 1);

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


    But the frame buffer being passed to DoProcess(HostBufferRef* p_pBuff) is definitely still NV12 4:2:0 and not UYVY 4:2:2. It seems as if one has to write a plugin, you have to pick a 'pIOPropColorModel' and set it to a pixel format that's larger or equal to what you need, then if one were to use a CODEC that uses a lesser pixel format, then one has to manually convert it which is quite inefficent.

    I'm trying to modify the x265_encoder_plugin and make it more efficient by getting rid of the vector copy needed to convert from UYVY -> NV12.