Custom Proxy files?

NickHope wrote on 3/28/2019, 11:17 PM

...Are there any options to control the how the proxy file gets created?...

No.

See section 9 of this post for a summary. 9c and 9d detail a couple of plugins you can use to make proxy use easier.

Marco. wrote on 3/29/2019, 6:40 AM

The internal generated proxy files are 1280x720.

Eagle Six wrote on 3/29/2019, 12:12 PM

@vidx in addition to @NickHope and @Marco. just to confirm, when you use the built in proxy feature of Vegas Pro, when you playback, the Preview Quality needs to be set for 'Preview' or 'Draft', then Vegas is using the proxy and should provide better playback. If your Preview Quality is set for 'Good' or 'Best' Vegas will use your source media and you will not have any advantage of building the proxy file.

If you use something like 'Cineform' to create proxies, you can manually right click on the proxy in the Project Media bin and select 'Replace', then navigate to the original source media, select it, and the original source will be replaced in your timeline. You might see a difference in playback using the Cineform codec, but maybe not. A test in your system would determine that, my system will run UHD Cineform intermediates at full speed in preview quality Best/Full, so I cannot test to determine if a 720p Cineform proxy is any advantage.

Kinvermark wrote on 3/29/2019, 2:01 PM

@Eagle Six Scrubbing backwards rapidly usually illucidates this difference. :)

I have never used the internal proxy feature of Vegas. Always just made my own in various ways (Vegasaur with Vegas, or one of myriad other pieces of software external to Vegas). That way you have a lot of options for size and codec (for me usually cineform - HD least, or MagicYUV.) It's now easy to swap as EagleSix has explained.

Internal Vegas proxy feature is better in that it is automatic and switches between proxy and original just by changing the preview quality. However, I find cineform degrades so elegantly, that even HD least is a workable representation of UHD media.

AVsupport wrote on 3/30/2019, 4:53 AM

Just had a play with proxies today, replacing 4K XAVC-S/25p clips on a 1080/25 project. Once they were created, I inspected with VLC to learn that the *.sfvp0's are 'mpeg 1/2 video mpgv at 23.976024 fps' that's been created... wtf? Is this normal? Is 24film drop frame at the heart of VP? Is this why my 25fps looks so bad??

What about having the option to create meaningful intermediate codecs as a 'quasi-proxy' if editing 4K is 'too hard' [not for Resolve, it isn't..I checked again today]

Marco. wrote on 3/30/2019, 5:00 AM

This was often discussed. The internal Vegas Pro proxy files do not have a dedicated frame rate. The proxy system uses the raw video stream (which is XDCAM EX 1280x720) but it reads the frame rate meta data from the source files meta data. So the proxies used in Vegas Pro will always automatically adopt its frame rate to the original source frame rate.

Confusion always arise if people start using SFVPO files separately so the meta data could no more be used correctly. These files only work correctly when used in the given Vegas Pro proxy workflow.

AVsupport wrote on 3/31/2019, 7:24 AM

IS there such a thing as a 'native codec' that VP is based on?

Marco. wrote on 3/31/2019, 10:00 AM

In which meaning of "native"?

AVsupport wrote on 4/1/2019, 12:02 AM

In which meaning of "native"?

hmm, I was wondering if there was an internal video processing codec that VP is based on, so, if there was, if it would help to use an intermediate that is VP 'friendly', perhaps a variant, as opposed to feed CPU intensive XAVC-S files for example..; in the meantime I shall try the 'batch render' script as suggested by Nick

AVsupport wrote on 4/1/2019, 1:17 AM

Just checked out the 'batch render' to 'Magix Intermediate HQ' (4K)..:

Transcoding multiple selected 4K XAVC-S files into what turns out to be 'Apple ProRes 422 HQ (apch)' took 100% CPU 28'30" for 7'32 source material. All into one single file.

Plus, trying to playing this back in realtime makes my HDD cringe 95% (which is usually ~1-2%), resulting in ~5 fps playback speed...at least I know where the bottleneck is (in this instance) now.

Not so exciting so far..

AVsupport wrote on 4/1/2019, 1:49 AM

'Batch render' to XAVC Intra 4K: render duration 21'30" with the help of 12% GPU, playback is stuttery even though HDD is ~30% and CPU ~60% load. not the expected result either

Marco. wrote on 4/1/2019, 2:31 AM

"hmm, I was wondering if there was an internal video processing codec that VP is based on"

Video processing can only be based on decoded (and thus uncompressed) video.

AVsupport wrote on 4/2/2019, 3:08 AM

Render to GV HXQ : 8'41" (fast!) and playback is awesome: CPU ~15% and GPU on a higher load, ~38%. excellent. that is what I wanted ;-) more tests to follow soon cheers

Marco. wrote on 4/2/2019, 4:01 AM

Both HQX and CineForm are very good codec choices though these ones are rather meant to be used as intermediates than as proxy files. Of course this would depend on the particular codec settings used.

AVsupport wrote on 4/2/2019, 7:19 AM

I'd love it if I could replace my original XAVCS 4K files with good playable quality intermediates, like you do with proxies, from within VP, as a workaround for the meager timeline playback performance that I am currently experiencing (possibly due to the effect that there is no GPU hardware acceleration for XAVCS in VP) . However, the 'batch render' script only outputs a single file, and the codec choice there seems restricted (or maybe I am not seeing the tree in the forest again) in thus I cannot edit the presets, and I am not seeing the custom ones I have created...

I'd love it if the 'proxy creation' feature would allow choice of codecs like 'Render As' etc has, and not limit to a single preset

Marco. wrote on 4/2/2019, 8:24 AM

That's what Vegasaur offers, in case you already use it.

AVsupport wrote on 4/2/2019, 5:29 PM

Haven't been using Vegasaur so far, was hoping for an internal workflow first, but might have to explore this option, thanks! (Doesn't VP have a standalone file management tool https://www.vegascreativesoftware.com/au/vegas-production-assistant-pro/workflow-automation-tool/..what happened to that, anyone using that, why isn't that part of a meaningful 'bundle'?)

john_dennis wrote on 4/2/2019, 5:43 PM

@AVsupport

My Sony RX10-IV has an option to shoot UHD XAVC-S at 100 Mbps and save 720p proxies simultaneously. Do any of your Sony cameras have a similar option?

I have shot creating proxies along with the main files, but I don't have to use proxies to get my work done so I don't use the option.

AVsupport wrote on 4/2/2019, 11:09 PM

Thanks @john_dennis but this is not the direction I want to head ;-) I don't think my A7iii does nor do I want to torture my camera..I'd like to maintain as good as a preview quality as I can manage, don't like the 'VPproxy' look..but wouldn't mind FHD Intra as Proxy...

