What Vegas 14 settings for 1:1 exporting of imported footage?

Teepeejay wrote on 12/30/2017, 6:50 AM

I've been intending to use Vegas Pro 14.0 on my Windows 10 PC for a YouTube thing I do where it's collecting footage but fixing it in aspect ratio, audio sync and/or editing from the source. I basically would like 1:1 exporting to the original footage's qualities. I do the thing where the project's settings are based on the first video file dragged to track and some of the other settings I have currently are so:

Specifically, what should I do when it comes to reference frames, "allow source to adjust X", variable bit rate stuff, slices and audio export Hz/bps settings? Also does it matter if the refresh rate (resolutionXresolutionXrefreshrate seen in preview) is higher than the original file's or if the project's audio sample rate Hz and the bps are higher/different than the original file's?

Many thanks if you can help me with this.

Comments

Musicvid wrote on 12/30/2017, 8:47 AM

Use an appropriate preset matched to your source properties. You can learn the unnecessary stuff later.

There is no such thing as "1:1exporting to the original footage's qualities," save for a couple of utility codecs that smart-render. You won't be using those for delivery.

dream wrote on 12/30/2017, 8:54 AM

put 1080*1080 in display bar

Teepeejay wrote on 12/31/2017, 5:42 AM

Use an appropriate preset matched to your source properties. You can learn the unnecessary stuff later.

There is no such thing as "1:1exporting to the original footage's qualities," save for a couple of utility codecs that smart-render. You won't be using those for delivery.

Preset for rendering? But how do I match say, variable bit rate to the original or if it's not listed within the source's properties?

Musicvid wrote on 12/31/2017, 12:36 PM

Preset for rendering? But how do I match say, variable bit rate to the original or if it's not listed within the source's properties?

You are not necessary able to do that. Variable bit rate algorithms are encoder-specific, with many implementations, and each encoder treats the same data differently! Similarly, variable frame rate is something you would never want to replicate in a nonlinear editor.

Look, there are some things you have to or should match or translate geometrically for encoding. These are the physical properties - - display aspect, resolution, actual frame rate, field order, luminance levels, to name a few. You seem to be focusing on some things that don't matter, assuming the above conditions are met, or which changing can do more harm than good.

To make this easier to understand, Vegas uses an ENCODER. That means that with very few exceptions, it changes your video (Decode, Edit, Encode is the exact order of steps). You are not going to unbake that cake. Last time:

1. Match Media Properties in your project. That means physical properties, not internal compression! This is a specific procedure, and if you don't know about it, now is the time. If you will be encoding using Scaling or Deinterlacing, post back for specific help. That's case-by-case, not a bunch of "what does this do?" questions.

2. Choose a compatible render template, and Match Project Properties.

3. The render properties in the templates have been carefully chosen to give the widest degree of compatibility and optimization with the widest variety of sources. Mucking with the internal settings will give you muck, no surprises there. Your proclivity to distrust the default settings at this stage, given your current level of understanding, may come off as sounding disingenuous. Baby steps.

4. If what you "really" want is a MUXER for making simple cuts and edits, which will not alter or recompress your source bits, try Videoredo, which has a free trial. Vegas is not a muxer, nor will it ever be, save for a couple of no-recompress intermediate formats (translate: "not for delivery") already mentioned.

5. As a beginner, your expectations are understandable. In reality, you will not be reverse-engineering Vegas' encoding engine to meaningfully duplicate or clone your source compression parameters, which could be anything under the sun.

6. Before beginning Step 1, reset Vegas to factory defaults, by Ctrl+Shift+Double-click on the Vegas icon. This will Undo unintentional changes already made to the interface properties.

Welcome to the forums.

                                                                                          

Musicvid wrote on 12/31/2017, 8:08 PM

You may not know that Vegas decodes your video to uncompressed RGB colorspace (raw bits), which although retaining ALL of the encoded data in your compressed original, relays none of the encoding parameters (instructions) that were used to get it there, nor does it care once decoded. It is what it is. Uncompressed.

After decompressing to raw bits and editing, encoding is the next step, something you choose for size, quality, speed based on your needs (oh, pick only two). Unless your source came from Vegas, you will not be able to duplicate the original compression parameters; even then, it will still be encoded again, not muxed (with a couple of unrelated exceptions).

Example: Sony AVC, Magix AVC, and Mainconcept are h264 compliant encoders included in Vegas. None of those will replicate the multitude of high profile parameters of x264 source, nor the CRF rate control (which is faster and smaller than variable bitrate), lanczos scaling, or Decomb filter, because those settings are simply not available inside Vegas' software encoders. Making some sense now?

