No one said you were crazy, TVCmike. I do have to laugh though, that people are spending MORE time talking about this, than actually sitting down and doing it. I've done it, posted the results on more than one occasion. If I could find the link to the article on the DMN that I wrote about it, i'd point you there. Further, look to Adobe, Pinnacle, and you'll see the same conclusion on their site. But I honestly urge you to compare, not only speed, but quality.
The encoder used in DVDA and Vegas are the same encoders too, but due to scaling issues, one looks better than the other. and one is faster than the other. But it's the same encoder. I'm creating another rendertest now, one that has some lines in it with black grades for you do use as a comparison. i'll post it to the Sundance site shortly.

The quality comment is absolutely correct. I used to use pinnacle pro one. Yes, I get frustrated at Vegas render time. Tonight my computer 1.8G took 25 minutes to render a 30 second spot(lots of filters and color correction).

Simple fact. Vegas blows everything else away when it comes to the final quality of the output. And that, to me, is well worth the wait.

Steve

Well, I was kinda kidding around with the quality comment, to be honest. However, I'm looking to dig the technical explanation of your claim. I'm a technical consultant for people editing video and am dealing with this kind of thing day-in and day-out, so I can't just tell a client to do something differently without telling them why they need to. And - believe me - they really appreciate the explanation even if they don't 100% understand my simplification.

You're talking about scaling issues, yet I'm not talking about real-time rendering or overall capability issues here. Really I'm not. I have two engineering degrees here, mostly focused on DSP and integrated circuit design, but I do understand the software design process too. If I were writing NLE software, I would never leave a useless or substandard feature in a released product. That's basically what you're calling "Render As..." for anything but rendering to AVI-encapsulated DV25 here. In the context of software, scaling has to do with either the speed or the actual hardware/software ability to process a finite amount of data. I could see speed being an issue due to the temporal nature of certain rendering operations and the swapping of data, but you're talking about quality too. That's where we differ. There should be absolutely no difference in quality because quality is not dependent on the speed of the processor. It is simply dependent upon the capability of the software and its interaction with hardware to process one or more frames and then encode those frames in an "internal frameserver" fashion. If there is a difference, I want to know why and not just that it's a certain way.

Your practical experience notwithstanding (because I believe you), I will again ask for the Sony developers' input here. If there is a problem with quality using "Render As..." to MPEG-2 versus to DV AVI and separate MPEG-2 encoding, then I hope it's ripped out of the next release of software and explained openly and clearly as to why. If there's a problem with speed, then we can deal with that on a case-by-case basis. Since most of my clients end up retaining both their source footage and final production in DV, they end up encoding in their authoring software anyway. My one client who archives old footage directly to DVD uses "Render As..." to MPEG-2 and ends up with better quality on his DVD, side-by-side, frame-by-frame, than his original SVHS source. Rendering time is not an issue for him, but I guarantee you his demands for quality would have flushed out any problems with the workflow I developed for him a long time ago and placed them back in my lap.

Any developers in the house?

The following comes from a site at MIT:


"There are three tape formats that are known as DV formats: MiniDV, DVCAM, and DVCPRO. All three utilize the same compression method called DV25 (which is sometimes just referred to as DV compression). The same data is recorded onto each format, with the difference between the formats being how the data is physically recorded onto the tape."

"As stated above, DV25 is the codec used to compress all video that is recorded onto a MiniDV, DVCAM, and DVCPRO tape. This compression occurs when the information is written on the tape. People often refer to "uncompressed DV," which is a bit of a misnomer. DV is always compressed; it's just a very light compression. There is no way to record onto a DV tape and not have the information compressed into the DV25 format. "Uncompressed DV" usually means that no additional compression is added during the capture process. A better term that is often used is "raw DV."

"Compression Ratio: 5:1 This ratio seems rather high when compared to the fact that analog video usually had to be compression at a 3:1 or 2:1 ratio using Motion-JPEG to be of acceptable quality. Yet DV25's 5:1 quality is about comparable to 3:1 Motion-JPEG quality. This ratio is fixed."

Hopefully, this will clarify the issue insofar as compression ratios are concerned.

