[MPlayer-users] Objectionable yadif haloing with certain top crop parameters
adf.lists at gmail.com
Sat May 9 12:53:46 CEST 2015
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.
same link -
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 =.
More information about the MPlayer-users