Waiting to see what Sony comes up with at the next CP+ show..I think they've got something in the bag re new software etc..; Not sure if I want to spend an extra $100 for Vegasaur or $250 for a mediocre "Production Assistant' just to do a little bulk transcoding..That's almost more than VP16 Edit is worth (upgrade, on special)

NickHope wrote on 4/2/2019, 11:24 PM

I'd love it if I could replace my original XAVCS 4K files with good playable quality intermediates, like you do with proxies, from within VP, as a workaround for the meager timeline playback performance that I am currently experiencing (possibly due to the effect that there is no GPU hardware acceleration for XAVCS in VP) . However, the 'batch render' script only outputs a single file, and the codec choice there seems restricted (or maybe I am not seeing the tree in the forest again) in thus I cannot edit the presets, and I am not seeing the custom ones I have created...

I'd love it if the 'proxy creation' feature would allow choice of codecs like 'Render As' etc has, and not limit to a single preset

@AVsupport You can use the RenderEvents within Happy Otter Scripts, or, if you subsequently want to be able to switch easily between originals and proxies/intermediates, ProxyAssist. In either of them you can render to any format that is available to Vegas, as well as x264 AVC.

AVsupport wrote on 4/2/2019, 11:28 PM

Thanks @NickHope I will give this a try!

AVsupport wrote on 4/3/2019, 1:12 AM

I just have tried Happy Otter and Yes! This guy is up for an award in my opinion! Finally a workflow that works ;-) Encoding to GV HQX1920x1080 codec (in less than realtime) gives me playback at CPU 22%, GPU 10%. Applying Filmconvert Pro 2.15, ColorFast2, Ignite Vibrance and Vegas Sharpening, playback is at CPU 50%, GPU 20%. Couldn't ask for more. This has made my day, Thanks so much @NickHope @Marco. @john_dennis

AVsupport wrote on 4/14/2019, 7:20 AM

Here's a couple of early findings:

For me, what matters is 1) encoding time, 2) playback performance with applied FX [here: FilmconvertPro2.15, ColourFast2, IgniteVibrance, VegasSharpen], 3) filesize, whilst maintaining FHD project resolution.

All of them 'looking good', at comparable quality (apart from the freaky AVC CPU render results which I have double checked..??)

So far my favourite being x264 AVC NVenc (this was vbr). Was expecting more speed from XDCAM since this is a blown up variant of the VP 'native' proxy choice (using the 'old' compoundplug), but this didn't convince. Had also more hopes for GV HQX, but numbers don't support the quick love. And can't hide my disappointment for Magix Intermediate which is a complete Fail on my system, playing back worse than the original dreaded 4K long-GOP.

Still haven't dared to re-enable iGPU, hence no Intel on Intel QSV ;-) and noticed I didn't have Cineform codec installed, next time.

All done and measured through the Fabulous Happy Otter Scripts. Thanks to @wwaag moving Vegas forward

AVsupport wrote on 4/18/2019, 4:10 AM

Please note: above table is Wrong, as I was comparing original with intermediates with FX applied. please see below for update:

becomes clear, there's little difference between x264 CPU and NVenc, apart from encoding time.