View Full Version : Jagged edges in separate fields of interlaced video


helge79
30th March 2007, 19:09
I've got an NTSC interlaced video recording, which I want to de-interlace and clean up. If I separate fields, I observe that, in each field, everything that moves has very uneven edges:

http://img339.imageshack.us/img339/1196/jiuge1nn7.png

http://img160.imageshack.us/img160/8487/jiuge2fw4.png

It looks as if there were some cross-talk between the two fields, which affects moving objects.

I would appreciate any information on the possible origin of this effect, and whether there are any intelligent ways to combat it (without introducing too much blurring). Thanks for your help!

Leak
30th March 2007, 22:36
I've got an NTSC interlaced video recording, which I want to de-interlace and clean up. If I separate fields, I observe that, in each field, everything that moves has very uneven edges:
Ummm... since movement is rather hard to see on screenshots - how about giving us a short clip that illustrates the problem?

np: Christ - Happyfour Twenty (Blue Shift Emissions)

helge79
31st March 2007, 00:14
Thanks for your participation, Leak! I've uploaded a short sample here: http://maxupload.com/0A4C5FF7

Please separate the fields and look at the edges of the red robe. They are much more rough than anything else in the frame, and it seems to me to be related to the interlace of the original video.

Didée
31st March 2007, 00:53
The bad news is that this is absolutely normal (judging only the screenshot). Chroma resolution of YV12 is only one quarter of luma resolution. For interlaced content, this means quarter resolution *per field*.
The edges of the red robe are where you can see the effect of this reduced resolution in all its glory.

Oh, if only they had never invented the idea of interlacing.

Welcome to the world of interlaced YV12. :)

helge79
31st March 2007, 09:22
Thank you, Didée, I see. So, this effectively means that anything with an abrupt change of saturated color (like this robe) will have quarter-resolution. But is there any intelligent algorithm that would smooth out the edges of highly saturated regions?

(I've never noticed this effect before when looking at my interlaced DVDs, but I guess it's not very common to have something so saturated against a black background...)

PS: Also, another thing: the edges of the Chinese characters on the first screenshot are also very uneven (look at the first column, for example). But they are white, so it shouldn't have anything to do with how chroma information is represented... :confused:

Leak
31st March 2007, 11:14
Thank you, Didée, I see. So, this effectively means that anything with an abrupt change of saturated color (like this robe) will have quarter-resolution. But is there any intelligent algorithm that would smooth out the edges of highly saturated regions?
Actually, most of the time just interpolating the chroma with something better than point sampling (which gave you those blocky edges) is enough.

Try using ffdshow to play your video and enable RGB32 output with "High quality YV12 to RGB conversion" enabled - that should give a much better picture.

But whether something like that is done totally depends on the playback software/video renderer/device.

PS: Also, another thing: the edges of the Chinese characters on the first screenshot are also very uneven (look at the first column, for example). But they are white, so it shouldn't have anything to do with how chroma information is represented... :confused:
Well, some of those lines are thin enough that they only appear in one field each. But unless the characters move this shouldn't be a problem, as a motion adaptive deinterlacer should just weave them, making them look correct. That's also why very thin lines always shimmer on TV.

helge79
31st March 2007, 11:26
Try using ffdshow to play your video and enable RGB32 output with "High quality YV12 to RGB conversion" enabled - that should give a much better picture.

But whether something like that is done totally depends on the playback software/video renderer/device.
Actually, I want to deinterlace and clean up this video and re-encode it as AVI. So, is there a way to emulate what you just described after loading the video into AviSynth with MPEG2Source?

Well, some of those lines are thin enough that they only appear in one field each. But unless the characters move this shouldn't be a problem, as a motion adaptive deinterlacer should just weave them, making them look correct. That's also why very thin lines always shimmer on TV.
The characters do move, and the shimmering looks worse than it usually does on good interlaced sources (at least, to my eyes). To be precise, I am not talking about the thin horizontal lines (which would indeed always shimmer), but about the roughness of the edges of the diagonal strokes (very similar to the roughness of the edges of the red robe on the other screenshot)...

