<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, Jul 30, 2018 at 3:49 PM David Engel <<a href="mailto:david@istwok.net">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 01:26:24PM -0700, Aman Gupta wrote:<br>
> 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>
> <br>
> > 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<br>
> > h264 interlaced<br>
> > > > > > > > content. I do not have much h264 interlaced content to test<br>
> > with.<br>
> > > > > > > I have at least one, 1080i, h264 channel.  I can check it<br>
> > tonight.<br>
> > > > > > ><br>
> > > > > > > David<br>
> > > > > > I have one 2-minute h264 interlaced 1080 file. I tested with that<br>
> > 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<br>
> > 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<br>
> > it<br>
> > > > > and also look into another bug I found.  Do you still want feedback<br>
> > 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<br>
> > 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>
> ><br>
> <br>
> Yes I can forward the bug report and sample if you email them to me. Please<br>
> test the sample with the latest Exoplayer and make sure it reproduces there<br>
> so they can investigate easily.<br>
<br>
Excellent.  I have Exoplayer built and running, but I don't see how to<br>
make the demo app play an arbitrary file.  How do I do that?<br></blockquote><div><br></div><div>You have to edit the json asset to add a custom section with your own media sample url/paths.</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>
David<br>
-- <br>
David Engel<br>
<a href="mailto:david@istwok.net" target="_blank">david@istwok.net</a><br>
</blockquote></div></div>