[mythtv] Kernel 2X HW-GL Deinterlacing

[Mark Spieth]

On 11/25/2018 4:42 AM, David Engel wrote:
> On Sat, Nov 24, 2018 at 10:31:49AM -0500, Peter Bennett wrote:
>>
>> On 11/23/18 5:48 PM, Mark Spieth wrote:
>>> 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
>> I have found that kernel deinterlacing has not worked well on Linux or
>> android, and I stick with linear blend. I tried the kernel deinterlace on
>> the fire stick and it looks the same whether I have interlaced normal or
>> interlaced reversed. In both cases there is a quivering effect on straight
>> lines, worse than when using bob. Linear blend looks best in all cases. What
>> type of effect do you see?
> The effect I see on my Shields when reversed is not selected is very
> much like a non-deinterlaced image -- the alternating scan lines are
> offset by a few pixels.  It's most apparent on scrolling news tickers.
> When reversed is selected, the scan lines all line up nicely.  Have
> you tried it on your Shield?
>
> What's troubling is the inconsistency.  Mark's comment about the
> coordinates being different between OpenGL and OpenGLES could explain
> why the Shield needs reversed selected to look good.  If that was
> true, though, I'd expect selecting reversed to look bad on Linux but
> it doesn't.
>
I dont think the coord system is different between GL and GLES but have 
not checked. GLES just has less capability than GL, I suspect all the 
other elements are identical. Main issue between them is the precision 
of the floats I believe for our purposes.

OT: I'm still looking into 4k on the shield but have not found a 
solution as yet but I believe I'm getting closer.

Mark