<div><br></div><div><br><div class="gmail_quote"><div dir="ltr">On Tue, Jul 3, 2018 at 11:35 AM 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 Tue, Jul 03, 2018 at 10:37:04AM -0400, Peter Bennett wrote:<br>
> <br>
> <br>
> On 07/02/2018 09:38 PM, David Engel wrote:<br>
> > On Mon, Jul 02, 2018 at 05:14:52PM -0400, Aman Gupta wrote:<br>
> > > On Mon, Jul 2, 2018 at 3:58 PM Peter Bennett <<a href="mailto:pb.mythtv@gmail.com" target="_blank">pb.mythtv@gmail.com</a>> wrote:<br>
> > > > Hi Aman<br>
> > > > <br>
> > > > Thank you for all your help so far.<br>
> > > > <br>
> > > > I upgraded my Shield to Android 8.0. Now I get a seg fault every time I<br>
> > > > play 1080 interlaced recordings. Progressive recordings are fine, and<br>
> > > > 480 interlaced are fine. Also 4K recordings are fine. With 1080<br>
> > > > interlaced it gets a seg fault in avcodec_receive_frame. This happens at<br>
> > > > about the fifth frame received in the video. It starts off fine, with<br>
> > > > avcodec_receive_frame returning EAGAIN until some number of packets have<br>
> > > > been sent, then it receives a few frames, then there is a seg fault in<br>
> > > > memcpy. There are no null addresses being passed to memcpy, but<br>
> > > > something must be invalid. This was working fine with Android 7. I am<br>
> > > > using the default buffer allocation: AVCodecContext->get_buffer2 =<br>
> > > > get_avf_buffer. avcodec_receive_frame should allocate the buffers using<br>
> > > > that routine so they should be valid.<br>
> > > > <br>
> > > > [backtrace snipped]<br>
> > > > <br>
> > > You can try the mpv-android apk from GitHub to compare. I'm pretty sure it<br>
> > > works fine on Oreo.<br>
> > mpv-android almost always crashes for me after a split second on 1080i<br>
> > content.  When it doesn't crash, it just exits playback, also after a<br>
> > split second.  720p content works fine, just like with MythTV.<br>
> > <br>
> > David<br>
> Thank you for doing that test.<br>
> <br>
> This indicates the problem is somewhere in ffmpeg rather than mythtv code. I<br>
> don't know what the trigger is, interlaced video or mpeg2 video, but it does<br>
> not affect 480 interlaced mpeg2 video.<br>
<br>
I have a few channels using 1080i and h.264 encoding.  It happens with<br>
recordings from them as well.</blockquote><div dir="auto"><br></div><div dir="auto">I'm traveling and don't have access to my devices to try this myself, but it sounds like a regression in the copy based decoder. Would be useful to know if the same issue occurs on an Oreo MiBox to narrow down the regression to Oreo itself vs Nvidia.</div><div dir="auto"><br></div><div dir="auto">You can also try setting the ffmpeg loglevel to trace which will show much more detailed info about each output buffer being returned from the decoder. A segv in memcpy is pretty low level so it's unclear if this is something we would be able to fix in ffmpeg ourselves.</div><div dir="auto"><br></div><div dir="auto">Aman</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
Davi<br>
<br>
> The issue of the illegal state exception while fast forwarding is still<br>
> there so I should remove the code that discards frames, as that did not fix<br>
> it consistently.<br>
> <br>
> I will wait a while to see if FFmpeg can give us a fix, before looking into<br>
> it further.<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>