I use two DVD players for day-to-day testing, an APEX and a Sony NS400D. Same DVD, same monitor, but a very different picture depending on the player. Sony does some noise filtering, while the cheapo APEX typically shows faint diagonal greenish lines in the pure blacks between segments (picture is fine usually, just the black exhibits this). I see this with Blockbuster rentals too. The APEX plays _anything_ I put in it, and ran $75, so I can't complain too much. The playback hardware absolutely makes a difference.

*test footage is a mix of moving hi-rez stills, PAL and NTSC DV, Digisuite MJPEG, QT from artbeats, and generated moving color patterns. Most of the video has a talking head for lipsync verification.

"Billy said: Maybe its the combinination of FX filters I typically use"

Care to share those? some prefiltering like median or color correction?

Also, side note: Using the now-shipping Boxx/SF turnkey, I am seeing render times of slightly less than 2:1. Straight-cut DV source rendered to the standard NTSC template with average br of 6,000,000.

Pete,

It is really good to hear that the encoding to DVD is really good.

You are right, all my experience so far has been with low-bitrate encoding (VCD, SVCD, and XVCD). This work in producing these CDs was in preparation to take the plunge and get a DVD burner. The SF people have made it clear that their focus has been on making the Vegas DVD encoding as good as possible, and not to spend too much time on VCD/SVCD. That is the correct decision, and I'm very much encouraged by your remarks to hear that this effort has paid off.

John

Maybe I just lucked out... it seems my rather out dated Pioneer 333 DVD player handles everything I throw at it. I noticed it got good reviews over at vcdhelp as far as compatibility.

As far as the steps I take for filtering keep in mind much of what I'm doing started out as one of a kind of home brew super eight movies from the 70's and in an attempt to save them I converted to beta video tape, then years later because that format was rapidly drying out I made a rather bad choice by deciding to convert them to MPEG files. Anyhow, with that in mind much of my source material is slighly red shifted and a little washed out.

Setup: If possible you should make all adjustments while watching a connected and properly calibrated TV feed through your digital camera instead of adjusting off the preview window directly. While you can just watch the preview on your computer monitor you are likely to either over or under correct resulting in your testing repeatedly on your TV and repeating adjustments to get things right.

As a first step I run the source file in VV3 and carefully watch, just to get a idea in my mind what I'm going to try to accomplish. Because most of the source files are red shifted I begin by applying the Color Balance filter to the entire source file by dragging it to the timeline and setting midtone reds -.300 and midtone blues -.150. This should NOT be considered something you would always do, in fact don't do it at all unless your videos are also shifted to the red. Next, I make a quick check switching to histogram-luminance to see if there are any out of bound levels. There usually are, so I apply the Broadcast Colors filter being sure to check both smooth upper and lower bounds.

Now I run the video all the way through and if there are any significant changes in lighting or obvious areas that are too light or dark I split at those points creating a series of events as I go along. For a 20-30 minute video I can make anywhere from a few to several dozen events.

I now play each event alone and set the event to loop. I switch back and forth between watching on the TV monitor and checking Histogram-luminance after dropping in the levels filter for each event. While watching the histogram I'll typically see some of the event, maybe all where the histogram is not filling the none shaded middle area where either shadows or highlights are shifted some to either the left or right instead of being balanced. For too dark scenes I usually drag the level input end control slider left somewhere to the 850-950 range. If you observe the histogram you'll see the graph spread out more as you adjust. For too light scenes I adjust levels input start anywhere from 20-120, again watching the effect on the histogram and the TV monitor. It seems mean reading between 50-58% give best all around results for my typical source file. While playing the event in loop mode I may nudge the gamma from the default 1.000 to 900 to darken up to 1.200 to lighten. I continue through the rest of video.

Next I return to the first event and if needed drop in the Color Curve filter. As I said in previous posts I've made several custom filters, starting with the presets as a template to cover the typical range of corrections. Again because much of my source files are a little washed out I frequently use a "S" curve to adjust contrast and brightness levels independent of each other, actually more tweaking of what I already did in the initial levels adjustments I made. If there was minor artifacting or color noise in some events this will usually reduce it to the point it is very minor if not totally gone. If you're not confortable working with curves you can try decreasing brightness and increasing contrast a tad using that filter. Again your mileage may vary. It really depends on the source file.

