Beiträge von Vouk

    Well, I put a 30 fps file on a 60 fps project / sequence / timeline. That's not under voukoders control, it will be handled by premiere / the NLE. The NLE will send a 60fps frames stream to voukoder. These frames can be anything. Applying a decimate filter at this staged doesn't make any sense, right? Setting cycle to 3 would just output a 40fps file.. but... why?

    Ok, crop and pad added.

    Not sure about decimate as it adjusts the output framerate.

    With a file of 25 fps "decimate=cycle=3" would generate a 16.66666 fps file. Wouldn't it make more sense to let the NLE handle all framerate stuff?

    Thanks for this very detailed error report.

    Code
    [15:36:17] Timebase:        815626929/612929536 (0.75 fps)

    I guess this is because of the strange framerate of 27.01 fps in your project. Can you try disabling "Match Source" for the framerate in premieres video tab and select a proper one?

    There is an issue with the adobe installer unfortunately.

    Short version: Update to Connector 1.0.1.

    Connector

    Normally there should be a registry key like this:

    Code
    HKEY_LOCAL_MACHINE\SOFTWARE\Adobe\Premiere Pro\CurrentVersion

    But if you have multiple versions of premiere installed (i.e. 2019 and 2020) and you uninstall one version it seems this key gets deleted in the adobe deinstallation process. This means the connector installer can't autodetect the target directory and it looks like this:

    You have to change this path to the adobe shared plugin directory (In my case):

    Otherwise the plugin can't be found.

    I will try to find a workaround for this next week.

    Voukoder Core

    The voukoder.dll should be installed to an independent directory (i.e. the default one). It gets registered as a COM server then. In the registry it should look like this :

    Normally there is no need to copy it over to the adobe plugin directory.

    Es ist OpenSource und muss auch OpenSource sein da ich andere OpenSource Komponenten verwende. Ich könnte theoretisch Geld nehmen, aber wenn der Quellcode offen ist könnte sich jeder den auch wieder selber kompilieren von daher macht es dann auch wieder keinen Sinn.

    Ich hoffe auf zukünftige geschäftliche Sponsoren, bzw. auf Unterstützung per Patreon / PayPal etc. Insbesonders von Personen / Firmen die mit dem Voukoder (u.A.) Geld verdienen.

    Implemented AV1:

    Code
    [21:27:01] Frame #439: vRender: 31 us, vProcess: 16 us, vEncoding: 63649 us, aRender: 61 us, aEncoding: 265 us, Latency: 64077 us
    [21:27:01] Frame #440: vRender: 23 us, vProcess: 11 us, vEncoding: 27684 us, aRender: 54 us, aEncoding: 254 us, Latency: 28058 us
    [21:27:05] Frame #441: vRender: 27 us, vProcess: 15 us, vEncoding: 3904113 us, aRender: 61 us, aEncoding: 509 us, Latency: 3904768 us
    [21:27:06] Frame #442: vRender: 48 us, vProcess: 16 us, vEncoding: 565042 us, aRender: 64 us, aEncoding: 355 us, Latency: 565568 us
    ...
    [21:27:06] Exported 445 frames in 170 seconds. (avg. 2.62 fps)

    I guess I need a better CPU... my 8700K is too slow.

    You don't want the smallest file size here. Smallest file size means highest compression. And as you want to put this clip as source media in a premiere project I guess you'd even like to have no compression (-artifacts) to get highest quality and fast timeline scrubbing.

    Don't care about 17MB files. :)

    Alpha channel makes only sense with intermediate codecs (like ProRes). You need these in the editing process. When you're exporting a finished project you don't need it anymore. h.264 does not support it.

    Good news! I tested it and it was already working with 2.2.

    It is important to use a codec / encoder that supports alpha channels (like ProRes) and a pixel format that contains an alpha channel (YUVA - A=Alpha).

    Works for me as you can see.

    Lets look at the whole processing chain:

    • You'd like to export with yuv420 10bit and hevc_nvenc => using "p010le"
    • Version 2.2 requested the frame data in either:
      • Format: PrPixelFormat_YUV_420_MPEG4_FRAME_PICTURE_PLANAR_8u_709 (bt709 selected)
        Input: bt709
        Output: bt709 or bt2020
      • Format: PrPixelFormat_YUV_420_MPEG4_FRAME_PICTURE_PLANAR_8u_601 (all other selections)
        Input: smpte170m
        Output: smpte170m
        • 1. Issue: It requested 8bit and converted it up to 10bit
        • 2. Issue: It used bt601 and converted it to bt2020
    • Version 2.3 changed this behaviour to:
      • Format: PrPixelFormat_VUYX_4444_32f (BT601 selected)
        Input: bt601
        Output: unspecified (or set by setparams / colorspace)
      • Format: PrPixelFormat_VUYX_4444_32f_709 (all other selections)
        Input: bt709
        Output: unspecified (or set by setparams / colorspace)
    • Premiere will render in 32bit float
    • Connector converts it to yuv444 (16 bit)
    • FFmpeg converts it to p010le

    So it's more or less clear why this is not working:

    1. Using 32bit float is a good (but slower) decision because we are downscaling, not upscaling.
    2. I somehow need to get the information what PrPixelFormat_VUYX_4444_32f means. Is it bt601? Or does it depend on the source? How to identify this? And what is the color range?

    I have to admit the 10bit (and higher) modes really need improvement.

    But all changes need to be done in the connector, not in the voukoder itself. It is about how to get the right information from Premiere.