[mythtv] YV12 problem

[David Engel]

On Tue, Dec 11, 2018 at 05:27:21PM -0500, Peter Bennett wrote:
> On 12/11/18 3:13 PM, Peter Bennett wrote:
> > Hi David
> > 
> > Please can you point me to the patches that you are planning to install,
> > or specific instructions on which commits you will reverse, so that I
> > can do a test.
> > 
> > Here are close-up photos of the screen from current master with UYVY and
> > YV12 when using fire stick (non-4k) or "mi box s" or other devices that
> > do not support high precision opengl es.
> > 
> > Screen using YV12 checked ---> https://imgur.com/lbfyEWQ
> > Screen using YV12 unchecked (i.e. using UYVY) --->
> > https://imgur.com/dLoMUau
> > 
> > If you send me your patches I will test with those and see how the
> > picture looks.
> > 
> > Peter
> 
> I have tried your patch on ticket #13358. It produces the jagged result
> (https://imgur.com/dLoMUau) on the Fire TV (non-4k), without any ability to
> fix it.

I tested on my second generation firetv stick and first generation
firetv tonight with and without the reversio patch.  I saw no jaggies
whatsoever.

The firetv 1g was quite usable but moreso with mediacodec decoding.
With ffmpeg decoding of mpeg2 video, 720p was fine but 1080i needed
bob or one-field deinterlacing to not stutter.

The firetv stick 2g wasn't as nice.  I couldn't find any combination
of setting that didn't stutter.  That's in line with what I've heard
and read about all firetv stick pre-4k -- they just aren't powerful
enought for MythTV.

Both devices worked reasonably well Kodi as a MythTV frontend.
Though, the firetv stick 2g didn't support any deinterlacing.  That's
in line with my past experience -- Kodi is considerably less resource
intensive than MythTV.

> I agree that the code you are removing is flawed, as stated by Mark. I
> recommend that we change the default for the "enable YV12" setting  to be
> "false" for everybody, which bypasses that flawed code and achieves the same
> effect as removing it. The users of fire tv non-4k, mi box s, or other
> android devices that do not support high precision can still enable that
> check box to fix the jaggies, albeit with flawed code that does not properly
> support kernel deinterlace. However, using Linear blend deinterlace with
> YV12 is better than looking at that jagged picture.
> 
> If somebody can come up with better code that supports these android devices
> without the jaggies, we can then remove that faulty YV12 code.
> 
> If my recommendation is not taken and the code is removed, then we need to
> remove the setting from the frontend setup for enabling/disabling YV12,
> since that will no longer have any effect. I will also need to update the
> wiki to remove the recommendations around YV12 for android.

It's not just the kernel deinterlacer part, it's all of the yv12
support that I find suspicious knowing what I know now.  Witness the
"green line" issue that is "fixed" by not using yv12.  Maybe there's a
good reason for it but it tends to reinforce that that code is just
buggy.

Note that I'm not opposed to keeping the yv12 code, especially if it
is indeed more efficient.  However, if that is to be done, I think the
code needs to be thoroughly re-reviewed and fixed as needed.  That
includes fixing the yv12, kernel, deinterlacing part (preferred) or
removing it (not preferred but better than leaving in known buggy
code).

FYI, I uploaded separate, reversion patches for the two commits
currently considered in ticket #13358.

David
-- 
David Engel
david at istwok.net