Why is it so hard to add NVENC to Vegas?

Richvideo wrote on 4/19/2017, 5:24 PM

I don't get why we can't make use of NVENC encoding in Vegas (gtx 960 card), I had a simple 1920X1080p project that I needed to render out with the Red Giant Film filter enabled, it was going to take well over a hour to render a HEVC version of it within Vegas. I ended up frameserving the project to TMPGEnc Video Mastering Works 6 and it only took 25 mins to complete that way and the quality was fine. I don't understand why this is difficult to implement in Vegas?

Comments

Musicvid wrote on 4/19/2017, 7:15 PM

It would add to the price of the product to benefit a minority of users.

Richvideo wrote on 4/19/2017, 10:36 PM

So you are saying that only a minority of users would be interested in having the ability to take advantage of the full power of their GPU to increase productivity? How much would it really add to the cost of the product, TMPGEnc Video Mastering Works 6 is very reasonably priced and it makes use of NVENC in its rendering engine so why would it be a monumental undertaking to add this ability to the Vegas render engine and why would it increase the price of the product dramatically? Are you saying that faster H.264 and H.265 (HEVC) encoding is not a priority?

Jam_One wrote on 4/20/2017, 4:14 AM

...Lets take me as an example.
My workflow goes such ways it takes 12-15 minutes of "astronomic" time to process 1 minute of "video" time.
Fifteen minutes of processing for One minute of video.
So, encoding times sink & dissolve deep within the processing routine. Encoder waits for processed frames. And waits. And waits... I could not be interested in "accelerating" the encoder to any extent because in no way I am going to see "acceleration" with my current workflow. Yes, I could not care less...

(Much more greater benefit for me would be acceleration of ReVision RSMB plugin which slows the things noticeably.)

OldSmoke wrote on 4/20/2017, 9:01 AM

I also don't care much about NVENC. It's proprietary to NVIDIA and will add cost to the product. I prefer better timeline preview, especially for 4K and that is OpenCL driven in Vegas, which is free. Maybe when NVIDIA finally catches up to AMD in terms of OpenCL capabilities would I change back to NVIDIA cards and maybe then will ask for NVENC. The other issue is that NVIDIA likes to change the way things are implemented, CUDA for example. It changed after FERMI and broke the encoding for VEGAS.

Proud owner of Sony Vegas Pro 7, 8, 9, 10, 11, 12 & 13 and now Magix VP15&16.

System Spec.:
Motherboard: ASUS X299 Prime-A

Ram: G.Skill 4x8GB DDR4 2666 XMP

CPU: i7-9800x @ 4.6GHz (custom water cooling system)
GPU: 1x AMD Vega Pro Frontier Edition (water cooled)
Hard drives: System Samsung 970Pro NVME, AV-Projects 1TB (4x Intel P7600 512GB VROC), 4x 2.5" Hotswap bays, 1x 3.5" Hotswap Bay, 1x LG BluRay Burner

PSU: Corsair 1200W
Monitor: 2x Dell Ultrasharp U2713HM (2560x1440)

Musicvid wrote on 4/20/2017, 9:11 AM

Oh, no, I wasn't saying that.

I am asking if a MAJORITY of users would benefit from robust Quicksync, NVENC, and AMD-VCE encoding, and whether they would consider it worth the cost paid to licensors?

TheHappyFriar wrote on 4/20/2017, 10:55 AM

I never even bothered with gpu encoding. To many restrictions and dependant on another piece of hardware\software combo. I bought Vegas specifically because I didn't need special hardware to use it.

Richvideo wrote on 4/20/2017, 3:37 PM

Jam you probably have a newer/faster CPU and motherboard than I do and so you are not in need of a speed boost, those of us on a budget and working with older hardware do, cutting down a render from 1h and 30mins to 25 mins is a big deal to me and I am sure to others. A few of you are speculating on what it would cost to license the tech and you seem to think it would be high--not sure what makes you think that? TMPGEnc has Quicksync and NVENC and the program is only around $100 dollars.The Neat Video plugin for Vegas makes full use of GPU acceleration and they don't seem to be worried if Nvidia is going to change some code on them and if they do they are usually quick to fix it as they have done so in the past. My understanding is AMD-VCE quality is poor compared to NVENC and NVENC is a bit better than Quicksync.

john_dennis wrote on 4/20/2017, 4:14 PM

Have you done a "feature request" with Magix. Few, if any, of the folks here are coders or software project managers.

Kinvermark wrote on 4/20/2017, 4:20 PM

For me, timeline editing performance and output encoding quality are highest priority by far. Fast encoding is a "nice to have", but as long as it is reasonable, I am prepared to go "have a cuppa tea."

The details of how to achieve these things is something for the tech experts at Magix.  

 

