Thin green line at the bottom (GreedyHMA?)

[Boulder]

Hi all, I seem to get a green line at the bottom of my video after deinterlacing it with GreedyHMA. Here's the script I used (PAL video):

LoadPlugin("c:\windows\system\convolution3d.dll")
LoadPlugin("c:\windows\system\greedyhma.dll")
SegmentedAVISource("e:\temp\captures\capture.avi")
Trim(2224,21876)+Trim(27454,39250)
Fadeout(53)
GreedyHMA(0,0,0,0,1,0,0,0)
Convolution3d(0,4,4,4,4,2.8,0)
BicubicResize(320,256,0,0.6,8,0,704,576)
AddBorders(16,16,16,16)

If I use FieldDeinterlace(blend=false) instead of GreedyHMA, there's no green line to be seen. I've tried different resizing methods with no luck. If I change to top field first, the line disappears but my video captures are bottom field first according to several identifying tests.

Any ideas?

[UGAthecat]

I got a similar green line on an encode of The Others. The green line on mine only appeared in the really dark scenes, and I probably wouldn't have noticed it if it didn't happen during the studio logo screen at the beginning of the movie when the bottom of the screen was all black.

Anyway... the only thing my script has in common with yours is the use of convolution3d, and bicubic resize. I was using an mpeg2dec source, no trim, no fadeout, no greedyhma, and no addborders.
So it looks like something with either the resize (which I doubt), or the convolution3d, or possibly the combination of the 2.

I have not gotten around this green line, as every attempt I made to encode the Others ended up WAY undersized, so I backshelfed it right after the test that got the green line, so I'm sorry I can't say I found a fix. :(

[Dark-Cracker]

hi,

perhaps greedyhma have a problem with the resolution (need to be a modulo 4 pix) try to put your resize filter and after the greedyhma filter, this will perhaps solve your problem.

++

[trbarry]

Blight reported this problems in an old post many months back but I thought he was crazy and I never found it. ;)

But I have since learned that I should not just use Vdub preview for looking for things like this since some of my filters have slipped past with this sort of bug. A one pixel thick OBO error will not always show up in Vdub preview because it is bumped up against a shaded frame.

So I have learned to do at least some testing with 8 black pixels around the edges of my test clips, but I have still not found the cause of the greedygreen line. :(

- Tom

[soujir0u]

I got this problem with TomsMoComp too! I was using BicubicResize and Convolution3d too! But I wonder why the green line only appears in some scenes.

Edit: Sorry, I realised that it was because I put tomsmocomp after crop. After I changed it to before crop, everything turned out fine!

[Boulder]

Fortunately the green line shows only when I add the borders. Otherwise it will end up in the TV overscan area so it doesn't matter.

[trbarry]

I got this problem with TomsMoComp too! I was using BicubicResize and Convolution3d too! But I wonder why the green line only appears in some scenes.

Edit: Sorry, I realised that it was because I put tomsmocomp after crop. After I changed it to before crop, everything turned out fine!

Arrrrrrrrrg! I thought TomsMoComp was immune to this. By the time I developed it I was onto the trick of using some black borders in Vdub to be able to see the edges.

And you should be able to crop before TomsMoComp. I always do it, though if it is to strange boundary alignments I may not have tested it for those conditions.

Could you post a filter script that causes this?

- Tom

[soujir0u]

Here's the script:

LoadPlugin("C:\PROGRA~1\GORDIA~1\mpeg2dec.dll")
LoadPlugin("C:\PROGRA~1\GORDIA~1\tomsmocomp.dll")
LoadPlugin("C:\PROGRA~1\GORDIA~1\convolution3d.dll")
mpeg2source("E:\3\3.d2v")

crop(15,64,687,357)
tomsmocomp(1,0,1)
convolution3d(0, 4, 4, 4, 4, 2.6, 0)
BicubicResize(560,320,0,0.5)

I think it's because my horizontal resolution isn't divisible by 4, but doesn't it usually give an error message?

[trbarry]

Yep, it's probably the odd cropping. And yes I thought there was an error message, at least for the horizontal. But it also wouldn't be valid to deinterlace an odd number of lines since deinterlacing tries to match them in pairs.

- Tom

[sh0dan]

Horizontal size doesn't affect the green line, but the green line appears, if height is odd.

mpeg2source("ae_gg.d2v")
crop(16,64,640,357)
tomsmocomp(1,0,1)

Gives a green line -

mpeg2source("ae_gg.d2v")
crop(16,64,640,358)
tomsmocomp(1,0,1)

Doesn't.

[Guest]

Originally posted by trbarry
But it also wouldn't be valid to deinterlace an odd number of lines since deinterlacing tries to match them in pairs.That's not necessarily true of all deinterlacing algorithms. For example, FieldDeinterlace() handles odd heights without complications.

[sh0dan]

Yeah - if (height&1) {BitBlt(last line);}

[trbarry]

Sorry. I'm going thru a lazy period. ;)

- Tom

[Guest]

@sh0dan

Isn't memcpy() faster for one dimension? :)

[trutifuti]

Take a look at this : http://forum.doom9.org/showthread.php?s=&threadid=37316
And your green line is gone.