Comments

Grazie wrote on 5/17/2018, 11:48 PM

Why doesn't the trimmer window use a Preview or Draft mode like the Video Preview window does?

Not a a stupid Question, not at all. Is this option greyed out when Preview option is used from within Trimmer.

 

Shady wrote on 5/18/2018, 12:07 AM

I have never seen an option to change the mode within the Trimmer Window. What Preview option are you referring to?

Grazie wrote on 5/18/2018, 12:25 AM

@Shady : This gets Trimmer into the Video Preview, are you doing this?:

 

Former user wrote on 5/18/2018, 12:31 AM

I would assume it is because it is assumed that your computer can play your raw footage. The preview modes allow you to preview any added effx in real time. I don't think it was designed with formats that overwhelm a computer in mind.

Grazie wrote on 5/18/2018, 12:39 AM

@Former user : ooooh I like your logic!

Shady wrote on 5/19/2018, 10:33 AM

@Former user I agree with the logic also. So here we are today with new high resolution and high bit rates.

It would make sense that they add the ability to scrub/edit from the trimmer in one of these modes.

Vegas has nice new feature of the auto scrub when pointer is over the trimmer window.....

Yet when you scrub you are actually playing back and forth at much faster than normal speed.

Doing that with 4k 100mbs footage is not fun.

 

Cliff Etzel wrote on 5/19/2018, 8:02 PM

@Former user I agree with the logic also. So here we are today with new high resolution and high bit rates.

It would make sense that they add the ability to scrub/edit from the trimmer in one of these modes.

Vegas has nice new feature of the auto scrub when pointer is over the trimmer window.....

Yet when you scrub you are actually playing back and forth at much faster than normal speed.

Doing that with 4k 100mbs footage is not fun.

 