Musicvid wrote on 4/20/2017, 5:25 PM

To parrot an old :saying:

Size, Quality, Speed. Pick two.

OldSmoke wrote on 4/20/2017, 5:57 PM

Jam you probably have a newer/faster CPU and motherboard than I do and so you are not in need of a speed boost, those of us on a budget and working with older hardware do, cutting down a render from 1h and 30mins to 25 mins is a big deal to me and I am sure to others.

If cutting down render times is a "big" deal and you are obviously getting paid for your work, why not invest in a newer/faster system? You would rather wait for MAGIX to implement a faster encoding procedure? Doesn't make sense to me, not from a business point of view anyways.

Proud owner of Sony Vegas Pro 7, 8, 9, 10, 11, 12 & 13 and now Magix VP15&16.

System Spec.:
Motherboard: ASUS X299 Prime-A

Ram: G.Skill 4x8GB DDR4 2666 XMP

CPU: i7-9800x @ 4.6GHz (custom water cooling system)
GPU: 1x AMD Vega Pro Frontier Edition (water cooled)
Hard drives: System Samsung 970Pro NVME, AV-Projects 1TB (4x Intel P7600 512GB VROC), 4x 2.5" Hotswap bays, 1x 3.5" Hotswap Bay, 1x LG BluRay Burner

PSU: Corsair 1200W
Monitor: 2x Dell Ultrasharp U2713HM (2560x1440)

Richvideo wrote on 4/20/2017, 6:37 PM

Thehappyfriar said "....I bought Vegas specifically because I didn't need special hardware to use it" Oldsmoke is telling me that I need to spend upwards of $800 on a new computer to cut my render speed down when all Magix needs to do is drop NVENC in the render engine and my $200 Geforce card would render almost as fast...and the people in this thread that are concerned about GPU rendering acceleration raising the cost of Vegas are telling me to spend hundreds on a new computer when a much more economical solution could come from Magix.

I don't do retail work as a video shooter so I work with a somewhat fixed budget and buying a new computer is something I will only do when I see a great price to performance system that is somewhat future proof. The new AMD CPUs seem like that they might fit the bill but I will wait to see how they perform once video software from Adobe and others is fully optimized to work with them. I can render to NVENC from Vegas if I frameserve the project from Vegas to TMPGEnc using this Vegas tool

http://www.debugmode.com/frameserver/

I just find it silly to have to jump hoops to do it when it could easily be part of Vegas

Some in this thread keep making it seem like it is a either/or situation in regards to tweaks to Vegas, like we can't get NVENC and timeline improvements...I am assuming that adding NVENC to the render engine would be a easier task than a complete re-work of the Vegas timeline, feel free to correct me if my assumption is incorrect.

 

OldSmoke wrote on 4/20/2017, 8:08 PM

I bought Vegas specifically because I didn't need special hardware to use it...

Yes, that is the good part of Vegas, but don't expect it to perform to its maximum potential when your hardware falls into the "minimum required" category.

when a much more economical solution could come from Magix

Two things. 1st) Yes, economical for you, but maybe not for Magix and 2nd) While you are waiting until who knows how long, the new and faster editing machine may have paid for itself already.😉

 

Last changed by OldSmoke on 4/20/2017, 8:09 PM, changed a total of 2 times.

Proud owner of Sony Vegas Pro 7, 8, 9, 10, 11, 12 & 13 and now Magix VP15&16.

System Spec.:
Motherboard: ASUS X299 Prime-A

Ram: G.Skill 4x8GB DDR4 2666 XMP

CPU: i7-9800x @ 4.6GHz (custom water cooling system)
GPU: 1x AMD Vega Pro Frontier Edition (water cooled)
Hard drives: System Samsung 970Pro NVME, AV-Projects 1TB (4x Intel P7600 512GB VROC), 4x 2.5" Hotswap bays, 1x 3.5" Hotswap Bay, 1x LG BluRay Burner

PSU: Corsair 1200W
Monitor: 2x Dell Ultrasharp U2713HM (2560x1440)

NormanPCN wrote on 4/20/2017, 8:13 PM

I suppose that adding NVENC to the Sony AVC encoder may not be a lot of work. I say that since that encoder is where Quicksync has been supported in Vegas for a while. Sony AVC is a software encoder but also has an option to use Quicksync. So it is structured internally to offload to a fixed function hardware encoder and NVENC is probably not so different from Quicksync AVC encode.

One thing to consider is that GPU encoders are not up to the quality of something like x264. At high bitrates most eyes will not see differences. No so at low bitrates. Excluding Blu-ray, the world of video deliver these days is low bitrate. Even the Mainconcept AVC encoder in Vegas is not up to x264.

