[mythtv] Mediacodec problem with avcodec_flush_buffers

Peter Bennett pb.mythtv at gmail.com
Mon Jul 30 16:59:17 UTC 2018

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.

Did you manage to test whether it ever happens on interlaced H264? The 
theory is that it is only on MPEG2. Maybe it only happens on interlaced 
MPEG2. For non-interlaced MPEG2 I suppose a recording from FOX could be 
used for a test, that seems to be 720p MPEG2.

AFAIK - the reason ff and rew are ok is that after each jump, only the 
first frame is used, then another jump is done. The first frame is 
always OK, the corrupted frame comes later at some random time.

The fix which I had made but is now removed, was by skipping 4 frames 
after each jump. Sometimes that was enough to avoid the bad frame and 
sometimes not. But this would cause extra load on the system by having 
to decode 4 extra frames.

At this point I am not sure what the conditions are for the corrupted 
frames, whether it is only MPEG2 or only MPEG2 interlaced or maybe both 
H264 and MPEG2 when they are interlaced.


More information about the mythtv-dev mailing list