It's not the bit rate from my understanding for editing video - it's the codec. There's a reason Hollywood transcodes all footage to Prores, DNxHD/DNxHR or Cineform - it's easier on system resources not having to process native compressed footage - especially if its RAW or something like XAVC (There's a reason Resolve more or less forces you to transcode compressed footage into a more standard codec for editing/color grading). I've been listening to interviews, reading articles and those who are deeply involved putting together serious hardware setups for editing/color grading have basically said the same thing - do not edit compressed formats - anyone familiar with Eric Bowen of ADK Video Editing might be aware of his expertise in configuring serious post production computers - in this interview, he goes into great length some of the parameters to consider when configuring a computer build depending on the type of footage being edited. (I had no idea that a Xeon isn't necessary for editing)

Although he refers to Premiere Pro and Davinci Resolve in this interview, the information he provides sheds alot of light on what one should choose for hardware for editing.

Former user wrote on 5/19/2018, 8:18 PM

Cliff, I have always advocated using uncompressed for intermediates because it is much easier on the system. But the codecs you listed are all compressed. Prores, DNxHD/HR and Cineform are all lossy compressions. They are optimized for systems, especially QuickTime based systems,so they are easier to edit with. (Prores was developed by Apple for Final Cut, DNxHD was developed by Avid for their systems). Because of storage requirements, technology has moved toward shooting compressed formats, but the ideal would be to shoot uncompressed. Not practical though.

Cliff Etzel wrote on 5/19/2018, 8:52 PM

Cliff, I have always advocated using uncompressed for intermediates because it is much easier on the system. But the codecs you listed are all compressed. Prores, DNxHD/HR and Cineform are all lossy compressions. They are optimized for systems, especially QuickTime based systems,so they are easier to edit with. (Prores was developed by Apple for Final Cut, DNxHD was developed by Avid for their systems). Because of storage requirements, technology has moved toward shooting compressed formats, but the ideal would be to shoot uncompressed. Not practical though.

I understand what you're saying but after listening to the podcast I linked to, the explanation of which codecs one should edit with and why seems to point to the three flavors as being the best compromise for the smoothest editing experience on most hardware. Personally, I'm a Cineform fan due to it being wavelet vs the DCI option of ProRes and DNx - and given that ProRes really isn't an official option on Windows, that leaves Cineform or DNx on Windows. Now that DNx can be wrapped in MXF format, it eliminates the retched issues .MOV containers use to inflict on Windows via Quicktime - which is no longer being developed by Apple. Which takes me back to Cineform in the old school AVI file format.

I'm not sure if Vegas supports DNxHD/DNxHR in an MXF container - I know that Premiere Pro CS6 certainly doesn't. Resolve does natively. Cineform in an AVI wrapper is supported by all three, so I defer to that. Based on what I've learned so far, editing native compressed footage brings more problems than it solves in post. Eric even mentions that even with ideal hardware, editing compressed footage can bring a high end machine to it's knees depending on the complexity of the codec and the number of effects being applied. Utilizing a less compressed codec alleviates much of that. And using an SSD doesn't do anything for editing performance when working with native compressed footage. That's dealt with at the CPU and possibly GPU level. Fast SSD's are when you need fast data throughput - the realm of less compressed/uncompressed footage which doesn't require much of the CPU/GPU. If Vegas were able to make use of the GPU more to help the CPU decode highly compressed footage, we wouldn't be having this discussion. As far as I can tell in Vegas, the GPU is only utilized for the most part for encoding certain file formats when rendering. I've seen my GPU sit at almost zero during playback in Vegas of compressed footage. The CPU on the other hand spikes quite high at times. Premiere is the worst while Resolve will take all that you give it hardware wise and more. I've seen my CPU & GPU utilization max out completely during playback and rendering in Resolve 14 testing I've done - and the renders are the fastest I've ever experience - period. That says alot about the efficiency of the code - and should set the bar for Vegas developers to aspire to. I'd love nothing more than to see Vegas utilize hardware the way Resolve does, but keep the fantastic editing paradigm that we all love in Vegas.

One can only hope.

Former user wrote on 5/19/2018, 9:39 PM

Resolve was originally developed around Nvidia GTX GEFORCE 470 video cards. They would use around 4 cards for hardware rendering. I know this because I have some of the same cards that were used. The company I used to work for provided maintenance on Resolve systems. I don't know what the commercial systems contain now but it was originally designed to get optimum results from Nvidia cards.

NickHope wrote on 5/20/2018, 12:06 AM

@Cliff Etzel What flavor of Cineform are you using (i.e. Which "Encoded format" and which "Encoding quality")? What chain of FX do you typically apply?

fifonik wrote on 5/20/2018, 10:21 PM

Cliff, I have always advocated using uncompressed for intermediates because it is much easier on the system.

That is not true in general. Compression is not always "harder" for system.

It depends.

Simple compression: "Take 1234 and do it 1 000 000 times" is much easier for system than reading uncompressed stream with the same content from HDD (SDD might not help a lot as other computers sub-systems could be a bottleneck).

Camcorder: Panasonic X1500 + Panasonic X920 + GoPro Hero 11 Black

Desktop: MB: MSI B650P, CPU: AMD Ryzen 9700X, RAM: G'Skill 32 GB DDR5@6000, Graphics card: MSI RX6600 8GB, SSD: Samsung 970 Evo+ 1TB (NVMe, OS), HDD WD 4TB, HDD Toshiba 4TB, OS: Windows 10 Pro 22H2

NLE: Vegas Pro [Edit] 11, 12, 13, 15, 17, 18, 19, 22

Author of FFMetrics and FFBitrateViewer

Cliff Etzel wrote on 5/20/2018, 10:55 PM

@Cliff Etzel What flavor of Cineform are you using (i.e. Which "Encoded format" and which "Encoding quality")? What chain of FX do you typically apply?

I typically encode to "High" quality setting Cineform AVI's - Chain FX is typically Levels, primary color corrector - then if the footage is noisy I will use Neat Video Denoiser but I leave that unticked until I'm ready to render. If I'm trying to get a certain look, I may add either a LUT or Magic Bullet Looks (LUT's in Vegas 15 trial go wonky at random times where I have to reduce playback quality to "Preview half"). I try to keep my FX to a minimum as much as possible.

NickHope wrote on 5/21/2018, 4:07 AM

@Cliff Etzel What flavor of Cineform are you using (i.e. Which "Encoded format" and which "Encoding quality")? What chain of FX do you typically apply?

I typically encode to "High" quality setting Cineform AVI's - Chain FX is typically Levels, primary color corrector - then if the footage is noisy I will use Neat Video Denoiser but I leave that unticked until I'm ready to render. If I'm trying to get a certain look, I may add either a LUT or Magic Bullet Looks (LUT's in Vegas 15 trial go wonky at random times where I have to reduce playback quality to "Preview half"). I try to keep my FX to a minimum as much as possible.

For me, in an 8-bit project, with 1 x Levels FX plus 1 x Color Corrector FX on the event, my original 8-bit UHD AVC video from my Panasonic GH4 plays more smoothly than Cineform "High RGB444" (or MagicYUV "RGB"). That's with either compoundplug or so4compoundplug.

Kinvermark wrote on 5/21/2018, 11:21 AM

+1 with gh4 and gh5 8 bit files. Technology moves on, so I now only use cineform & magic YUV as means of exchange with other programs. Cineform is now old and unsupported, so I only use it when the other program (eg Resolve) has limited format options. Magic YUV seems fast to render and mathematically lossless, so is better, and I use it when sending to Handbrake.

FWIW, I find that Resolve does NOT play back faster than Vegas with native camera footage, unless you employ its full "bag of tricks" for performance enhancement (optimized media, proxy, and cache) - perhaps Vegas will one day employ a few more "tricks" of its own to help with transitions and other composited areas that play back slowly.

Cliff Etzel wrote on 5/21/2018, 7:22 PM