Personally, I could use/support a NVENC encoder for high(er) quick test encodes. Otherwise, for me, it's x264 or nothing for AVC encodes. I use frameserving from Vegas to ffmpeg to get access to x264 without an intermediate encode file. If I wanted uber fast test encodes, x264 can run at/near GPU encoder speeds at similar quality, using something like the superfast preset. By using x264 I don't have to worry about final quality. It is as good as we have available to us.

With that said, I could really support Vegas having native x264 support. Frameserving does have its quirks. x264 is GPL, but there is commercial licensing available. Of course that is cost. Then you have to fit it (x264) into the whole encoding subsystem with the muxer(s). aka Mainconcept.

Richvideo wrote on 4/20/2017, 9:15 PM

Thank you Norman for your input, from my research my understanding is that NVENC was designed to match up with x264 quality from the start. NVENC implementation on the most recent generation cards is almost as good as x264 as well as faster encode speeds(depending on what software is being used). Quicksync and AMD GPU encoding don't come close to x264 quality.

Why does NVENC need to be tied just to Sony AVC, HEVC (H.265) is where it is really needed, unless you are working with one of the newest generation CPUs h.265 is difficult to render out quickly, depending on what software you are using to encode NVENC it can render a h.265 file that looks just as good as x265 at the same bitrate

For some reason Vegas wraps h.265 in a MOV instead of a MP4 wrapper, not sure what the advantage of that is?

This thread is a few years old but it touches on a few of things I just mentioned in this post

https://forum.videohelp.com/threads/371187-Testing-NVENC-with-the-GTX-960

 

Nigel wrote on 4/21/2017, 10:10 AM

If Tmpgenc can sell their impressive Mastering Works 6.x product for $122

that does x264, x265 and solid GPU encoding with Nvidia nvenc,

AMD GPU H.264/AVC hardware encoder and decoder functions,

10-bit 4:4:4 H.264/AVC Input and Output,

High-Precision Deinterlace,

then there is no reason why Magix cannot also do it in their Pro $599 product.

Tmpgenc also sell their SDK that Magix could negotiate and license to add

these features quickly to their product.

I have been in the software development industry for 30 years. Have both coded and worked on many partnering deals.

Price is not a reasonable argument.

P.S. I also agree with Richvideo that wrapping/muxing h.265 in only mov is strange, when the clear standard for playback wrapper compatibility for computers and devices, for the past several years is mp4

NickHope wrote on 4/21/2017, 10:23 AM
P.S. I also agree with Richvideo that wrapping/muxing h.265 in only mov is strange, when the clear standard for playback wrapper compatibility for computers and devices, for the past several years is mp4

It may be related to the fact that it shares the same new DLL with the ProRes codec which is obviously MOV only.

Former user wrote on 4/23/2017, 6:29 AM

Maybe its a case of waiting for Version 15?, then Magix gets paid for it. I see ffmpeg supports nvenc, I tried some command line tests but just kept getting errors, no luck, doing something wrong. What Norman is doing is attractive, frameserving to ffmpeg, not sure how easy/difficult that is to set up though?

Vegas is definitely not the fastest kid on the block when it comes to codec improvements, for example still no GH5 422 10 bit support, GJeffrey on this forum came to the rescue here though with his wrap to .mxf.

Live horse and you'll get grass I guess😩

 

 

 

NormanPCN wrote on 4/23/2017, 2:51 PM

What Norman is doing is attractive, frameserving to ffmpeg, not sure how easy/difficult that is to set up though?

Pretty easy. The usual frameserving requirements for having Avisynth installed. I use Avisynth+. You have to use a 32-bit version of ffmpeg because debugmode frameserver is 32-bit.

Here is a sample script that encodes using the x264 encoder. You can encode to anything that ffmpeg supports. I do the RGB -> YUV conversion in Avisynth since ffmpeg is pretty quirky doing RGB->YUV. It uses rec601. In this frameserve+script setup the Vegas output file is always "server.avi" and the result is always "output.mp4". So after starting the frameserver in Vegas I just double click this or any of my other ffmpeg frameserve scripts.

@echo off

title encode crf23

REM setup PATH to include ffmpeg binaries folder
call "%~dp0set_path32.cmd"

cd d:\renders
d:

REM output the AviSynth commands
echo AviSource("server.avi") > server.avs
echo ConvertToYV12(matrix="rec709") >> server.avs
REM echo ConvertToYV12(matrix="PC.709") >> server.avs

ffmpeg.exe -i server.avs -c:v libx264 -preset slow -profile:v high -crf 23 -colorspace bt709 -color_primaries bt709 -color_trc bt709 -pix_fmt yuv420p -bufsize 40M -maxrate 40M -c:a aac -b:a 192k -chunk_size 64K output.mp4

