GK and GreedyHMA (wrong crop/green borders)

[Corrado]

Hi,

just encoded a movie to DivX4 with GK and, since it's PAL, as usual I didn't de-interlace. But I found several "ghost horizontal lines" in the output avi during panning camera movements, so I tried GreedyHMA (which gives me good results on my DV material).

The Problem? The new movie has a thin black border on the left (ca.3/5pix) and a not-so-thin GREEN (!) border on the right (ca.10/12pix). Why?

Other than this, the movie is fine (the "ghost lines" disappeared), although a bit more blurred than the not-deinterlaced version and with more visible compression artifacts (shadow pixels around sharp tone changes, like the character's head). But I guess this is unavoidable by deinterlacing, isn't it?

These are the steps I followed:

1-Re-open the previous .avs file, Remove comment to GreedyHMA line, save file.
2-Open GKnot with the same settings as before (I saved them in a profile): this is needed for the bitrate, right?
3-Only difference: use the already encoded MP3 file (telling it to GK with the proper settings in the resolution and job windows)
4-Open the "Add Job" window in the encode tab and manually specify the path for .avs, .avi and .mp3
5-Run Job

These are the movie specs:

Movie is 118min PAL 16:9 (interlaced? DVD2AVI says so...)
.d2v with no FORCE FILM (obviously), YUV colorspace.
Final Resolution: 640x272
Resize method: Sharp Bicubic
Filter: none
Sound: 160kbs ABR
Size: 2x650MB CDs (minus 25MB total for launcher, codec, player)
Video Bitrate (specified by GK): about 1300 kbs
bits/frame: 0.3+

Thanks for your help, sorry for the long post (wanted to give all the info I could...)

Corrado

[manono]

Hi Corrado-

You may have to fool around a bit to get it right, but I believe the easiest way to get rid of the green along the right is to move your deinterlace command before crop. Another way might be to make sure all of your crop numbers are even numbers.

As for the black on the left-you did make sure to crop it away at the beginning, right? Is it the same all the way through the movie? Sometimes the size of the black bars changes as the movie goes along.

As for deinterlacing artifacts-Greedy sometimes deinterlaces good frames making jagged lines, and if you're sure the problem is not with the source DVD, you might have more luck using Decomb for deinterlacing. Or maybe try Neutral Bicubic if the "shadow pixels" are caused by the Sharp Bicubic.

It's usually a good idea to scroll through the .avs in the preview window in GKnot, or in NanDub before encoding to make sure everything looks OK.

[Acaila]

The green line is the result of a wrong cropping resolution. Make sure the parameters within the crop command are all divisible by 4.

e.g.
crop(714,288) --> gives a green line
crop(704,288) --> a correct resolution

[Corrado]

Thanks for the answers.

Deinterlacing was performed BEFORE the crop/resize functions, I believe (I just edited a GKnot made movie.avs file, so I'm not sure, maybe TheWEF can help here. Unluckily I've deleted the .avs and the .log files).

I also thought that a wrong crop/resize could be the reason, but the final size is 640x272, surely divisible by 4 (and 8, 16, 32...): the resize couldn't be the problem, then. Maybe the cropping (it had odd numbers like 7 and 9 for left/right), but again I think that cropping was done AFTER GreedyHMA, or anyway together with resizing. TheWEF, can you confirm this?

About the black bars: I'm sure I cut them out: it's the SAME .avs file that I used for the not-deinterlaced test before (that had no black or green borders at all). And yes, I know that they move during the movie, I had to browse it before finding the "highest required" crop...:( But those "new" bars are there in all the movie.

About scrolling in Nandub, thanks Manono for the suggestion, I knew it but I forget it sometimes, expecially since GKnot has made that great automation work and you don't even open Nandub... :D

About deinterlacing alternatives, thanks again. I also found a couple of interesting threads about PAL deinterlacing and I'll experiment a bit.

Corrado

[Acaila]

I also thought that a wrong crop/resize could be the reason, but the final size is 640x272, surely divisible by 4 (and 8, 16, 32...): the resize couldn't be the problem, then. Maybe the cropping (it had odd numbers like 7 and 9 for left/right), but again I think that cropping was done AFTER GreedyHMA, or anyway together with resizing. TheWEF, can you confirm this?

The resolution that's used as input for the GreedyHMA filter is the one that has to be correct. That usually is the crop(x,y) resolution, not the resize(x,y) resolution. In GKnot GreedyHMA is always used after cropping, but before resizing...

[Corrado]

Originally posted by Acaila
In GKnot GreedyHMA is always used after cropping, but before resizing...

Thanks. I've retried the whole process and I noticed the same thing. Unluckily the "Smart Crop" function in GKnot uses also odd figures regardless if you perform a deinterlace operation. I fixed that manually.

By the way, I tried a multiple of 4 (700x420 after cropping) but I still had the same problem. When I moved to a multiple of 8 (704x416, multiple of 32x16 to tell the truth...) the green line disappeared.

Corrado

[Acaila]

Oh well, I know for certain that the SimpleResize filter needs multiples of 4, I just figured that GreedyHMA (since it has the same creator) needs the same. If 8 works, great.

[Corrado]

Originally posted by Corrado
I found several "ghost horizontal lines" in the output avi during panning camera movements, so I tried GreedyHMA (which gives me good results on my DV material).

Oh, by the way, I discovered (after trying 11 different de-interlacing methods...:) ) that the movie wasn't interlaced at all. And it wasn't a field swap or field shift problem either.

I think it's a sort of player trouble, I've started A new thread in the player's forum (http://rilanparty.com/vbb/showthread.php?s=&threadid=15993) about it. If you have suggestions also on that, you're really welcome.

thanks
Corrado

[Corrado]

Originally posted by Acaila
the SimpleResize filter needs multiples of 4, I just figured that GreedyHMA (since it has the same creator) needs the same. If 8 works, great.

Just for info: GreedyHMA works only with width multiple of 16. It's also written in the last note of the readme file that comes with it. ;)

Cor