[mythtv] Kernel 2X HW-GL Deinterlacing

[Mark Spieth]

On 11/24/2018 8:53 AM, David Engel wrote:
> This issue was discussed on IRC some weeks ago but never resolved.  I
> thought I'd bring it up here in hopes of resolving it.
>
> On the Nvidia Shield, the kernel 2X HW-GL deinterlacer looks terrible
> by default.  However, after explicitly setting the scan type to
> "interlaced (reversed)", it clears up very nicely.  I don't see this
> same behavior on Linux.  In fact, I don't see any difference among
> the detect, interlaced (normal) and interlaced (reversed) scan types
> on Linux but my vision isn't the best.

I have seen this too. I believe it is gl/gles driver implementation 
dependent.

Ive also seen this on windows (laptops esp.)

The GL interleavers need to perform the deinterleaving algo first and 
the last step also inverts the image. GL coord system has 0,0 at bottom 
left which mean the line order is reversed too so the 2nd field is 
originally on the first line.

I dont know if there is any way to tell its behaviour from an API call. 
I suspect not.

This ordering can be tweeked for android or runtime selectable.

I noticed similar things for YV12 where the color was line swapped and 
looked weird in one of the samples your provided. Easier to see on a low 
res video.

I have mods that I havent pushed which I have distributed in the past 
and still use. I suspect something like this also as an impact on the 
green line situation.

Mark

>
> Can anyone else confirm my findings, particularly on Linux?  More
> importantly, can anyone explain the observed behavior?  I know one
> difference is the Shield uses OpenGL ES and Linux uses full OpenGL.
> Does the Raspberry Pi use OpenGL ES, and if so, how does kernel 2x
> HW-GL perform on it?
>
> This is of interest because, in theory, kernel deinterlacing should be
> better than linear blend deinterlacing.  Getting it working correctly
> without having to set the scan type manually every time would be a
> nice improvement.
>
> David