What’s the quickest way to check?
Kernel hasn’t been updated yet to support the deinterlace options I put into Kodi. Should just need building.
We have a Dr Who clip with Tennant being dragged across the floor by some monster. We can see flashes of corruption (blocking) in that but @chillbo and I get them at different timestamps. I think it’s going to be a toughie.
Cool! Are we going to get the same options for other codecs?
I don’t know. I haven’t spent any time with other codecs.
It would be nice to have it for MPEG2 and h.264 as well.
Should not be a need because we don’t have to force the DI pathway
Well, my 480i/60 mpeg2 test clip is deinterlaced correctly in software, but wrongly in hardware. 
So just change hardware acceleration to HD and up for said format?
-
That gives me this problem: 480p output being scaled when it shouldn't be...? .
-
There’s something ever so subtly wrong about the colours using software decoding.
-
There are rare cases of 1080i/50 mpeg2 to contend with (for example the blu-ray of Farscape: Peacekeeper Wars).
-
From what other posters have said, 1080i h.264 isn’t deinterlaced correctly in hardware either.
But the point I was making was that even if you aren’t “forcing the DI path” for other codecs, they’re still not being handled correctly.
Well - if you play interlaced content (1080i50), we obviously won’t bypass the deinterlacer.
I have some ideas to resolve for 1080i at least. Stay tuned.
BTW: the VC1 kernel is ready now.
Just checking. This is a thread about 4.9. IIRC you thought this also applied on 3.14.
Thanks for this, great work, progressive 50i VC1 can now play with weave deinterlace, and the results are so much better than before. Not a hint of moire and (to my eyes) a clear step up in resolution. Also passes the 1080/25p whitelist test, with perfect motion at 25p output.
I’ve seen some other posts in the thread about whether or not changes are needed for h264 and MPEG2. I suggest changes are needed. At present, h264 and MPEG2 both fail on the 25p output test for 50i-encoded progressive sources, which to me is a clear indicator that by default, the Vero is not using weave deinterlace correctly on these codecs when the source is progressive. I have tried SD MPEG2 and HD h264, and motion on 25p output is terrible, whereas now (with deinterlacing disabled via the GUI), VC1 is perfect. If the team can crack this for VC1, is there a good chance it can be fixed for other codecs as well?
I would completely understand if you just parked this one. I only have a small number of titles with this issue, they are the blu-rays of the David Tennant specials, which have a butchered standards conversion from 50i to 59.94. I recall from discussions on fan sites that the conversions are a complete mess, with differences both between and within episodes resulting in a totally mangled field structure. The Pi can play these without the occcasional blocking flashes I see on the Vero, but I flagged this in case it relates to how the Vero handles VC1.
It’s been so long since I was running 3.14, I honestly don’t remember. I found an old post of mine on here, from back when I first raised this, which suggests that, at that time, everything was working correctly on 480p; but it’s possible that I was running in software at that point and didn’t properly appreciate the difference between software/hardware behaviour.
I was talking about progressive-stored-as-interlaced. (E.g. 1080p/25 stored as 1080i/50).
Interesting! My clip from Planet Earth now plays smoothly at 1080p/25, with deinterlacing set to Off. And my 1080i/60 test clip is weaving correctly with deinterlacing set to Off.
Both are still being handled wrongly with the setting set to “Auto select”, though.
Intriguingly, if you set deinterlacing to Off, after a few seconds the output refresh rate changes: the 1080i/50 clip starts playing at 1080p/25 rather than 1080p/50, and the 1080i/60 clip actually switches to 1080p/24, which is rather impressive.
I just ask because HDR movies which i´ve played in 3.14 kernel were fine. In 4.9 kernel are all colors little bit greyish including menu. It seems to be darkened and colors are faded.
Maybe i will have to reinstall the whole system. Noone report this.
Of course! If it’s tagged as interlaced, Auto will assume it’s interlaced.
1 Like
The 1080i/60 clip is tagged as “progressive”. MediaInfo:
General
Unique ID : 181905201492690631976731927959520899318 (0x88D9AADE9F79C2D858E81B5FE80B70F6)
Complete name : E:\Video\Test Clips\Deinterlacing test patterns\1080i_60_deinterlace_test.mkv
Format : Matroska
Format version : Version 2
File size : 54.1 MiB
Duration : 1 min 7 s
Overall bit rate : 6 716 kb/s
Encoded date : UTC 2019-03-09 19:09:14
Writing application : MakeMKV v1.14.2 win(x64-release)
Writing library : libmakemkv v1.14.2 (1.3.5/1.4.7) win(x64-release)
Video
ID : 1
ID in the original source medium : 4113 (0x1011)
Format : VC-1
Format profile : Advanced@L3
Codec ID : V_MS/VFW/FOURCC / WVC1
Codec ID/Hint : Microsoft
Duration : 1 min 7 s
Bit rate : 6 714 kb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Variable
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Scan order : 2:3 Pulldown
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.135
Stream size : 54.1 MiB (100%)
Language : English
Default : No
Forced : No
Original source medium : Blu-ray
We do know the OSD display when playing HDR on a SDR display is not as bright as it is with SDR-SDR. It’s being worked on.
For me, the colours of a HDR video played as SDR are too saturated. The next kernel release will correct that.