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