+1 with gh4 and gh5 8 bit files. Technology moves on, so I now only use cineform & magic YUV as means of exchange with other programs. Cineform is now old and unsupported, so I only use it when the other program (eg Resolve) has limited format options. Magic YUV seems fast to render and mathematically lossless, so is better, and I use it when sending to Handbrake.

FWIW, I find that Resolve does NOT play back faster than Vegas with native camera footage, unless you employ its full "bag of tricks" for performance enhancement (optimized media, proxy, and cache) - perhaps Vegas will one day employ a few more "tricks" of its own to help with transitions and other composited areas that play back slowly.

Yet it's those bag of tricks in Resolve that provides a much more responsive playback experience - something I wish Vegas Pro had in my case. I'm still testing though...

With regards to Cineform being "old and unsupported" - that's a misnomer IMO. Cineform is now open source and if it's old and unsupported, why did Adobe implement an internal native option to encode Cineform within Premiere Pro and Media Encoder without the need to install GoPro's QUIK software? Cineform is easier on system resources and maintains high image quality - at least from everything I've read/seen so far indicates that. Same can be said for DNxHR in an MXF wrapper - why do post houses standardize on that for handing off projects?

Vegas uses less system resources of the three I've been testing - Resolve needs all that it can take and more - Premiere falls in the middle preferring gobs of RAM.

I'm not trying to start a flame fest - I'm just trying to find answers so that I can make a well informed decision.

Kinvermark wrote on 5/21/2018, 9:10 PM

Cineform was initially developed in 2001 (http://cineform.blogspot.ca/) so it is 17 year old tech. I have long been a fan, but the demise of GoPro and thus GoPro Studio (even the old version is unavailable for download now) means no access to the metadata engine, or Flux, etc. Realistically, who will debug this codec now if/when it does not work with new cameras? Adobe went with Cineform quite a few years ago to support a 3d workflow that is also now passe. The codec is only necessary as a legacy, when other alternative means of inter-program exchange are not available.

I totally agree that Vegas should implement similar strategies to Davinci Resolve to deal with performance issues, and in a sense it already has those features ( auto proxy generation for 4k; selective pre-renders) they just need to be improved. ie, Selective pre-render should work like "auto cache" in Resolve.

 

 

Shady wrote on 5/21/2018, 9:29 PM

Great discussion.

Though this was about the Trimmer window. ;)

Why can't Vegas use it's own Proxy files it creates for 4k footage in the Trimmer I wonder?

Kinvermark wrote on 5/21/2018, 10:42 PM

Ooops! Sorry. I don't know. But a proxy is just an easily played back, usually lower res file, so you could use a batch renderer like Vegasaur to transcode your media to proxies, and those would load and scrub nicely in the trimmer.

Cliff Etzel wrote on 5/22/2018, 1:42 PM

Cineform was initially developed in 2001 (http://cineform.blogspot.ca/) so it is 17 year old tech. I have long been a fan, but the demise of GoPro and thus GoPro Studio (even the old version is unavailable for download now) means no access to the metadata engine, or Flux, etc. Realistically, who will debug this codec now if/when it does not work with new cameras? Adobe went with Cineform quite a few years ago to support a 3d workflow that is also now passe. The codec is only necessary as a legacy, when other alternative means of inter-program exchange are not available.

I totally agree that Vegas should implement similar strategies to Davinci Resolve to deal with performance issues, and in a sense it already has those features ( auto proxy generation for 4k; selective pre-renders) they just need to be improved. ie, Selective pre-render should work like "auto cache" in Resolve.

 

 

I guess I've used Cineform for so long and gotten use to how it has performed in previous versions of Vegas and Premiere Pro CS6, I have just stuck with it. I'm not using DNxHR since it still gets put into an MOV wrapper and Prores is a no go more or less on Windows so I've just stayed with Cineform. It affords full Alpha channels as well, something XAVC-I doesn't do in addition to other native codecs. I'm not sure what else to try to improve stability and overall improved performance. I look at what Resolve supports, and from what I've read, stick with mezzanine codecs that are industry standards and one should have a pretty straight forward editing experience. Yet that doesn't seem to be the case within Vegas for me to date.

AVsupport wrote on 5/24/2018, 4:36 AM

Could you please change the title of your thread to contain some vital information; this just feels like a honey trap ;-)

my current Win10/64 system (latest drivers, water cooled) :

Intel Coffee Lake i5 Hexacore (unlocked, but not overclocked) 4.0 GHz on Z370 chipset board,

32GB (4x8GB Corsair Dual Channel DDR4-2133) XMP-3000 RAM,

Intel 600series 512GB M.2 SSD system drive running Win10/64 home automatic driver updates,

Crucial BX500 1TB EDIT 3D NAND SATA 2.5-inch SSD

2x 4TB 7200RPM NAS HGST data drive,

Intel HD630 iGPU - currently disabled in Bios,

nVidia GTX1060 6GB, always on latest [creator] drivers. nVidia HW acceleration enabled.

main screen 4K/50p 1ms scaled @175%, second screen 1920x1080/50p 1ms.