How big of a project would that be I honestly don’t even imagine but if it’s possible I’m sure someone will do it at some point.
I’d definitely donate towards such a project and I’m sure a lots of people would
By hacking the kernel to force deinterlace off I can change this
to this
Now just need to figure out if we can recognise when deinterlacing should be turned off or else bring a setting out to the GUI.
Is this something unique to VC-1 @ac16161 @angry.sardine?
1 Like
Impressive work! This is not unique to VC-1. I just tried a BBC Sherlock bluray (h264) and it failed the 25p output test on the Vero, mix of some smooth motion but lots of stutters. The moire was not as bad as I saw on the Dr Who Time of Angels episode, but still evident from time to time on finely patterned clothing. Also, the weave deinterlace on the Pi (to my eyes) has obviously superior vertical resolution.
A 480i MPEG2 file exhibits the same issue as a 1080i VC-1 file, so I don’t think so.
I have a growing collection of titles with file-specific “deinterlace=off”, and these all get stored in the settings table of the database. So it’s a one-time thing, then all the Pi’s on my network play the file correctly, without further intervention on my part. Could the Vero be configured to pick this up from the database, to initiate playback correctly?
Sure. But as a part-time pedant, I really would like to know by what logic mediainfo reports these as ‘interlaced’ while we need to play them as if progressive.
The whole interlaced/progressive/non-progressive saga is doing my head in.
I don’t want to go into the kernel with size 10s and break stuff for other media streams.
An interim solution might be to add a manual toggle in the Video Settings menu during playback, so you can force “weave” deinterlacing on a title by title basis. This option already exists on the Pi; bringing the Vero 4K in line with it would be a step forward.
We already bypass DI for VC1, otherwise it causes stutters. Or at least we used to. As far as I can tell, we still do this.
Exactly. This is exactly what I have been doing via the Pi. For all my progressive 50i content, as I work through the library I manually disable deinterlacing via the Kodi GUI video settings on a Pi. This causes an entry to be written to the central videos database on my NAS MariaDB, then whenever I initiate playback via another Pi, it reads the setting and knows to disable deinterlacing. Works perfectly, I have complete control of when deinterlacing is switched off, and I only have to do it once per title. Much of my library has these entries now, just waiting for the Vero to be able to work with them in the way a Pi can.
Well, interlaced VC-1 material is definitely not being handled correctly now, and it wasn’t being handled correctly in early 2019 either. And the issue certainly affects MPEG2 as well right now.
I’ve checked, and we do indeed have patches for this which are active. Without them, VC-1 wouldn’t really play at all.
I really appreciate the engagement on this topic.
interlaced VC-1 plays on the Vero (at least under 3.14, not under 4.9, as of the last time I checked), but if the source is progressive, with interlaced encoding, the Vero does not pick that up and attempts to deinterlace instead of weaving the progressive fields. This can lead to really bad moire (per the screenshot I posted earlier in the thread, and confirmed by @grahamh, as he can now fix it), and also the Vero fails the 25p output test on such 50i material, which the Pi handles perfectly when it has deinterlacing set to off.
So whatever patches are in place, they may be sufficient for “passable” playback of interlace-encoded progressive sources, but they are not delivering reference-standard playback that is available from the Pi, either for VC1 or h264.
1 Like
This is intended.
If you bypass the deinterlacer for progressive VC-1 content on AMLogic hardware, it will not play smoothly at all.
At least this was definitely the case with 3.14 and early 4.9 builds. Things may have changed – verifiable with echo 0 > /sys/module/di/parameters/di_debug_flag during the playback of progressive material. You’d need to test that on 4.9.
Other codecs: like H264/HEVC/VP9 aren’t affected by this problem and therefore don’t have this workaround.
Other devices, like the Pi, have different HW IP blocks for decoding. Going from one device to another will usually give a deviation in picture quality which some will prefer and some won’t. One person’s reference standard is not another person’s.
We can look at the VC-1 content again, but I’m not sure there’s anything to change with H264 and other codecs.
just want to check we are not talking about different things here. I am talking about material that has been captured or rendered in the progressive domain during production, but authored onto disc as interlaced. E.g. most BBC content ever released on bluray, which is 50i on the disc but the production rendering (if that’s the right term) was progressive. Hence the 50i fields just need to be weaved. The Vero does not do this for sure with VC-1, and I’m pretty sure that it does not do it for h264 either, judging by the Sherlock comparison I did earlier today between the Vero and the Pi.
All we need here for the Vero to get to parity with the Pi is the ability to disable deinterlacing when the hardware deinterlacer has failed to figure out that the fields are from a progressive source. Just compare the two, and on any half-decent display, I’d say the inferiority of the Vero is pretty obvious.
Then I don’t think we’re talking about the same thing.
I’m saying that even for content that is marked as progressive, we have to enable the deinterlacer for smooth playback for VC-1. For other codecs, we bypass the deinterlacer for progressive sources.
So it may not be a case of us misidentifying the content, but rather the fact that we have to force the content through the deinterlacing pathway because it will otherwise not play smoothly.
You can verify if this is still the case as suggested above.
that’s a shame as the HW deinterlacer on the Vero does not do a very good job with interlaced authoring of progressive material, per the screenshot earlier in the thread. The Pi allows deinterlacing bypass and gives perfect results.
hmm, earlier today I checked out the h264 Sherlock season 2 bluray, 50i authoring of a progressive source. As I posted earlier, the Vero still has slight moire compared to the Pi, but in particular, it fails the 25p output test, so the Vero isn’t getting it right with h264 either.
Unless we verify that VC1 no longer needs progressive on with the latest 4.9, I can’t see things improving for that codec.
If H264 issues are just caused by us deinterlacing when we shouldn’t, that shouldn’t be too hard to fix.
We would need to be careful not to break live TV though, as general tinkering in that area tends to cause issues for users like @jahutchi
I would second this. I find that the playback of BBC-based HD 50i h264 channels is poor - loads of stuttering.
As discussed at length previously I found that setting bypass_all=1 would fix the issue.
This wound me up so much that I patched kodi in a similar way to the CoreELEC guys do…to set bypass_all=1 for h264 content. It is annoying having to maintain my own builds…would be nice to just have some sort of gui setting included in the standard osmc builds.
I was not aware you were still having issues A PR is welcome. I’m not sure that’s 100% the right approach though. But it could be tested on 4.9 users.
I’ve checked and it looks like CE treat deinterlacing the same way we do: ie force it for VC-1 only. I didn’t see any additional provisioning for H264 from a quick glance.
Will likely need some more clips again.
They seem to have an extra option to switch off the de-interlacer, and this patch to set bypass_all=1 for h264 1080i when that setting is enabled.
I’ve kinda been tempted to move to Coreelec but as this is my only issue…