I sincerely hope this helps you get started down the right path. It's now 7:00 on NYE - - time to relax...

Musicvid wrote on 12/31/2017, 8:38 PM

... and to forgive all of my students over the past thirty years for upside-down thinking.

Happy New Years 2018 (or whatever)!

Teepeejay wrote on 1/1/2018, 11:12 AM

So if I'm getting perhaps slightly different colour in the export is that from the RGB colorspace thing? Thanks for the helpful assistance also :)

Musicvid wrote on 1/1/2018, 11:17 AM

So if I'm getting perhaps slightly different colour in the export is that from the RGB colorspace thing?

Good question, and the answer is "sort of." If your source already has RGB Levels, Vegas won't recognize this or change them for you. For source like this, we will add a Levels filter.:

Click on the effects button above the preview screen

Find the Levels fx

Use the Computer RGB to Studio RGB preset

Be sure the FX is active before rendering.

The preview will look different. This is OK.

Render and report back if ?

Musicvid wrote on 1/1/2018, 11:36 AM

Now that we're communicating, follow the instructions here to post your full source properties. https://www.vegascreativesoftware.info/us/forum/faq-how-to-post-mediainfo-and-vegas-pro-file-properties--104561/

Now, others will offer their opinions as to what presets will work well for your intended use, and whether the default bitrate is near optimal.

Teepeejay wrote on 2/12/2018, 1:56 PM

Okay so, I've since had an error with Vegas and have reinstalled it so it may no longer have my original settings.

Sorry if the following is already covered, but if I were to just make the rendering as absolutely identical to the original source file as possible, what are any and all attitudes and guidelines I should follow in the render settings and what not? Just all of what you've mentioned thusfar? I'd like to make edits of footage that preserve the original footage's qualities at least as closely as possible.

Musicvid wrote on 2/12/2018, 3:54 PM

Vegas is an ENCODER. That means simply "not in Vegas." The explanatione is simpler than dirt. Vegas will not have the same CODEC used to create your original file, and if it did, you could not smart render. Please accept this answer at face value. The things you CAN match in post are the ones I already told you about. I'm sure you dont mean to appear disingenuous, but it's getting closer.

Can your Vegas file "look as good as" your source file without being bigger? The answer is "Probably."

A MUXER named VideoRedo will make simple cuts and edits and join, but with no fx, without RE-ENCODING your video.

Good luck.

Musicvid wrote on 2/12/2018, 4:15 PM

Here is a short list of terms and definitions you can refer to going forward.

https://www.vegascreativesoftware.info/us/forum/speaking-good-video-a-beginner-s-guide--104463/

NickHope wrote on 2/12/2018, 11:11 PM

Okay so, I've since had an error with Vegas and have reinstalled it so it may no longer have my original settings.

Sorry if the following is already covered, but if I were to just make the rendering as absolutely identical to the original source file as possible, what are any and all attitudes and guidelines I should follow in the render settings and what not? Just all of what you've mentioned thusfar? I'd like to make edits of footage that preserve the original footage's qualities at least as closely as possible.

What format is your source footage and how was it created?

Assuming you're editing the video and wishing to render for YouTube, then rendering to AVC/H.264 makes sense, and this post explains how you can maximize the quality: https://www.vegascreativesoftware.info/us/forum/faq-how-can-i-improve-the-quality-of-my-avc-h-264-renders--104642/

Teepeejay wrote on 2/13/2018, 5:48 PM

Sorry about that disingenuous thing. I'm obsessive compulsive over getting the most faitfhful/accurate rendering to the original source file.

Is what's already covered ALL I have to do to get that most faithful/accurate rendering out of any source file, in the case that say, I wanted to edit a video in a more complex way unachievable with a MUXER?

@Nick Hope Yeah I have a lot of YouTube ripped video files to work with, but I'd like a universally applicable set of guidelines in getting the most accurate/faithful rendering to any general source file. Does your link help with that?

fifonik wrote on 2/13/2018, 6:12 PM

Sorry about that disingenuous thing. I'm obsessive compulsive over getting the most faitfhful/accurate rendering to the original source file.

So do I (however, many people do not care about quality much)

As a result, I'm encoding with x264 encoder from Vegas through farmeserver (probably some people already hate me because I'm continue to mention this, sorry guys).

