Isn't there a way to put two video files out of phase to see what the difference is? Maybe someone could try that with a smart-rendered file out of phase with the original. I remember that this can be done, but I'm not sure of the exact process.

Another possiblity is that Vegas is rewriting the header during the smart-render in such a way as to make it play back with a different playback codec: one that isn't as good it seems. Maybe the files are identical but being played back in such a way as to make it seem inferior after the no-recompress render. Especially if the no-recompress file is being played back with something like the k-lite codec vs some codec that SCS installed.

"Isn't there a way to put two video files out of phase to see what the difference is? ... I remember that this can be done, but I'm not sure of the exact process."

I described how to do that in the fourth message in this thread.

And I alluded to a method in my last post.

"Another possiblity is that Vegas is rewriting the header during the smart-render in such a way as to make it play back with a different playback codec: ... Maybe the files are identical but ..."

Why would rewriting the header make the render time increase by a factor of FOUR? It seems to me that a lot more than setting a few flags is going on.

[I]"Isn't there a way to put two video files out of phase to see what the difference is? Maybe someone could try that with a smart-rendered file out of phase with the original. I remember that this can be done, but I'm not sure of the exact process. "[/I]

That's exactly what I did and No, the smart rendered file from V13 is different to the original.



Bob.

I rendered my test HDV video with Vegas 9 and Vegas 13 five times , to average out slight variability. In all cases, Vegas said "no recompression required".

On average, Vegas 13 took 4.53 times longer to render than Vegas 9.

[I]"I rendered my test HDV video with Vegas 9 and Vegas 13 five times , to average out slight variability. In all cases, Vegas said "no recompression required".

On average, Vegas 13 took 4.53 times longer to render than Vegas 9. "[/I]

Which proves ONLY that V13 is slower at doing something than V9, beyond that it proves nothing. Not to say that it isn't alarming and shouldn't be looked into but by itself it does not prove that V13 is recompressing video when it says it isn't.


As I posted previously my own tests indicate that there is something going wrong, the "No recompression required" output from V13 is significantly different to the source. That's what matters, how long it took doing it doesn't lend any weight to your argument either way.

Bob.

"Which proves ONLY that V13 is slower at doing something than V9, beyond that it proves nothing. Not to say that it isn't alarming and shouldn't be looked into but "

It is NOT by itself. As I said a few posts above there are two pieces of evidence that Vegas 10-13 is not smart rendering.

I mentioned the time factor above to discredit the view that it is something simple like a flag in the header. Why would something simple like that take 4.5 times longer to render?

Can you prove that it is smart rendering? Is there any hint that it is except for the message saying that it is?

As I asked before, what else is likely to produce a non-zero difference and a 4.5 fold render time except a re-render?

[I]"Can you prove that it is smart rendering? Is there any hint that it is except for the message saying that it is?"[/I]

No, in fact as I've now posted for about the third time I can prove that it is NOT smart rendering.

[I]" As I asked before, what else is likely to produce a non-zero difference and a 4.5 fold render time except a re-render?"[/I]

Anything could produce a difference in render times.
Slight differences in a header could cause Vegas to decode video slightly differently.
That's why in the test that I ran I attempted to smart render between exactly the same codec that's internal to Vegas and it failed.

I've found instances with HDV years ago where Vegas doesn't do exactly what it says it does e.g. capture 25PsF from a tape and render it to the same thing and yet it could not be printed back to tape. 50i could, weird. I could render the 25PsF to 50i and print that to tape, the video is in theory the same however the "P" flag is missing on the tape.

Bob.

"Anything could produce a difference in render times."

Not too many things will produce a 4.5 times increase AND non-zero difference AND still smart render.

[I]"
Not too many things will produce a 4.5 times increase AND non-zero difference AND still smart render."[/I]

Why don't you simply try the same kind of test that I used.

Take the video that you rendered from the captured tape and render it again using the exact same codec and settings.
Then compare the two video files using the Difference Squared compositing mode. If you see ANYTHING on the scopes your case is made. You've eliminated every possible variable.

I'd do this myself however I haven't used HDV in years and the codec (XDCAM EX) that I did use is VBR mpeg-2. HDV is CBR so it'll be interesting to see if the CBR / VBR difference has anything to do with it.

Bob.

I just want to ask a question here. All the test methods mentioned in this thread involve applying an FX or composting mode to one or both tracks, right? So if we apply a FX or compositing mode, doesn't the video then get processed before it is shown in the preview window hence distorting the test?

Well I did just as you said, and there was still some scatter near the origin of the Vectorscope for the difference between first and second renders.

(I prefer the difference function on the scope (strictly absolute difference, because it takes the magnitude of the difference) over the difference squared because the scatter is more obvious.)

