[mythtv] Kernel 2X HW-GL Deinterlacing

[David Engel]

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 at istwok.net