Mailing List Archive

1 2  View All
Re: 20180705 Android Observations [ In reply to ]
On Thu, Jul 12, 2018 at 04:13:07PM -0400, Lennart Sorensen wrote:
> On Thu, Jul 12, 2018 at 02:56:16PM -0500, David Engel wrote:
> > It was using timestretch at 1.5x. It didn't happen last night. I did
> > see multiple, but not too many, short pauses, as you described. They
> > were annoying, but certainly not as annoying as exiting playback
> > altogether. I later tried some talking heads shows at 1.8x
> > timestretch, but I couldn't take the jitter.
> >
> > Yes, it shouldn't hurt. Hopefully, they will take interest. Our
> > timestretch and fast forward/rewind use is definitely more of a
> > torture test than with any other player of which I'm aware.
>
> All this talk of mythtv on android got me curious, so I just tried doing
> a build to see how it would be on my Sony TV, but since (I believe)
> it runs 32 bit, I had to build for that, and those 32 bit large file
> support bugs hit and that seems just not fixable. Trying to go to API
> 24 that supposedly fixes that problem causes other things to not work.
>
> Oh well, I guess the sony TV is probably too ram limited anyhow to run
> the frontend.
>
> I think the readme file might as well state building for 32 bit is broken
> for now. Would have saved some time.

What doesn't work for you? I have a 32-bit, Anroid box on which I do
some very, basic testing. I haven't noticed anything not working.

David
--
David Engel
david@istwok.net
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: 20180705 Android Observations [ In reply to ]
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
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: 20180705 Android Observations [ In reply to ]
On Thu, Jul 12, 2018 at 12:42:40PM -0700, Aman Gupta wrote:
> On Thu, Jul 12, 2018 at 12:39 PM Peter Bennett <pb.mythtv@gmail.com> wrote:
> > On 07/11/2018 03:16 PM, David Engel wrote:
> > I tried using yesterday's patch to watch the World Cup last night and
> > some other stuff. I had to abandon that when playback got very
> > stuttery and I didn't have time to debug. I suspect your sledge
> > hammer was getting used repeatedly. I tried again later and it
> > happened again and then went away. It didn't happen on my other
> > shield, but I didn't test with it much.
> >
> > Was this in normal playback, time stretch or fast forward? AFAIK the
> > IllegalStateException that the sledge hammer handles only happens in fast
> > forward or occasionally in skip/jump. (i.e. when flush is used).
> >
> > I suppose I need to dig into the FFmpeg source code and figure out the
> > IllegalStateException and find the correct FFmpeg fix.
> >
> > According to mediacodec documentation, IllegalStateException only happens
> > on dequeue output if the decoder is not executing or it is in asynchronous
> > mode.
> >
> > It is not in asynchronous mode or dequeue output would never work.
> >
> > The ways it can stop executing are if you call "stop" or "reset" or
> > "release" it. In ffmpeg there is a "stop" routine but it is never called,
> > and there is no reset routine. It seems that there is no way to get into a
> > non-executing state. Prehaps it is in an error state. Unfortunately there
> > is no native API that will tell you the state.
> >
> > It seems that this may be a bug in mediacodec on the shield. I don't know
> > how much I should do to try and work around it. I have tried reordering
> > calls and adding a stop and start after the flush, but nothing has helped.
> >
>
> FWIW I am not able to reproduce this issue with mpv-android. Are you maybe
> calling ffmpeg APIs from different native threads?

I was not able to reproduce the problem using rapid skips on a 720p
sample with mpv-android. I did see some occasional short pauses,
though. I don't know if those were due to I/O stalls or decoder
resets like Peter now does when he sees the IllegalStateExceptions.
As noted earlier, mpv-android crashes on 1080i content like MythTV did
before Peter put in a fix for 1088 rows, so I couldn't test that

BTW, when is mediacodec being used, when HW or SW showing in the OSD?
I tried both. I've always found those types of interfaces confusing.
Is what's shown the current state or what will be switched to if it's
clicked.

Also, I didn't see any way to test fast forward/rewind with
mpv-android. Is there a way? What about any other apps? I've yet to
see any other apps which try to do as good of a job with ff/rew as
MythTV.

