[mythtv] Mediacodec problem with avcodec_flush_buffers

[David Engel]

On Mon, Jul 30, 2018 at 09:57:40PM -0500, David Engel wrote:
> On Mon, Jul 30, 2018 at 01:26:24PM -0700, Aman Gupta wrote:
> > On Mon, Jul 30, 2018 at 1:22 PM David Engel <david at istwok.net> wrote:
> > 
> > > On Mon, Jul 30, 2018 at 12:59:17PM -0400, Peter Bennett wrote:
> > > > On 07/29/2018 11:12 PM, David Engel wrote:
> > > > > On Sun, Jul 29, 2018 at 08:55:20PM -0500, David Engel wrote:
> > > > > > On Fri, Jul 27, 2018 at 12:35:25PM -0400, Peter Bennett wrote:
> > > > > > > On 07/27/2018 10:37 AM, David Engel wrote:
> > > > > > > > On Fri, Jul 27, 2018 at 08:09:36AM -0400, Peter Bennett wrote:
> > > > > > > > > I think it is only with deinterlace. It may also happen with
> > > h264 interlaced
> > > > > > > > > content. I do not have much h264 interlaced content to test
> > > with.
> > > > > > > > I have at least one, 1080i, h264 channel.  I can check it
> > > tonight.
> > > > > > > >
> > > > > > > > David
> > > > > > > I have one 2-minute h264 interlaced 1080 file. I tested with that
> > > and I do
> > > > > > > not see the corrupted frame there when skipping.
> > > > > > > Attached is a patch to undo the non-functional workaround for the
> > > corrupted
> > > > > > > frame in case you want to try it.
> > > > > > This is now commit 4287f45f, right?  I just now got a chance to try
> > > it
> > > > > > and also look into another bug I found.  Do you still want feedback
> > > on
> > > > > > it?
> > > > > Okay, I have some feedback.  Maybe, just maybe, this might help with a
> > > > > fix.
> > > > >
> > > > > The previous behavior I saw was this.  The corruption was very
> > > > > prevalent in ff/rew.  It was not very prevalent at all when skipping
> > > > > forward and backward.
> > > > >
> > > > > The new behavior I now see is this.  I never saw any corruption even
> > > > > once in ff/rew of a 1-hour and a half-hour show.  The corruption is
> > > > > very prevalent now in skipping forward and backward.
> > > > >
> > > > > In other words, ff/rew was bad before and is now good and skipping was
> > > > > good before and is now bad.  Do ff/rew and normal playback still have
> > > > > separate GetFrame() calls?  If so, maybe what is being done now for
> > > > > one ff/rew frame can be done for skips too and fix the problem.
> > > > >
> > > > > David
> > > > Hi David
> > > >
> > > > This was expected. I reverted to the original behavior by taking out my
> > > > patch, which did not fix the issue and likely made it worse. Aman has
> > > > acknowledged the bug and passed it on to NVidia so maybe we can get a
> > > patch
> > > > from them in due course.
> > >
> > > Aman, do you have a good connection at Nvidia?  My local ABC station
> > > seems to have again started sending streams that show corruption when
> > > decoded with MediaCodec (and VDPAU, for that matter), but not when
> > > decoded with ffmpeg software.  I have a short sample that I can
> > > provide.
> > >
> > 
> > Yes I can forward the bug report and sample if you email them to me. Please
> > test the sample with the latest Exoplayer and make sure it reproduces there
> > so they can investigate easily.
> 
> I've confirmed the problem show with Exoplayer r2.8.2.  I can try with
> the latest, unreleased version from git if need be.  I'll send you
> them sample directly.  It's only 16 MB so should be okay by email.  If
> you don't get it in the next 10 minutes or so, let me know and I'll
> put on Google Drive and send you a link.

There is something else I just noticed using the sample and Exoplayer.
After the sample starts playing, bring up the OSD and keep pressing
the |< (go back to the beginnig) button every second or so.  The
corrupted, 1080i, mpeg2 issue we've been discussing happens almost
every time.  Please pass that on the Nvidia as well.  Thanks for your
help.

David
-- 
David Engel
david at istwok.net