<div dir="ltr"><br><div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, Jul 30, 2018 at 1:22 PM David Engel <<a href="mailto:david@istwok.net" target="_blank">david@istwok.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, Jul 30, 2018 at 12:59:17PM -0400, Peter Bennett wrote:<br>
> On 07/29/2018 11:12 PM, David Engel wrote:<br>
> > On Sun, Jul 29, 2018 at 08:55:20PM -0500, David Engel wrote:<br>
> > > On Fri, Jul 27, 2018 at 12:35:25PM -0400, Peter Bennett wrote:<br>
> > > > On 07/27/2018 10:37 AM, David Engel wrote:<br>
> > > > > On Fri, Jul 27, 2018 at 08:09:36AM -0400, Peter Bennett wrote:<br>
> > > > > > I think it is only with deinterlace. It may also happen with h264 interlaced<br>
> > > > > > content. I do not have much h264 interlaced content to test with.<br>
> > > > > I have at least one, 1080i, h264 channel.  I can check it tonight.<br>
> > > > > <br>
> > > > > David<br>
> > > > I have one 2-minute h264 interlaced 1080 file. I tested with that and I do<br>
> > > > not see the corrupted frame there when skipping.<br>
> > > > Attached is a patch to undo the non-functional workaround for the corrupted<br>
> > > > frame in case you want to try it.<br>
> > > This is now commit 4287f45f, right?  I just now got a chance to try it<br>
> > > and also look into another bug I found.  Do you still want feedback on<br>
> > > it?<br>
> > Okay, I have some feedback.  Maybe, just maybe, this might help with a<br>
> > fix.<br>
> > <br>
> > The previous behavior I saw was this.  The corruption was very<br>
> > prevalent in ff/rew.  It was not very prevalent at all when skipping<br>
> > forward and backward.<br>
> > <br>
> > The new behavior I now see is this.  I never saw any corruption even<br>
> > once in ff/rew of a 1-hour and a half-hour show.  The corruption is<br>
> > very prevalent now in skipping forward and backward.<br>
> > <br>
> > In other words, ff/rew was bad before and is now good and skipping was<br>
> > good before and is now bad.  Do ff/rew and normal playback still have<br>
> > separate GetFrame() calls?  If so, maybe what is being done now for<br>
> > one ff/rew frame can be done for skips too and fix the problem.<br>
> > <br>
> > David<br>
> Hi David<br>
> <br>
> This was expected. I reverted to the original behavior by taking out my<br>
> patch, which did not fix the issue and likely made it worse. Aman has<br>
> acknowledged the bug and passed it on to NVidia so maybe we can get a patch<br>
> from them in due course.<br>
<br>
Aman, do you have a good connection at Nvidia?  My local ABC station<br>
seems to have again started sending streams that show corruption when<br>
decoded with MediaCodec (and VDPAU, for that matter), but not when<br>
decoded with ffmpeg software.  I have a short sample that I can<br>
provide.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> Did you manage to test whether it ever happens on interlaced H264? The<br>
> theory is that it is only on MPEG2. Maybe it only happens on interlaced<br>
> MPEG2. For non-interlaced MPEG2 I suppose a recording from FOX could be used<br>
> for a test, that seems to be 720p MPEG2.<br>
<br>
Yes, I replied somewhere regarding this.  I did not see the problem<br>
with interlaced h264.  I also did not see the problem with 480i mpeg2.<br>
The problem seems to be limited to 1080i mpeg2.<br></blockquote><div><br></div><div>Interesting that 480i doesn't reproduce. I can confirm that interlaced h264 seems fine.</div><div><br></div><div>Aman</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> AFAIK - the reason ff and rew are ok is that after each jump, only the first<br>
> frame is used, then another jump is done. The first frame is always OK, the<br>
> corrupted frame comes later at some random time.<br>
<br>
I see.  Strange.<br>
<br>
David<br>
<br>
> The fix which I had made but is now removed, was by skipping 4 frames after<br>
> each jump. Sometimes that was enough to avoid the bad frame and sometimes<br>
> not. But this would cause extra load on the system by having to decode 4<br>
> extra frames.<br>
> <br>
> At this point I am not sure what the conditions are for the corrupted<br>
> frames, whether it is only MPEG2 or only MPEG2 interlaced or maybe both H264<br>
> and MPEG2 when they are interlaced.<br>
> <br>
> Peter<br>
<br>
-- <br>
David Engel<br>
<a href="mailto:david@istwok.net" target="_blank">david@istwok.net</a><br>
</blockquote></div></div></div>