MPEG2 Rendering oddities

shooter wrote on 8/2/2003, 10:15 PM
When I render a project into MPEG2, the output has scan line motion artifacts in places that equate to certain parts (clips) of the same source clip. Anyone tell me what might be causing this ?
The project I am currently working on is exhibting this in some of the clips. The clips in the beginning are of varying lengths from 15secs to several mins.
The source clip is an MPEG2 captured from an analog tape thru ATI's TV video capture.
The source clip DOES NOT have these lines in it.
I rendered the project to .avi then re-rendered that to MPEG2, it solved the problem of the lines, but... (I know that all of this rendering on clip of a clip does not give the best output).

Source clip data:
NTSC-DVD 29.97FPS 720x480 VBR 6000KB max Audio: 48KHZ 224kbps layer 2.

Comments

JohnnyRoy wrote on 8/3/2003, 9:58 AM
If it’s only noticeable during quick motion, it’s possible that this is a field order problem due to interlacing. When you render, go into the options and reverse the filed order. If is says, “bottom field first” try “top field first” or vise versa.

~jr
shooter wrote on 8/3/2003, 10:58 AM
Thanks, I'll try that, btw...
Field order on project is set to None / progressive scan. I've been using that previously on my Ulead projects & haven't seen this problem. Is it something unique to this encoder ?
JohnnyRoy wrote on 8/3/2003, 2:38 PM
No, this is not unique to any encoder. I’m no expert, but from what I’ve read, field order has to do with the fact that NTSC video is not transmitted progressively but rather the even lines are sent and then the odd lines are interlaced with it. This had to do with the rate at which you need to refresh the phosphor on a T.V. picture tube so that your eyes would not detect the frame rate flicker. Computer screens are progressive but TV’s are not.

Field order should not be set to progressive scan unless your input device is progressive scan or you want to output to a device that is progressive scan. Field order only has to do with video interlacing so if you have everything (i.e., from capture through render) set to progressive scan then field order shouldn’t matter.

The analog tape you are capturing absolutely has a filed order because it’s interlaced. I would venture to guess that the ATI TV card also captures interlaced. If you are capturing as progressive scan from your ATI card then it must be deinterlacing the video on-the-fly as it captures. That means it’s blending the two fields into one as its captures and encodes. I don’t know if this is what you’re doing (or of the ATI is even capable of this)

I also don’t know anything about what worked or not with Ulead products, but I assume you’re creating MPEG2 to burn to DVD’s. If you don’t own a progressive scan DVD player, then I suggest you capture, edit, and render the interlaced video as interlaced video preserving its original format. Otherwise it will just get transformed into interlaced on the fly as its output to your non-progressive DVD player/TV set anyway. If you are creating MPEG2 for display on a PC only, then you should use progressive scan for output.

If you are really worried about quality, I would not be capturing MPEG2 because it is highly compressed, it does not compressed very well in real-time without costly hardware assistance, and it’s a terrible format for editing. If you are just capturing to burn onto DVD then its OK, but you would get better results if you captured to DV AVI and then rendered as MPEG2. This is because its takes about 2 times the running length of the clip to do a good job at encoding. By encoding on-the-fly in real-time with the ATI card, you are capturing with sub-optimal quality to begin with.

~jr