Beiträge von Joe24

  • Memory leak?

    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):

    Code
    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"

  • Memory leak?

    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.

  • Multi-GPU rendering

    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 0.7.2.8 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.

  • Multi-GPU rendering

    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:

  • VoukoderPro - Public Beta

    Zitat von Joe24

    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.

  • high quality for filmmaker color davinci resolve

    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.

  • VoukoderPro - Public Beta

    Zitat von buddhabas

    Why?

    It's a beta version, that's why. You can open Scene Designer manually from the Windows Start Menu.

    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 (too much video information; alpha = transparency).

  • Multi-GPU rendering

    Zitat von Vouk

    ... using its DLL variants. So for each export it creates a new instance.

    I don't recall ever finding a way to control more than one GPU at a time with FFmpeg command line. Usually you specify "-gpu 1" etc. at the beginning, and that's the only card targeted by the entire command line. For multiple cards, you use multiple command lines.

    Am I to understand that VoukoderPro, with its FFmpeg DLL version, is under the same restrictions of 1 GPU per render/export?

    Not a huge problem for what I do, but just curious. Other people do far heavier stuff.

  • Multi-GPU rendering

    As it happens, using Download/Upload to transfer data between cards doesn't work. I'm not sure it's even possible to move video data between GPUs mid-task, or even use more than one GPU with a single instance of FFmpeg. This might be an FFmpeg limitation? Tried several different ways, and couldn't get it to work.


    When specifying an Upload to GPU0 -> Encode on GPU1, throws an FFmpeg error:

    Code
    [FFmpeg:0] Could not set non-existent option 'gpu' to value '1'


    Tried parallel Upload filters directly from Video Input node, uploading to 2 different cards (GPU0/1), and it throws the same type of error:

    Code
    [FFmpeg:0] Could not set non-existent option 'gpu' to value '0'


    Using Upload to GPU0 -> Scale -> Download from GPU0 -> Upload to GPU1 -> Encode on GPU1 doesn't work either. Throws the same FFmpeg error:

    It would certainly be nice to run multiple GPUs from a single Vegas render, but if this is in fact an FFmpeg limitation, I guess there's not much anybody can do about it except to run multiple Vegas instances, each with a separate VoukoderPro Scene controlling it's own GPU. Unless VoPro could run multiple FFmpeg instances from the same Vegas output buffer?

  • Multi-GPU rendering

    Well now I feel a bit silly. It wasn't a VoukoderPro problem at all.

    Removed all video nodes from a test scene, and still observed significant GPU0 copy and CUDA activity on an audio-only VoPro encode. Hmmm.

    I always have GPU acceleration turned off in Vegas because it slows renders down . . . but must have enabled it for some test, and forgot to disable it again. *facepalm*

    Once I turned GPU acceleration off in Vegas, the copy and CUDA activity is no longer present on GPU0. There is a light 3% load on GPU0 3D/CUDA engine when Vegas is onscreen, but this drops to 0% when Vegas is minimized, and seems to be just normal Windows usage of the primary graphics card.

    Tested renders on all 3 cards individually, and all GPU activity takes place on the correct intended card.

    So there is no actual problem.


    On another note . . . To my way of thinking, it would make more sense to have each node 'inherit' the GPU assignation of the previous (upstream) node in Scene Designer, rather than having to set a target GPU for every single node. If a user wanted to transfer the stream from one GPU to another at any point, couldn't they manually use Download/Upload nodes to send data from one card to another?

  • Multi-GPU rendering

    When assigning a filter/encode operation to FFmpeg GPU1, the encode uses NVENC of GPU1, but the CUDA + copy engine of GPU0. There is bus activity on both GPUs, so this is not an OS reporting anomaly. Data is being shuffled from one GPU to the other mid-task.

    When assigning filter/encode operations to both GPUs: both CUDA + copy engines of FFmpeg GPU1 remain idle.

    Testing on a 2-GPU system, VoPro version 0.7.2.8, Vegas 20 build 411. GPU was assigned by setting the target GPU in the CUDA Upload filter.

    NOTE: FFmpeg numbers the GPUs differently than Windows does. In my system:

    • Windows GPU0 = FFmpeg "GPU1"
    • Windows GPU1 = FFmpeg "GPU0"

    You can find the FFmpeg designation for each card by the following command:

    Code
    ./ffmpeg -f lavfi -i nullsrc -c:v h264_nvenc -gpu list -f null -

    Scene files to test:

    scenes.zip

    PS, to run both these Scenes simultaneously, you'll probably have to patch your drivers (because there are more than 3 total output streams):

    nvidia-patch/win at master · keylase/nvidia-patch
    This patch removes restriction on maximum number of simultaneous NVENC video encoding sessions imposed by Nvidia to consumer-grade GPUs. - keylase/nvidia-patch
    github.com

  • Dynamic file naming

    Output-file naming is a problem in VoukoderPro. To date, including the current version (0.7.2.8), file naming choices are: either completely custom, or completely set by the NLE.

    For one thing, if you manually set the file name in your VoPro Scene, this makes it super easy (barely an inconvenience) to accidentally overwrite a previous render, because all output files encoded with that Scene will have the same name.

    If you're using VoPro to encode multiple formats from the same NLE render, you cannot use the NLE-supplied name because then all your output files are simultaneously attempting to have the same name. Chaos ensues (although VoPro now has a lockout in this situation and will refuse to encode at all).

    Further, if you are using the Render Regions function in Vegas, each rendered region file will overwrite the previous one. If you rendered 3 regions, you'd be left with only a single video file which would contain the last region rendered. The first 2 regions will be lost, overwritten.

    Would be nice to see some rule-based dynamic naming functions. For instance:

    • Perhaps a function for simple sequential naming. I.E., if "00000.mp4" exists, name output "00001.mp4". Or an unconditional master counter, like the log file naming system.
    • Suffix-based naming with wildcards, based on the filename supplied by the NLE. I.E., NLE filename: "Lost in the Woods.mp4", VoPro options: "%NLEfilename - %VoProScene - %seq.mp4", VoPro output filenames would be something like: "Lost in the Woods - Monochrome 8K - 00000.mp4" and "Lost in the Woods - 192 kbps ABR - 00000.mp3".
    • Date- and time-based names.