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

[mplayer-list at media.mit.edu]

    > Date: Fri, 08 May 2015 13:31:48 +0100
    > From: Andy Furniss <adf.lists at gmail.com>

    > Andy Furniss wrote:

    > > 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.

    > Of course if you are wanting to do existing recordings and you confirm
    > they are 420 already then you would need to convert in an interlace
    > aware way to 422 before cropping then convert back.

...or just crop an extra pair of scanlines off so I have a multiple
of 4.  I'm trying to understand why 4 and not 2 (see my previous
message), and thus whether this can conceivably be a software bug
or is instead just a bug in my understanding, and whether this is
something that should be explicitly mentioned somewhere so others
avoid the same pitfall.

    > If you are planning on getting this to work on a CRT it will be tricky
    > with a PC and I would consider making into interlaced ntsc dvds and
    > using a player! This wouldn't work so well with the cropping as you need
    > 480 height - though I don't know what height you are starting and ending
    > with? Maybe you could crop to remove junk then pad out again to 480
    > (though a dvd player + CRT TV would likely overscan off the junk anyway).

Yeah, I've been considering that issue.  (I'm starting with 720x480.)
It may well be that attempting to maintain interlacing all the way to
the display is too difficult (I suspect the answer there is "never crop",
but that leads to large transcodes and -someday- I'll probably decide
to go to a progressive display).  To maintain proper interlacing on a
CRT after I've cropped the input, I presumably need to tell mplayer to
pad it back out---I haven't (yet) figured out mplayer args might do
that.  But there's also the issue of convincing X to be interlaced, etc.

    > You need to be careful with encoding/manipulating interlaced - and I
    > don't know what handbrake does.

It seems to DTRT with deinterlacing/decombing even if I use a non-mod-4
top crop.  But if I don't deint and instead push that to mplayer during
display, then yadif shows chroma artifacts.  I just now found discussion
which seems related from 11.5 years ago:
http://lists.mplayerhq.hu/pipermail/mplayer-users/2003-October/039051.html

    > Errors may not be instantly noticeable = always keep your masters if
    > possible.

I'd love to, but I won't be able to do so forever.  So I'm trying to
proceed in the most future-proof way possible---that's in part why
I'm talking about (as long as I have to retranscode anyway) using
MBAFF (what Handbrake does with --encopts:tff) so the output is not
(yet) deinterlaced but still reads as interlaced to downstream
processing, whether that processing is mplayer, VDPAU, or something
else.  (My earlier transcodes omitted that because I had assumed that
Handbrake would produce an interlaced output for an interlaced input
if I didn't specify any deinterlacing, but it produced progressive
instead.  I can see why that's useful for the majority of users,
but whoops, not what I was expecting.)