The free Voukoder continues to work even if it's not updated anymore.

But will there be a necessary connector to install free Voukoder in future versions of Vegaspro?

There will not be connector updates and it's unknown whether the current connector will continue to work beyond 22. In the past copying and pasting the connector to the right folder worked with certain multiple versions of VEGAS.

I have Voukoder working in VP22 & I shared the Voukoder / connector downloads in this Vegas forum post on 2/20/2025, I got them from this Voukoder website post but the Github links no longer work.

The final post on that last link

Vouk - Administrator

March 25, 2025

Official Post

Important: I'll stop distributing the old version of "Voukoder" and its Connectors by the 2025-04-30. If you want to keep the installers, start making backups of it now. The version will (most likely) continue to work.

There will not be connector updates and it's unknown whether the current connector will continue to work beyond 22.

There is a Voukoder connector for VP22 and I using it all the time.
Unfortunately, developer not publishing free version any longer and current Pro version has an issue with audio (that free version do not have). The issue is in dev's todo list atm.

When looking into the pro version I scanned the comments section and the developer did say there was an issue with Vegas Pro where he may not be able to support it in the future.

Here is the text: It's quite difficult to find this issue. My guess is it doesn't load because an old Voukoder (Non-Pro) component has been installed earlier, although I developed it in a way so this couldn't happen. But I can't attach a debugger to it to debug my plugin running in VEGAS Pro. The VEGAS Pro developers are protecting it against debuggers so I can't step through my plugin. This means basically they either give me help and / or the possibility to debug my plugin or I have to stop supporting VEGAS Pro. Sigh ...

So I managed to get FFMetrics to work and obtained the following Vmaf values for a complex detailed clip at the following VBR bit rates with :
Original Clip 101Mb/s size 301Mb
H264 98/196 Vmaf 95.4109 size 126Mb reduction 42%
AV1:
90/180 Vmaf 100.0000 size 277Mb red 92%
80/160 Vmaf 100.0000 size 245Mb red 81%
70/140 Vmaf 99.9849 size 215Mb red 71%
60/120 Vmaf 99.7022 size 185Mb red 61%
55/110 Vmaf 99.1043 size 168Mb red 56%
53/106 Vmaf 98.9954 size 163Mb red 54%
50/100 Vmaf 98.2492 size 154Mb red 51%
40/80 Vmaf 95.7581 size 124Mb red 41%
30/60 Vmaf 91.6335 size 93Mb red 31%
20/40 Vmaf 84.1775 size 61MB red 20%

Just a question, you are talking about MP4 .H264/265 archival here, it is not ProRes or some lossless codecs which will use up alot more storage space. Storage is so freaking cheap now a day. A 1TB SSD or NVMe .M2 will be able to store so many compressed MP4 files. I archive my important video file in ProRes and when I archive MP4 files, I always go with higher bitrate because with higher bitrate I can further edit the video if needed and not worry to much about the video file falling apart when re-edited. just my opinion.

Thanks Bruce, I am using MP4 AV1 (replaces H265). I am aware that H266 is starting to make an appearance but is much more intensive to encode and decode. I take your point about lossless ProRes, I must see what file size I get with it.

Thanks Bruce, I am using MP4 AV1 (replaces H265). I am aware that H266 is starting to make an appearance but is much more intensive to encode and decode. I take your point about lossless ProRes, I must see what file size I get with it.

ProRes 422 standard file size is much more manageable then ProRes HQ/XQ. No need for the HQ/XQ.

Original Clip 101Mb/s size 301Mb
H264 98/196 Vmaf 95.4109 size 126Mb reduction 42%
AV1:
90/180 Vmaf 100.0000 size 277Mb red 92%

What are these numbers at the beginning of line '98/196', '90/180' etc?

Avg/max bitrate for your encoder?

If so, I stop using it long time ago as required bitrate depend on content too much. 'Speaking head' require less bitrate and high bitrate is just overfill, while dynamic scenes in forest require high bitrate.
So I'm using CRF for years.

BTW, there are many different flawors of 'h264'. For example one can use GPU for produce h264 with no b-frames %-)

Also, AV1 it much harder to play and my mother's old laptop was not able to play it at all. Some mobile devices could struggle as well. So encoder choice should depend on what are you going to do with your rendered media.
 

Storage is so freaking cheap now a day. A 1TB SSD or NVMe .M2 will be able to store so many compressed MP4 files. I archive my important video file in ProRes and when I archive MP4 files,

Good for you.

But this does not fit my situation, for example :-P

I have 1 TB+ home videos already with bitrate ranged from 10 Mbps to 60 Mbps, average is about 30 Mbps. For storing this in ProPesor or similar would require 15x more space (as bitrate would start from about 500 Mbps). So 15 TB just for storing and 30 TB for at least 2 backups. Plus 15x more time for backups (semi-manual process in my case). Cost would be be much higher as well and probability of loosing some data because of non-recoverable errors during copy/storing is also increasing. Relability of data stored for long time on SSD is also questinable.

No one asked, but I don't "archive" video of finished projects. I keep all the source media from cameras, etc., Vegas project files as well as a copy of a FHD and UHD render in the project folder. I render AVC to the current capabilities of the three TVs, two iPads and visiting phones. UHD from a DLNA server (for the TV that can play it over a wired network) is rate-limited to ~45 mbps because of the 100 mbps ethernet adapter in the SONY XR-55A80CL TV. Playing UHD over a wireless network on the Sony XBR-49X800E and the BRAVIA XBR-49X850B is a non-starter so I make a FHD copy available for those. All devices will play UHD from a USB port.