J--

The 'new' rendertest is there now. I created a 30 second file with lots of gradients, straight line, fringe noise like DV always has regardless of who's camera you use, inserted blur and rendered it as an avi and as an MPEG. MPEG just finished rendering on an identical machine, avi render took 2:24:31 to render. Then rendering to MPEG from the AVI took 31 seconds.
Rendering to MPEG took 3:10;21, and the quality is not as good as the avi to MPEG. Even a screen shot shows this, although the compression to JPEG compromises both shots, but it's even evident at that point. My understanding on this is that the temporal scaling is harder on the CPU and so it takes more away from the encoder. I could be talking out of my butt. I was hoping that Sonic Dennis might catch this thread, I've mailed him separately. Maybe he'll provide the 'real' answer to why this is the case. Anyone who wants to see the screenshots, ask and I'll redo them and post them.

>I do have to laugh though, that people are spending MORE time talking about this, than actually sitting down and doing it.

Well, some of us sit down during the day at a computer that does something other than vegas rendering ;-)

>I've done it, posted the results on more than one occasion. If I could find the link to the article on the DMN that I wrote about it, i'd point you there. Further, look to Adobe, Pinnacle, and you'll see the same conclusion on their site.

Honestly, Spot, how am I supposed to look at the Adobe or Pinnacle site and find some discussion on this issue? Its a big site(s) and I have no idea how to phrase a search for something like this. P.S. I tried it on the Vegas forum and on google and struck out.

>But I honestly urge you to compare, not only speed, but quality.

Will do.

>The encoder used in DVDA and Vegas are the same encoders too, but due to scaling issues, one looks better than the other. and one is faster than the other. But it's the same encoder.

What you mean by "scaling issues"? I'm afraid that's a vague term to a programmer like myself.

>However, I'm looking to dig the technical explanation of your claim...useless or substandard feature in a released product. That's basically what you're calling "Render As..." for anything but rendering to AVI-encapsulated DV25 here...There should be absolutely no difference in quality because quality is not dependent on the speed of the processor...If there is a problem with quality using "Render As..." to MPEG-2 versus to DV AVI and separate MPEG-2 encoding, then I hope it's ripped out of the next release of software and explained openly and clearly as to why.

TVCMike, I agree with you 100%. And I write software for a living, so there are at least two crazy people in this thread :-) I can think of no *good* reason why the two-stepper should be superior to the "same" process performed in one-step.

If the "good" reason is speed, then its time to add an asterisk to the "best" setting in the mpeg render as.

>Any developers in the house?

LOL, but where is the rest of that classic?

>My understanding on this is that the temporal scaling is harder on the CPU and so it takes more away from the encoder. I could be talking out of my butt.

Spot, I *really* hope so :-) Because as TVCMike said, its quality vs speed tradeoffs. When the goal is quality uber alles, there is no such thing as "harder on the CPU", there is only "I hope you don't need this today".

And in all seriousness, I'm going to be really steamed if I find I've been missing a superior option that was available all along. Steamed at myself, perhaps if it turns out I wasn't reading this forum closely enough, but still really steamed...and I doubt I'll be alone.

I'm now starting to step out of my field of 'for sure' knowledge, so may well stumble, forgive me if I do.
In the process of combinant video as pixels are resampled, they are also scaled and dithered before being converted in a different color space. (4:1:1 to 4:2:0) and in the process they are scaled. My limited understanding is that Main Concept uses vertical temporal processing in the encode, which is a scaling device on it's own, regardless of whatever pre-processing Vegas might be applying to the stream. I was given some of this information because I wanted to know why in Vegas 4 beta, the encode to MPEG 2 looked different in Vegas from DVDA encoding the same information. They both use the same encoder.
As far as finding information on MPEG encoding on the Pinnacle and Adobe sites, just search their tech support. I'm sure it's there if it shows up on the DMN forum sites. (and it has) Either way, I'm not gonna argue over it, I've done it more than once, the results are clear, and it's not as though I'm standing alone waving this flag. If you really wanna know, the file is there for you to try it.
I will offer this one small caveat; if you are rendering only a talking head or no motion/low motion video, you are likely not going to see much if any difference for fairly obvious reasons.

