[mythtv] Kernel 2X HW-GL Deinterlacing

[Mark Spieth]

On 11/25/2018 2:31 AM, 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? 

I see odd and even lines swapped.

This is particularly noticable for YV12 on adjacent horizontal/diagonal 
color boundaries. Does nto affect YUY2/YUYV since color info is on a per 
line basis.

However this seems to have affected

I have a patch to for the above but I thought it was only an android 
issue. havent examined the effect on linux. This is a problem with the 
original GL deinteracers which process all lines from bottom to top (0,0 
being at bottom left) and then inverts the whole picture. I considered 
this an algo error but could not be sure about linux effects.

If you want the patch again let me know.

Mark