Here are some comparative benchmarks that include Vegas Pro v16.424 and Vegas Pro 17.284.
http://rtpress.com/roundup.htm
(UPDATE: also see HEVC 2020 thread)
Started working on this before last Christmas when I was considering the purchase of a 4K camera. In the collaborative I often work with, a couple members have been showing up for shoots with xc10 and bm 4k production cameras and dumping their footage on me. So I’ve been accumulating a number of mixed-resolution projects under my belt; with my own xf305 and jvc hd’s on other tracks. My benchmarking objective was to assemble a Vegas system capable of handling projects with more if not all 4K multi-cam tracks. So my 1st step was to put together an i9-9900k system this past Spring with Radeon VII video.
My Christmas 2018 effort included transcoding the main Sony Red Car footage (clip#3) from its original 1920x1080 50 mpbs mxf format to suitably upscaled 4K. Studying online sample clips and resolving not to get a camera with a lesser mbps output than my Canon, I transcoded the original 4:30 min mxf to 100 mbps Prores using ffmpeg, matching file size and other parameters of the samples I found, as best I could. Clips #1 and #2 of the original Red Car are actually just compressed versions of clip#3 squeezed down to around 24 mbps and 13 mbps. My cohorts seem to think a lowest useable 4K compressed limit might be 20 mbps so we went with that using Mainconcept and AMD VCE encoders on the original mxf. That coincidentally seems to match the bit rate that Magix uses for proxy files, though we didn’t think of looking at that at the time.
I’ve learned allot over the years about how to use Vegas by studying the original Red Car project. Like how to put a proxy or different camera angle in a box or overlay a track with it faded. I use that to good effect in concert and theatrical musical videos with the players hands or faces. And observed that if used in a window or faded like a ghost, a compressed version of the clip gives great timeline performance… and might even be left in the final render without any visible quality loss. The 4K Red Car tries to follow that learning. I’ve also included a 4K Red Car Torture version… the only difference being that in the Torture project, clip#3 is mapped to both clips#1 and #2. This is meant to measure what happens when 100 mbps 4K clips are used on all the tracks… keeping in mind that many video projects might not actually play two 4K clips on top of one another for long stretches. But crossfades between cameras do add up.
Mine is not the 1st 4K Red Car effort here. At least 2 others lead the way with earlier versions of Vegas:
https://www.vegascreativesoftware.info/us/forum/4k-scs-benchmark--99009/
https://www.vegascreativesoftware.info/us/forum/v15-4k-render-benchmarks--108438/
You might have seen my mention of this effort in a couple of other threads this past Spring. It seems to have inspired a new community effort called the Sample Project which I have followed with interest. You might notice that I admired it so much, I shamelessly ripped off their spread sheet presentation, adjusting column headers a little for clarity, and being a little more fastidious in listing my encode mode. I encourage everyone to check out the Benchmarking thread, and if you run your own timings for it, be sure to report them there:
https://www.vegascreativesoftware.info/us/forum/benchmarking--116285/
I’ve studied the Sample Project and it’s quite different in approach from the Red Car. For one, it makes no effort to resemble a real world video project shot with a 4K camera. It uses a single mp4 video track, but at around 10 mbps, that’s kind of window dressing. The real action is in 4 tracks that play concurrently with the mp4 running a media generator called the Vegas Noise Texture. It basically uses a noise generator to create a simulated video load on the fly. So the benchmark actually measures the efficiency of Vegas both creating the load and processing it. The 2 loads could be separated by muting all the other clips, rendering each track having noise generator clips, then substituting rendered output back into the project and alternately muting original and substitute clips. I leave that as an exercise for others. To the extent that a media generator resembles a 4K camera clip, it would model such clips being played concurrently on 4 tracks. Although that might not be common for real world 4K camera projects, the big advantage of the Sample Project benchmark is it’s relatively tiny to download and is a good yardstick of relative cpu and gpu performance under stress. So long as measurements are taken and presented in a way that does not comingle both cpu and gpu in all of its measurements. Assuming you want to use this data to make informed decisions on CPU’s independent of gpu purchases.
In all of my own timings I have taken care not to conflate combined CPU and GPU performance as reported cpu-only timings. Generally speaking, any gpu performance measurement will use a mix of cpu and gpu… gpu-enabled encoders, however, vary in how and when they choose one over the other. Which is clearly reflected in observed timing. But a true CPU-only measurement is required as a yardstick if you want to estimate the GPU contribution of a particular encoder. I was able to do that for both Mainconcept and AMD VCE encoders because they do not disappear when I disable GPU in Vegas video settings. When I tested physically removing the GPU, AMD VCE disappeared as a render option but I confirmed that timings for Mainconcept were identical to disabling gpu in Vegas. So I feel reasonably confident that when I only disable GPU in Vegas, it’s not being used when I run AMD VCE which yields much lengthier timings. QSV is different, however. I can still run the QSV encoder even though I might not select Intel as the Vegas GPU… and it runs even faster. Being that it’s an internl GPU that is tightly bound to my Intel CPU and motherboard chipset, I suspect the CPU might be handing off operations to the iGPU without regard to what Vegas asks. So all my QSV timings are with iGPU enabled in bios and all my other timings are with iGPU disabled in bios… in which case QSV disappears as a Vegas render option and I cannot get a CPU-only render with that encoder and view it as a GPU/CPU-only encoder.
Note that I’ve made no effort to assess relative render quality. Without honest to goodness high quality 4K camera footage, I don’t think that’s possible.
If you want to run your own timings yourself, get the project here:
https://drive.google.com/open?id=1TK2lyFZSlzU9JQ8xO1mvoj-zl9tyj2lc
I’ll try and leave it there for Googles of years, or their lifetime, whichever is shorter .
Feel free to post your own 4K Red Car timings here. But I’m not inclined to add any but my own to my spreadsheet. I do have at least 2 more systems of my own that I hope to add… a Microsoft Surface Book and an Intel NUC. I do, have 4 Vegas licenses to go around, now that I jumped on the 16+17 deal! But it’ll take a little juggling. Speaking of 17… expect I’ll be doing it again sometime soon.
Just remember that benchmarking is mostly a waiting game. During which time reading the refraction patterns in a glass of fine whiskey on the rocks helps pass the time. Then when all is said and done, you can proudly proclaim, “I Benchmark, and I know things.”