Thanks for your patience.
We have removed some bugs from the deinterlacing code and spent some time optimising the video chain to minimise stutters and judders. For VC-1, the smoothest playback is in our tests obtained by setting ‘Deinterlace’ in the OSD menu (ie the default). We have not (yet) been able to improve automatic detection of frame- vs field-interlace. but few titles seem to benefit from being treated as frame-interlaced. Some feedback on that would be welcome.
Okay, you literally asked for it. 
When you say you’ve removed some bugs, are you talking about something you’ve done in the past couple of months, or are you talking about work that was done previously? If there have been any recent changes to this, I’d love to try testing them. If there haven’t been, then IMO the results can be distinctly sub-optimal - I’m happy to rant at length about how!
It’s about work we did the last couple of weeks.
I’d appreciate it if you could test this and provide feedback before we potentially release this as an update to other users. To test this update:
echo 'deb http://apt.osmc.tv bullseye-devel main' | sudo tee /etc/apt/sources.list.d/osmc-devel.listsudo apt-get update && sudo apt-get dist-upgrade && rebootPlease see if the issue is resolved.
I also recommend you remove /etc/apt/sources.list.d/osmc-devel.list after updating.
This will deactivate the staging repository. You can do so with the following command:
sudo rm /etc/apt/sources.list.d/osmc-devel.list.
Please note that we will automatically disable this update channel after 14 days on your device in case you forget to do so to ensure that your system reverts to the stable update channel.
Okay, @sam_nazarko and @tanio99 , I will take a look! Is there any specific thing I should be checking, or just “deinterlacing in general”? And have you made any changes that would affect non-VC1 videos?
via ssh I’m being prompted whether to install package maintainer’s version of a configuration file in /etc/sshsshd_config or keep local modified version. This has nothing to do with any mod on my part, never heard of this config before. Which one should I pick?
We normally avoid those things. I would go for keep the local version.
Just play some videos and let us know what you find. We don’t need to tell you where to sniff out issues! @Scottosan’s clips have been a bit of a challenge and I’m still puzzled why his versions of the divergent lines patterns can behave differently from yours - apparently from the same original source.
You should find the MPEG2s play better. We haven’t been able to completely cure Mycroft’s jacket, though.
I usually keep the local version, any changes that i’ve made were made for a reason but you are saying that you’ve not made any changes so this would be interesting to see what the differences are, i’d be worrying that something devious has gone on.
Guessing wildly, but it could possibly be because mine is in MKV format while his is in m2ts…? They may have been ripped with different tools as well.
I’ll need to have another look when my eyes are less tired, but the “Deinterlace” option does now seem to be producing pretty good output on nearly all of my VC-1 clips. It gives poor results on the 1080i60 wedge pattern, but I think I can live with that: in practice, something that is filmed as 1080p/24 is probably going to be stored on a disc as 1080p/24, not as 1080i/60; and stuff that was captured at 1080p/30 is going to be quite rare; so pretty much all 1080i/60 VC-1 stuff is going to be field-interlaced anyway. If you were extending the logic to h.264 then you’d have to worry about American TV broadcasts, but those will never be VC-1. And defaulting to Deinterlace for 60Hz stuff means that those BBC titles that have been subjected to 50->60Hz conversion (e.g. Cranford season 1, Bleak House or the Doctor Who specials) will look better.
I did find one other very slight glitch with Deinterlace, although you have to squint a bit to see it. If you look at my clip from Cranford s02e02, and keep a careful eye on Jonathan Pryce’s eyebrows when the camera cuts from Judi Dench to him, around about 00:26 and particularly around 00:35, there’s a little bit of shimmer there with the “Deinterlace” option. You can get rid of it if you turn deinterlacing off and switch the output mode to 1080p/25Hz. But based on my testing so far, I think the Deinterlace option can reasonably be the default for all VC-1 videos now, and purists like me and @ac16161 can still switch if we want!
(Although, if you could fix the issue of 25fps video stuttering when output at 50Hz, then I think the “Auto-select” option would be a better default).
This, incidentally, is the kind of image that tends to trip up deinterlacers - and it’s the same issue on Mycroft’s suit. If you have some rapid variation in either colour or luminance between several adjacent rows of pixels (like the check pattern on the suit) the deinterlacer can mistake that for combing.
Will check some MPEG2 stuff tomorrow.
Thanks for the feedback.
great to see ongoing work in this area. For native interlaced 50i such as the Timeflight clip posted by @angry.sardine the new build might be better than before but does not compare well vs a V4K on Nov 2020 OSMC (I think the last build on the old kernel). Here’s a couple of pictures to illustrate that (framing not identical but the jaggies present on the Vero V with the current test build are clearly absent on the old version of OSMC:
Vero V test build:
Vero 4K Nov 2020 OSMC:
I have looked at “progressive 50i” in h264 and VC-1. I think for general use they are good but not perfect (e.g. moire artefacts). Neither is resolving perfectly clean 25p frames (i.e. they fail the 25p whitelist test), but if deinterlacing is disabled for VC-1 there is perfect 25p playback and no moire at all. I imagine it may be next to impossible to get perfect performance on auto for all content, if we could just get the option to disable deinterlacing for h264 and match the old kernel for diagonal filtering then the Vero 4/V could then match my old Pi’s which are still my reference within the Kodi domain as they can render perfect 25p with deinterlacing disabled for h264 as well as VC-1 (and don’t have the jaggy problem on fully interlaced MPEG2).
Thank you. That’s confirmed what I’m seeing, although I’m going to look more closely at Timeflight again. I noticed an issue only near the end of that clip where the edge of the console is very close to horizontal.
@ac16161 @angry.sardine I don’t think your update has gone right. I’m checking with Sam.
Oh, okay! 
Well, keep us posted, I’ll take another look.
In terms of what it’s doing now, I concur with @ac16161 .
I’d guess the “Deinterlace” option for VC-1 is now doing the same as the standard (i.e. only) option for interlaced h.264; which means it will make for a good default, but it’s definitely worth keeping the other options for fussy people like us. As I said before, if you ever fix the thing that makes 25fps video stutter when output at 50Hz, at that point it would probably make sense to default to “Auto-select” for 1080i/50 VC-1 (but probably not for 60Hz stuff, that should still default to Deinterlace even then).
Again, in terms of what it’s doing now for DVD remuxes: the diagonal filtering is certainly not working as well as it did under the 3.14 kernel. You can see roughly what it should look like by switching to software decoding.
The two most important sections in that clip are probably 0:11-0:15 and 0:34-0:38 - as AC says, keep an eye on the control console and look for jaggies along the edges of shiny metal strips.
(Diagonal filtering not working does also affect h.264 btw, although it’s as visible because of the extra resolution).
Another thing that used to work better under 3.14 is that the 480i version of the wedge test pattern used to be deinterlaced correctly in hardware - it isn’t now.
Try updating from staging again. Kodi for V is probably there already, Kodi for vero 4k will follow shortly.
Please try updating again as you may have not received all the changes that we made.
I ran the update again. On the Timeflight clip I do think the overall playback now is better than the current production version of OSMC, but it’s still not quite there compared to the 3.14 kernel on a V4. Where it’s falling down slightly is on camera moves, e.g. at 34s into the clip the camera moves, and during that movement some minor jaggies appear on the console. These are not present on the 3.14 kernel, it’s coping better with diagonal edges under movement.
I did. I can’t honestly say I noticed a great deal of difference from this morning - certainly still getting jaggies in Time Flight. Though I’m not seeing the flicker in the pixels at the top left that I used to.
One other possible problem: my TV isn’t automatically switching to 4:3 aspect ratio. That could be an issue with the TV rather than with the Vero - sadly my lovely Lumagen video processor died a while back, so I’ve now got the Vero 4K+ connected directly to the TV, which it used not to be; so it’s quite possible that the TV just isn’t switching when it should, and it has always been like that; but it might be worth checking.
Hmmm. I don’t have a 3.14 kernel handy, but to my eyes Timeflight looks the same under SW or HW decoding. I doubt there’s much more we can do there.
Please check the update again. What’s the compile date of Kodi at the start of the log?
TBH I haven’t tried this on vero 4k yet.
My Panasonic is switching to 4:3 as it always does (except when running CoreElec :P)