However, what I also noticed was that for the difference between original and first render, only about 1/3 of frames were non-zero while for the difference between first and second renders, only about 1/4 of frames were non-zero. In other words, most of the frames were either copied without change or computed to an identical value.

If the smart render feature is turned off in preferences, render time increases by about 20%, and the message "no recompression required" does not appear. However, now all the frames seem to have a non-zero difference. Clearly smart rendering is not occurring now.

So my title for this thread seems correct after all. It would appear that Vegas 13 sort of smart renders when it says it is, but not properly. The long render time is still a worry, however, and still gives me some doubts about that statement.

OldSmoke, not really, not in the way you think. Both videos get "processed" in that they get decompressed, but that's the end of it. Inverting the video is a lossless transform that doesn't alter the, well, for lack of a better term, the 'physical construction' of the image. It is a mathematically pure operation.

What farss is getting at is that the videos may not be decompressed the same if the header information is different, so different codecs might get called into play in the decompression step. He's proposing a test that would eliminate this difference.

Reply to OldSmoke.

The important thing is that if you do a difference on a render made with Vegas 9 you get zero for all frames, but the render from Vegas 13 gives many frames that are non-zero.

Vegas decodes both video tracks to RGB or whatever space it works in and then computes the difference. Vegas has to decode in order to display the video on the monitor. Decoding is always done on the fly.

Sorry Kelly. You said it better.

How about VP10? I don't have it on my machine anymore. The reason I am asking is that after V9, SVP was changed to include GPU support. In V10, not many know that, Sony AVC was supposed to be GPU supported during render. From my understanding, with the introduction of GPU acceleration, the render engine was redesigned and with VP11, the ON/OFF setting in preferences became available and also the render templates where changed to include GPU options.
I have done the test(s) as suggested and I can see the difference in the scopes too but I am uncertain of what I see in the scopes as I don't see anything at all in the preview window or on my external monitor. I even changed the external monitor's contrast and brightness to highlight the darker areas better which is where the difference seems to be, but nothing to see.
I doubt that different codecs are in play, I "smart" rendered the already "smart" render clip to ensure both will use the same codec.
What is puzzling is that the files are different in size too.

[I]"However, what I also noticed was that for the difference between original and first render, only about 1/3 of frames were non-zero while for the difference between first and second renders, only about 1/4 of frames were non-zero. In other words, most of the frames were either copied without change or computed to an identical value."[/I]

Thanks.

That's pretty much what I've seen as well.
The frames that were different were at the beginning and end of the video. I thought this might have something to do with the mpeg-2 XDCAM EX uses being VBR but not so it seems.

I would understand (I think) the need to encode [I]some[/I] frames when using a fixed length GOP but not as many as I'm seeing being re-encoded lossly.

I'll try different length video clips and compare render times and outcomes.

SCS did seem to admit they made some changes to how this smart rendering stuff works in V13 because of issues with H.264 video. I have to wonder just how carefully that was tested and why the changes are not fully documented.

Bob.

When you do an MPEG2 render, there is an option to set the video quality using a slider ranging from 0 to 31. If Vegas is smart rendering, this slider should have no effect.

Using Vegas 9c, I rendered a short SD 50i clip with the slider set to 31 and to 0. There was a difference at the start and at the end of the clip, suggesting that the first (few?) and last GOPs were being re-rendered, but the intervening GOPs were being smart rendered. (From 0.00 to 1.10 (35 frames) there was usually a difference. From 1.11 to 16.05 there was no difference and from 16.06 to the end at 16.17 there was usually a difference.) Taking the difference between the original and a rendered version produced the same pattern.

When repeated with Vegas 13, the difference between quality 0 and quality 31 renders was generally non-zero from 0.00 to 6:17 (167 frames). then there was zero difference until the final GOP, the same as for Vegas 9c. The difference between the original and a rendered version was generally non-zero throughout.

So with Vegas 13, the render quality does have some effect when it should be smart rendering, but the effect is not as great as I thought it might be.

It is interesting that even Vegas 9c re-renders the start and end of a clip when there should be no need to. A VideRedo render shows no difference throughout.

"I have done the test(s) as suggested and I can see the difference in the scopes too but I am uncertain of what I see in the scopes as I don't see anything at all in the preview window or on my external monitor."

I now see the same thing but when I started, I thought that the "noise" difference was slightly visible in the monitor if you squinted hard. Certainly the difference is more visible with SD rather than HDV, and more visible at the ends where the GOPs are definitely being re-rendered.

I have been having a closer look at rendering MPEG2 in Vegas. My source material was 50i HDV recorded with a Sony HDR-HC7E (PAL version).

