[MPlayer-users] Objectionable yadif haloing with certain top crop parameters
mplayer-list at media.mit.edu
mplayer-list at media.mit.edu
Sun May 10 00:00:29 CEST 2015
> 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.
Aha! Thank you, sensei. I am enlightened!
> same link -
> 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
> 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.
> > 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. :)
More information about the MPlayer-users