[mythtv] Playback next steps

[David Engel]

On Fri, Dec 14, 2018 at 03:16:59PM +0000, MARK KENDALL wrote:
> I forked master last week - just to keep track of patches etc. You can see what I've been doing at:
> 
> https://github.com/mark-kendall/mythtv/commits/master
> 
> In summary so far for OpenGL:
> 
> - fixed UYVY kernel deinterlacer (I see that's already in master)
> - fixed YV12 kernel deinterlacer (pretty sure linear blend is broken as well, it looks terrible)
> - patched mythavtest to add double rate deinterlacing support (mythavtest is really useful for performance testing if you haven't used it before)
> - some openglbicubic fixes
> - minor improvement to the UYVY kernel deinterlacer
> - fix for desktop OpenGL ES2

I tested your changes on my nvidia shield this evening with a little
extra focus on YV12.  I'll try on my firetv sticks this weekend.  In
short, after it compiled, everything worked well including one
pleasant and interesting surprise.  Here are some of the details.

Android doesn't have a #define for GL_RGBA16 so I had to add another
workaround for it to the existing ones in mythrender_opengl_defs.h.

There was no green line with YV12 like before.  Either your changes or
another one must have fixed that.

The YV12 kernel deinterlacer worked fine.  Here's where the surprise
was.

I like to watch some things with timestretch, sometimes with a lot of
timestretch.  One of those things is bicycle racing.  At 2x
timestretch, it can be quite the decoding and deinterlacing torture
test with lots of individual cyclists and moving scenery.  It's even
more tortuous for races on one of my h.264/1080i channels.

My old, Linux/vdpau frontend had no problem with it but my shield has
never been able to handle it without slight to moderate stuttering.
With mediacodec decoding, it wasn't watchable and required backing
down quite a bit on the timestretch.  With software decoding, uyvy
pixels and linear blend deinterlacing it could almost keep up.  A lot
of motion would cause stuttering.  Tonight, with software decoding,
yv12 pixels and kernel deinterlacing, it kept up just fine!

I belive you said deinterlacing was the big problem area for yv12.  I
don't doubt you on that.  However, it seems the savings from moving
less data around more than makes up for the loss from more complicated
deinterlacing.

David
-- 
David Engel
david at istwok.net