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

[Andy Furniss]

mplayer-list at media.mit.edu wrote:
>> 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?)

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

same link -

http://tinyurl.com/q4w6tlo

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

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

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

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

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