Degree of No Recompression

Vegas 7 does not have a "no recompress" feature. Using the difference compositing function, I compared the "no recompression" outputs from Vegas 8 to 13. Outputs from versions 8 and 9 were the same, versions 10 and 11 were the same and versions 12 and 13 were the same. Video outputs that looked the same did not have identical file contents, however (tested with FC /B command).

Vegas 8 and 9 gave almost complete no recompression, the start and end of the file being the possible exceptions, especially when previously trimmed.

Vegas 10 and 11 renders started off with most frames generally different (recompressed). After about 4 seconds (100 frames) it settled into a "two frames different one the same" pattern for most of the remainder of the clip, giving about 67% recompression.

With Vegas 12 and 13, the first 3 or 4 seconds (75 to 100 frames) of the clip had fairly heavy recompression. This was followed by clusters of frames with non-zero differences, apparently related to the GOP structure, giving about 25% recompression.

Render speed

Vegas 7 apparently only renders to program stream (.mpg suffix) but later versions can render to HDV (transport stream, .m2t suffix).

The render times and CPU usage given are for rendering an unedited HDV clip 5 mins 47 secs long, using my computer's CPU only (Intel i7 920 2.7 GHz). It has 4 cores with hyperthreading, giving 8 possible processing threads. The render times are only approximate because of variability, and I only rendered a few times. The results for "Enable no recompresion" set to "off" (i.e. force recompression) are given first.

Vegas 7e: 2m 52s, 52% CPU with 7 threads; N/A
Vegas 8c: 3m 22s, 47% CPU with 7 threads; 2m 32s, 18% CPU with 4 threads.
Vegas 9c: 0m 43s, 19% CPU with 4 threads ("no recompression" notice!); 0m 45s, 19% CPU with 4 threads.
Vegas 10e: 2m 54s, 83% CPU with 8 threads; 3m 20s, 22% CPU with 4 threads.
Vegas 11-701: 2m 56s, 85% CPU with 8 threads; 3m 20s, 19% CPU with 4 threads.
Vegas 12-770: 2m 55s, 90% CPU with 8 threads; 3m 10s, 19% CPU with 4 threads
Vegas 13-373: 3m 15s, 95% CPU with 8 threads; 3m 9s, 18% CPU with 4 threads.

Note that "no recompression" uses 4 instead of 8 threads and the CPU usuage is much lower, as expected.

There is a bug in Vegas 9 in that disabling "no recompression" apparently has no effect, but surprisingly the rendered output files are still different.

While Vegas 8 and 9 gave the same video output for no recompression, the processing times are considerably different. The short processing time for Vegas 9 is singular.

Vegas 10, 11 and 12 are slightly slower during no recompression, compared to forced recompression.

Effect of GPU (Vegas 11-13).

The GPU processing results were generally the same as for CPU only processing. Frame differences followed the same pattern, but were not identical to the CPU only results. Processing times were only slightly lower with GPU enabled and forced recompression, while CPU usage was very similar.

Generational Loss

With Vegas 13, the first and second frames suffer the most from reprocessing during so-called "no recompression necessary" rendering. If I switch between the original and the first render, I can see a slight change in texture; a slight increase in noise. After several generations of reprocessing, this becomes quite bad and ugly (blotchy). At the 3rd generation it is quite obvious to me. At the 6th generation, the second frame is equally bad, but the third frame is the same as the original. After that there are differences, but they are small and not obvious when looking at the compositing difference on the monitor. In fact, when comparing the 5th generation with the 6th it looks as though, well after the start, the differences have almost disappeared!

With Vegas 9, It was the 2nd frame that suffered the worst.

I then looked at generational loss with enforced recompress. Throughout the video, including the start, the noise increase was gradual with generational increase, and was not unpleasant. By the 6th generation, the compositing difference was obvious in spots without straining to see. When you focused on one of these spots and alternately looked at the original and the 6th generation render, there was a quite obvious change in colour, but it might go unnoticed if it is small enough.

Conclusions

Smart rendering (no recompression of unchanged video) is sort after because it has the potential for fast rendering and no quality loss. Only Vegas 9 has a significant speed advantage, while Vegas 8 and 9 have the least unnecessary recompression, but they are not perfect. (Some unnecessary recompression may occur at the ends of a clip that has not been trimmed.) Vegas 12 and 13 are the next best at not recompressing unnecessarily. The worst effect of re-rendering is in the first two frames (in my samples).

If the first two frames are important and you intend to do multigenerational rendering, you might consider whether it would be better to force recompress. If not, then most of the video will look virtually unchanged with "no recompression necessary" rendering.

I have just updated the previous post to include consideration of multigenerational forced recompress.