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

[Andy Furniss]

mplayer-list at media.mit.edu wrote:

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

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

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

> 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

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

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