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

[mplayer-list at media.mit.edu]

    > Date: Sat, 09 May 2015 11:53:46 +0100
    > From: Andy Furniss <adf.lists at gmail.com>

    > There is more than one 4:2:0, what we are dealing with is interlaced
    > 4:2:0 which is different from progressive.

!!

    > Look at Figure 4 about 25% down the page.

    > http://www.hometheaterhifi.com/technical-articles-and-editorials/technical-articles-and-editorials/the-chroma-upsampling-error-and-the-420-interlaced-chroma-problem.html

Aha!  Thank you, sensei.  I am enlightened!

    > same link -

    > http://tinyurl.com/q4w6tlo

    > You can see that cropping 2 (2 luma 1 chroma) will result in chroma
    > confusion for a deinterlacer.

Yes.  I've read through the rest of that article, and now I see what's
going on.

    > FWIE If you happen to read the rest of the article, what computers do by
    > default is the opposite of what they describe = display weaved frames as
    > if they were progressive.

In other words, you're saying that DVD players often incorrectly think
that progressive content is interlaced, whereas computers often incorrectly
think interleaved content is progressive.  Yeah, I can see how that might be.

    > 			      On the right samples you can see this as the
    > tearing on chroma will cover 2 lines vs one for luma. It doesn't matter
    > if you deinterlace of course as the deinterlacer should do the right thing.

    > If you want to get a TV to deinterlace it does matter. As I will say in
    > reply to other post.

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

    > Hard to predict what will happen if it depends on content and
    > deinterlacer behavior - but now you know the source issue, all should
    > work, if they don't more investigation is needed.

OK.

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

    > Well mplayer is a player and mencoder is depreciated by ffmpeg, maybe
    > there could be somewhere to put that cropping interlaced needs to be 4 line.

A mention -anywhere- in the (mplayer) manpage would probably be good,
so people cropping upstream of it won't be surprised when yadif halos.
I would imagine that cropping interlaced 4:2:0 isn't -that- much of an
edge case. :)  A mention in the Handbrake documentation would also be
good, but that's a matter for a different set of people.  I'll try to
figure out who to suggest it to.

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

    > Hmm, works for me with current ffmpeg.

Oh, I was supplying that to mplayer, not ffmpeg.  I'll try on modern
mplayer, but more likely the issue was it should be ffmpeg or avconv.

    > My font does make the letter l at the end of interl look the same as the
    > number 1 after the =.

I think I got it right ("interl" as in "interlaced", "1" as in "enable".)
But supplying it to mplayer and not ffmpeg was likely incorrect. :)