pause

del server.avs

REM saved commands for alternate audio output formats and bitrates
REM (mp3 160k vbr) -c:a libmp3lame -qscale:a 4
REM (mp3 192k vbr) -c:a libmp3lame -qscale:a 2
REM (aac 192k vbr) -c:a aac -q:a 1.7
REM (aac 192k)     -c:a aac -b:a 192k

 

Former user wrote on 4/23/2017, 3:57 PM

Thanks for that Norman, very nice.

alexander-nNevis wrote on 4/24/2017, 11:06 AM

I have the camcorder: "JVC GY-HMQ10," which creates video files in 4K 60P 4:2:0.

I have a computer: Intel Core i7 6900(4 GHz) w/o "Quicksync" , 8 cores, DDR-4 2400 64GB RAM, GTX 1080.

Here's an example:

The video, filmed "With hands" in a "4K 60P" format, duration 20 seconds
encoded in HEVC format with maximum quality.

The result:

"Vegas Pro 14" CPU only - 20 min..
"TMPGEnc Mastering Works 6.0" CPU+ GPU (NVENC) - 2 min.

It's Quite tempting to have this ability in "VP14"

Last changed by alexander-nNevis on 4/24/2017, 11:17 AM, changed a total of 1 times.

Camcoders: Panasonic Lumix-DC-GH5, Sony DSC-RX10M4, Sony FDR-X3000

Windows 10 Pro 64-bit 2004, Intel Core i9 10920X, ASUSTeK "X299 PRIME EDITION 30" (SOCKET 2066), 64 Gb DDR4-3200 G.Skill RAM, 200GB INTEL SSD (System), 800 Gb INTEL SSD for NLE, Same HDD for data, Creative Sound Blaster AE-9, NVIDIA GeForce RTX 2080Ti.

NormanPCN wrote on 4/24/2017, 12:12 PM

If you want to use NVENC HEVC right now, you can via frameserving. This script is nearly identical to the previous one I posted this thread, except for changing the ffmpeg command to use NVENC HEVC.

@echo off

title encode NVENC HEVC 9Mbps

call "%~dp0set_path32.cmd"

cd d:\renders
d:

REM output the AviSynth commands
echo AviSource("server.avi") > server.avs
echo ConvertToYV12(matrix="rec709") >> server.avs
REM echo ConvertToYV12(matrix="PC.709") >> server.avs

ffmpeg.exe -i server.avs -c:v hevc_nvenc -preset:v slow -profile:v main -b:v 9M -maxrate 15M -colorspace bt709 -color_primaries bt709 -color_trc bt709 -pix_fmt yuv420p -c:a aac -b:a 192k -chunk_size 64K output.mp4

pause

del server.avs

REM saved commands for alternate audio output formats and bitrates
REM (mp3 160k vbr) -c:a libmp3lame -qscale:a 4
REM (mp3 192k vbr) -c:a libmp3lame -qscale:a 2
REM (aac 192k vbr) -c:a aac -q:a 1.7
REM (aac 192k)     -c:a aac -b:a 192k

 

clive.gardner wrote on 4/24/2017, 12:20 PM

Don't quote me on this, but based on some digging I did around another product which had similar issues starting from the launch of the 600-series Kepler cards, the reasoning seemed to be that when Nvidia originally launched GPU acceleration, Main Concept were one of the only companies who developed a reference implementation to support it. As a result their code was licensed and used by pretty much everyone who offered GPU assisted encoding in their products.

As OldSmoke says, the Kepler architecture brought some large under-the-bonnet changes to the way GPU assisted encode worked, but by this time Main Concept had stopped supporting their code and showed little interest in updating it to support the newer architectures.

This is supposedly the reason so many products either dropped the feature, or remain tied to the older Fermi cards - these features require complete re-implementation from the ground up to get them working again which is a fairly sizeable task in a legacy application.

NormanPCN wrote on 4/24/2017, 1:04 PM

The Mainconcept GPU AVC encoders were shader based. They did a CUDA implementation and an OpenCL implementation. They were all hard coded to specific GPU architectures. The CUDA to specific Nvidia and the OpenCL to specific AMD. All old and never updated. They did not implement generic CUDA/OpenCL versions that would work on new/different architectures. They only had a tuned/optimized version for each GPU architecture generation they supported at the time.

The GPU vendors had been adding fixed function hardware AVC and HEVC encoders. They have been getting better in each generation of newer GPUs. For the crowd that wants fast, and/or is doing high bitrate, this is the direction the industry is going. Shader based encoders are effectively dead. They are a lot more work to develop and maintain. The GPU vendors are putting a fair bit of effort into their fixed hardware encoders so just run with that.