<div dir="ltr">Hi Peter,<div><br></div><div>I've been working on trying to reproduce this issue. It looks like it never happens when using Surface based zero-copy rendering.</div><div><br></div><div>When copying frame data, I can reproduce after flushing rapidly. Looking at logcat, I see that the entire mediacodec decoder appears to be crashing:</div><div><br></div><div><div>A/DEBUG: *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***</div><div> Build fingerprint: 'NVIDIA/foster_e/foster:8.0.0/OPR6.170623.010/3019194_1174.8512:user/release-keys'</div><div> Revision: '0'</div><div> ABI: 'arm'</div><div> pid: 431, tid: 27041, name: media.codec >>> android.hardwar <<<</div><div> signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x10</div><div> Cause: null pointer dereference</div><div>A/DEBUG: r0 4a22f810 r1 00000010 r2 00000220 r3 00000030</div><div> r4 4a203240 r5 4e7ed000 r6 4e7ee18c r7 4a22f800</div><div> r8 00000000 r9 00000002 sl 00030d40 fp 5246a91c</div><div> ip 80000000 sp 5246a868 lr 4cf455d1 pc 4936be9c cpsr a00f0010</div><div>A/DEBUG: backtrace:</div><div> #00 pc 00018e9c /system/lib/libc.so (memcpy+124)</div><div> #01 pc 0000b5cd /vendor/lib/libnvmmlite_video.so</div><div> #02 pc 0000aaab /vendor/lib/libnvmmlite_video.so</div><div> #03 pc 0000636c /vendor/lib/libnvos.so</div><div> #04 pc 0004831f /system/lib/libc.so (_ZL15__pthread_startPv+22)</div><div> #05 pc 0001b4df /system/lib/libc.so (__start_thread+32)</div><div>E//system/bin/tombstoned: Tombstone written to: /data/tombstones//tombstone_03</div><div>E/ACodec: OMX/mediaserver died, signalling error!</div><div> signalError(omxError 0x8000100d, internalError -32)</div><div>I/ServiceManager: service 'media.codec' died</div><div>E/MediaCodec: Codec reported err 0xffffffe0, actionCode 0, while in state 7</div><div>E/NdkMediaCodec: sf error code: -32</div><div>E/ffmpeg: [ffmpeg/video] h264_mediacodec: Failed to flush codec</div></div><div><br></div><div>Are you seeing anything like this in the logs?</div><div><br></div><div>Aman</div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Jul 2, 2018 at 1:06 PM Peter Bennett <<a href="mailto:pb.mythtv@gmail.com">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">Hi Aman<br>
<br>
This workaround that I sent you (see below) is not successful. On <br>
Android 8 I am getting illegal state exceptions with FF with 720p <br>
recordings, with the workaround in place.<br>
<br>
Peter<br>
<br>
<br>
On 06/29/2018 05:40 PM, Peter Bennett wrote:<br>
> The method dequeueOutputBuffer can throw IllegalStateException. <br>
> According to the MediaCodec documentation that means it is not in the <br>
> Executing state, or codec is configured in asynchronous mode. I don't <br>
> have enough understanding of how it works to know why that would be.<br>
><br>
> I believe that this may only happen with 1080i interlaced video.<br>
><br>
> The situation only occurs if you send several packets until there are <br>
> frames available, then receive only one frame from the codec context <br>
> and then flush, expecting to lose any remaining frames. Doing this <br>
> sequence repeatedly causes the error after about 10 or 15 times. <br>
> Somehow those available frames are not being correctly flushed. By <br>
> adding my own code to discard those frames I avoid the problem.<br>
><br>
> Add this code before avcodec_flush_buffers:<br>
><br>
> int ret = 0;<br>
> while (ret == 0)<br>
> {<br>
> AVFrame *frame = av_frame_alloc();<br>
> ret = avcodec_receive_frame(enc, frame);<br>
> av_frame_free(&frame);<br>
> }<br>
><br>
> No More exceptions!!<br>
><br>
> It should not be necessary to receive all available frames and discard <br>
> them like this before flushing. Perhaps something like this code <br>
> snippet should be added to avcodec_flush_buffers.<br>
><br>
> Please let me know if you make any change in ffmpeg to solve this <br>
> issue so that I can remove this piece of code.<br>
><br>
> Peter<br>
><br>
<br>
</blockquote></div>