[Norman Black]

You might try lowering the video quality slider off of the max. It has a dramatic effect of speed. Down to maybe half of that you most likely will not notice a quality loss, especially at your bitrates. I only did VERY brief tests of that so take it with a GRAM of salt. I only did that after reading it online.

Sony does not say what it does but certainly one thing is the motion search algorithm being used. If you know anything about the x264 encoder, then you probably know about some of the insanely slow ME algorithms that WILL find all motion but they are not worth the cost in encode time. They keep the options for those who do not care about time. I suspect at least one thing the slider is controlling is ME algorithm selection.

[Norman Black]

I did a little quickie test of my own. I took a 20 seconds of 35Mbps AVC 1080p30 GoPro Hero 3 Black clip with lots of super fine detail. Leaves, twigs, sandy surface.

I rendered 4 times with Sony AVC at its max bitrate, about 26Mbps, high profile. The fourth generation was not all that good. A fair amount of softening.

I did the same with Mainconcept AVC, one pass variable bitrate at 35Mbps average and 45 max, high profile. The fourth generation was nearly as good as the original. You could not tell without pixel peeping at 100% and flicking back and forth between the two samples.

To be fair to Sony AVC since it cannot use the high bitrates of my source, I tried Mainconcept at 25Mbps average and 35 max. The fourth generation was really very good. I still needed static pixel peeping to tell but there was more loss.

This is an example from my statement about so many factors involved including the specific encoder use. Sony AVC did not do as well in this circumstance.

Intermediate codecs should be visually lossless over generations. For intermediates in Vegas without installing anything you have HDCAM SR variants and XAVC Intra.

[Norman Black]

You can do this very easily in NewBlue Titler Pro. This would be my first choice. One of the standard fade in animations might be all you need, otherwise you can use its timeline.

You can also do this in the Protype titler. It has a cascade feature I remember reading about that could be useful here. Sorry I cannot say more. I use Titles and Text or NewBlue.

Both of the above can have multiple independent text blocks in a single event.

I have done something similar to what you ask in Titles and Text, in one event, but only with two lines. You can keyframe the text in Titles and Text but you don’t really have control over fading. I just had my second line pop in.

[Norman Black]

There is no standard for RAW video like mpeg-2 or AVC for normal video. Every camera is different. Vegas supports RED camera raw and that is all at this point. Magic lantern RAW ouptut is unique to magic lantern. They do have utilities to convert to CinemaDNG but Vegas does not support CinemaDNG.

[Norman Black]

Shift+B pre-renders to RAM and is limited by the amount of preview RAM you have set on your preferences. The default is 200MB. How many seconds you can do with Shift+B depends on the preview RAM size and your preview setting (quarter, half, full).Half can buffer 4 times the frames as full and quarter can buffer 8 times the frames as full.

[Norman Black]

There is no real answer except that there is always loss when using a lossy compression algorithm. How much is the question, but that cannot be answered as that depends on the source material, the encoder used and what options were used for the encoder. By encoder I don’t mean mpeg-2 verses mpeg-4. I mean the actual encoder implementation. Like one AVC encoder versus another.

Loss effects are not necessarily linearly accumulative. When you encode to a lower level than source, you lose detail. This allows the lower bitrate of the lesser encode. Encoding again is not likely to lose the same amount of detail as the first generation because the encode options are a better fit for the material that is about to be encoded. That said you might think something can stabilize, but the encoders do not make the exact same compression decisions, regarding macroblocks, each time you do an encode and this will continue to soften the image.

If you intend to do generational renders then use an intermediate codec and/or keep your bitrates high. Intermediate codecs are best for this.

Do a test yourself. Your eyes are the best judge out there.

Then remember that pixel peeping a frame is different than watching video. Easier to notice differences.

[Norman Black]

When you open a saved project, the timeline will default to the length of that particular project. Be that 2 hours or 20 seconds.

[Norman Black]

Your crop looks fine, but do you have any track motion also?

[Norman Black]

[Brian Tallant] “when I render to the .m2T format using the YUV codec”

I don’t know what this is. What Render As template are you using. It sounds like maybe something in Mainconcept Mpeg-2 since is lists .m2t in the render as dialog but what template within that encoder?

YUV codec? 99.9% of all video is YUV based, or to be technical YCbCr in digital form. Most video uses some sort of chroma subsampling and hence the need for YUV components.

[Brian Tallant] “) Is it possible to render still photos to the .m2T format using the YUV codec and produce a video that EXACTLY reproduces the color of the original image?”

“EXACTLY”, then the answer must be No.
Still camera files are in many color spaces, but lets stick with SRGB for this argument. Do not confuse this SRGB with the Studio RGB term in the video world. In HD video the color space is Rec 709. SRGB and Rec 709 use the same color primaries, but I am not sure how this applies to the reduced numeric range.

Since video typically wants a numeric space of 16-235 and the still photo was 0-255, this conversion is not “perfect”. Even if you compress to 16-235 and the video player expands back to 0-255, there can be differences.

I have never tried testing anything for these small differences. I just know my initial use of stills I noticed the expansion and the Computer to studio conversion seemed close enough at least. I did not try any side by side comparison.

Also when I view stills, anything actually, on my PC I come into issues. I have a wide gamut monitor and app like the Windows 7 photo viewer and photoshop are color managed and video players may not be and I am pretty sure Vegas is not color managed. Therefore any differences I see could be due to one app being color managed and the other is not. This is very true of stills and was applicable when I compared my source still to the video after learning about the need for a level adjustment.

[Norman Black]

[Stephen Mann] “And for real help using Vegas – not “Hey, Sony, Fix my PC”. I have needed to ask Sony tech support a “How do I do this…” question recently and received a reply the next morning.”

Yep, “how do I” using type questions are the types of things the support crew can answer and probably do relatively quick.

For bugs, I don’t they have the ability do that. They can try to reproduce your problem and report if they cannot, but beyond that, all they can do is dump the info into a queue where QA probably looks at the problem and then hopefully gets back to support to get back to us.

I reported a bug in the XAVC encoder, where I gave a same VEG, and they got back pretty quick, saying it was reproduced and entered into the bug system. Who knows if or when it would be fixed.

I reported Stephen’s report on the HSL GPU bug. Again with a VEG to reproduce. No response as yet (30 days). That should be 100% reproducible. He is on Nvidia and I am on AMD which removes a lot of variables in the system.