just to clarify, I have not seen anything so I think this was directed to another user, does the 4.9 test build referred to above address the absence of weave deinterlacing for interlace-encoded progressive sources (affects 4.9 and 3.14), or the 4.9 playback stutter I reported with bluray-sourced 1080/50i VC1? (only affects 4.9)
Neither - these are 4.9 builds that don’t require an eMMC build.
If you’re already on 4.9 – you’re testing. To clarify, the purpose of the builds produced is to allow @jahutchi to test 4.9 without erasing his eMMC install which is relying on 3.14.
I now understand that. 
If you’ve ever got a build that allows one to force a weave deinterlace, I’ll be happy to help with testing that…
At the risk of veering off-topic, does anyone have any thoughts on why my 480i deinterlacing test-clip, if played on software, behaves differently depending on whether you select nearest neighbour or bilinear scaling?
You would think that with a 480i video and 480p output there shouldn’t be any scaling going on, so changing the scaling algorithm shouldn’t make any difference. The fact that it does makes me think there’s some extraneous scaling happening.
This thread has already pivoted from a HW issue to a video playback issue and is covering both deinterlacing and stuttering which may or may not be related. Can we park your question or deal with it elsewhere?
Sure. I mentioned it here just because the same test-clip that reveals problems with hardware-deinterlacing of 480i MPEG2 also reveals the scaling issue when played in software.
I did actually raise the problem once before, but it kind of fell by the wayside: 480p output being scaled when it shouldn't be...?
I found some time this morning to carry out some testing, and have posted the results on the main 4.9 testing thread [TESTING] Linux 4.9 kernel and improved video stack for Vero 4K / 4K + - #1341 by monkey
I’ve made some progress on this. I have a bunch of test clips which I suspect came from you and/or @angry.sardine, plus one I found on the interweb. The filenames are:
1080_50i_VC1.mkv
1080_60i_VC1.mkv
MainconceptLogo_Blu-ray_VC-1_1920x1080_LPCM.mpg
VC-1_23.976_sample.mkv
VC-1_29.970_sample.mkv
VC1_1080_50i_sample.mkv
They all play smoothly on 4.9 with the latest Kodi (which engages the deinterlacer for all VC-1s). Only the last one which you just sent me has the artifacting, which as I said, can be cured by forcing progressive in the decoder so that it supplies whole frames to the deinterlacer at 25fps. I honestly think there’s something wrong with the way that has been ripped. How exactly did you make it?
Despite that, I’ve tried to implement an option to force progressive from Kodi but it’s not trivial.
These improvements should be active in the kernel pushed earlier today.
So far @jahutchi seems to be OK with H264 (which we can control deinterlacing for trivially enough); but I’m waiting for more feedback on this.
Thanks for ongoing efforts with both VC1 and weave deinterlace.
I won’t be able to look at this for a few days but look forward to trying a new build.
All my content is direct disc to mkv via makemkv, no other processing.
All my VC1 50i and 60i content plays perfectly on my Pi’s, and as discussed the Pi has significant PQ benefits over the Vero when weave deinterlacing is forced on for appropriate content (this is a general benefit of the Pi, not just for VC1).
My 4.9 Vero has stuttering issues on 50i VC1 that are not present in 3.14, I have posted on that in the 4.9 thread with logs.
I have also previously posted about some 3.14 issues with 60i VC1 with occasional flashes of blocky corruption that are not present on the Pi. I will re-test everything when I get to try the new 4.9 and report back.
I can’t say I’ve noticed any difference in the clips I use to test deinterlacing.
Do you want logs or anything?
Note: My 4.9 testing so far has been extremely limited. Hope to move over to the 4.9 kernel for daily use later next week, and will keep you informed.
That’s puzzling. I think the clip I have called 1080_50i_VC1.mkv came from you as well as the VC1_1080_50i_sample.mkv (same disc). Yet they need to be decoded differently. the first one stutters with disabled deinterlacing, plays fine with deinterlacing. The second plays smoothly and moire-free with deinterlacing disabled. Both are supposedly ‘interlaced’ content.
I’m not blaming anybody, but that moire on the latest Dr Who clip is there on Vero, Pi and on Kodi and VLC on Windows unless I turn interlacing off (which is effectively a weave, I guess). Just saying.
Better wait a bit - there was a glitch incorporating some VC-1 improvements. Tomorrow should be good to go.
Solved now.
Sam
Agree this is a fair comment. With deinterlacing set to Auto on the Pi, it also fails to use weave deinterlace when it should do so. But the Pi has a GUI-level option to turn off deinterlacing (i.e. use weave) for HW-accelerated playback which is missing from the Vero. And since this is stored in the database, it’s a one-time switch per title. If this could be available on the Vero that would be really appreciated, but I recognise the OSMC team have to prioritise what you work on, and apart from me and @angry.sardine, no-one else is asking for this.
Updated again this morning, and I’m still not seeing any difference. 
Wholeheartedly agree.
As a check you’ve got the right update, can you turn on detailed logging for the video component, and look at what you get from tail -f ~/.kodi/temp/kodi.log | grep GetPicture when playing a clip.
Do the frame durations look sensible?
Your display should be outputting 50 or 60 (as appropriate) fps for best results.
It should look like this
2020-10-12 09:28:08.941 T:3357532384 DEBUG: CAMLCodec::GetPicture: index: 9072, pts: 1.820, dur:20.000ms
2020-10-12 09:28:08.959 T:3357532384 DEBUG: CAMLCodec::GetPicture: index: 9073, pts: 1.840, dur:20.000ms
2020-10-12 09:28:08.981 T:3357532384 DEBUG: CAMLCodec::GetPicture: index: 9074, pts: 1.860, dur:20.000ms
2020-10-12 09:28:08.997 T:3357532384 DEBUG: CAMLCodec::GetPicture: index: 9075, pts: 1.880, dur:20.000ms
2020-10-12 09:28:09.024 T:3357532384 DEBUG: CAMLCodec::GetPicture: index: 9076, pts: 1.900, dur:20.000ms
2020-10-12 09:28:09.039 T:3357532384 DEBUG: CAMLCodec::GetPicture: index: 9077, pts: 1.920, dur:20.000ms
2020-10-12 09:28:09.058 T:3357532384 DEBUG: CAMLCodec::GetPicture: index: 9078, pts: 1.940, dur:20.000ms
with only an occasional one of these
2020-10-12 09:28:09.081 T:3357532384 DEBUG: CAMLCodec::GetPicture: index:
9079, pts: 1.920, dur:2147463.648ms
I’ve added the necessary plumbing in kernel but struggling with what’s needed in Kodi for this. Can’t promise anything atm.
Okay, let me just check that step by step. I went into Settings, System, Logging, and checked “Enable component-specific logging”, then went into “Specify component-specific logging…” and selected “Verbose logging for the Video component”, and then “OK”. Then played the clip. While it was playing I did
tail -f ~/.kodi/temp/kodi.log | grep GetPicture
from the command-line. That didn’t give me any output - it just hung until I hit Ctrl+C.
What am I doing wrong?