>>>And in all seriousness, I'm going to be really steamed if I find I've been missing a superior option that was available all along. <<<
This is where I have to draw a pretty solid line. C'mon, you are gonna be steamed because you didn't take the time to bone up on something and try it out? And that's someone else' fault?
What I know about Vegas, I know because I've tried it. I've rarely read anything new here in the forums where I didn't immediately sit down and try it out for myself. No, I don't have a lot of time in the world either. But I do want to know everything that I can learn about this craft, and while reading is great, it doesn't further your real knowledge. There are a million armchair quarterbacks, but only 50 or so professionals that actually throw the ball. Somewhere, someone has to throw the ball. So rather than being steamed at anyone, how about throwing the ball. In the 14 hours or so that you've been reading this discussion, you could have easily rendered a couple of test files with your own media and looked at the differences.
There is SO MUCH info on this subject on the web, and in books. I highly recommend Ralph LaBarge's book on MPEG, and/or Ben Waggoners books on compression. Both excellent reads.
Fast, Cheap, Good...pick 2 of three, cuz you don't get them all. Good ain't fast, but it can be cheap. There is no Fast in quality, ever.
If Fast is what you REALLY want, render an avi, then print to tape, then use a hardware device to encode as I mentioned earlier on. That's the BEST means currently no matter what you use. But it's not cheap. Just good and fast.
But being steamed because you disagreed with something one way or another...That's your own call.

"TOUCH DOWN!" . . nice one Spot me lad .. .

.. . ahh the power and potency of information .. .

Zipps go and play, find what works for you and bring back your findings here . .I'm interested .. . .

Best regards,

Grazie

>>>>And in all seriousness, I'm going to be really steamed if I find I've been missing a superior option that was available all along. <<<

>This is where I have to draw a pretty solid line. C'mon, you are gonna be steamed because you didn't take the time to bone up on something and try it out? And that's someone else' fault?

Whoa. Did you read my following sentence? I'll repeat it:

"Steamed at myself, perhaps if it turns out I wasn't reading this forum closely enough.."

IOW, I am *not* saying it is someone else's fault. I am perfectly able to recognize when something is my own fault. I blame no one if there is a superior approach that I don't yet know about. However, there is a difference between stupidity and ignorance. In this instance, IMHO its ignorance. Am I stupid for assuming the 1-step render is equal *in every way* to a 2-step render? I really don't think so. I would *expect* the 1-step to be identical to the 2-step because it could be made to be. At the very least, in principle, by writing the intermediate avi to a temp folder behind the scenes. Or better yet to file out to an avi file as an intermediate buffered filestream if you absolutely had to for some esoteric reason that the algorithm required. IOW, I am *certain* I know of at least one (ugly) way to make that 1-step as good as the 2-step, if I were the programmer.

Which reminds me of a fine quote that is valid more often than I would like: "Its not what you don't know that gets you into trouble; its what you know that ain't so." Translation: Since I "knew" the 2-stepper could be coded as a 1-stepper without quality loss I *assumed* they were equivalent. Ok, bad assumption, but hardly an unreasonable one.

(Actually, I assumed that the extra step back and forth to a compressed avi would actually make things slightly worse, but let's not get off track with an additional ignorant assumption.)

>What I know about Vegas, I know because I've tried it. I've rarely read anything new here in the forums where I didn't immediately sit down and try it out for myself. No, I don't have a lot of time in the world either. But I do want to know everything that I can learn about this craft, and while reading is great, it doesn't further your real knowledge. There are a million armchair quarterbacks, but only 50 or so professionals that actually throw the ball.

Over the top, but I agree with you. I don't ever believe I know until I can do. But you do undersell reading. For example, a map is a useful read that can contribute real knowledge that might come in handy. Or a forum thread entitled: "Always use the 2-step render approach because it produces superior quality. Here's why" Now that might further my real knowledge without requiring having to sidestep a linebacker.

>So rather than being steamed at anyone, how about throwing the ball. In the 14 hours or so that you've been reading this discussion, you could have easily rendered a couple of test files with your own media and looked at the differences.

Actually, no I couldn't have. You surely don't want to know all this but since you bought it up: I've been programming all day (I don't have Vegas at work -- intentionally since I might not get any "real" work done otherwise; I think I mentioned this already), then I had to take care of my kids when I got home, while watching my jayhawks get beaten on national tv, then I finally got some free time, oh about 11PM my time. Then I downloaded your project and now I'm "doing" it. I won't be able to stay up all night but I have checked the 1st second of your veg file and I see *no* differences yet. Looking forward to checking the remainder, but I won't have the data until this time tomorrow.

