New AVR - and some blank screen issues

You could enable digital noise reduction.
We turned it off because people didn’t like the effect that it had and wanted an image that was true to source.

I did start to look into that (I think - may have been someone else with a deinterlacing issue). Did you share some clips with us that demonstrated the effect you are describing?

I’ve never posted any clips on this but I recall the thread that you may be thinking of, as it got me thinking about deinterlacing performance of the Vero vs the Pi, and led me to discover just how much better the Pi can be with some sources.

I just checked, and screenshots can show this. This first one is from a Vero, with hardware-accelerated playback of a 1080/50i mkv (completely native rip, no handbraking etc). Check out the overhead hoses, you can see a clear interference pattern all over the rings, particularly near the central column above the console.

Now check out this one, from a Pi with MMAL playback, which has a killer feature - you get hardware accelerated playback, with option for user intervention on the deinterlacing method. For content of this nature, I can disable deinterlacing, and the interference pattern is gone. It may be hard to tell via the screenshots, but there is a definite bump in detail with the Pi.

I hope one day to find a device that combines the strengths of the Vero and the Pi, it would be great if this could be improved in a future build for the Vero.

Have you tried disabling interlacing on the Vero?
Have you tried disabling digital noise reduction?

P.S: you will want to stay on Kodi v18. From Kodi v19, MMAL is gone.

To me, the vero picture is sharper, while the Pi seems to be smoothing over the bumps. But I take your point.

with HW-accelerated playback on the Vero there is no option (via the GUI) to disable deinterlacing, that option is greyed out in the playback video settings, and SW playback is choppy with 1080/50i.

I’ve not been able to find a setting for DNR, happy to try it if I can be pointed to where it is.

Thanks for the heads-up re v19, will make sure I just use one of my test Pi’s before committing.

For deinterlacing, you can try these on the commandline:

echo 1 | sudo tee /sys/module/di/parameters/bypass_all
and/or
echo 1 | sudo tee /sys/module/di/parameters/bypass_post

DNR (only have a 4.9 system at hand where we now enable by default):

echo 0 | sudo tee /sys/module/di/parameters/dnr_en  (turns off)
echo 1 | sudo tee /sys/module/di/parameters/dnr_en (turns on)

You need to restart the stream each time.

thanks for the further suggestions. Tried all the commands before initiating playback, and no joy. As the camera pans across the control room at ~8:30 into the episode, with the Vero there is clear shimmer on the overhead hoses, whereas the Pi is rock-solid. Also in other shots, the fabric weave in Matt Smith’s jacket and shirt has lots of moire on the Vero, again absent on the Pi via MMAL+deint -Off.

If you send us a clip of that sequence or point us to the source then we could try some other stuff.

Meanwhile, try issuing the di bypass commands while the clip is playing.

I had no joy with applying the bypass commands during playback, but have sent a PM.

Graham, are you saying upsampling 420 to 422 actually involves more processing than upsampling to 444? How come?

Everything is upsampled to 444 internally. So downsampling it back to 422 is an extra step - as explained above.

I see there’s a discussion about deinterlacing. It’s something that’s been discussed before, for example: Issues with deinterlacing 1080i/50

At the time that thread was active there were definitely some issues with the hardware deinterlacing; and it still seems to be an issue now. Back then I uploaded a pair of test clips to https://collab.osmc.tv/s/XveutUz2Om7DZWh - I don’t know if they’re still available there, but I can upload them again if it’s useful. They’re 60Hz clips rather than 50, but they clearly illustrate the difference between correct and incorrect film-mode deinterlacing: they both play correctly with software decoding, but incorrectly in hardware.

If you want to test whether film-mode deinterlacing is working on 50Hz material then often a good test is to set the output to 1080p/25. Correct film-mode deinterlacing gives 25 progressive frames per second; if it’s using video-mode deinterlacing and throwing away half the resulting frames, that gives visibly jerky motion on what should be a smooth pan.

Yup, I still have those clips but I could never be sure what they are telling me - I’ll re-read that thread. For the current issue I don’t have a native 1080p display - only 1366x768 and 4K. Don’t know if that’s going to be a problem. My 4K TV disguises that crawling effect on the hanging pipes so it’s not as noticeable as on the old HDready screen. Anyway, I’ve ordered a VC-1 licence for Pi (it takes up to 72 hours, they say) and I’ll see what happens on the screens I have.

Both of those test clips can be played in software mode on a Vero 4K+. I know 1080i is usually impossible in software, but in that particular clip the bit rate is low enough that it can actually cope with it. So, just compare what both of them look like in software with what they look like in hardware. Play the 480i clip at 480p and the 1080i clip at 1080p, obviously. Watch for a serious moiré in the centre of the horizontal (right-hand) wedge in hardware mode.

The 480i clip actually also exposes a second issue on the Vero, which I’m fairly sure is something to do with it scaling when it shouldn’t, rather than being a deinterlacing problem. If you play it in software and set the scaling method to Nearest Neighbour, every now and then you get some strange distortion in the vertical (left) wedge. You can mask it by setting the scaling to Bilinear, but if the video is 480i and the output is 480p, it shouldn’t be doing any scaling, and changing the scaling method shouldn’t have any visible effect.

Just tried this on the Vero vs the Pi for the 1080/50i Dr Who, and it’s conclusive. I set 1080/25p as the only whitelisted resolution, and on the Pi+MMAL with deinterlacing off, playback was perfect. On the Vero, it was essentially unwatchable. I tried MMAL on the Pi with deinterlacing set to Auto, and it was as bad as the Vero, but at least on the Pi, it is possible to get this right.

1 Like

One further point on this. I had the impression that on the Pi, deinterlacing method was not selectable via the GUI when using OMX. Turns out that it is. OMX on auto gives good 25p motion, but with the moire effects I see on the Vero. OMX with deinterlacing disabled is as faultless as MMAL.

So, good motion on 25p is not conclusive that weave deinterlacing is being performed, but I guess poor motion is conclusive evidence that weave is not being performed

Let’s hope that with ARM becoming more and more popular and SoCs becoming more and more capable we can have a vero that can run madvr sometimes in the future

Ain’t gonna happen unless madvr is ported to ARM. AIUI it relies on DirectX and x86 hardware.