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

[m***@media.mit.edu]

tl;dr: "mplayer -vf yadif" produces terrible results when an even but
non-multiple-of-4 number of scanlines are cropped off the top. It is
only the -top crop-, not whether the total number of scanlines is a
multiple of 4. It happens regardless of whether the input is mpeg2
(with mplayer doing the cropping) or H264 (with Handbrake doing the
cropping as part of the transcoding process and no cropping arg
supplied to mplayer). VLC displays the same behavior. I can't
seem to find a prior report of this behavior anywhere.

Details:

I'm starting with NTSC SD interlaced recordings from Hauppage PVR-250
capture cards. If I crop 0 or 4 lines off the top using "-vf crop="
(e.g., to avoid line-21 closed-captioning data) and use yadif, it
looks fine. If I crop 2 or 6 lines off the top, it looks terrible.

If I transcode using Handbrake to H264 in an MKV container, either
with the output as a progressive file (but no deinterlacing filters
applied), or as an MBAFF (--encopts:tff, because mediainfo reports
that output from these cards is always top field first), then the
output also looks bad using "mplayer -vf yadif" if I have cropped 2 or
6 lines from the top, but it's okay if I've cropped 0 or 4 lines from
the top. (If I'm cropping 2 or 6 lines, and also telling Handbrake to
produce interlaced output via MBAFF, I must also tell Handbrake to
crop 2 lines off the bottom so the frame size is a multiple of 4.)
Note that if I'm cropping with Handbrake, I am -not- supplying any
crop argument to mplayer.

In the "bad" case, fast motions, such as a white performer waving
their hands around gesturing or clapping, has very objectionable,
large colored halos and preimages---red or blue blurry copies of
the hands displaced from the hands by substantial amounts (like the
size of the entire hand), either leading or lagging the motion.
For example, hands coming together in a clap have red halos leading
the motion, while the hands themselves have turned into blue blobs,
until the moment of contact, whereupon they become pink hands again.
This is really obvious when single-stepping through the frames.

The "good" case has no color haloing and the hands, while somewhat
blurry from motion, look much more like hands than blobs. And, of
course, without "-vf yadif", I see sharp but combed hands with no
haloing.

I've observed this effect in mplayer from version 1.0rc4-4.4.5
(Ubuntu 10.10) all the way through 1.1-4.8 (Ubuntu 14.04), using
both Handbrake 0.9.9 and 0.10.0. I get identical results using
VLC media player 2.1.6 Rincewind (revision 2.1.6-0-gea01d28),
also under Ubuntu 14.04, which isn't entirely surprising because
I believe that VLC uses mplayer's yadif. [VLC doesn't seem able
to play PVR-250 files, so I can't play one of those and ask VLC
to crop it, but using VLC's yadif to play a cropped Handbrake file
shows the same dependence as mplayer on how many scanlines Handbrake
cropped off the top.]

It's interesting that this happens even if Handbrake was the entity
that cropped the video, and even if mplayer's input is H264. It seems
entirely related to the top crop value, but I'm not sure how that
value makes it all the way through Handbrake's transcoding process
in a way that then screws up yadif later.

I can supply exact command lines and input/output samples if that
would help diagnosis, and/or open a real ticket, if my description
above isn't enough and/or this is an unknown bug. (I've never
submitted a bug report about mplayer before, and get the distinct
impression from the documentation that doing so can be a major
effort, but don't want to do so unless we know where the blame
lies.)

Thanks!

P.S. I am neither deinterlacing not decombing during the transcode
from interlaced mpeg2 to either progressive or interlaced H264,
because I'm trying to preserve my options to apply better deinterlacers
in the future (either better software, or VDPAU), hence I don't want
to lose information by deinterlacing during transcoding. (I also want
to preserve my ability to use an interlaced output device (a CRT) if I
can get an entirely interlaced path and hence do no deinterlacing at
all on output if that path is active.) A single-step transcode with
deinterlacing or decombing does -not- show these effects, even though
I believe Handbrake uses yadif internally while decombing. (I am not
positive about that, though.) At the moment, 38% of my transcoded
corpus has a top crop of 2 mod 4 instead of 0 mod 4; fortunately, I
had not yet thrown away the originals when I noticed the bug, but I'm
not too happy about having to retranscode a large pile of stuff to
work around the bug.