(BTW, earlier today when I wrote: "Guess its something to try for myself tonight..." did you think I was kidding?)

Note 1: Rather than repeat the same old test you'd already run, I changed the project settings from "good" to "best" and added the Broadcast Colors filter with smoothing. Closer to how I normally do it.

Note 2: My procedure is to open the mpeg files in Intervideo WinDVD 4 and snapshot a bmp file, then open both bmp files in a graphics editor as 2 layers, then use a difference filter on the layers. I don't know if my capture tool is ideal. If you know a better approach with generally available tools, please let me know. But I can say that my one test point so far was identical in both cases. Probably very important caveat: It was in the B&W portion.

BTW, you get the award for most intensely challenging render test I've ever seen. Unbelievable :-) Media generators I never knew existed in Vegas! (I'm multitasking my P4 3.0Ghz, and the avi render is predicting a 5 hr encode...for a 30 second project.)

>There is SO MUCH info on this subject on the web, and in books. I highly recommend Ralph LaBarge's book on MPEG, and/or Ben Waggoners books on compression. Both excellent reads.

Actually, I find the field fascinating. I got sparked when I learned that one Japanese guy (TMPGenc) could blow away all those other companies. I figured it had to be either an incredibly challenging, open-ended algorithm and/or a very badly documented one. Truthfully, though, I've done quite a bit of web searching more than once and have been very disappointed in what I could find, at least without having to pay a *lot* of money. So I must respond that IMHO there is NOT "SO MUCH info on this subject on the web", at least in the form that I would desire before satisfying myself that I could code it myself.

As for the books you mentioned, I'll look them up sometime. Perhaps that is where I should have gone first.

>Fast, Cheap, Good...pick 2 of three, cuz you don't get them all. Good ain't fast, but it can be cheap. There is no Fast in quality, ever.
If Fast is what you REALLY want, render an avi, then print to tape, then use a hardware device to encode as I mentioned earlier on. That's the BEST means currently no matter what you use. But it's not cheap. Just good and fast.

I think the discussion long since moved to GOOD, period, so how about I pick just that 1 and let the other 2 float as needed. In the above paragraph, when you said "BEST" I assume you meant quality.

>But being steamed because you disagreed with something one way or another...That's your own call.

Never disagreed with anything. I just stumbled onto a shocking issue which is apparently common knowledge to the vast majority of the professional field. Frankly, I am dying to learn why the 2-stepper is better than the 1-stepper. So much so that I've already lost 3 hrs sleep testing and working on this response :-)

...and, I'm sure I'm not alone in finding this to be *big* news. (Granted, probably a minuscule quality difference in the vast majority of cases, but still a stunner factoid.) I'm wondering how everyone else will react when this leaks outside the "zippy-ignored, useless subject-matter" thread.


--------------
UPDATE

I have some results from the test: I had time to check 6 different snapshots this morning. I cannot trust Intervideo's timeline exactly, but I made the comparison at 2 secs, 5 secs, 10 secs, 15 secs, 20 secs, and the end. Identical in all cases. Conclusion: (1) My test procedure is invalid. (2) Setting Best quality and adding a Broadcast filter somehow changes the results. 3) There is no difference between the 1-step and the 2-step. Waiting with great interest for any futher information...

I must admit I've been reading Vegas and other forums daily for 2 years without knowing about this.

As it happens, I always create a single avi first, but not because I knew it produced better quality.

- I have experienced random glitches printing to tape directly from the timeline, so I always go to tape with a rendered avi from the Capture Utility.

