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

[mplayer-list at media.mit.edu]

    > Date: Sat, 09 May 2015 15:51:24 +0100
    > From: Andy Furniss <adf.lists at gmail.com>

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

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

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

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