[MPlayer-users] Objectionable yadif haloing with certain top crop parameters

[mplayer-list at media.mit.edu]

    > Date: Fri, 08 May 2015 11:24:50 +0100
    > From: Andy Furniss <adf.lists at gmail.com>

    > mplayer-list at media.mit.edu wrote:
    > > tl;dr:  "mplayer -vf yadif" produces terrible results when an even
    > > but non-multiple-of-4 number of scanlines are cropped off the top.

    > If you are capping 420 weaved interlaced then you should only crop in
    > chunks of four (and 2 off top and bottom won't work). That's just the
    > the way 420 interlaced is as you have found.

Okay, I've just pondered Wikipedia's Chroma_subsampling page.

mediainfo tells me that the input is indeed YUV 4:2:0, but isn't the 4
a -width- and the 2 a -height-?  Why does removing 2 pixels from the top
make this not work?  (Is the issue that we're really talking frames
and not fields, so cropping 2 pixels is removing one frame scanline,
which is equivalent to saying that the "frame" is starting on an odd
instead of an even line and that's confusing yadif?)

Obviously there are things about this situation I don't understand:
o  Why this mess gets passed right through Handbrake if I'm asking
   it to crop; I'd imagine it should either emit garbage or emit
   something valid, since it's managed to totally reencode it to
   H264 and the result -still- is confusing yadif.
o  Why Handbrake's decomber works in this situation.  Maybe either it's
   not using yadif internally or it's doing something else to compensate.
o  Why I don't see confused chroma -everywhere- if this is the case,
   instead of only where yadif is decombing.  (That would have made
   the problem spectacularly obvious very early.)

Part of where I'm going here is, if this is not a code bug, what is
the right explanation to put -into the mplayer manpage- to explain
why this is a bad idea?  I've read that manpage fairly carefully at
various points and see no warning not to do this if you expect yadif
to work, and a warning like that would have been an enormous
timesaver.  Is this a doc bug?  (A simple caution about checking
yadif results when cropping from the top in the face of various
types of chroma subsampling, in particular the common 4:2:0, would
have at least perhaps caused me to test that particular situation
carefully and/or do more research.)

    > As you are capping NTSC I guess it would be possible to tell card/v4l to
    > cap as 422 and then crop - still 4 but I expect 2 off bottom and top
    > would then be possible.

Well, the captures have already been made, and I don't know a priori
how much I want to remove without image analysis, so changing how
capturing works isn't the way forward here.

    > You would then need to convert to 420 using say ffmpeg and you must tell
    > it that it's interlaced or it will still be messed up in a different way.

    > untested but something like -

    > -vf scale=interl=1,format=pix_fmts=yuv420p

I get "Option vf: scale doesn't have an interl parameter" with that
command line, but I'll poke around and see if I can figure out
something along those lines.

    > I don't know handbrake so can't say how to do with that.

OK.  Thanks!