[mythtv] Seg Fault in mediacodec

Aman Gupta aman at tmm1.net
Thu Jul 5 20:49:50 UTC 2018

On Thu, Jul 5, 2018 at 4:04 PM Peter Bennett <pb.mythtv at gmail.com> wrote:

> On 07/05/2018 01:08 PM, David Engel wrote:
> I reduced the number of buffers so that it displays a couple of frames
> before crashing. I see a fat green line along the bottom. I suspect that it
> is trying to use a frame size of 1920x1088 instead of 1920x1080 (see the
> trace I sent, it shows slice-height 1088). I plan to step through the ffmpeg
> code and see if perhaps it is copying 8 rows more than it should. I don't
> know what the slice-height refers to, but it looks suspicious.
> It may be that the problem is associated with 1080 rows. Of the resolutions
> I have tried, only 1080 is not divisible by 16. I have tried 480, 720, 2160
> - all work without seg fault.
> You could be on to something.  The a/v side of things is not an area
> with which I'm intimately familier, however, I vaguely recall various
> issues with 1080 vs. 1088 popping up in the past.  Where's Mike Dean
> when we need him? :)
> It turns out that is in fact the cause of the crash. The second plane in
> the buffer follows on immediately after 1080 lines of the first plane, but
> the code assumes it is after 1088 lines of the first plane, based on
> slice_height. Is slice_height supposed to tell the height of the plane? It
> crashes on copying data for the second plane when it hits the actual end of
> the data and starts accessing addresses beyond that.
> This is the patch that fixes it. Instead of using slice_height here, use
> height. I suspect that this may cause a failure in Nougat or other systems
> if they do in fact have a gap between planes.
> --- a/mythtv/external/FFmpeg/libavcodec/mediacodec_sw_buffer.c
> +++ b/mythtv/external/FFmpeg/libavcodec/mediacodec_sw_buffer.c
> @@ -150,7 +150,8 @@ void
> ff_mediacodec_sw_buffer_copy_yuv420_semi_planar(AVCodecContext *avctx,
>          } else if (i == 1) {
>              height = avctx->height / 2;
> -            src += s->slice_height * s->stride;
> +            src += s->height * s->stride;
>              src += s->crop_top * s->stride;
>              src += s->crop_left;
>          }
> Aman - please let me know if this is the correct fix and if you can
> incorporate it into FFmpeg.

I'm not very familiar with the s/w decoding code paths. I believe this part
of the code came from gstreamer so it might be useful to see what (if
anything) they've done to deal with Oreo.

If this breaks Nougat then obviously it cannot be committed as-is.

IIRC slice_height is supposed to return the size of the buffer so I'm
pretty sure the correct thing to do here is to continue using slice_height.
It's possible that adding the crop values on top is what's causing the
buffer overflow- maybe those weren't set before Oreo?


> Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-dev/attachments/20180705/c4bcdf04/attachment.html>

More information about the mythtv-dev mailing list