Leak
31st March 2007, 13:03
Actually, I want to deinterlace and clean up this video and re-encode it as AVI. So, is there a way to emulate what you just described after loading the video into AviSynth with MPEG2Source?
Well, if your video is to stay in YV12 colorspace - not really. Sure, you can just do a ConvertoToRGB32(interlaced=true), which interpolates chroma, but if the codec you use converts back to YV12 (like MPEG2 or MPEG4 or h264) you'll get the same jagged output afterwards, since YV12's chroma channels have only half the resolution it's luma channel has.

If anything, you need to use a renderer that correctly interpolates chroma values, or use a YUY2 or RGB codec - and YUY2's chroma still has only half the horizontal resolution.

np: Styrofoam - There Is No Rest (A Short Album About Murder)

helge79
31st March 2007, 16:18
But this YV12<->RGB problem is twice as severe for interlaced footage as it is for progressive footage (as, I think, Didée implied). So, the question is how to do deinterlace appropriately to minimize the amount of jagginess in the final progressive frames. (True, there is a fundamental limitation due to YV12 color space, but I think that unintelligent deinterlacing would produce a clip twice more rough than this fundamental limitation... Basically, I just don't like the way it looks after I bluntly apply TDeint, and I am trying to find out whether there is anything more intelligent to do...)

Guest
31st March 2007, 20:00
Try applying the AutoYUY2() filter and then running TDeint() in YUY2 space.

http://neuron2.net/autoyuy2/autoyuy2.html

I don't know if it will help, but it will be an interesting experiment to see if it does. :)

helge79
31st March 2007, 20:45
Thanks for the suggestion, neuron2, but I'm afraid it makes the problem worse (I haven't played with the threshold of AutoYUY2 though).

Here is what plain TDeint does:
http://img339.imageshack.us/img339/1903/tdeintpz6.png

And here is AutoYUY2() followed by TDeint:
http://img508.imageshack.us/img508/5535/autoyuy2tdeintra6.png

Leak
31st March 2007, 21:47
But this YV12<->RGB problem is twice as severe for interlaced footage as it is for progressive footage (as, I think, Didée implied).
Well, the colorspace conversion probably is less severe than you think - why don't you just try it out for yourself? :)

The output of

MPEG2Source("jiuge_fragment.d2v")
ConvertToRGB32(interlaced=true)
LeakKernelDeint(order=1,threshold=5) # I don't have a current build of TDeint here
#ConvertToYV12()

looks okay to me, as does the same script with the "#" removed in the last line - it's normal for the deinterlaced parts to look a bit blockier than the rest, but it's not really that noticeable once you play the result; don't just go by stills.

np: Styrofoam - A Heart Without A Mind (I'm What's There To Show That Something's Missing)

helge79
31st March 2007, 22:27
Thank you, Leak! Actually, your little script produces quite nice result. In fact, much better than TDeint in YV12 color space (which, I think, is precisely coordinated with Didée's remark on hyper-reduced chroma resolution in interlaced YV12).

Here is the output of your script:
http://img76.imageshack.us/img76/5553/rgb32bv9.png

And here is plain TDeint:
http://img57.imageshack.us/img57/7579/tdeintty1.png

As a matter of fact, after your previous posts, I was trying to do just what your script does, but TDeint refused to take RGB input. So, the question now is what's the best combination of colorspace convertion and deinterlacer for my video. (I am not really familiar with LeakKernelDeint. From its name, I am assuming it's your creation...)

helge79
1st April 2007, 09:26
Oops, but if I do ConvertToRGB32() after TDeint, it's also fine... So, I guess the problem is with VirtualDub renderer... Sorry about confusing everyone... :rolleyes:

Leak
1st April 2007, 10:28
Oops, but if I do ConvertToRGB32() after TDeint, it's also fine... So, I guess the problem is with VirtualDub renderer... Sorry about confusing everyone... :rolleyes:
Well, earlier versions of VirtualDub and probably all of VirtualDubMod can't display YV12 directly, so that might be your problem.

VD 1.6.17 displays YV12 fine, though.

np: Styrofoam - You Pretend You Own This Place (I'm What's There To Show That Something's Missing)

helge79
1st April 2007, 10:39
Yes, thank you, I've got an earlier version. Will update it then...