(I don't have VDPAU-capable hardware configured yet, so I can't tell
if it might also have issues with such top crops, nor am I 100%
confident that VDPAU works well with MBAFF files; if anyone can run
either test, I'd appreciate it.)

[Andy Furniss]

Post by m***@media.mit.edu
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.

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.

You would then need to convert to 420 using say ffmpeg and you must tell
it that it's interlaced or it will still be messed up in a different way.

untested but something like -

-vf scale=interl=1,format=pix_fmts=yuv420p

I don't know handbrake so can't say how to do with that.

[Andy Furniss]

Post by Andy Furniss
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.

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

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

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

[m***@media.mit.edu]

Date: Fri, 08 May 2015 13:31:48 +0100

Post by Andy Furniss
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.)

[Andy Furniss]

Post by m***@media.mit.edu

Post by Andy Furniss
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.

OK, 4 vs 2 in other post.

Cropping 4 from top would be safer than doing my 422 way.

The reason it's safer is that going via 422 would involve being careful
about making sure the conversions were interlaced aware and with ffmpeg
at least there are potential issues.

For the curious I am thinking of -target ntsc-dvd <some extra interlaced
mpeg 2 options> when dealing with 422 (historically at least) if you
tried to specify interlaced aware conversion it would get overidden to
progressive by the scaler that -target introduces.

Post by m***@media.mit.edu

Post by Andy Furniss
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.

With a modern TV via HDMI it is possible to get it working, but what you
have to do/workaround is going to be specific to your computer hardware
and of course you need a TV like mine that automagically deinterlaces
everything you throw at it when in an interlaced mode.

You do have to convert to 422 interlace aware - as per your link below
mplayer has ilpack for this. MPlayer also has a filter called tinterlace
which you also need to use - but it got extended in ffmpeg and it's the
x2 extension that is needed. In theory I think mplayer should be able to
call ffmpeg filters, but I don't think it works. So to get a TV to
deinterlace you need to use the mplayer derivative mpv.

The fact you need 422 for this may be an issue as in OSS GPU driver
world even if it's available it may not work xorrectly so you get 420.
This is h/w specific workarounds may be possible, but it's safest to use
opengl for output (colour apace conversion/scale) rather than xv, vdpau
or vaapi (just display, decode should be software). Scale by player (if
needed) can only be horizontal of course.

