Ta. If we can reproduce it we won’t need more logs.
There are quite a number of things you can potentially get from those clips, but many of them are only relevant for potential future enhancements - right now the priority (I assume!) is to get things working as well as they did under Leia/3.14 so you can get the Matrix/4.9 release out.
From that perspective, there are probably only two things you need to worry about. One is the aforementioned crazy behaviour that you get when playing the 1080i/50 h.264 clips if you’ve whitelisted both 1080p/25Hz and 1080p/50Hz. The other is something subtly off with VC-1 decoding. While it isn’t its primary function, the 1080i/60 clip does also reveal the VC-1 issue if you look carefully. It’s not exactly a moiré effect, it’s subtler than that. Compare what that clip looks like when it’s played with software decoding with what it looks like with hardware decoding. In both cases set Deinterlacing to “Off”. In software it plays correctly; in hardware there are some faint diagonal bands that sweep from side to side across the right-hand horizontal wedge. (If I had to guess, I’d say some noise reduction is turned on somewhere where it shouldn’t be).
If you do ever want to get into possible future enhancements, here are other things you can usefully get from those test clips; but let me just reiterate that these issues also happen in 3.14/Leia, so you presumably shouldn’t be looking at them now.
-
The 480i wedge pattern decoded in software is deinterlaced correctly. Decoded in hardware you get a massive moiré pattern in the horizontal wedge, centered on the 240 mark. This indicates that it’s being deinterlaced as video instead of film.
-
There is, however, a weird scaling issue that affects the 480i clip if it’s played in software (with 480p whitelisted). Set scaling to Nearest Neighbour and watch the vertical wedge on the left - every now and again you see a column of distortion sweeping across it from side to side. You can somewhat mask the effect but setting scaling to Bilinear. But if the video is 480i and the output is 480p, why is there any scaling going on?! The setting shouldn’t change anything. (So I don’t think this is a deinterlacing error, I think it’s a scaling problem - the problem being that it’s scaling when it shouldn’t be!)
-
Decoded in hardware with deinterlacing set to Deinterlace or Auto-Select, the 1080i/60 wedge clip is decoded as video rather than film. (Big moiré pattern around the 540 mark). With Deinterlacing set to Off it’s deinterlaced correctly. It’s also handled correctly in software.
-
The Little Dorrit clip is 1080i/50 VC-1. It is an example of deinterlacing errors that are easily visible on something that isn’t a dedicated test pattern. Watch for shots where you can see a gold box design on the side of the piano, and look at the top and bottom edges of the gold box and the reflections along the bottom edge of the piano. Artefacts are fixed by setting deinterlacing to Off, but very visible in Deinterlace or Auto-Select modes.
-
The Sherlock clip is 1080i/50 h.264. Watch the pattern on Mycroft’s grey suit, especially between 00:30 and 00:47 - you get a shimmering effect because of deinterlacing errors. Because this is h.264 rather than VC-1 you don’t have the option of fixing it by setting deinterlacing to Off.
-
The clip from Time Flight is 576i/50, MPEG2. It is correctly deinterlaced as video, but highlights poor quality diagonal filtering if it’s played in hardware mode. Decoded in software it looks okay. But in hardware, watch the control console between 00:10 and 00:15, and between 00:34 and 00:39 - note the jagged edges and “crawling” effect.
Thanks. I will print that out as a useful summary of points you and @ac16161 have raised. We made progress back in October but when I checked last week, turning DI off didn’t seem to be working any more.
I’m still curious about 480i. Are you playing that as 480 lines in the middle of your huge panel or letting the TV scale it up to full-screen?
You get the same artefacts either way. They’re probably easier to see if you blow it up full screen.
Honestly, though, the issues with the 480i wedge pattern are not subtle. Have you actually tried comparing what it looks like with software decoding and what it looks like decoded in hardware? The differences between the two are very obvious.
Yes, the difference between SW and HW decode on the 480 clip is clear, and I can see the nearest neighbour artifact.
But at the moment I see no difference with the 1080 clip. Not sure why. That’s because I’m testing on a 1366x768 screen. That was why I asked about playing 480 at exactly 480 lines.
Okay, good! 
The issue with (I guess?) VC-1 decoding is a lot more subtle, to be fair. Again, if you turn off hardware decoding, the 1080i wedge pattern plays perfectly - that gives you a reference. To give you an idea of what you’re looking for, try playing it with hardware decoding and deinterlacing set to Auto-Select. If you look carefully, you can see two different sets of artefacts: at the left edge of the horizontal wedge and centred on the 540 mark, there’s some very obvious moiré (just like what you see on the 480i clip in hardware); further to the right within that wedge, you should see also a couple of diagonal bars which sweep left to right, turn till they’re vertical, keep turning till they’re diagonal again, sweep right to left, disappear, and then repeat the cycle.
If you now switch deinterlacing to Off, it fixes the main moiré, but the sweeping diagonal bars are still there (but much fainter).
Given that those bars aren’t there when decoding in software, I have to assume it’s a decoding artefact.
My “Little Dorrit” also looks like it has a slight hint of “clay face”, which usually means there’s some DNR going on. (Obviously you can’t play that one in software for comparison, you have to play it on a different device!)
I’ve noted that with some live TV, but only on my 14-year-old HD-ready set. On my 2017 4k Panasonic it’s OK.
Hi, After updating to Kidi 19.1 (latest I believe), I experienced that the audio and video gets slightly out of synch. Also, I could not access embedded subtitles that worked well on VLC in windos.
On one movie (also ok in vlc windows) embedded subtitles were also now available and the video movements choppy.
It would be good to see some logs. It’s not clear what device you are using
Sam
Yes sorry about that, a bit tired here in Asia right now… hte missing subs might be my own mistake, but about the choppy movie I will reboot and get back soonest with a log. Just goptr surprised since its worked so well for years …
Ah, yeah, you won’t see very subtle distortions in a 1080p image if you’re downscaling it to 1366x768. I don’t think upscaling 480 is a problem, though.
Come to think of it, if the TV is 1366x768, is it even capable of receiving a 1080p/60 signal? Maybe the Vero is actually sending 1080i/60, in which case you might not be seeing player-side deinterlacing errors!
No it’s good for that, even with deep colour. It’s a child of those few years when manufacturers must have had too many 1366x768 panels in their warehouses while 1080 HD TV had taken off already.
Sorry about this Sam, behaving the way I hate so see others do in forums…
Anyway - here is more info and problem seesm solved, but a new one showed up:
I run OSMC in a VERO 4k+ and after updatibg to 19.1 version - should be the very latest.
I believe that the issues started after I updated to 19.1 some week ago.
I noticed a small lad between audio and video, speech and lip movements are a trine bit out of synch. Watchable, but irritating.On some movies the video is soimnetimes flowing as normal, then freeze for a split second, and then jump forward again to contimue as normal. I experience no issues when listening to music.
Before posting this, I re-added the deb http://apt.osmc.tv buster-devel main line to sources.list and after running update the time delay was FIXED.
However, a new issue have showed up. I can no longer find my USB-DAC listed as a source under Settings/System/Audio/, I have tried ther usual ways, rebooting (both the DAC and the VERO) and plugging in out the USB cable without success. The DAC show that there is a constant 48kHz (standby) signal in, so the cable seems to be ok.
Fresh Log: https://paste.osmc.tv/ivahabodul
In the Log, I can find the name of the USB dac / device as it normally is listed in Settings/System/Audio. “AMB zeta1 USB-I2S Audio-Widget”
A new thing I noticed, is that it seems to take quite a while (minutes) before VEROs remote start to work. But the remote for my TV can still operate VERO.
I later restarted the DAC (at that point the VERO remote had started working again) and then KODI could find my DAC after I opened the Settings/System/Audio menu.
Is this some kind of USB issue? It seesm to me as if the USB ports are not available for KODI at teh time it start to look for devices after a boot? (IF that is how the boot process works…)
Maybe (not that likely) a power issue especially as in your Logs it shows
Jul 18 13:16:05 osmc kernel: usb 1-2: device descriptor read/64, error -110
Jul 18 13:16:05 osmc kernel: usb 1-2: Device no response
Jul 18 13:16:06 osmc kernel: usb 1-2: new high-speed USB device number 4 using xhci-hcd
Do you have a powered USB Hub that you can try? Or try to boot without the DAC does the Remote work faster?
Just tested: with USB-DAC unplugged the remote work right away, when it’s plugged in the delay is 1-2 minutes.
Log of the reboot with DAC unplugged here (later plugged in again and found right away by OSMC): https://paste.osmc.tv/vesukudana
I still wonder why this happens - two reasons would speak against USB power being the issue:
- there were no issues at all with remote or DAC before my upgrade - and I have not changed the setup for many years.
- The DAC is not one of the small bus-powered USB-DACs but a full-sized HiFi DAC with its own power supply so all the VEROs USB port has to drive is the remote receiver.
And at the second reboot things got weird, this time I had DAC plugged in at restart, and this time OSMC found both remote and DAC right away.
log of the second reboot: https://paste.osmc.tv/lutusaqawo
One reason could be the new Software might need more power when booting up.
Ok, that would speak against the power issue
Yes, I double-checked the schematics right now to make sure since the audio widget that handles the USB-I2C conversion in the DAC can be set in either mode. In this DAC it is however hard-wired to use its own power to ensure quality. (it’s not my design, but I did build it as part of the prototype team so I have a pretty good idea of how it’s working.
I was thinking of this too as an explanation, and guess it might still be valid, but that must mean quite alot of more power go into the boot-up sequence.
Or the power supply just degraded at a similar time as you did the upgrade. Do you by any chance have a fitting 5V/2A power supply with correct plug/polarization on hand to test?
But maybe I am on the totally wrong hunt here and @sam_nazarko sees a better reason in the logs why this happens.
That seems possible, although a bit far-fetched since it did boot properly at the last attempt. I will wait and see if Sam has any comment before I try, It is quite a major operation to access the power supply behind the TV/HiFi Setup unfortunately.