I'm currently keeping two copies of everything on 16TB WD Ultrastar Data Center spinning disks (one spinning and one off-line). I do save a UHD and FHD copy of just the rendered output to a pair of my son's G-RAID Thunderbolt drives. I've still got more money than brains. We'll see which one runs out first.

I do the same as @john_dennis, keep all source media and project files and I'am always able to re-render those projects with whatever fancy codec is available or needed. As​ ​​​​​​@fifonik I use CFR instead of VBR, for my TV it's H265 up to UHD and for my mothers TV it's H264 up to FHD. I use my wireless network to stream from editing PC to my TV for previewing/checking the project. The final render is stored on portable USB HDD's directly attached to the TV's.

@3POINT Out of curiosity: how much storage space are you talking about in TB (excluding backups)?

@fifonik I guess it's about 6TB, my source clips are always selective and mostly short (about 10-20 seconds). They vary from DV, HDV, AVCHD (years 2003-2016) and 4k MP4 (from 2016 till now).

Original Clip 101Mb/s size 301Mb
H264 98/196 Vmaf 95.4109 size 126Mb reduction 42%
AV1:
90/180 Vmaf 100.0000 size 277Mb red 92%

What are these numbers at the beginning of line '98/196', '90/180' etc?

Avg/max bitrate for your encoder?

If so, I stop using it long time ago as required bitrate depend on content too much. 'Speaking head' require less bitrate and high bitrate is just overfill, while dynamic scenes in forest require high bitrate.
So I'm using CRF for years.

 

BTW, there are many different flawors of 'h264'. For example one can use GPU for produce h264 with no b-frames %-)

Also, AV1 it much harder to play and my mother's old laptop was not able to play it at all. Some mobile devices could struggle as well. So encoder choice should depend on what are you going to do with your rendered media.
 

H264 98/196 Vmaf 95.4109 size 126Mb is the settings I have been using previously, now replaced by AV1 VBR 55/106 Vmaf 99.9737 to reduce file size.

You using VMAF score as a comparison.
Do you aware that some VMAF models (including the one that is default in most programs including vmaf.exe and FFMetrics) are taking into account some video properties that not related to quality?

To put it simple, you can create 2 distorted file and one will have worse visual quality, but have higher metric?
In addition, some encoders have additional options to make the result have higher such scores (read about AV1's option 'tune=vmaf')?

If I compare 264 vs 265 vs AV1 I'd:

- Check what tunings are enabled by default in all the encoders I use
- Use VMAF models that not taking into account such properties (with 'neg' suffix)

P.S. Sure AV1 is more modern, with more features and so provides better quality. I'm not arguing that. My point is 'compare oranges with oranges, not oranges with apples'
 

P.S. Sure AV1 is more modern, with more features and so provides better quality. I'm not arguing that.
 

To me it's not better quality, but just same quality at lower bitrates/smaller filesizes. It's all about keeping the quality of the original recording at a lower bitrate/smaller filesize. For personal use, I don't care about filesize only about quality.

The other thing I noticed (this is going back a number of years when AC3 Pro was available in Vegas, V16 was the last version where you could get AC3pro to work before Magix closed all the holes due to licence reasons.) is that to my ears AC3 gives a nicer sound than AAC, more delicate and open. Easier to place instruments. However many times I sit and compare I keep going back to AC3.

You using VMAF score as a comparison.
Do you aware that some VMAF models (including the one that is default in most programs including vmaf.exe and FFMetrics) are taking into account some video properties that not related to quality?

To put it simple, you can create 2 distorted file and one will have worse visual quality, but have higher metric?
In addition, some encoders have additional options to make the result have higher such scores (read about AV1's option 'tune=vmaf')?

If I compare 264 vs 265 vs AV1 I'd:

- Check what tunings are enabled by default in all the encoders I use
- Use VMAF models that not taking into account such properties (with 'neg' suffix)

P.S. Sure AV1 is more modern, with more features and so provides better quality. I'm not arguing that. My point is 'compare oranges with oranges, not oranges with apples'
 

I'm encoding using Happy Otter Render+ with AV1-NVENC, this is my replacement for the free Voukoder option.

No one asked, but I don't "archive" video of finished projects. I keep all the source media from cameras, etc., Vegas project files as well as a copy of a FHD and UHD render in the project folder. I render AVC to the current capabilities of the three TVs, two iPads and visiting phones. UHD from a DLNA server (for the TV that can play it over a wired network) is rate-limited to ~45 mbps because of the 100 mbps ethernet adapter in the SONY XR-55A80CL TV. Playing UHD over a wireless network on the Sony XBR-49X800E and the BRAVIA XBR-49X850B is a non-starter so I make a FHD copy available for those. All devices will play UHD from a USB port.

I'm currently keeping two copies of everything on 16TB WD Ultrastar Data Center spinning disks (one spinning and one off-line). I do save a UHD and FHD copy of just the rendered output to a pair of my son's G-RAID Thunderbolt drives. I've still got more money than brains. We'll see which one runs out first.

Thanks John, I am with you on this, I keep all my camera cards, and my project folders and back these up to a 4TB and 8TB spinny drives. I used to use BluRay DVD to store rendered files but most now have 4K TV's to play video back on. We play back on TV via USB sticks at the moment.

P.S. Sure AV1 is more modern, with more features and so provides better quality. I'm not arguing that.
 

To me it's not better quality, but just same quality at lower bitrates/smaller filesizes. It's all about keeping the quality of the original recording at a lower bitrate/smaller filesize. For personal use, I don't care about filesize only about quality.

Better quality for the same average bitrate and the same quality for lower average bitrate is technically the same, imho.