Posts by Vouk

    As it's written in the release notes it might be necessary to update your gpu driver:

    Quote

    For using NVENC (SDK 10) encoders driver version 450.51 or newer is required.


    Edit:


    I just tested it with a GeForce RTX 2080 TI and a Quadro P2000 and can confirm that after a driver update Voukoder 6 is working with both of them.

    Release Notes

    If you like Voukoder and especially if it helps saving time and money in your business - please consider supporting the project by paypal or on patreon. Thank you.


    I am also looking for sponsors and partners. I am doing custom encoder solutions as well. Please contact me if you are interested.

    Important

    Make sure you are using the latest connector for your application(s)!

    Fixes

    • Updated the x264 presets (Thanks to iAvoe)
    • Fixed HAP encoder pixel format
    • Fixed NVENC encoders "Good quality" preset ("preset" option)
    • Increased AAC offset by 1024 samples (fixes audio delay)

    Changes

    • Added QuickTime RLE encoder
    • Build with latest stable FFmpeg 4.3.1

    Notes

    For using NVENC (SDK 10) encoders driver version 450.51 or newer is required.

    Credits

    Thanks to my all supporters - especially the platinum tier patrons ValnirÆsirsson and Gronkh!

    It is not an issue. It is just a consequence of the settings you are using. I'd guess its related to rc-lookahead.


    You can't have small file size AND high compression AND fast encoding speed. If one goes up the other one goes down.


    AAC-LC is most compatible. 96kbit/s is in my opinion enough.

    Okay, got it.


    Depending on your settings x264 buffers alot of frames to do motion estimation and other analysis to better compress the frames. So at the end of the encoding it still has a buffer which has to be cleared. In the above log you can that FFmpeg had like 200 frames left in the buffer that had to be processed. So it is not hanging, it is just working asynchronous. I guess if you use the standard encoder settings this should not happen.

    Code
    [19:14:20] Frame #308: vRender: 225377 us, vProcess: 5572 us, vEncoding: 1621685 us, aRenderEncode: 1494 us, Latency: 1854176 us
    [19:14:20] Frame #309: vRender: 156465 us, vProcess: 3080 us, vEncoding: 275766 us, aRenderEncode: 1407 us, Latency: 436759 us
    [19:14:20] Frame #310: vRender: 110187 us, vProcess: 2646 us, vEncoding: 58322 us, aRenderEncode: 1442 us, Latency: 172633 us
    [19:14:20] Frame #311: vRender: 100072 us, vProcess: 2401 us, vEncoding: 33833 us, aRenderEncode: 648 us, Latency: 136990 us
    [19:14:20] Frame #312: vRender: 103894 us, vProcess: 2798 us, vEncoding: 41393 us, aRenderEncode: 874 us, Latency: 148988 us
    [19:14:27] Frame #313: vRender: 95837 us, vProcess: 2264 us, vEncoding: 6898403 us, aRenderEncode: 443 us, Latency: 6996967 us

    The first number vRender is the time VEGAS needs to render the frame. 0.1s means it will limit the fps to a theoretical maxium of 10fps - 0.2s even 5 fps.

    I have to admit the last encoding time of 6.9s is also pretty high, but this is within FFmpeg.


    Code
    [19:14:46] Frame #347: vRender: 56344 us, vProcess: 1565 us, vEncoding: 21048 us, aRenderEncode: 743 us, Latency: 79722 us
    [19:14:46] Frame #348: vRender: 67644 us, vProcess: 1446 us, vEncoding: 19972 us, aRenderEncode: 517 us, Latency: 89601 us
    [19:14:46] Exported 349 frames in 161 seconds. (avg. 2 fps)
    [19:14:46] Flushing encoders and finalizing ...
    [19:16:23] Video and audio buffers flushed.
    [19:16:23] Trailer has been written.
    [19:16:23] Closing encoders ...

    Almost 2 minutes to flush remaining frames and writing the mp4 footer. Looks also strange. Maybe i should use an older version of FFmpeg again.

    These options are basically choosing the scaling algorithm. "Point" just duplicates pixels. "Bicubic/Bilinear" are interpolating pixels by averaging them, "Lanczos" and "Spline" are the most sophisticated algorithms and should normally produce the best results - but there are rather slow.