Recent kernels with intel and radeon at least will allow CEA interlaced
modes to be selected by xrandr. Whether they work again depends on h/w
my testing intel = yes, radeon only HD (as CEA SD modes are double
clocked and AMD haven't done it yet) There are nits even with HD for me
- but it's useable.

With mpv just as an example with opengl you would do something like

--vf=lavfi=[scale=interl=1,format=pix_fmts=yuv422p,tinterlace=interlacex2]

If you were not using opengl for vo then you may need to adjust
to something other than yuv422p eg. vdpau on radeon offers yuyv422
(but it doesn't work unless you hack mesa).

The tinterlace=interlacex2 filter is what makes it work.

On OSS Linux drivers/players there is no concept of field sync
in the sense that the player could know which field a vsync was on.
vsync is at field rate though so the filter just updates half of
the full frame weave output each field and leaves the other alone.
Whichever one the gpu is scanning out doesn't matter - they will be
in order. I guess it's a bit hacky as the sound may or may not be a
field out - but that's a small amount.

Post by m***@media.mit.edu

Post by Andy Furniss
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.

I expect handbrake deints first, then the now progressive output is cropped.

Post by m***@media.mit.edu
But if I don't deint and instead push that to
mplayer during display, then yadif shows chroma artifacts. I just
http://lists.mplayerhq.hu/pipermail/mplayer-users/2003-October/039051.html

ilpack does what the above scale=interl=1,format=pix_fmts=yuv422p
does (well it actually does yuyv422) which is packed 422 vs planar.

Post by m***@media.mit.edu

Post by Andy Furniss
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.)

Yea everything tends to assume progressive.

Since you are using ntsc there could be more issues - is the content
really interlaced ot is it progressive and just flagged as interlaced
or is it progressive and telecinied - I live in pal land so don't know
anything about the latter.

I think retaining interlacing is a good idea, it more flexible than doing
it at encode time where you need to choose things like framerate vs
fieldrate
the former being destructive.

You do as you found need to know about the issues/pitfalls. It seems
handbrake did try to save you (mod 4) but you beat it by cropping 2 + 2.

telecine and progressive content are something else you need to examine
you input for.

[m***@media.mit.edu]

Date: Sat, 09 May 2015 15:51:24 +0100
OK, 4 vs 2 in other post.
Cropping 4 from top would be safer than doing my 422 way.

Yeah, the only reason I was cropping 2 was because "why waste a
scanline?" when removing VBI, etc. Also, interestingly, Handbrake's
autocrop algorithm seems -perfectly- happy to crop non-mod-4 values
from the top on YUV 4:2:0 interlaced input. Come to think of it, that
seems like a genuine bug.

I'm very surprised that it didn't at least complain in its log when I
cropped YUV 4:2:0 the wrong way. I wasn't using --loose-crop (always
crop up to (default) 15 pixels to get to the modulus), because I knew
I didn't want to lose up to 15 whole scanlines on each edge, and the
efficiency gain of exactly matching the 16x16 macroblocks is trivial.
That might be something to suggest to the Handbrake people---look for
weirdo chroma-bashing crops and complain in the log, and perhaps even
have a --pedantic or --picky or somesuch option that tries to find
ways you may be shooting yourself in the foot. Not perfect, but at
least a start.

With a modern TV via HDMI it is possible to get it working, but what you
have to do/workaround is going to be specific to your computer hardware
and of course you need a TV like mine that automagically deinterlaces
everything you throw at it when in an interlaced mode.

Yes. I could probably do it, and may spend the effort to do it
(knowing it will be thrown away when I eventually replace the large
CRT with something else), but I don't wnat to -depend- on it working. :)

You do have to convert to 422 interlace aware - as per your link below
mplayer has ilpack for this. MPlayer also has a filter called tinterlace
which you also need to use - but it got extended in ffmpeg and it's the
x2 extension that is needed. In theory I think mplayer should be able to
call ffmpeg filters, but I don't think it works. So to get a TV to
deinterlace you need to use the mplayer derivative mpv.

Oh, that's good to know.

The fact you need 422 for this may be an issue as in OSS GPU driver
world even if it's available it may not work xorrectly so you get 420.
This is h/w specific workarounds may be possible, but it's safest to use
opengl for output (colour apace conversion/scale) rather than xv, vdpau
or vaapi (just display, decode should be software). Scale by player (if
needed) can only be horizontal of course.

Hmm, yeah. I'd heard really good things about the VDPAU Advanced 2x
deinterlacer, so I'm trying to at least enable use of that, but I'll
probably wind up feeding it MBAFF interlaced H264 and having it just
deinterlace to progressive, whereupon the output card apparently is
just taking that progresssive scan, reinterlacing, and sending via
S-Video. If I can do interlaced out and pad back up to 480, yes,
that'll be slightly less blurry on my CRT, but I know that's going
to take some fiddling.

