<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 07/05/2018 04:58 PM, Peter Bennett
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:6507ab74-9ccc-42ad-a498-5d8c540bed8a@gmail.com">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 07/05/2018 04:49 PM, Aman Gupta
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAK=uwuyWZp7NMNy3w5cjdMMa987x3L3E4LxCgKtEArKzQeSNvw@mail.gmail.com">
<div><br>
<div class="gmail_quote">
<div dir="ltr">On Thu, Jul 5, 2018 at 4:04 PM Peter Bennett
<<a href="mailto:pb.mythtv@gmail.com"
moz-do-not-send="true">pb.mythtv@gmail.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<p><br>
</p>
<br>
<div class="m_679149163732860208moz-cite-prefix">On
07/05/2018 01:08 PM, David Engel wrote:<br>
</div>
<blockquote type="cite">
<blockquote type="cite" style="color:#000000">
<pre>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.
</pre>
</blockquote>
<pre>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? <span class="m_679149163732860208moz-smiley-s1" title=":)"><span>:)</span></span>
</pre>
</blockquote>
</div>
<div text="#000000" bgcolor="#FFFFFF"> 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.<br>
<br>
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.<br>
<br>
---
a/mythtv/external/FFmpeg/libavcodec/mediacodec_sw_buffer.c<br>
+++
b/mythtv/external/FFmpeg/libavcodec/mediacodec_sw_buffer.c<br>
@@ -150,7 +150,8 @@ void
ff_mediacodec_sw_buffer_copy_yuv420_semi_planar(AVCodecContext
*avctx,<br>
} else if (i == 1) {<br>
height = avctx->height / 2;<br>
<br>
- src += s->slice_height * s->stride;<br>
+ src += s->height * s->stride;<br>
src += s->crop_top * s->stride;<br>
src += s->crop_left;<br>
}<br>
<br>
Aman - please let me know if this is the correct fix and
if you can incorporate it into FFmpeg.</div>
</blockquote>
<div dir="auto"><br>
</div>
<div dir="auto">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.</div>
<div dir="auto"><br>
</div>
<div dir="auto">If this breaks Nougat then obviously it
cannot be committed as-is.</div>
<div dir="auto"><br>
</div>
<div dir="auto">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?</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">
<div text="#000000" bgcolor="#FFFFFF"><br>
<br>
Peter<br>
</div>
</blockquote>
</div>
</div>
</blockquote>
<br>
Here is the output from explore on my Oreo system when it got the
seg fault. You can see that crop_left is zero so leaving that out
will not help. It seems to me that this may be a bug in Oreo or
the Shield version of it.<br>
<br>
The value of '*s' is of type 'MediaCodecDecContext' which is a
typedef of type 'struct MediaCodecDecContext'<br>
The value of '*s' is a struct/class of type 'struct
MediaCodecDecContext' with the following fields:<br>
<br>
avctx = <Enter 0 to explore this field of type
'AVCodecContext *'><br>
refcount = 1 .. (Value of type 'atomic_int')<br>
hw_buffer_count = 0 .. (Value of type 'atomic_int')<br>
codec_name = <Enter 3 to explore this field of type
'char *'><br>
codec = <Enter 4 to explore this field of type
'FFAMediaCodec *'><br>
format = <Enter 5 to explore this field of type
'FFAMediaFormat *'><br>
surface = <Enter 6 to explore this field of type
'void *'><br>
started = 0 .. (Value of type 'int')<br>
draining = 0 .. (Value of type 'int')<br>
flushing = 0 .. (Value of type 'int')<br>
eos = 0 .. (Value of type 'int')<br>
width = 1920 .. (Value of type 'int')<br>
height = 1080 .. (Value of type 'int')<br>
stride = 1920 .. (Value of type 'int')<br>
slice_height = 1088 .. (Value of type 'int')<br>
color_format = 21 .. (Value of type 'int')<br>
crop_top = 0 .. (Value of type 'int')<br>
crop_bottom = 1079 .. (Value of type 'int')<br>
crop_left = 0 .. (Value of type 'int')<br>
crop_right = 1919 .. (Value of type 'int')<br>
display_width = 1920 .. (Value of type 'int')<br>
display_height = 1080 .. (Value of type 'int')<br>
output_buffer_count = <Enter 22 to explore this field of
type 'uint64_t'><br>
current_input_buffer = <Enter 23 to explore this field of
type 'ssize_t'><br>
delay_flush = false .. (Value of type '_Bool')<br>
serial = 1 .. (Value of type 'atomic_int')<br>
<br>
<br>
</blockquote>
Aman <br>
<br>
You could check the size of the buffer received. This is the trace
log message - <br>
<br>
[mpeg2_mediacodec @ 0x2afc77f378] Got output buffer 7 offset=0
size=3110400 ts=53009921316 flags=0<br>
<br>
Buffer size of 3110400 is equal to 1920*1080 + 1920 * 540.<br>
<br>
If you use the slice_height you access 1920 * 1088 + 1920 * 540 =
3125760 bytes which is more than the buffer size. <br>
<br>
Using the buffer size you can tell whether height or slice_height
should be used.<br>
<br>
Peter<br>
</body>
</html>