4:2:2 deinterlacing - chroma judder

[skunge2000]

In 3.9.4 on tvOS MrMC now supports 4:2:2 h.264 interlaced playback - which is great. Thanks so much for this! (Combined with W3FDIF this is a brilliant development in MrMC)

However I noticed that this appears to have chroma artefacts very similar to those you get with ffmpeg's default 4:2:2->4:2:0 conversion. These chroma artefacts mean that, when deinterlaced to field-rate (i.e. a 2x deinterlace / full rate deinterlace), very saturated picture content (you see this particularly on saturated reds and blues on interlaced entertainment shows) appears to judder at frame rate, whereas less saturated content is fluid with field rate motion. (Performers wearing bright red clothing, fast moving saturated blue light beams judder, but performers wearing white, grey or black clothing, and white light beams are fluid)

I first spotted these artefacts when offline ffmpeg converting 4:2:2 1080i25 h.264 to 4:2:0 1080i25 h.264 to allow for playback on 4:2:0-only devices. Without an interlaced aware scale filter you get judder on highly saturated chroma (Even though there isn't a resolution scale with 1080i->1080i conversion, I guess there is a chroma vertical subsample that needs to be interlaced aware)

To get ffmpeg to convert correctly you need a -filter:v scale=interl=1 or similar filter in the video pipeline - which will then correctly subsample the chroma in an interlaced aware fashion.

Is MrMC doing 4:2:2->4:2:0 chroma subsample in the interlaced domain, and then deinterlacing the 4:2:0 result? ISTR that if you deinterlace 4:2:2 1080i to 4:2:0 1080p directly you don't get the same artefacts (I guess because you are going to progressive subsampled chroma, rather than interlaced).

[davilla]

GLES render only knows about RENDER_FMT_YUV420P and as such asks for AV_PIX_FMT_YUV420P when ffmpeg decodes the frame.

how would "-filter:v scale=interl=1" be used with "w3fdif=complex" ?

[skunge2000]

Is there a single ffmpeg chain doing the 4:2:2 1080i25 decode and deinterlace? If so then the interlace scale shouldn't be needed - as 1080i25 4:2:2 -> 1080p50 4:2:0 shouldn't kick in the chroma issue as you are generating progressive vertically-subsampled chroma, and not interlaced.

I THINK it's only if two ffmpeg processes are used consecutively - 1080i25 4:2:2 -> 1080i4:2:0 (with a non-interlaced aware scale) followed by 1080i25 4:2:0->1080p50 4:2:0 (with a deinterlace) that I'd expect to see the issue, at least on x86 boxes at the command line level.

When playing 4:2:2 1080i25 h.264 - what command line-equivalent options/flags etc. is mrmc currently using with ffmpeg?

If I get a chance I'll convert offline from 1080i25 4:2:2 to 1080i25 4:2:0 in an interlaced aware manner, the same conversion without the interlace aware scaling, and also convert 1080i25 4:2:2 to 1080p50 4:2:0 as a single ffmpeg process and see how mrmc plays them both.

I'll also do a -filter:v "scale=interl=1,w3fdif=complex:all" vs a -filter:v "w3fdif=complex:all" for the 4:2:2 1080i25 to 4:2:0 1080p50 conversion offline to see if that makes any difference.