As mentioned in another thread, I’m watching some videos that are natively 1080i/50. Being hi-def, the Vero 4K+ obviously has to decode them in hardware; that imposes hardware deinterlacing and outputs the video as 1080p/50.
The deinterlacing on the S905D is pretty good for video sources, but it’s not always optimal for 50Hz film sources, and there are some picture artefacts which (I’m 75% sure) are the result of it using video-mode deinterlacing when the camera is moving.
There are two possible solutions to that: one would be an option to tweak the deinterlacing and force it always to weave (instead of using motion-adaptive); the other would be to skip deinterlacing completely and output raw 1080i/50 instead of 1080p/50, so an external deinterlacer could do the job.
Is either of those something you could conceivably add?
I ask mostly because I was having a quick play with CoreELEC the other day and it has an option “Disable deinterlacing” - I’m not entirely sure what it does(!) but I wondered if it might apply here.
I guess I could also try setting the output to 1080i/50 in the system settings, and disabling the refresh-rate change, and seeing what happens; but I’m not sure if I trust Kodi to output the raw 1080i video (as opposed to internally deinterlacing and then reinterlacing using the wrong fields at the last minute); do you know if that would work correctly?
Hi
Update to the staging repository, and the issue should be fixed if it is caused by the deinterlacer
Cheers
Sam
ATM, I’m pretty sure we deinterlace in the video processor and re-interlace for 1080i.
If you keep the right pixels and throw the right ones away, you could reconstruct the original perfectly; how does it choose which field to take from which frame?
To test this update:
- Login via the command line
- Edit the file
/etc/apt/sources.list
- Add the following line:
deb http://apt.osmc.tv stretch-devel main
- Run the following commands to update:
sudo apt-get update && sudo apt-get dist-upgrade && reboot
- Your system should have have received the update.
Please see if the issue is resolved.
I also recommend you edit /etc/apt/sources.list again and remove the line that you added after updating. This will return you to the normal update channel.
I’ve no idea. If you want to have fun, look in /sys/module/di.
Didn’t get around to that back when I first raised this, but I’ve now updated to the staging rep, and tried running some of the deinterlacing tests on my old Spears & Munsil disc. These are 60Hz rather than 50; and in the case where you have a 24fps film converted to 60Hz (or 59.94) the calculation required to determine whether we’re in film mode or video mode is much, much easier than it is with 50Hz material.
It looks like it’s correctly detecting film-mode for 480i/60 material, but isn’t bothering to check at 1080i/60 - not even when the material is explicitly flagged as progressive.
Given that distinguishing between film and video for 1080i/50 is so much harder than it is for 1080i/60, it seems unlikely that it’s bothering with that either.
Can we get a sample of a file that plays as expected vs one that doesn’t?
Sam
Sure. Where would you like them uploaded to?
I’ll let @sam_nazarko answer that - I don’t understand how our system works.
There you go, @sam_nazarko - two files uploaded. They both look similar when played - a pair of wedge shapes, rotating around the screen.
If you run the 480i/60 version, you’ll notice there’s a slight moiré pattern at the narrow end of both wedges - that’s caused by upscaling - but otherwise the lines are fairly clear. If you run the 1080i/60 version, you’ll notice a much stronger moiré pattern at the narrow end of the horizontal wedge, and also a pronounced second moiré, the centre more or less level with where it says “540”.
Both files are based on a 24fps progressive source, which has been interlaced using the standard 2,3,2,3 pattern, and tagged as progressive. So, the deinterlacing should recognize that both are from a progressive (film-like) source. The extra moiré on the 1080i/60 clip strongly suggests that it’s being deinterlaced as if it were video (per-pixel motion-adaptive) instead of as film (with a simple weave). But it seems to get it right with the 480i clip.
If I play the 1080i clip on something that can deinterlace film-mode 1080i/60 correctly (like my Oppo 203) there’s no extra moiré, and both clips look very similar.
I’m struggling to understand what I’m looking at, here. MediaInfo says both of those files are 23.97fps and progressive.
They’re 23.97fps progressive frames stored as 59.94Hz interlaced fields with a 2.3.2.3 repeat pattern. Both files will play back as 1080p/59.94Hz (one of them being upscaled from 480).
EDIT: the issue is that the Vero 4K+ is able to recognise that the 480 file is progressive frames stored as interlaced fields and play it accordingly, but for the 1080 file it doesn’t recognise that fact.
I think it’s simpler than that. It’s playing the 480 file as progressive and the 1080 file as interlaced and attempting to deinterlace it. Just load each into VLC and toggle deinterlacing on/off and you see those moire patterns.
I’m not sure why it’s doing that, but the metadata is inconsistent: why should mediainfo think it’s 23.9Hz? And why does every other software think it’s 29.97Hz if it’s got 60Hz fields and flagged as progressive?
Can the fact that the 1080 file is VC1, but the 480 file in MPEG be affecting things?
The 1080p file is encoded as VC-1. For these videos we have to disable the post processing or we get stutters; as users reported some time ago with Blu-Ray rips. This workaround fixes progressive VC1 playback, but might cause issues for interlaced content.
You could try echo 0 > /sys/module/di/parameters/bypass_prog during playback.
If it were simply treating the 480 file as progressive, wouldn’t it be playing it as 1080p/23.976 rather than 1080p/59.94…?
But yeah, I guess you could say the fact that it doesn’t recognise the 1080 file as progressive-encoded-as-interlaced is the problem I’m asking you to investigate. 
It’s a question of how it’s deinterlaced. If it recognises that the two fields come from an originally-progressive source then it will deinterlace using a weave, and reconstruct the original progressive frames. If it deinterlaces it as if it were a natively interlaced video source, then you see the moiré.
I feel like I should be asking you that but yeah, maybe. The original 1080i/50 file I was having trouble with when I first started this thread was also VC-1, I think.