- Also, I usually create MPEG 1 and MPEG 2 versions for CD Rom and DVD, and sometimes WMV for web, so it's best to have a single avi from which to create these.

- For archiving and space saving purposes, as soon as the final avi is rendered, all the original footage can be deleted.

Anyway, it's good to know that I've also been maximising my quality by doing this.

There's no way image quality can suffer because the processor "chokes" or whatever. It can do no such thing.

There's no way I would get better image quality by going through yet another lossy generation.

However, I do agree that by going to DV first it may look different. And that difference might look like it's better to someone so used to seeing DV encoded material. But what you're seeing shouldn't even be there in the first place.

If the straight-to-MPG file looks clearly worse, I would investigate the MPG encoder for errors.

Let me ask you this, do you get the same "improvement" by going to uncompressed .avi then to .mpg? No? Then the "improvement" is something created by the DV codec.

There, I'm crazy too.

LOL, but where is the rest of that classic?

This is all I could find. They have the Monkey Boy video on there as well.

As for the issue at hand, it's not even close to being finished...and you have an electrical engineer to back you up on that. :)

Perhaps the extra render to DV smooths out some high frequency detail that the MPEG-encoder then no longer needs to take care of.

Perhaps this is why I always find TMPGEnc better than the Mainconcept Codec at lower bitrates. More filtering in TMPGEnc?

Perhaps I should stop beginning sentences with the same word? :-)

The cure for high frequency content is higher bitrate, but as always storage space is limited.

I've got to say I agree with you on every point.

I am skeptical the Sony programmers would have written the render process in such a way that rendering direct to MPEG from the timeline would produce lower quality results in the way that Spot suggests. It might not be impossible I guess... but as you pointed out there are ways it could be coded to compensate for this.

I too have never noticed anything previously which demanded we (any NLE it seems) should always render from timeline to AVI and then to MPEG (at least not as a way to improve the quality).

If your tests are showing no difference using the approach you described (which seems to remove any subjective assessment from the equation) then I cannot understand where the stated improvements are coming from.

This to me sounds like it can only be answered once-and-for-all by a post from the developers.

K, after spending most of the day looking at this, talking to Sony's guys, testing....I have to make an apology and correction. I'm wrong, dead wrong.

Rendering to an MPEG from the timeline IS a better option, because you are at that point effectively rendering 4:4:4 to 4:2:0 instead of 4:4:4 to 4:1:1 to 4:2:0. The reason I'm seeing the difference, is that most of our MPEG output is to progressive scan formatting, and not to interlaced formatting. No scaling occurs in interlaced formatting, only in deinterlaced mode. This is why I'm seeing the improvement that I'm seeing. With high motion content even in interlaced mode, you'll see some improvement with the DV to 4:2:0 flow, ONLY because of some anti-aliasing that is taking place, but if you take the direct gradients and render them to MPEG from the timeline with zero movement, you can see a marked improvement over rendering to DV first.
My sincere apologies to all that I confused with my faux pax, mea culpa, mea culpa.

So, to clarify for anyone I've left confused:
Regardless of the origin of timeline content, render straight to MPEG, not to DV first. It's slower, but more accurate to original.

If you are blending fields, there is a visible difference/improvement in MOTION quality, but a loss in COLOR quality. I've been more interested in motion than color, simply because detail is more important to me than color depth. Hence the reason for my finding that rendering to DV is better first.

Rich, TVCMike, you can kick my A$$ next time you see me.

I'm glad we got an answer to this. Thanks.

I see the problem now --- 4:2:0
(not everyone will get this)
;->

>Rich, TVCMike, you can kick my A$$ next time you see me.

Not a problem. I'll settle for you buying the next round :-) Nah, you've helped out so often, I'll still "spot" you a couple.

Plus another thing I dont think I saw in this thread .
If you are going to use Markers for chapter points in DVDA,the markers you placed on the timeline do NOT stay with the avi render. yes you will see the orange lines in the avi render but some of the info is lost. then render that to say the mpeg DVDA template import into DVDA and try and find those chapter points in DVDA . Invisible!
Found out the hard way,