Anyway, this is also re-encoding so the quality in resulting video is ALWAYS worse that in source video. You need simple tools like VideoRedo that was already mentioned here to be able to cut/join without re-encoding whole video (only small parts will be re-encoded).

Camcorder: Panasonic X920

Desktop: MB: MSI B450M MORTAR TITANIUM, CPU: AMD Ryzen 3700X (not OC), RAM: G'Skill 16 GB DDR4@3200 (not OC), Graphics card: MSI RX580 8GB (factory OC), SSD: Samsung 970 Evo+ NVMe 500MB (OS), HDDs: Seagate & Toshiba 2TB, OS: Windows 10 Pro 1909

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

Musicvid wrote on 2/13/2018, 6:35 PM

The ocd thing - seen it a thousand times in beginning video hobbyists. It doesn't work that way if you want to edit your video, and it only works in a very few cases in Vegas even when there is no editing at all!

When you edit a video, the edits are not a new video, but exist as a set of instructions to be applied to encode the new video. In Vegas, that is aptly called rendering, which literally means "change to a different state." So the answer to your question is no, you cannot do anything beyond simple cuts and joins in a straight muxer because that would require encoding, by definition. Likewise, you cannot generally MUX in an editor, save for a couple of uncompressed, intraframe, and short GOP interframe codecs, that are used as lossless intermediates, not so much for delivery in this century.

Now, what can we do if we want to edit and render a new video with great quality? Well, since none of the original encoding instructions were carried over to the decoded raw Rgba bits that are now unpacked on on your timeline, trying to duplicate those settings in post, beyond their original architecture, is a nothing burger, as the expression goes.

So the goal for someone interested in retaining quality, is to focus proactively on the metrics and delivery more or less independently from what "was." We have good tools and.methods to use, often to the point of retaining quality temporally indistinguishable from the original, in a smaller file!

We also have level controls that can reclaim information from misflagged cell phone video, so it plays better than the original! Neat stuff, but we need to defer the perfectionist mindset in order to see the actual and creative potential of the result not being the same as the original, even though encoding losses are unavoidable. Think of achieving a balance between size, quality, and encoding speed that meets your needs going forward. Therein lies your accomplishment.

Welcome to the forums, keep asking good questions, and by all means find ways to test your assumptions when sharing.

but I'd like a universally applicable set of guidelines in getting the most accurate/faithful rendering to any general source file.

Those don't exist, and they will never exist, until you write them!

 

fifonik wrote on 2/13/2018, 8:53 PM

I perfectly understand what video editing is and that the original video is changed dramatically during the process. Pan/crop, stabilization, colours/levels correction -- just a few examples of the filters that produce different video.

I understand what encoder/decoder are and that video quality is degraded with every re-encoding using non-lossless encoder.

I'm not trying to keep resulting video as close to the source as possible at any cost by refusing to use some tools that improves overall watching experience (like non stabilizing video or keeping under-exposed levels as is that they be as much close to the original as possible).

However, I'm trying to use workflows that do not produce additional, non-needed quality losses. For example, I'm trying to use the best possible encoders (less quality loss during encoding) and 32-bits pixel formats (less quality loss during composing).

This makes my workflow harder:

  • More time required to learning and analyzing possibilities
  • Lower preview framerate because of 32-bits pixel format processing (choppy preview)
  • More tools need to be installed, configured, updated for using x264 (+frameserver + avisynth +megui +x264)
  • More keys should be pressed to encode with x264 than with Mainconcept AVC/SonyAVC
  • More time required for encoding

Am I crazy? Possible. May be I have to spend the time on something more useful. Unfortunately, I cannot do anything with that because of my OCD. I cannot make fade 1 sec and 1 frame, it must be 1 sec and 0 frame or 1 sec and 30 frames, or 2 secs and 0 frames... Something round. I know that I will not be able to notice the different in resulting video but... That's it.

Camcorder: Panasonic X920

Desktop: MB: MSI B450M MORTAR TITANIUM, CPU: AMD Ryzen 3700X (not OC), RAM: G'Skill 16 GB DDR4@3200 (not OC), Graphics card: MSI RX580 8GB (factory OC), SSD: Samsung 970 Evo+ NVMe 500MB (OS), HDDs: Seagate & Toshiba 2TB, OS: Windows 10 Pro 1909

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

Musicvid wrote on 2/13/2018, 8:59 PM

I'm not trying to keep resulting video as close to the source as possible at any cost by refusing to use some tools that improves overall watching experience.

