Mailing List Archive

Kernel 2X HW-GL Deinterlacing
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.

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
--
David Engel
david@istwok.net
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Kernel 2X HW-GL Deinterlacing [ In reply to ]
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

_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Kernel 2X HW-GL Deinterlacing [ In reply to ]
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?

Peter
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Kernel 2X HW-GL Deinterlacing [ In reply to ]
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.

David
--
David Engel
david@istwok.net
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Kernel 2X HW-GL Deinterlacing [ In reply to ]
On 11/24/18 12:42 PM, David Engel wrote:
> 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 tried it on my shield, with standard decode and opengl  display -
using HW-GL deinterlacers -
Kernel 2x - the ticker looks double, two flickering copies of it
scrolling - most unpleasant.
Kernel 2x with interlace reversed selected - perfect.
Kernel 1x - the ticker shakes while scrolling.
Kernel 1x with interlace reversed selected - smoother, almost perfect.
Linear Blend 2x - perfect
Linear Blend 2x with interlaced reversed selected - the ticker looks
double, two flickering copies of it scrolling - most unpleasant.
Linear Blend 1x - ticker shakes while scrolling
Linear Blend 1x with interlaced reversed - same as with interlaced
normal - ticker shakes while scrolling

In 2x deinterlace, Linear blend and kernel seem equal, except that
kernel gets it wrong by needing the interlace reversed.
in 1x deinterlace, kernel is better but gets it wrong by needing
interlace reversed.

I am afraid I cannot offer any hope as far as understanding the OpenGL
is concerned, it seems to be a very complicated subject.

Peter

_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Kernel 2X HW-GL Deinterlacing [ In reply to ]
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


_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Kernel 2X HW-GL Deinterlacing [ In reply to ]
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


_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Kernel 2X HW-GL Deinterlacing [ In reply to ]
On 11/24/18 9:13 PM, Mark Spieth wrote:
> 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.

Mark
FYI
I have committed a change to set default float precision on opengl es to
highp instead of mediump. It does not affect shield, which seems to use
high precision regardless, but it fixes fire tv 4k so that YV12 and UYVY
both work. Without this fix, UYVY has poor resolution on the right hand
side of the screen. Fire tv (non-4k) does not support highp and ignores
the setting, so I believe this change should not adversely impact
anybody, it should be ignored where it is not supported.

Peter
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Kernel 2X HW-GL Deinterlacing [ In reply to ]
On Sat, Nov 24, 2018 at 05:25:30PM -0500, Peter Bennett wrote:
> On 11/24/18 12:42 PM, David Engel wrote:
> > 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 tried it on my shield, with standard decode and opengl? display - using
> HW-GL deinterlacers -
> Kernel 2x - the ticker looks double, two flickering copies of it scrolling -
> most unpleasant.
> Kernel 2x with interlace reversed selected - perfect.
> Kernel 1x - the ticker shakes while scrolling.
> Kernel 1x with interlace reversed selected - smoother, almost perfect.
> Linear Blend 2x - perfect
> Linear Blend 2x with interlaced reversed selected - the ticker looks double,
> two flickering copies of it scrolling - most unpleasant.

Hmm, I would have sworn I'd tested this. I just redid and, yes, I now
see the obvious distortion when turning on reversed with linead blend.
What do you see with Linux/full OpenGL?

> Linear Blend 1x - ticker shakes while scrolling
> Linear Blend 1x with interlaced reversed - same as with interlaced normal -
> ticker shakes while scrolling
>
> In 2x deinterlace, Linear blend and kernel seem equal, except that kernel
> gets it wrong by needing the interlace reversed.
> in 1x deinterlace, kernel is better but gets it wrong by needing interlace
> reversed.
>
> I am afraid I cannot offer any hope as far as understanding the OpenGL is
> concerned, it seems to be a very complicated subject.

The above leads me to believe there is simply a bug in the kernel,
OpenGL code. I will endeavor to try to figure it out. Not really
knowing OpenGL nor the kernel algortith, I don't know know how long it
will take.

David
--
David Engel
david@istwok.net
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Kernel 2X HW-GL Deinterlacing [ In reply to ]
On 11/25/18 9:03 PM, David Engel wrote:
> What do you see with Linux/full OpenGL?

Linux laptop with OpenGL slim profile

Linear blend 2x - perfect
Linear blend 2x with interlace reversed - uneven and shaking
Kernel 2x - uneven and shaking
Kernel 2x with interlace reversed - perfect

The uneven shaking performance is bad but not as bad as on the shield.
Like with the shield, Kernel seems to get it wrong.

I have long found that kernel does not work well, but I have not tried
interlace reversed with it before.

Peter
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Kernel 2X HW-GL Deinterlacing [ In reply to ]
On Mon, Nov 26, 2018 at 01:36:14PM -0500, Peter Bennett wrote:
>
>
> On 11/25/18 9:03 PM, David Engel wrote:
> > What do you see with Linux/full OpenGL?
>
> Linux laptop with OpenGL slim profile
>
> Linear blend 2x - perfect
> Linear blend 2x with interlace reversed - uneven and shaking
> Kernel 2x - uneven and shaking
> Kernel 2x with interlace reversed - perfect

Thanks. That pretty much confirms the problem is with the kernel GL
deinterlacer. I'll see what I can do. No promises beyond that.

> The uneven shaking performance is bad but not as bad as on the shield. Like
> with the shield, Kernel seems to get it wrong.
>
> I have long found that kernel does not work well, but I have not tried
> interlace reversed with it before.

Back in the days before vdpau, kernel deinterlacing in software was
the preferred option on systems that couldn't do yadif and greedh. By
the time kernel GL came along, vdpau was king. I think everyone
noticed that kernel GL sucked but nobody cared enough to look into it.

David
--
David Engel
david@istwok.net
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org