[mythtv] Seg Fault in mediacodec

[Aman Gupta]

On Tue, Jul 3, 2018 at 10:37 AM Peter Bennett <pb.mythtv at gmail.com> wrote:

>
>
> On 07/02/2018 09:38 PM, David Engel wrote:
> > On Mon, Jul 02, 2018 at 05:14:52PM -0400, Aman Gupta wrote:
> >> On Mon, Jul 2, 2018 at 3:58 PM Peter Bennett <pb.mythtv at gmail.com>
> wrote:
> >>> Hi Aman
> >>>
> >>> Thank you for all your help so far.
> >>>
> >>> I upgraded my Shield to Android 8.0. Now I get a seg fault every time I
> >>> play 1080 interlaced recordings. Progressive recordings are fine, and
> >>> 480 interlaced are fine. Also 4K recordings are fine. With 1080
> >>> interlaced it gets a seg fault in avcodec_receive_frame. This happens
> at
> >>> about the fifth frame received in the video. It starts off fine, with
> >>> avcodec_receive_frame returning EAGAIN until some number of packets
> have
> >>> been sent, then it receives a few frames, then there is a seg fault in
> >>> memcpy. There are no null addresses being passed to memcpy, but
> >>> something must be invalid. This was working fine with Android 7. I am
> >>> using the default buffer allocation: AVCodecContext->get_buffer2 =
> >>> get_avf_buffer. avcodec_receive_frame should allocate the buffers using
> >>> that routine so they should be valid.
> >>>
> >>> [backtrace snipped]
> >>>
> >> You can try the mpv-android apk from GitHub to compare. I'm pretty sure
> it
> >> works fine on Oreo.
> > mpv-android almost always crashes for me after a split second on 1080i
> > content.  When it doesn't crash, it just exits playback, also after a
> > split second.  720p content works fine, just like with MythTV.
> >
> > David
> Thank you for doing that test.
>
> This indicates the problem is somewhere in ffmpeg rather than mythtv
> code. I don't know what the trigger is, interlaced video or mpeg2 video,
> but it does not affect 480 interlaced mpeg2 video.
>
> The issue of the illegal state exception while fast forwarding is still
> there so I should remove the code that discards frames, as that did not
> fix it consistently.


You could try setting the delay_flush option on the decoder to see if it
makes any difference.

Aman


>
> I will wait a while to see if FFmpeg can give us a fix, before looking
> into it further.
>
> Peter
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-dev/attachments/20180704/7ee53612/attachment.html>