Chain link fence jitter

studio818 wrote on 10/24/2007, 11:46 AM

I have an annoying rendering problem with Vegas, although it could be an inherent problem with all editors.

The problem occurs when I 'ctrl-stretch' a video clip of a still photo sequence and render it. The result can be pretty bad and looks like jitter or flicker which is very noticeable in outdoor clips. The chain link type fence is jittering away like crazy!! I do not believe it is interlace flicker because I can see it on the computer screen.

I take 2 still photo jpgs (outdoor scenes) and put them on the timeline for 1 second each. (BTW, I usually use 5 or more but I'm simplifying the problem) I create an intermediate avi file from these.
I can then ctrl-stretch this avi to fit into specific length video windows in the final video (e.g. 3 seconds, 2.5, etc). When I look at the timeline with the stretched clip before I render, it looks fine. Now if I render the stretched avi it looks like hell. The chain link fence is jittering away.

I have tried all the obvious tricks. Reduce Interlace flicker, force resample, best rendering, two-pass rendering, and progressive rendering didn't help. It happens to all the output I've tried - avi, mpeg2, mov, etc. Also tried no compression.
These are still scenes with no motion!! Why would I need a special render?

Yes, my workaround is to go back and use the original stills, but I normally don't keep them with the project. I also work with lots of these sequences.

Why does this motion type conversion wreak havoc?
Is it just Vegas?

Any help or insight appreciated,
Peter

Comments

xberk wrote on 10/24/2007, 7:59 PM

>>Why does this motion type conversion wreak havoc?<<

Don't know why. I did duplicate the problem. I even tried saving the 5 still images as a .veg file and using that for the "ctrl-stretch" .. I thought the .veg would just be pointing to the original file and settle down -- but no luck. Oddly, what seemed to work (I didn't do extensive testing so I might be way off here) is to reverse the workflow and make your 5 stills longer on the timeline, say 3 seconds each and then instead of "ctrl-stretch" to lengthen the event, use "Ctrl-stretch" to shorten it to time....Not sure this will be practical or work timing-wise but the render seemed to lose the jitters in the outdoor stills....

ushere wrote on 10/24/2007, 8:58 PM

why ctl-stretch? if it's a still what's it matter just trimming as normal?

leslie

Grazie wrote on 10/24/2007, 10:51 PM

Leslie, I'm guessing here, but maybe our friend has some panning going on ON the still and wants to s - l - o - w it down a tad? Is this a non-deinterlace still? Are the 2-fields of the captured still playing jitter?

I suppose it this is NOT a interlaced still, the thing to do to start with is to deinterlace it - yes? Then I would fill the time space with the whole of the still and THEN do a slow Pan. If it WAS a captured still, I'd deinterlace first. But maybe I've got it wrong? Let's see ..

Regards

Grazie

Ah! Edit here . . just seen that it WAS a still photo! And not a captured still from a 2-field supply.

Ok, maybe too much detail and panning going on? But no, I too don;t see why ctrl+stretch? Only if it IS to slow panning movement. Again to high a resolution creates jitter - just by itself. Lower reso and a tad of Gaussian.

studio818 wrote on 10/25/2007, 1:04 AM

Thanks for replying.

There is no panning going on although I also have had issues before with a slow zoom into a hi-res still photo.

These are still photos, not interlaced captures. I checked the original resolution and it was 1600 by 1200. I resized to 640 by 480 and tried again. Same jitter. Also tried Gaussian blur to no avail.

Glad to see someone else could reproduce this. I did try the ctrl-stretch to make it shorter and it is not as noticeable bu still there slightly.

This only seems noticeable with outdoor photos but not a comforting thought about ctrl-stretching and rendering in general. I'll see if I can post an example photo.

Thanks
Peter

farss wrote on 10/25/2007, 1:05 AM

I was going to suggest it was some Zen thing, a slow motion still :)

But reading back exactly what is going on here it's not quite so simple.
He's taking (say) two stills, putting them on a T/L as 1 second each and rendering that to an AVI. Then he takes that avi into a new project and stretches that to a length to match into the rest of the project. In the process he may well delete the original still image(s).

I seriously cannot fathom why he's working this way, it seems kind of counterproductive as the the avi stubs use more disk space than the stills and are of lower quality. More to the point if rendered to an AVI it's most likely interlaced and that's what's being stretched which means Vegas is interpolating fields. Anyways as you said a small amount of Gaussian Blur (.001 to .003) in the vertical direction only should nail the problem.

What looks like interlacing problems can occur in a purely progressive video also. Potentially you might need GB in both directions I think. What you're seeing if that does happen is aliasing.

Bob.

studio818 wrote on 10/25/2007, 5:37 AM

Thanks for replying.

I knew some of you were going to get hung up why I was doing it this way. I didn't want to waste a lot of time explaining but hopefully suffice it to say is I'm currently working with dozens of these type of clips and it's a big time saver and organizational help (although not storage efficient, etc) Enough said.

Anyway, if I go in and modify the properties of my questionable intermediate avi clip and set this to progressive, then the subsequent stretching and rendering works fine. NO jitter. Problem solved (I hope).

So no matter what kind of rendering options I used before, it didn't matter because the input AVI clip was interlaced (garbage in/garbage out).
I should have thought of that sooner.

Thanks again for your help

Peter