<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/13/2018 05:35 PM, Aman Gupta
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAK=uwuypc7ZvdvMZZZX7YE0O68U3VUpUqoXEsbUmykrQeYxeaw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<div><br>
<div class="gmail_quote">
<div dir="ltr">On Fri, Jul 13, 2018 at 2:31 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"><br>
<br>
On 07/12/2018 05:43 PM, Peter Bennett wrote:<br>
><br>
><br>
> On 07/12/2018 03:42 PM, Aman Gupta wrote:<br>
>> FWIW I am not able to reproduce this issue with
mpv-android. Are you <br>
>> maybe calling ffmpeg APIs from different native
threads?<br>
>><br>
>> Aman<br>
>><br>
> We have a decoder thread. All ffmpeg calls should be
done from there. <br>
> I looked at it and it looks correct. For a next step I
will add some <br>
> logging to make sure all the calls are coming from the
same thread.<br>
><br>
> Peter<br>
I added logging of the calls and confirmed that all of the
send, receive <br>
and flush calls are on the same thread.<br>
<br>
This is what I see from the more detailed logging.<br>
The IllegalStateException came from a receive_frame. The
sequence is<br>
<br>
flush<br>
receive frame returns EAGAIN<br>
send packet<br>
receive frame returns EAGAIN<br>
send packet<br>
REPEAT receive and send until receive frame returns data.<br>
After about 15 packets have been sent the next send packet
returns <br>
EAGAIN and receive_frame returns EAGAIN. It tries
receive_frame again <br>
and gets the IllegalStateException and the return code of
Generic error <br>
in an external library. Any further operations including
flush continue <br>
to get IllegalStateException and return Generic error in an
external <br>
library.<br>
<br>
This seems bogus. If the flush caused an illegal state it
should be <br>
reported on the first send of data after the flush. But it
is happy <br>
receiving 15 packets before suddenly deciding it is in an
illegal state.<br>
<br>
In the cases where flush works (95% of the time it works
correctly), the <br>
above sequence also occurs, but after send and receive both
return <br>
EAGAIN, the next receive_frame returns a frame correctly, as
do <br>
subsequent receive_frame calls.<br>
<br>
I also saw one case of the following error from flush:<br>
<br>
[amediacodec @ 0x205ceea118]
android.media.MediaCodec$CodecException: <br>
Error 0xffffffe0<br>
[mpeg2_mediacodec @ 0x205ced1378] Failed to flush codec<br>
This was followed by the IllegalStateException on the very
next <br>
receive_frame.</blockquote>
<div dir="auto"><br>
</div>
<div dir="auto">This CodecException is what we need to get to
the bottom of. The MediaCodec docs say you can expect them
to happen, and details how to get more information and check
the type of exception (transient, recoverable) and how to
deal with each type when it is received.</div>
<div dir="auto"><br>
</div>
</div>
</div>
</blockquote>
I have only seen that CodecException once. Most of the time the
error happens without that. You are checking for exceptions on every
call, so we would see if that was happening.<br>
<blockquote type="cite"
cite="mid:CAK=uwuypc7ZvdvMZZZX7YE0O68U3VUpUqoXEsbUmykrQeYxeaw@mail.gmail.com">
<div>
<div class="gmail_quote">
<div dir="auto">Aman</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
This occurred when we did the flush and sent a bunch of
packets as <br>
above. Before getting to the point of send and receive both
returning <br>
EAGAIN, we started a new flush and got this error.<br>
<br>
Peter<br>
<br>
<br>
</blockquote>
</div>
</div>
</blockquote>
I thought of submitting a question or bug report to NVidia. <br>
<br>
I see the developer's forum at NVidia is not very active. There are
questions that have been unanswered for months. In fact I cannot see
a post that has been answered, except by the original poster either
having solved it himself or asking if he will get a reply
(<a class="moz-txt-link-freetext" href="https://devtalk.nvidia.com/default/board/158/shield-development/">https://devtalk.nvidia.com/default/board/158/shield-development/</a>)<br>
<br>
I don't really have much information for submitting a bug report.
They will want to know the calls being made to the underlying
mediacodec api.<br>
<br>
I think maybe a different approach is needed. For FF or REW
processing, we have to send around 15 packets to mediacodec to get a
response. It is decoding 15 frames in order to give back one. It
seems that mediacodec is designed as a pipeline for maximum
efficiency of decoding a stream of frames. One at a a time does not
really work well. Reverting to software decoding for FF and REW may
perform better, because you should be able to decode one or two
packets in order to get one frame back. Skip, Jump, and time stretch
would have to continue using mediacodec.<br>
<br>
Peter<br>
</body>
</html>