Posts by Joe24

    In the Vegas "Render As" menu, make sure you have "Show Favorites Only" de-selected.

    If neither Voukoder nor VoukoderPro works on your rig, there's something screwy with your system settings. Lots of successful users with Vegas 21.

    Your vRender times are 100x higher (slower) than mine.... and my system is not new. Some of your vRender times (the time Vegas takes to render the frame before it gets fed into Voukoder/VoPro) are over 1 second, which is bonkers. On a system like yours, I'd expect at least double-digit fps . . . not <1 fps.

    [20:02:18] Frame #49: vRender: 798341 us, vProcess: 0 us, vEncoding: 3036 us, aRenderEncode: 906 us, Latency: 802295 us
    [20:02:19] Frame #50: vRender: 1071685 us, vProcess: 0 us, vEncoding: 4496 us, aRenderEncode: 566 us, Latency: 1076763 us

    Are you trying to run any other programs at the same time (e.g., mining?), or is Vegas running out of RAM? To be clear, you're saying that all projects malfunction, without exception? Have you tried creating a simple new project and rendering that?

    Does it render without using Voukoder? Or using Voukoder but software rendering, like x264? Are your video drivers up to date?

    Yes VoukoderPro works fine in Vegas 21. On the other hand, Voukoder 13 predates Vegas 21, so possibly there are some issues there?

    When you install VoukoderPro, you have to manually select your NLE (Vegas 21, etc.) from the setup menu. This is not automatic. Seems to confuse a lot of people.

    Always stops on frame #102? That's odd. Do you have "Render Loop Regions Only" set in Vegas render options?

    Can you elaborate on what you mean by the render "freezing"? Do you have to force-close Vegas, or what?

    No errors that i can find in the logs. Maybe somebody else can see something. The fact that it's rendering at all is puzzling.

    The AAC codec in FFmpeg used to have a bug that would glitch on anything over 48 kHz sample rate, although i thought that was fixed years ago. Did you try 48 kHz?

    Also, maybe try changing video and audio formats, see if you can pin the error down to some specific setting or format.

    Does VoukoderPro give you the same problems?

    Lower the audio sample rate of your Vegas project and try again. AAC has a limit of 96 kHz.

    What's the correct configuration of ffmpeg?

    What i mean to say is that something about your audio/video output format from Vegas needs changing. It's probably nothing major.

    What specifically are you trying to do? What is your video project resolution, framerate, format, etc? What is your audio sample rate and bit depth?

    Post your most recent logfile from your %localappdata%\VoukoderPro\logs folder. That will likely tell us what the problem is.

    The following may be the problem:


    Correct syntax should be: hwupload_cuda=1

    It is in fact possible to use multiple GPUs from a single FFmpeg command line. There doesn't seem to be a lot of information out there on this topic. However, the following example uses GPU0 to perform resolution-scaling, then GPU1 and GPU2 to encode different formats (1080p, 720p).

    In FFmpeg command line, assigning each NVENC encoder "-gpu 1" or "-gpu 2" is completely pointless, as the encoder always uses whatever GPU was targeted by the previous hwupload_cuda command, regardless of NVENC GPU preference in the command line. If you (nonsensically) specify separate GPUs for Upload and Encode, the Upload GPU setting overrides the Encode GPU setting, and both actions take place on the Upload GPU. So adding/removing the NVENC "-gpu" options makes no difference in function.

    Using 3 GPUs is hilariously inefficient for such a small job, but the following command is a working example of FFmpeg running a complex operation using 3 GPUs at once. Using uncompressed AVI file input, which seems the most similar to what VoPro is doing (no hardware decoding):

    ffmpeg -y -probesize 42M -analyzeduration 10 -i "d:\temp\input.avi" -filter_complex:a "[0:a]asplit [asplit1][asplit2]" -filter_complex:v "[0:v]hwupload_cuda=0, split [split1][split2], [split1]scale_cuda=1920:1080:interp_algo=4:format=yuv420p:force_original_aspect_ratio=1, hwdownload, hwupload_cuda=1 [split1scaled],[split2]scale_cuda=1280:720:interp_algo=4:format=yuv420p:force_original_aspect_ratio=1, hwdownload, hwupload_cuda=2 [split2scaled]" -map "[asplit1]" -c:a ac3 -b:a 96k -map "[split1scaled]" -c:v h264_nvenc -gpu 1 -2pass 0 -b:v 2500k -maxrate 5000k -bufsize 5000k -bluray-compat 1 -coder 1 -cq 0 -g 48 -level 4 -preset:v p7 -profile:v high -rc:v vbr -rc-lookahead 20 -tune:v hq "output_1080v4.9.mp4" -map "[asplit2]" -c:a aac -profile:a aac_main -b:a 96k -map "[split2scaled]" -c:v h264_nvenc -gpu 2 -2pass 0 -b_ref_mode:v middle -preset:v p7 -profile:v 2 -qp 30 -rc 0 -rc-lookahead 20 -tune:v hq "output_720v2.1.mp4"

    Corresponding VoPro Scene would be something like this: This cannot yet be tested due to the current bug (as of version 0.7.4).

    No memory leaks observed using FFmpeg command line. Tested all 3 GPUs individually.

    The following is for GPU1. To change to a different GPU, just change the target of hwupload_cuda. Using AVI file input, which is the closest to what VoPro is doing (no hardware decoding):

    ffmpeg -y -probesize 42M -analyzeduration 10 -i "d:\temp\input.avi" -filter_complex:a "[0:a]asplit [asplit1][asplit2]" -filter_complex:v "[0:v]hwupload_cuda=1, split [split1][split2], [split1]scale_cuda=1920:1080:interp_algo=4:format=yuv420p:force_original_aspect_ratio=1 [split1scaled],[split2]scale_cuda=1280:720:interp_algo=4:format=yuv420p:force_original_aspect_ratio=1 [split2scaled]" -map "[asplit1]" -c:a ac3 -b:a 96k -map "[split1scaled]" -c:v h264_nvenc -2pass 0 -b:v 2500k -maxrate 5000k -bufsize 5000k -bluray-compat 1 -coder 1 -cq 0 -g 48 -level 4 -preset:v p7 -profile:v high -rc:v vbr -rc-lookahead 20 -tune:v hq "output_1080v4.9.mp4" -map "[asplit2]" -c:a aac -profile:a aac_main -b:a 96k -map "[split2scaled]" -c:v h264_nvenc -2pass 0 -b_ref_mode:v middle -preset:v p7 -profile:v 2 -qp 30 -rc 0 -rc-lookahead 20 -tune:v hq "output_720v2.1.mp4"

    Update for version 0.7.4:

    • Memory leak does not occur on any of the 3 cards in my system when using simple Video Source -> NVENC Encode scenes.
    • Memory leak *does* occur using more complicated Scenes involving Video Source -> CUDA Upload -> NVENC Encode. These Scenes are only possible to test on GPU0, due to the current bug involving duplicate "gpu" assertions in the FFmpeg command.

    PS, If you want a quick and dirty way to add more cards to your system for multi-GPU testing, you could grab a couple x1 riser cables and burned-up cards from a starving miner. 😋 The performance won't be great because of the PCIe x1 bandwidth bottleneck, but it'd be good enough for testing.

    Just taking a couple steps back here and collecting a bit more data. And I triple-checked that GPU acceleration was turned off in Vegas.

    Version does use the intended GPU1/2, with no 3D/CUDA activity on any cards. However, when encoding on GPU0 (FFmpeg designation), which happens to also be Windows' primary card, 3D/CUDA sees a 93% load even with all windows minimized and GPU acceleration turned off in Vegas.

    Version 0.7.4, as mentioned, cannot do any complex operations on GPUs other than GPU0. Anything that requires both CUDA Upload and an NVENC Encoder nodes fails because "gpu" is declared/assigned multiple times in the FFmpeg initialization. GPU0 still has the same 3D/CUDA activity on it, similar to v0.7.2.8 behavior above, and only when encoding using GPU0. No GPU0 activity when encoding with GPU1/2. No 3D/CUDA activity on any cards when encoding on GPU 1/2. No CUDA filters are being used in the test scenes.

    Seems like the duplicate assertions of the target GPU are causing problems. Directly encoding (Video Input -> Encoder) on GPU0/1/2 works. But when using (Video Input -> CUDA Upload -> Encoder), FFmpeg scrams.

    This appears to be caused by the duplicate GPU assertion commands issued to FFmpeg (both Upload and Encoder nodes have options to choose a GPU in Scene Designer). These duplicate commands are not being accepted by FFmpeg. For instance, commanding an Upload to GPU2, then commanding an NVENC encode also on GPU2. FFmpeg acknowledges the first assertion, but rejects the second.

    As mentioned in the previous post, I don't believe FFmpeg allows you to use the "-gpu " assignment more than once in a single instance. Even if it's to the same GPU.

    This only seems to affect GPUs other than GPU0. When GPU0 is used, I don't see any GPU assertion entries at all in the log file.

    In this log, when attempting to run on GPU2, it looks like FFmpeg is choking on the second assertion of "-gpu 2". See log, especially lines 2 and 14:

    Attempts to encode on GPU0 run properly, but this is probably because according to the log, "-gpu 0" is never asserted:

    Also, if you want to save yourself some trouble later on, start with the YUV 4:2:0 template instead of the YUVA 4:4:4 one you selected in the screenshot. Many video formats choke on the latter.

    .... and if that wasn't the problem, post your log file (%localappdata%\VoukoderPro\logs\)

    You've got something configured wrong in a way that FFmpeg refuses to deal with.

    For great quality, you'll need CPU encoding (e.g., x265), not GPU. If you want speed but are content with okay/decent quality, you would use GPU (e.g., NVENC).

    That said, there are quite a few threads on this site related to settings for getting the most out of your CPU/GPU encoding. I suggest you take a look through them.