(2015-07-05, 20:32)noggin Wrote: [ -> ]Really interesting stuff Andy. Will muse. Certainly the saturated chroma deinterlacing to look more 25p than 50p could be explained by some of what you are talking about. I'm using both an Ivy Bridge i5 and a Haswell i5 to play this stuff, and YADIF 2x deinterlace, so both CPU decode and CPU deinterlace.
My source material and my display resolution are the same though - so there shouldn't be a scale in the process? (unless there is 1080 vs 1088 oddness) My source material is 1920x1080 4:2:2 H264 50i (or ProRes or DNX HD) and my display resolution is 1920x1080/50p via HDMI, and output is either via Intel GPU or nVidia GPU.
There is still a chroma scale to 420 then to rgb, the first of which is the cause of the problem you see.
You could play 422 OK with say mpv --vo=opengl as it seems to be able to do 422 yuv -> rgb in opengl. You could also use ffmpeg yadif if you wanted --vf=lavfi=[yadif=1].
FWIW it may be possible to use your TV to de-interlace if you put it in an interlaced mode it may just do it. My 2010 Panasonic plasma does and it's my normal way of watching uk hd tv. I guess interlaced modes are GPU dependent - my baytrail and various radeons can do them.
There is the issue of field sync, though, I don't think kodi can use ffmpegs tinterlacex2 filter even though I got the idea from this forum.
So it's mpv again, if your source is 422 (planar) all you would need to do was put the TV into 1080i50 mode and do -
mpv -vo opengl --display-fps=50 --vf=lavfi=[tinterlace=interlacex2] ...
for most the source is going to be 420 so it needs an interlace aware conversion to 422 (as like everything mpvs yuv -> rgb would do progressive 420 -> rgb and mess things up, 422 -> rgb is the same whether it's progressive or interlaced) ) it would look like
--vf=lavfi=[scale=interl=1,format=pix_fmts=yuv422p,tinterlace=interlacex2]
tinterlace x2 could be considered a bit of a hack as you may be a field out sound wise. It works by placing a weaved frame on the display and updating half the lines at field rate, as long as you have vsync the fieldsync always sorts its self out even though it's not true field sync as you don't know what field the gpu is scanning out, it doesn't matter as each line stays on screen for 2 fields
Anyway I think I am getting a bit off topic :-) quickly think of something byt related - I wonder if intel will ever do deep colour and yuv 422/444 for HDMI, radeonsi will do deep color and may do 422 one day (deep colour needs patched xserver)
The idea of 422 is interesting - many TVs, including mine, sneakily turn rgb input back to 422 anyway - no idea how that would work with xserver, though.