NVENC resolution scaling (scale_cuda)

Not really a bug, more of a question . . . Am I just missing something here?

I've been playing around with the Scene Designer a bit, while waiting for Vegas Pro functionality to arrive. Love the interface. From downloading to having more-or-less what I wanted on the screen took less than 15 minutes. Of course I'm not able to actually test the results yet . . .

One thing I notice is that the scale_cuda video filter doesn't appear in the list of available filters. (scale_cuda is the hardware scaler function on Nvidia graphics cards.) This would be fairly important for my use-case, as I'm trying to have the GPU accept a single video stream, split this into two streams, scale one of them down to 720p resolution, then use NVENC to encode them to different formats (h.264 and h.265).

If this chain has to send a video stream back to the CPU for software scaling, and then back to the card, there will be a huge performance penalty.

You can see my desired scenario below, except the Scale video filter would use scale_cuda and thereby keep all the computation on the graphics card.

PS, wildcard file naming would be helpful, especially in a case like this where both output files will be MP4 file formats with the same name from the NLE. It would be nice to be able to add a suffix to the name from the NLE, for instance "* - Blu-ray version.mp4" and "* - download version.mp4".

Test function reports success with this layout. Will see how that translates to the real world when the time comes.

Video and audio streams in output files are by default flagged as.... Swedish??? Even after manually enabling language metadata in each stream node and setting all 4 streams to English.

The 'Scale' filter that is currently available does seem to use the GPU, but it's shuffling data back and forth to the CPU, very inefficient. Running 1 dual-output render in VoPro 0.7 is currently slower than running 2 simultaneous renders with Voukoder 13.

'ZScale' is even worse, as it doesn't seem to use the GPU at all.

On the other hand, the speed advantage of 'scale_cuda' should be substantial when it becomes available.

For reference, here are some FFmpeg command lines I've used for scale_cuda with AVI/h.264/h.265 file sources:

FFmpeg.zip

Properly fed, all 3 variants will max out the GPU encoder with minimal CPU usage.

An even more powerful feature of FFmpeg is the ability to use multiple graphics cards. Hopefully both GPU filtering (e.g., scale_cuda) and the ability to assign a job to a particular GPU will be added in the future.

Awesome news, thank you! I'm out of town on business ATM, but will try this out when I get back.

Hmm, can't get it to work. Rendering fails immediately with message: "Unable to start VoukoderPro: FFmpeg error."

Excerpt from the log file:

2023-08-22 22:28:55 (trace)    [FFmpeg:0] auto-inserting filter 'auto_scale_0' between the filter 'buffer@9309cf357e4c40e3b1334754fe21a3f3' and the filter 'Parsed_hwupload_cuda_1'
2023-08-22 22:28:55 (trace)    [FFmpeg:0] query_formats: 9 queried, 7 merged, 1 already done, 0 delayed
2023-08-22 22:28:55 (trace)    [FFmpeg:0] picking yuva420p out of 9 ref:yuva444p16le alpha:1
2023-08-22 22:28:55 (trace)    [FFmpeg:0] w:1920 h:1080 fmt:yuva444p16le sar:1/1 -> w:1920 h:1080 fmt:yuva420p sar:1/1 flags:0x00000004
2023-08-22 22:28:55 (trace)    [FFmpeg:0] Calling cu->cuDeviceGetAttribute(&priv->tex_alignment, 14 , hwctx->internal->cuda_device)
2023-08-22 22:28:55 (trace)    [FFmpeg:0] CUDA texture alignment: 512
2023-08-22 22:28:55 (trace)    [FFmpeg:0] Unsupported input format: yuva420p
2023-08-22 22:28:55 (trace)    [FFmpeg:0] Failed to configure output pad on Parsed_scale_cuda_3
2023-08-22 22:28:55 (error)    [InputNode.cpp:110] Unable to configure filter graph.
2023-08-22 22:28:55 (error)    [Router.cpp:202] Init phase of track #0 (video) failed!
2023-08-22 22:28:55 (error)    [Router.cpp:242] Initialization failed: -11
2023-08-22 22:28:55 (info)    [VoukoderPro.cpp:502] Unable to start VoukoderPro: FFmpeg error.

Both encoder nodes are set to CUDA, as you can see in the following exported scene. Tried it both ways (CUDA / YUV 420).

temp scene v0.1.zip

When working with h.264/h.265 input in FFmpeg command line, I found I had to use h264_cuvid/hevc_cuvid instead of hwupload_cuda to avoid a similar auto_scale_0 error.

On the other hand, when working with uncompressed AVI input, I'd have to use hwupload_cuda and be very careful to feed it a supported pixel format (YUY2 in that particular case). See my command-line options in post #4 above for working examples.

Not sure what format the Vegas -> VoukoderPro link uses. If h.264, then h264_cuvid might work instead of hwupload_cuda?

In any case, something seems unhappy about the YUVA pixel format.

Testing the scene from Designer has always worked. But the scene doesn't work in Vegas.

Scene Designer test video appears to be YUV. Output from Vegas is YUVA.

No it does not. Admin rights make no difference in either Scene Designer or Vegas.

Tested with VoPro v0.7.2.5, Vegas 20 build 411. Scene (see post #9 above) works in Designer, scene does not work in Vegas.

Here's a log file with two attempts in it. The first is a successful run from Scene Designer, and the second is an unsuccessful run from Vegas. Exported *.scene file attached.

voukoderpro-0.log.zip

temp v0.1.scene.zip

Just a side note, the issue with all A/V streams being flagged as Swedish seems to be resolved. I haven't checked this for awhile, but VoPro 0.7.2.5 is functional, shows tracks as my default English.

Zitat von Vouk

does it work if you select the 'YUV 4:2:0 (8 bit)' template?

Yes that was the problem. I guess I based my templates off of the VoukoderPro YUVA template in Vegas, like you said.

Started fresh with the YUV 4:2:0 8-bit template instead, linked it to my desired Scene, and it seems to render. I'll test it more tomorrow. But it does appear to encode what I told it to do, and we do finally seem to have the speed advantage in rendering.

That being the case, I have a suggestion for your consideration. Once a VoPro template in Vegas is renamed, there is no way to tell what pixel format is being exported from Vegas. And that can lead to confusion, as just witnessed.

So why not have a dropdown menu in the Vegas template itself which allows you to select which pixel format to use? Perhaps accompanied with a helpful hint that if you use YUVA with certain CUDA functions, you're screwed! See below for a mockup of what I mean.

This would serve as both control of the settings, and visual feedback of what the current settings are.

Question: What video/picture format does Vegas pass to Voukoder? Is it raw bitmap, or some form of h.264? If h.264, maybe h264_cuvid would offer an advantage over hwupload_cuda. I found that this was necessary for processing h.264 source material in FFmpeg, seems to be able to cope with a lot of different h.264 flavors. Maybe this wouldn't be useful here. Just a thought. See my command lines in Post #4 above for how I used this.

Zitat von Vouk

P.S.: I'll also add the 'hwdownload' filter, but I doubt it makes much sense to upload the frame to gpu, scale it, download it to the cpu, then upload it again to encode it ...

In some specific cases it might make sense. Depends on if you need some oddball filter that NVENC doesn't have, or you might want to balance the workload between your GPU and CPU, or even multiple GPUs with different jobs. There are outlying cases where it makes sense.

Zitat von Vouk

This is how VEGAS Pro works. Some important parameters have to be defined in the template.

Hmm, that's unfortunate. Can we at least have some indication of which pixel format the current template uses? Once you rename the template, you lose that information.