My understanding of the Pi’s deinterlacing behaviour under Kodi 19 was that it would not support “hardware deinterlacing”. My interpretation of this was:
-
It will not be able to deinterlace anything that is decoded using hardware acceleration. Therefore it will not be able to handle 1080i material at all.
-
It should be able to sensibly deinterlace when it is decoding in software. Since hardware decoding of mpeg2 is disabled, playback of standard definition mpeg2 should happen in software, and it should deinterlace correctly.
It looks like neither of these interpretations is correct. What’s actually happening may conceivably be expected behaviour, but if so, you need to find a different way of describing it!
Here’s a link to some of my deinterlacing test clips: Dropbox - Deinterlacing test patterns - Simplify your life
(N.B. Some of these won’t play on the Pi, as they’re VC-1).
Try playing the Sherlock extract - this is 1080i/50, originally captured as progressive. The deinterlacing here works fine - in fact, it’s better quality than you get on the Vero 4K. (Watch the pattern on Mycroft’s grey suit, especially between 00:30 and 00:47 - on the Vero 4K you get a shimmering effect because it’s deinterlacing in video-mode instead of film-mode. On the Pi it’s sharp.)
Now try playing the clip from “Time Flight”. This is 576i mpeg2, captured as interlaced fields, so it requires video-mode deinterlacing. Being mpeg2 it should be being decoded in software, but the deinterlacing is just horrible - watch, for example, between about 00:10 and 00:25, keeping an eye on the Doctor’s face, hair, and the red lines on his coat. (Compare the quality you get on the Vero 4K with hardware decoding turned off - that handles it fairly well).
Explicitly turning off hardware decoding makes no difference to the Time Flight clip.
Some logs, in case you think my Pi is doing something non-standard (playing Sherlock first, then Time Flight): https://paste.osmc.tv/ruhilurovu
This calls to mind the discussion that took place late last year on whether or not it would be possible to implement an option for deinterlace bypass for h264 and mpeg2 on the Vero, following the work done to enable this for VC-1. Since the Pi 3 prior to K19 had this option for all codecs, I guess K19 is delivering perfect weave/bypass by default for progressive 50i as it doesn’t yet have any deinterlace capability at all? That would make sense of the cleaner default output for progressive 50i on a K19 Pi 3 than we get from the Vero, but of course a Vero on K19 can deinterlace natively interlaced material such as classic Dr Who.
I would love to know if there is another Kodi device out there apart from the Pi 3 (on a suitable version of Kodi) that supports optional deinterlace bypass for progressive sources that are encoded in an interlaced stream. The Vero has this only for VC-1, and as far as I can tell, the Shield does not have it at all. Outside Kodi I’ve looked at Infuse on the Apple TV, as far as I can tell that does weave deinterlace perfectly for progressive 50i, but is completely unwatchable for native interlaced sources.
EDIT: This post is a little off-topic. I’ll leave it up, but anyone reviewing the whole thread from beginning to end should probably skip this, and also the next one.
The Vero deinterlaces quite nicely with software decoding - it correctly handles both film- and video-mode stuff. But of course you can’t decode 1080i in software. The Pi 4 might well be powerful enough to decode 1080i h.264 in software, but not VC-1. (ffmpeg decodes VC-1 single-threaded, which is a real pain). I don’t know if a well-designed S922X box with CoreELEC could do it? Possibly not - my Amazon Fire TV Cube can’t handle VC-1. (But then again, Amazon’s weird take on Android…).
EDIT: This post is also a little off-topic. Again, anyone reviewing the whole thread from beginning to end should probably skip this.
I live in hope that they will one day revisit this. (Not in the middle of this massive new release, obviously!) I did take a quick glance at some of the kernel code the other day. My C is very rusty, and I don’t really understand the low-level entities being manipulated, but as far as I could tell it basically tries doing a weave, and then looks for evidence of combing (looking at luminance and chroma separately); if it finds what it thinks is significant combing, it drops back to video mode. (I was a bit surprised by this, as I would have thought looking for a repeating 3:2:3:2 cadence would be much more reliable for 60Hz sources; but maybe that’s too computationally intensive. And you pretty much have to do this for 50Hz stuff anyway.)
The Sherlock clip that I linked to above is a good example - the pattern of the check on Mycroft’s suit looks enough like a combing pattern that it gets mistaken for one.
Based on a cursory glance, it didn’t look like it would be that hard to add a line saying “if some_parameter <> 0 then don’t bother doing any of these combing checks, just return whatever value the parameter specifies”. But maybe it’s a lot more complex than that in practice.
That said, software decoding certainly does a much better job of deinterlacing on the Vero than hardware does, so if you could figure out how software decoding distinguishes between film and video (and bypass the combing check accordingly) you’d get much better results.
The actual picture quality of deinterlaced video-mode stuff is also much better in software - in hardware there’s no diagonal filtering, so you get major jaggies and crawlies on diagonal lines. Fixing that might be more complicated. (The TimeFlight clip shows it quite well).
Okay, so we got a little off topic there. 
To get back to the original subject, there were two points…
The not very important one is that you may be slightly underselling the Pi’s ability to handle 1080i material in Kodi 19: so long as the codec is h.264, and the source is 1080i/50, originally captured as progressive frames (e.g. on film), it seems to do just fine.
The much more important one is that when playing a 576i DVD remux (of material originally captured as interlaced fields, e.g. with a TV camera in a studio) the deinterlacing looks horrible, despite the fact that it should be decoding mpeg2 in software.
Just going to bump this one, as it’s been a while…