[mythtv] 20180705 Android Observations

[Peter Bennett]

On 07/13/2018 05:35 PM, Aman Gupta wrote:
>
> On Fri, Jul 13, 2018 at 2:31 PM Peter Bennett <pb.mythtv at gmail.com 
> <mailto:pb.mythtv at gmail.com>> wrote:
>
>
>
>     On 07/12/2018 05:43 PM, Peter Bennett wrote:
>     >
>     >
>     > On 07/12/2018 03:42 PM, Aman Gupta wrote:
>     >> FWIW I am not able to reproduce this issue with mpv-android.
>     Are you
>     >> maybe calling ffmpeg APIs from different native threads?
>     >>
>     >> Aman
>     >>
>     > We have a decoder thread. All ffmpeg calls should be done from
>     there.
>     > I looked at it and it looks correct. For a next step I will add
>     some
>     > logging to make sure all the calls are coming from the same thread.
>     >
>     > Peter
>     I added logging of the calls and confirmed that all of the send,
>     receive
>     and flush calls are on the same thread.
>
>     This is what I see from the more detailed logging.
>     The IllegalStateException came from a receive_frame. The sequence is
>
>     flush
>     receive frame returns EAGAIN
>     send packet
>     receive frame returns EAGAIN
>     send packet
>     REPEAT receive and send until receive frame returns data.
>     After about 15 packets have been sent the next send packet returns
>     EAGAIN and receive_frame returns EAGAIN. It tries receive_frame again
>     and gets the IllegalStateException and the return code of Generic
>     error
>     in an external library. Any further operations including flush
>     continue
>     to get IllegalStateException and return Generic error in an external
>     library.
>
>     This seems bogus. If the flush caused an illegal state it should be
>     reported on the first send of data after the flush. But it is happy
>     receiving 15 packets before suddenly deciding it is in an illegal
>     state.
>
>     In the cases where flush works (95% of the time it works
>     correctly), the
>     above sequence also occurs, but after send and receive both return
>     EAGAIN, the next receive_frame returns a frame correctly, as do
>     subsequent receive_frame calls.
>
>     I also saw one case of the following error from flush:
>
>     [amediacodec @ 0x205ceea118] android.media.MediaCodec$CodecException:
>     Error 0xffffffe0
>     [mpeg2_mediacodec @ 0x205ced1378] Failed to flush codec
>     This was followed by the IllegalStateException on the very next
>     receive_frame.
>
>
> 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.
>
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.
> Aman
>
>
>
>     This occurred when we did the flush and sent a bunch of packets as
>     above. Before getting to the point of send and receive both returning
>     EAGAIN, we started a new flush and got this error.
>
>     Peter
>
>
I thought of submitting a question or bug report to NVidia.

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 
(https://devtalk.nvidia.com/default/board/158/shield-development/)

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.

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.

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