By this time I usually have a decent video (considering the source was MPEG) and to finish up I may use the Median and blur filters with very low settings followed by sometimes adjusting with the HSL filter. I rarely will increase saturation, however I sometimes find reducing it to the 90-95% range and boosting luminance to 1.01 - 1.05 can be helpful. Avoid going much higher or you can introduce blooming and if you have color noise you'll only make it worse.

I never finalize the same day I finish editing a project. I've found it better to put a project aside then go back to it a day or two later and if possible have someone else look at it before rendering because you'll tend to be more critical of any adjustments you made if you haven't worked on it straight for hours. Before rending the whole project I frequently will test render a few sections just to see how it looks played off my DVD player. If you're starting with digital input you can probably skip most of the correcting process unless you really made some bad shots. <wink> One reason I really love Vegas Video is with some effort and a lot of patience you can take some pretty awful source files and turn them into respectable videos, just don't expect miracles. Results vary depending on source material, how carefully you apply filters and of course your own subjectivity of the final results.

Some excellent tips here. I'll add one more: make sure to use "Best" quality if you're using any pan/crop on stills. Otherwise, some high frequency content can sneak in (due to the faster image scaler used with "Good" quality), and MPEG encoding hates high frequencies that don't need to be there (they use bits that could better be used on actual content).
///d@

Say Dennis, maybe you can clean up one area I'm confused on. Does the quality selector for the preview window only effect playback prior to rendering or does it also impact on the final rendered version, meaning you should always set to "best" prior to closing out a project?

<OffTopic Rant>

Hmm...I really hate you guys. Honestly :).

Joking aside, one of my first DV footages were some massive fireworks on a late evening background. Needless to say, I was really happy to test my brand new camcorder on such a demanding shoot: LOTs of movement, sharp constrasts, bursts of colors and, most important, the utter stressing of resolution (focusing individual on flares, sparks, the works). No wonder I cherish that 5 min. footage (rendered only once) as the _the_ yardstick when it comes to encoding.

Maybe that's just me being over-paranoid/demanding, but using Vegas MC MPEG-2 encoder made me clearly see the artifacts in the form of slightly pixelated image and clearly distinguish btw. horizontal lines (on my 21'' monitor from 50 cm distance). Alternatively, if I get further back /use a larger screen, the image gets noticeably blurred. To be honest transcoding using Ulead Video Studio 6 MPEG2 didn't make things better. However, I am still left w/ a bitter taste of double-encoding DV footage to MPEG2...

Still, after reading your knowledgeable comments I'm really tempted to give it another shot but apparently it will take quite some extensive tweaking to get "good quality video" (in paranoid terms). Time for homework.

Greets to SoFo for putting together such a comprehensive MPEG2 guide. And, most important, for carefully listening to and asking for feedback. I'm honestly impressed

</OffTopic Rant>

Yeah, I want to know that too. I thought this setting only affected the preview window, not the final results. Surely not?

-Pete

Preview window size or quality setting has ZERO impact on the render.

Florian: Are you creating DVDs or SVCDs? Did you use Vegas 3.0a or 3.0 to encode?

DVDs. Well, I didn't burn the plastic and test it in a player (yet) but I've rendered it as PAL DVD (25 fps, 720x576).

I'm using Vegas 3.0 bld 76 and MC MPEG plugin 1.0 bld 13. Any major improvement lately ? How much would an upgrade cost (and which components should I upgrade) ?

BillyBoy,

Wow! That is an impressive, and very useful description. Thank you for taking the (considerable) time to write it all down.

John

At this point, I still have to use TMPGenc as my MPEG2 encoder. VV3 is still not as good and is not significantly faster in encoding. In testing to get 2 hours on a DVD, I used a bitrate that will allow for approx. 2 hours on one DVD and encoded the same 30 minute segment 4 different ways. All of the VV3 sample showed terrible artifacts on movement. For example, in one scene a person was talking and rotated their body left and then back right. The side of their face and edge of their arms became an extremely wiggly line with the VV3 MC MPEG2 encodings. The TMPGenc encodings all had very straight edges for both the face and the arms. Our tests included both VBR and CBR encodings with both programs.

Vegas 3.0a has an improved MPEG-2 encoder over version 3.0. No problems with the update (which is, like all upDATES, free).

