Beiträge von Vouk

This is coming up again and again. That's why I'm gonna explain it one more time and then pin this topic.

The Basics

The software you are using Voukoder with (i.e. Premiere, VEGAS Pro, ...) needs to render frames first before it hands them over to Voukoder so it can encode them (using CPU, NVENC, ...). The rendering process is mostly done on the CPU and depending on your system and the complexity of your project it takes its time - lets say it can render 13 frames per second.

That means Voukoder gets 13 frames per second which it should then encode with the fastest GPU available (lets assume an imaginary RTX 7090 TI which can do like 700 fps 8K with NVENC).

So you would like to get an export speed of 700 fps because that's what you've just bought this awesome GPU for, right? But how can the GPU do that when it just gets 13 fps from the rendering engine?

This is a so called "bottle-neck" and will be visible as low GPU utilization.

A Step Further

The above assumes the chosen rendering engine is using all CPU cores. But what if it is only using 4 cores (for whatever reason)? Your new AMD Ryzen 9950X with 256 cores is mostly ideling, just as your GPU. And still, Voukoder can't do anything about it, it just takes what it gets and tries to do its best.

In Depth Explanation

See this forum thread: https://www.voukoder.org/forum/thread/352

Edit:

By the way: Container formats create a multiplexed data stream of alternating video and audio packets, like:

VAVAVAVAVAVAVAVAV ...

So after one video frame we have to encode one (or more) audio frames to keep the muxer happy and the video encoder is idleing for that time span:

(Frame #0/x = video, Frame #1/x = audio)

I'll see what I can do about it.

So If I understand this correctly:

• The Video with the transparent background "Voukoder for VEGAS Alpha Channel test" is being exported correctly with that Alpha Channel template, right? If so then basically Voukoder is basically working.
• Even on the timeline everything looks correct.
• When rendering the final video there are issues in the rendered video.

I guess this is an issue with VEGAS and/or with its settings as the transparent video itself is looking correct. But when using this clip again issues are happening. But that's VEGAS responsibility. Maybe you shoudn't use the alpha channel template for the final video.

• Render the text clip with the alpha channel template
• Render the final clip with a non-alpha channel template (as you don't want alpha information there)

That was a bug. It is fixed in the next version.

The website had a little downtime this morning while I was upgrading both the OS and the forum software. Basically I ended up with a clean installation of everything on a new cloud instance. The voukoder.org server got a new IP address and it might take some time until all DNS records are updated.

If you experience any issues with the forum / website please let me now.

Thanks.

NVENC h264 supports only up to 4096x4096 frame size. You might want to use h265/hevc which supports up to 8192x8192.

Overall.

Just wondering ... Did you notice a speed improvement?

I posted a link to a topic that exactly explains the situation of the bottle necks. Don't just read the TL;DR if you want to understand this.

You are comparing "Staxrip" to "Premiere + Voukoder". "Premiere+Voukoder" will always be slower than any single file transcoding software. And Premiere is not using all CPU cores for rendering.

It is explained here: https://www.voukoder.org/forum/thread/352

TL;DR: Staxrip, Hybrid & Co. are not combined with an NLE that has to render each frame first.

Today is VEGAS day. With the latest updates of the connectors I added a "Audio only" template.

Working on it.

Edit: Please try out the latest VEGAS connectors.

Changes:

- Alpha channel templates (VEGAS 18 and 19)

- Speed improvements

Voukoder currently gets the frame data as I420 or P010 from VEGAS only (which does not have alpha channel). I would have to use A410 for this.

Unfortunately I don't have the necessary information to implement this. This is not documented in the DVR SDK.

Please provide a voukoder log file.

Yes.

Copy the directory C:\Program Files\VEGAS\VEGAS Pro 18.0\FileIO Plug-Ins\voukoderplug and the file Voukoder-x64.fio2007-config to:

C:\Program Files\VEGAS\VEGAS Pro 19.0\FileIO Plug-Ins\voukoderplug

Not in FFmpeg:

Encoder hevc_nvenc [NVIDIA NVENC hevc encoder]:
    General capabilities: dr1 delay hardware
    Threading capabilities: none
    Supported hardware devices: cuda cuda d3d11va d3d11va
    Supported pixel formats: yuv420p nv12 p010le yuv444p p016le yuv444p16le bgr0 rgb0 cuda d3d11

The thing is: It doesn't really make sense to have alpha in this kind of lossy codecs. You use h264/h265 as the final output format of your project.

When creating i.e. an overlay in AfterEffects to import this in Premiere again you would use ProRes or other lossless(y) intermediate formats. Esp. with alpha information you dont want to have any encoding artifacts.

What is your use case?

Thanks for the Piwo

To your question:

According to https://developer.nvidia.com/nvidia-video-c…k#NVENCFeatures the size limit for h264 is 4096x4096 and 8192x8192 for h265.

Yes, the format might support this but the libx265 encoder does not accept input formats with alpha channels (yuva):

Encoder libx265 [libx265 H.265 / HEVC]:
    General capabilities: delay threads
    Threading capabilities: other
    Supported pixel formats: yuv420p yuvj420p yuv422p yuvj422p yuv444p yuvj444p gbrp yuv420p10le yuv422p10le yuv444p10le gbrp10le yuv420p12le yuv422p12le yuv444p12le gbrp12le gray gray10le gray12le

VP9 does:

Encoder libvpx-vp9 [libvpx VP9]:
    General capabilities: delay threads
    Threading capabilities: other
    Supported pixel formats: yuv420p yuva420p yuv422p yuv440p yuv444p yuv420p10le yuv422p10le yuv440p10le yuv444p10le yuv420p12le yuv422p12le yuv440p12le yuv444p12le gbrp gbrp10le gbrp12le

So when you select "AMD H264" and you click OK it changes back to "libx264"? That sounds strange.

btw: Not every encoder has presets. Presets are usually supplied by the community.