David
--
David Engel
david@istwok.net
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: 20180705 Android Observations [ In reply to ]
On Thu, Jul 12, 2018 at 04:35:21PM -0500, David Engel wrote:
> On Thu, Jul 12, 2018 at 04:13:07PM -0400, Lennart Sorensen wrote:
> > On Thu, Jul 12, 2018 at 02:56:16PM -0500, David Engel wrote:
> > > It was using timestretch at 1.5x. It didn't happen last night. I did
> > > see multiple, but not too many, short pauses, as you described. They
> > > were annoying, but certainly not as annoying as exiting playback
> > > altogether. I later tried some talking heads shows at 1.8x
> > > timestretch, but I couldn't take the jitter.
> > >
> > > Yes, it shouldn't hurt. Hopefully, they will take interest. Our
> > > timestretch and fast forward/rewind use is definitely more of a
> > > torture test than with any other player of which I'm aware.
> >
> > All this talk of mythtv on android got me curious, so I just tried doing
> > a build to see how it would be on my Sony TV, but since (I believe)
> > it runs 32 bit, I had to build for that, and those 32 bit large file
> > support bugs hit and that seems just not fixable. Trying to go to API
> > 24 that supposedly fixes that problem causes other things to not work.
> >
> > Oh well, I guess the sony TV is probably too ram limited anyhow to run
> > the frontend.
> >
> > I think the readme file might as well state building for 32 bit is broken
> > for now. Would have saved some time.
>
> What doesn't work for you? I have a 32-bit, Anroid box on which I do
> some very, basic testing. I haven't noticed anything not working.

Get an error about undefined ::fgetpos in freesurround.cpp which from what
I found is due to using android API less than 24 and _FILE_OFFSET_BITS=64

Following the readme uses API 21.

This is where the build ends:

In file included from freesurround.cpp:20:0:
/home/lsorense/android/android-ndk/sources/cxx-stl/gnu-libstdc++/4.9/include/cstdio:107:11: error: '::fgetpos' has not been declared
using ::fgetpos;
^
/home/lsorense/android/android-ndk/sources/cxx-stl/gnu-libstdc++/4.9/include/cstdio:117:11: error: '::fsetpos' has not been declared
using ::fsetpos;
^
In file included from threadedfilewriter.cpp:2:0:
/home/lsorense/android/android-ndk/sources/cxx-stl/gnu-libstdc++/4.9/include/cstdio:107:11: error: '::fgetpos' has not been declared
using ::fgetpos;
^
/home/lsorense/android/android-ndk/sources/cxx-stl/gnu-libstdc++/4.9/include/cstdio:117:11: error: '::fsetpos' has not been declared
using ::fsetpos;
^
In file included from /home/lsorense/android/android-ndk/sources/cxx-stl/gnu-libstdc++/4.9/include/fstream:41:0,
from mythcommandlineparser.cpp:45:
/home/lsorense/android/android-ndk/sources/cxx-stl/gnu-libstdc++/4.9/include/cstdio:107:11: error: '::fgetpos' has not been declared
using ::fgetpos;
^
/home/lsorense/android/android-ndk/sources/cxx-stl/gnu-libstdc++/4.9/include/cstdio:117:11: error: '::fsetpos' has not been declared
using ::fsetpos;
^
freesurround.cpp: In member function 'uint FreeSurround::putFrames(void*, uint, uint)':
freesurround.cpp:173:65: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
if ((surround_mode != SurroundModePassive) && (ic+numFrames > bs))
^
freesurround.cpp:185:35: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
for (i = 0; i < numFrames && ic < bs; i++,ic++)
^
freesurround.cpp:195:32: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
for (i=0; i<numFrames; i++)
^
freesurround.cpp:207:35: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
for (i = 0; i < numFrames && ic < bs; i++,ic++)
^
freesurround.cpp:221:35: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
for (i = 0; i < numFrames && ic < bs; i++,ic++)
^
freesurround.cpp:234:32: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
for (i=0; i<numFrames; i++)
^
freesurround.cpp:246:27: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
for (i = 0; i < numFrames && ic < bs; i++,ic++)
^
freesurround.cpp:265:27: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
for (i = 0; i < numFrames && ic < bs; i++,ic++)
^
make[2]: *** [Makefile:767: obj/freesurround.o] Error 1
make[2]: Leaving directory '/work/lsorense/myth-android/packaging/android/build/mythtv/libs/libmythfreesurround'
make[1]: *** [Makefile:54: sub-libmythfreesurround-make_first] Error 2
make[1]: *** Waiting for unfinished jobs....
make[2]: *** [Makefile:8119: obj/threadedfilewriter.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: *** [Makefile:6626: obj/mythcommandlineparser.o] Error 1
make[2]: Leaving directory '/work/lsorense/myth-android/packaging/android/build/mythtv/libs/libmythbase'
make[1]: *** [Makefile:79: sub-libmythbase-make_first] Error 2
make[1]: Leaving directory '/work/lsorense/myth-android/packaging/android/build/mythtv/libs'
make: *** [Makefile:68: libs] Error 2A

--
Len Sorensen
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: 20180705 Android Observations [ In reply to ]
On Fri, Jul 13, 2018 at 10:55:49AM -0400, Lennart Sorensen wrote:
> On Thu, Jul 12, 2018 at 04:35:21PM -0500, David Engel wrote:
> > On Thu, Jul 12, 2018 at 04:13:07PM -0400, Lennart Sorensen wrote:
> > > On Thu, Jul 12, 2018 at 02:56:16PM -0500, David Engel wrote:
> > > > It was using timestretch at 1.5x. It didn't happen last night. I did
> > > > see multiple, but not too many, short pauses, as you described. They
> > > > were annoying, but certainly not as annoying as exiting playback
> > > > altogether. I later tried some talking heads shows at 1.8x
> > > > timestretch, but I couldn't take the jitter.
> > > >
> > > > Yes, it shouldn't hurt. Hopefully, they will take interest. Our
> > > > timestretch and fast forward/rewind use is definitely more of a
> > > > torture test than with any other player of which I'm aware.
> > >
> > > All this talk of mythtv on android got me curious, so I just tried doing
> > > a build to see how it would be on my Sony TV, but since (I believe)
> > > it runs 32 bit, I had to build for that, and those 32 bit large file
> > > support bugs hit and that seems just not fixable. Trying to go to API
> > > 24 that supposedly fixes that problem causes other things to not work.
> > >
> > > Oh well, I guess the sony TV is probably too ram limited anyhow to run
> > > the frontend.
> > >
> > > I think the readme file might as well state building for 32 bit is broken
> > > for now. Would have saved some time.
> >
> > What doesn't work for you? I have a 32-bit, Anroid box on which I do
> > some very, basic testing. I haven't noticed anything not working.
>
> Get an error about undefined ::fgetpos in freesurround.cpp which from what
> I found is due to using android API less than 24 and _FILE_OFFSET_BITS=64
>
> Following the readme uses API 21.
>
> This is where the build ends:
>
> In file included from freesurround.cpp:20:0:
> /home/lsorense/android/android-ndk/sources/cxx-stl/gnu-libstdc++/4.9/include/cstdio:107:11: error: '::fgetpos' has not been declared
> using ::fgetpos;
> ^
> [...]

Oh, you meant build error. I thought you meant a run-time error.
Yes, that's a known issue. Use the the 13b NDK for 32-bit builds.
That needs to be added to the README.

David
--
David Engel
david@istwok.net
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: 20180705 Android Observations [ In reply to ]
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 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


_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: 20180705 Android Observations [ In reply to ]
On Fri, Jul 13, 2018 at 2:31 PM Peter Bennett <pb.mythtv@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.

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
>
>
>
Re: 20180705 Android Observations [ In reply to ]
On 07/13/2018 05:35 PM, Aman Gupta wrote:
>
> On Fri, Jul 13, 2018 at 2:31 PM Peter Bennett <pb.mythtv@gmail.com
> <mailto:pb.mythtv@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

1 2  View All