fifonik, not crazy, just said better than i did

+1

fr0sty wrote on 2/13/2018, 9:02 PM

Unless you "encode" to a completely uncompressed format using the same color space, framerate, and resolution as the source video, you can expect there to be some loss. Depending on effects used, etc... even uncompressed stuff will have quality lost. There are a number of good formats for preserving as much quality as possible, but unless you have insane amounts of disk space to waste, you aren't going to back stuff up 1:1 without some compression.

Systems:

Desktop

AMD Ryzen 7 1800x 8 core 16 thread at stock speed

64GB 3000mhz DDR4

Radeon VII

Windows 10

Laptop:

ASUS Zenbook Pro Duo 32GB (9980HK CPU, RTX 2060 GPU, dual 4K touch screens, main one OLED HDR)

Musicvid wrote on 2/13/2018, 9:11 PM

you aren't going to back stuff up 1:1 without some compression.

Well, (Ctrl+C, Ctrl+V) in Windows works, and that's what i tell most people asking the same question...

NickHope wrote on 2/13/2018, 11:54 PM

@Nick Hope Yeah I have a lot of YouTube ripped video files to work with, but I'd like a universally applicable set of guidelines in getting the most accurate/faithful rendering to any general source file. Does your link help with that?

If you want lossless rendering, use MagicYUV or UT Video Codec. The files will be very large and I have no idea how well YouTube deals with them.

If you want near-lossless rendering, you have formats like XAVC-Intra, Cineform, DNxHR. Not quite so large files but still large and I have no idea how well YouTube deals with them.

All of the above can be rendered directly in Vegas, without frameserving, but you'll have to download the codecs, with the exception of XAVC-Intra.

You can get close to that quality with AVC, and perhaps even match it with a low CRF value in x264. The files will be much smaller and the path to YouTube is well proven. I'm about as OCD as it gets when it comes to video quality, and I'm happy with CRF16. My link helps with that, although there is no quick and easy solution at the moment due to difficulties with Vegas2Handbrake and the audio glitch with Frameserver. If you don't fancy that, or you have trouble setting it up, I suggest you try rendering a test with XAVC Intra and seeing how YouTube handles it.

fifonik wrote on 2/15/2018, 4:00 AM

2 Nick Hope:

Could you advice, what kind of audio issues do you have with frameserver?

I'm rendering through frameserver and have not noticed any.

It's possible that I just missed one as almost all my videos are shot and final (I do not process them after rendering so 1-frame audio shift could be overlooked).

It's also possible that in my workflow I there is no the issue you mentioned as I'm rendering audio first, then rendering video through frameverver and in MeGUI "One Click" encode (I use it instead of Vegas2Handbrake & Handbrake) I selecting the frameserver's proxy-file and already rendered audio stream.

Thanks.

Camcorder: Panasonic X920

Desktop: MB: MSI B450M MORTAR TITANIUM, CPU: AMD Ryzen 3700X (not OC), RAM: G'Skill 16 GB DDR4@3200 (not OC), Graphics card: MSI RX580 8GB (factory OC), SSD: Samsung 970 Evo+ NVMe 500MB (OS), HDDs: Seagate & Toshiba 2TB, OS: Windows 10 Pro 1909

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

NickHope wrote on 2/15/2018, 4:19 AM

2 Nick Hope:

Could you advice, what kind of audio issues do you have with frameserver?

I'm rendering through frameserver and have not noticed any.

It's possible that I just missed one as almost all my videos are shot and final (I do not process them after rendering so 1-frame audio shift could be overlooked).

It's also possible that in my workflow I there is no the issue you mentioned as I'm rendering audio first, then rendering video through frameverver and in MeGUI "One Click" encode (I use it instead of Vegas2Handbrake & Handbrake) I selecting the frameserver's proxy-file and already rendered audio stream.

Thanks.

See last paragraph of section 4b in that link.

fifonik wrote on 2/15/2018, 4:25 AM

Thanks. I missed that part when I read the article.

Looks like workflow I use already use the workaround.

Camcorder: Panasonic X920

Desktop: MB: MSI B450M MORTAR TITANIUM, CPU: AMD Ryzen 3700X (not OC), RAM: G'Skill 16 GB DDR4@3200 (not OC), Graphics card: MSI RX580 8GB (factory OC), SSD: Samsung 970 Evo+ NVMe 500MB (OS), HDDs: Seagate & Toshiba 2TB, OS: Windows 10 Pro 1909

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