Problems detecting and handling deinterlacing and pulldown

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.

Left: Vero V, Right: CoreELEC

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.

Left: Vero V, Right: CoreELEC

Will these two points be improved in the future?

Did you own a Vero 4k and is this new to Vero V?

Graham, how many years have I been grumbling about poor cadence detection and the lack of diagonal filtering on the Vero 4K? :laughing:

@Scottosan : where did you get the clip from? I might add it to my test clip collection.

I know. Just trying to see if this is different from the 4.9 kernel issue. Have you got your V yet?

I’m still waiting for a little more feedback before I make my mind up.

It would be good to know what SoC you tested on, and if you’ve tested on a Vero 4K before.

I am sure we can improve things for you, but need a bit more information.

Testing was done with the Vero V.
This is my first purchase of a Vero.

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.

Which SoC did you compare it to?

We tested the following devices:

BOXY with Dune HD Media Center with Amlogic S905X4-J

CoreELEC is a Chinese Android box with Amlogic S905Y2, called X96S

Okay, that’s useful to know. We should definitely be able to improve things. Did you test those devices on the 4.9 or 5.4 kernel?

We can dump the sysfs values of the deinterlacer to compare it to CE values as there may be some low hanging fruit there to improve things.

Kodi on BOXY is running kernel 5.4 and CE is running kernel 4.9. There was no significant difference between the two in our tests.

I’m not familiar with Linux, so I’m not sure. Tell me how to do it, and I’ll try if I can.

@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.



This is being discussed in our development chat.

Any progress?

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.

We will check it further. Thanks for elaborating.

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!).