Recent kernels with intel and radeon at least will allow CEA interlaced
modes to be selected by xrandr. Whether they work again depends on h/w
my testing intel = yes, radeon only HD (as CEA SD modes are double
clocked and AMD haven't done it yet) There are nits even with HD for me
- but it's useable.

OK.

With mpv just as an example with opengl you would do something like
--vf=lavfi=[scale=interl=1,format=pix_fmts=yuv422p,tinterlace=interlacex2]
If you were not using opengl for vo then you may need to adjust
to something other than yuv422p eg. vdpau on radeon offers yuyv422
(but it doesn't work unless you hack mesa).
The tinterlace=interlacex2 filter is what makes it work.
On OSS Linux drivers/players there is no concept of field sync
in the sense that the player could know which field a vsync was on.

Oh, oy.

vsync is at field rate though so the filter just updates half of
the full frame weave output each field and leaves the other alone.
Whichever one the gpu is scanning out doesn't matter - they will be
in order. I guess it's a bit hacky as the sound may or may not be a
field out - but that's a small amount.

Post by m***@media.mit.edu

Post by Andy Furniss
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.

I expect handbrake deints first, then the now progressive output is cropped.

Oh. That hadn't occurred to me. I'd assumed that cropping would come
first in the filter chain, because it's more efficient---why deint
lines that will be immediately thrown away?---but I haven't looked
at the code to really verify.

Post by m***@media.mit.edu
But if I don't deint and instead push that to
mplayer during display, then yadif shows chroma artifacts. I just
http://lists.mplayerhq.hu/pipermail/mplayer-users/2003-October/039051.html

ilpack does what the above scale=interl=1,format=pix_fmts=yuv422p
does (well it actually does yuyv422) which is packed 422 vs planar.

OK. I'll have to spend some quality time looking over all the options
you've been mentioning.

Yea everything tends to assume progressive.
Since you are using ntsc there could be more issues - is the content
really interlaced ot is it progressive and just flagged as interlaced
or is it progressive and telecinied - I live in pal land so don't know
anything about the latter.

All the captures I have are from a hardware encoder (PVR-250) and
mediainfo certainly claims them to be interlaced mpeg2's. And that
very same mpeg2 gets sent to a hardware decoder (PVR-350) and sent via
S-Video to my CRT, and I don't see any deinterlacing artifacts that
way, so I'm willing to believe that the claimed interlaced flagging on
those mpeg2's is correct. Probably we'd have heard about it in the
10+ years since those cards were introduced if they were somehow
producing progressive. :)

I think retaining interlacing is a good idea, it more flexible than doing
it at encode time where you need to choose things like framerate vs
fieldrate
the former being destructive.

I agree. (Since the framerate from these cards never changes, I'm
just telling Handbrake to preserve the input framerate as the output
framerate, which seems both safe and easy.)

You do as you found need to know about the issues/pitfalls. It seems
handbrake did try to save you (mod 4) but you beat it by cropping 2 + 2.

Yeah. See above re HB's lack of warning in this situation.

telecine and progressive content are something else you need to examine
you input for.

The capture cards can't produce progressive, as far as I know.

Telecine, well, I'm not going to try to IVTC or something because I'd
rather mess with the input as little as possible and especially
because I don't want to try to make that call automatically (and
I don't want to have to figure it out by hand for every one of a
large number of transcodes). If the output's a little bigger, oh
well.

Again, thanks for all the advice. Every time I touch video, I wind up
on a learning curve...

[m***@media.mit.edu]

Date: Fri, 08 May 2015 11:24:50 +0100

Post by m***@media.mit.edu
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?)

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

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

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.

Well, the captures have already been made, and I don't know a priori
how much I want to remove without image analysis, so changing how
capturing works isn't the way forward here.

You would then need to convert to 420 using say ffmpeg and you must tell
it that it's interlaced or it will still be messed up in a different way.
untested but something like -
-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.

I don't know handbrake so can't say how to do with that.

OK. Thanks!

[Andy Furniss]

Post by m***@media.mit.edu

Date: Fri, 08 May 2015 11:24:50 +0100 From: Andy Furniss

Post by m***@media.mit.edu
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.

Post by m***@media.mit.edu
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.

Post by m***@media.mit.edu
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.

Post by m***@media.mit.edu

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

[m***@media.mit.edu]

Date: Sat, 09 May 2015 11:53:46 +0100
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.

Post by m***@media.mit.edu
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.

Post by m***@media.mit.edu
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.

Post by m***@media.mit.edu

Post by Andy Furniss
-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. :)