Hi.
I used and checked the test pattern and found problems with Vero V deinterlacing quality and pulldown detection and handling.
I played back the image with HW decoding and took it. The Vero V has jagged lines. This indicates poor deinterlacing quality. On Android TV Kodi and CoreElec using Amlogic SOC, the lines are not very jagged.
Pull-down detection and processing images are square boxes with no lines and filled in. This indicates that the operation is failing. Kodi and CoreElec on Android TV handle it correctly, so the lines are clearly visible.
The test pattern in the image is from the HQV Benchmark 2.0.
We also ran a similar test with Spears & Munsil HD Benchmark 2nd Edition, and the results were the same.
@tanio99 will know specifics but we had to remove deinterlace from VFM under certain circumstances for performance reasons. Conversely, we can likely reintroduce deinterlacing for certain formats and certain conditions.
Can you provide us with a link to the test pattern you used and we will investigate this further
Here is the link for the test pattern. There are patterns other than the test pattern used in the image. Make use of it. The patterns used in the images are 00005.m2ts and 00006.m2ts.
Still talking – but honestly, it is low on our priorities list.
The problem is that while @angry.sardine has mentioned de-interlacing many times, he is keen to describe the technical issue often without highlighting part of the scene where the problem exists.
@Scottosan’s images are more useful and may not be interpolating correctly.
We will see what can be done and certainly provide you with an update whether we can improve things.
I posted some thoughts here: OSMC Vero V Review - #235 by ac16161, I’m happy to elaborate. When you look at @angry.sardine 's Time Flight clip on a Vero V or 4 running the current kernel, the jaggies are in-your-face obvious. The playback is terrible. It’s not as bad as Infuse on an ATV (the Vero at least gives 50Hz temporal resolution), but it is very poor. I’ve compared several MPEG2 files with a Vero 4K running the old kernel as well as a Pi 3 running current OSMC, and they are vastly superior. As a result I have abandoned plans to run a V as a primary mkv player for each of my TV’s. It’s excellent for 24p content and I’m happy with it for field-interlaced 1080i such as the classic Dr Who bluray upscales, but with regret, I wouldn’t say it’s excellent for SD material or progressive 1080i content. So for now, if anyone is looking for excellent playback across all the standard content types, then it should be understood that the current build for the V does not provide a single-box solution.
I really must take issue with that claim, in rather strong terms. I’ve posted plenty of detail in the past, including comparative screenshots.
If you would like more info now, for example about any of my test clips (a couple of which, incidentally, are exactly the same clips as some of @Scottosan 's!) and about what they illustrate, then by all means let’s have that conversation.
Of the clips I’ve posted, probably the two most important ones are the bit from Sherlock and the bit from Time Flight (a classic Doctor Who story). Here’s the download link again:
Let’s start with the Sherlock clip, which is 1080i/50 h.264, and is designed to show what happens when the material is frame-interlaced but the deinterlacer misidentifies it as field-interlaced.
Ignore the first couple of seconds; after that the clip mainly consists of Sherlock himself (in the black jacket) talking to Mycroft (in the light grey suit). If you can, try watching the clip first on a Pi 3, with deinterlacing set to Off: this is what it should look like. Note, in particular, the fine check pattern on Mycroft’s grey suit - you get a nice steady close-up of it when the two men stand next to each other from about 00:30 to about 00:47. Compare that to what you see on the Vero 4K: instead of being able to see the check pattern on the grey suit clearly you get a shimmering moiré-like pattern.
If you don’t have a Pi 3 to hand then try using Kodi’s screenshot facility during playback: for some reason the screenshot comes out looking the way it should, and very different from what you see on screen.
The Time Flight clip is 576i/50 MPEG2 and is designed to show the problems caused by the lack of diagonal filtering when playing something that is field-interlaced.
I suggest you start by playing it (on a Vero device) with software decoding and deinterlacing set to Deinterlace. This is roughly what it should look like (although there is some odd stuttering sometimes when playing in software). Now try playing it with hardware decoding. Watch, in particular, the control console between about 0:11 and 0:15, and then again between 0:34 and 0:38 - notice all the jagged edges along the sides of the white or reflective areas. Also worth looking out for is the horizontal line of darkened pixels at the top left of the screen: in software they appear simply as dark, but in hardware there’s a very obvious flicker.
(Incidentally, there’s an unrelated bug that causes horrifically jerky playback on 576i/50 stuff with hardware decoding if the whitelist is active but you don’t whitelist anything below 1080p - I already raised that here - I mention that just because I happened to bump into it again today!).