What were the settings, precisely? Your results are atypical and I suspect the Vegas encodings were actually at lower bitrates than you anticipated. How did the file sizes compare?

-Pete

Basically, the only settings I changed were the bit-rate settings: left low alone, changed the average to 4800000 and the high to 8600000 (I believe these numbers are close. I'm 99% sure on the middle and the high was in this neighborhood). Everything else was the standard DVD settings (except elementary streams to get two separate files?). I was encoding a .mov file from Cinestream and the wavy results were VERY noticable. TMPGenc's result was dead smooth in the exact same section of video. When my wife first saw the VV encoding, her first response was that we could not show that DVD. She was happy with the TMPGenc result.

This was done using VV3.0a on a 700 MHz Pentium III. As stated before, actual encoding time was comperable between VV3.0a and TMPGenc (rougly 3 hours each on a 9 minute test video).

Thanks for the kind words John.

Remember my routine works for me because much of the source material in this mammoth project I'm working on has very similar flaws I'm trying to correct so it became almost a reflex where I see X problem I know I need to apply Y solution.

Its kind of a evolutionary thing. When I started with Vegas Video I was rather timid in what filters if any I would use and then I was happy with the presets. In a short time because I'm a "knob-twister" I started to fiddle more and more, then started making my own presets so I didn't have to manually make the same adjustments over and over.

Here's another tip that really shows off how powerful Vegas is.

Begin by making a small event of 30 seconds or so that has similar content without much change. Drag the levels filter to the event you just made on the timeline. Be sure the sync cursor control in enabled on the Video FX window. Click first keyframe and set gama to 850. Click last keyframe and set gama to 1200. Be sure the cursor is somewhere within the event you just applied the levels filter to. Set event to loop. Go to first frame in event. Start playback. Now watch as the level changes. Stop anywhere in the event to see what the value is. You now had Vegas automate the process of sampling gama levels automatically and elimiated the drudgery of keying in all those value one at a time! Now pick what level looks best and apply to the whole event by having that value in the first and last frames. If you had other key frames already in the event then use the previous or next keyframe buttons to avoid having the levels change back and forth.

Of course you can use any FX filer and "test" values the same way. A big time saver and a lot of fun for knob twisters. <wink>

jet: try setting the average to 6,000,000 or higher. We're working on better quality with lower bitrates, but I think you'll see a big difference right now by bumping up the average. No problems fitting that 9 minute piece on a DVD.

I agree that there is no problem fitting a 9 minute segment on DVD at 6000000 or even higher. In fact, I did encode at a higher rate as well and did see much better results. The problem is, I was testing which format I was going to use to put a 2 hour wedding on DVD (instead of spending DAYS encoding, I could spend hours). At a 2 hour DVD rate, VV3.0a using MC is clearly inferior to TMPGenc.

Here's a question, how does the encoder know when to apply maximum, average and low bitrates? I'm sure there is some complex formula, just looking for a quickie explanation. And just because I'm a knob twister, is there any way to tell the encoder to use higher or lower bitrates based on content within the same video? TIA!

I think it's a bit of guess work on it's part just based around the complexity of movement etc in each scene.
2 pass VBR (or more) are what the best VBR encoders use.
In the first pass they encode nothing just view the movie in it's entirity to work out what frames need what rate working to your levels & then in the second pass they will encode. This will obviously give more accurate encode than single pass.

Are you listening Sonic....any chance of a 2 pass update to MC encoder ??

Here is a free utility , a bitrate viewer.
It will examine your MPEG and show you a graph displaying what the bitrate is at any given time in your movie. It also shows the quantization scale (amount of compression).
if you purchase the full version you can actually amend peaks (in case you have gone overlimit for DVD spec)

http://www.tecoltd.com/bitratev.htm

Simply put, the encoder analyzes frames and makes compression assumptions based on complexity of the current frame along with changes from preceding/subsequent frames. Every encoder handles this differently. There's more to it than that obviously- read all about it at MPEG.org

There is no way to do scene-by-scene encoding in this implementation. You could theoretically render one scene at a time and stitch together all the scenes in some other app. We can't offer any support at all if you opt for this method, but if you do try it, I'd be curious to know the

a) tools used,
b) end results,
c) amount of lost hair (in kilograms).

That's what the high end authoring software will allow you to do. Tweek the encode for small sections or individual frames and link it all together.
Bit out of my price range though !!!