[mythtv] 20180705 Android Observations

[David Engel]

On Fri, Jul 06, 2018 at 01:50:08PM -0400, Peter Bennett wrote:
> 
> 
> On 07/05/2018 10:54 PM, David Engel wrote:
> > Peter,
> > 
> > Here are my initial observations using your 20180705 patch.
> > 
> > With my Mecool M8S Pro:
> > =======================
> > 
> > Amlogic S912 box running 32-bit Nougat.
> > 
> > Both 720p and 1080i played reasonably well.  Video was slightly
> > stuttery at 1x speed and much more noticeably at any higher speeds.
> > Skips were okay.  Fast forward and rewind were very sluggish causing
> > the actual speed to be well below the intended speed, but otherwise
> > worked.
> > 
> > All 3 jellyfish versions (250 mbps h.264, 250 mbps hevc and 400 mbps
> > hevc) played, but were stuttery and slower than normal speed.
> > 
> > With my Nvidia Shield:
> > ======================
> > 
> > Running 64-bit Oreo.
> > 
> > 720p played mostly great.  Video was smooth at 1x and very good at any
> > speed up to and including 2x.  Skips were very quick.  Fast forward
> > and rewind were very good except I had one case where playback timed
> > out and exited back to watch recordings during one extended rewind.
> > 
> > 1080i played fairly well.  Video was slightly stuttery at 1x and more
> > noticeably at all faster speeds up to and including 2x.  Skips were a
> > little slower than hoped for but still okay.  The main problem with
> > skips was there was almost always a brief flicker of what looked to be
> > a misaligned frame.  Fast forward and rewind were very good except for
> > another playback timeout.  Strangely, fast forward and rewind did not
> > show the same flickering as with skips.
> > 
> > All versions of jellyfish played great when I started playback from a
> > bookmark.  All versions crashed and exited back to the Android home
> > screen when I started playback from the beginning.  That's a strange
> > one.
> > 
> > I'm going to go do some real TV watching with this version now and
> > will report any other problems I see.  Also, I'll be able to do some
> > more detailed testing and collect logs and whatnot this weekend.
> > 
> > David
> The jerkiness is likely due to the reduced buffers. However I did try one
> 1080i recording that has a scrolling row of text and that seems perfectly
> smooth. I find that with a scrolling text it is easy to see if the speed is
> not smooth, jerks are very visible.
> 
> A log when ff or rew has a timeout would be helpful. For the crash on
> jellyfish, running with gdb will give the reason. If the reason is not Kill,
> you can get a back trace. I did FF through an entire 1 hour program
> successfully, so I do not seem to get your timeout situation.

I hate it when results aren't consistent.  I never got the "Video
frame buffering failed too many times" error when I was trying to
catch it.  I only got it when I wasn't logging.  Ugh!

I did catch some probably related errors, though.  Here they are.  All
of these were done with the unmodified, 0705 patch and audio
buffereing set to 300ms.

One quick sidenote is that I captured the logs with "adb logcat
org.mythtv.mythfrontend".  What's strange is that the logcat would
exit when something happened for reasons that I don't understand.
First error?  I don't know.  Should I be running logcat differently?

ffrew-timeout1: I got this when rewinding a 1 hour program at 20x.
Log 1 captured when the rewind hung.  Eventually, the screen went all
black, the position OSD came up and the current position time started
increasing as if the recording was playing back normally.  I think
mythfrontend thought it hit the beginning of the program and started
playing it back normally, but there wasn't any video.

ffrew-timeout2: This is just like case 1 above except I was fast
forwarding and have more logs.  Log 2 is when the hang occurred.  Logs
2a, 2b and 2c are when the fast forward was hung and the video was
still visible.  Log 2d if from when the video went all black and
position OSD was increasingly normally.  Eventually playback exited to
the watch recording screen without any error popup.

rapid-skip3: I got this when rapidly skipping forward 10s at a time.
Log 3 is from when the hang occurred.  Logs 3a, 3b and 3c are from
when playback was hung.  Eventually, the end of recording menu popped
up, but it was totally unresponsive.  I had to force stop
mythfrontend.

The jellyfish issue was also incosistent.  It did eventually crash
form me under gdb.  Everytime, it was due to a SIGKILL, presumably
because the system was out of memory.  Log 1 is from one of them.

> I am wondering what to do about the buffers. There are currently hardcoded
> numbers for each video output method (OpenGL, VDPAU, etc.). It is fine on
> most linux systems to grab 300MB for buffers, but android tends to kill the
> application if it thinks it is using too much memory. I think it will need
> some way of dynamically setting the number of buffers based on things like
> the amount of available memory, framerate, picture size, operating system.

I bumped the number of buffers up a little bit and 1080i at 1x was
very smooth, but any timestretching made it more jerky than it should
be.  I think something in the video display timing doesn't know that
the video is being deinterlaced at 2x.  720p content at 60 fps is as
smooth as it can be at any speed, so 1080i content deinterlaced to 60
fps should be the same.  The only thing that could prevent that is if
the decoder or deinterlacer can just barely do their jobs at 1x with
no extra margin. and don't believe that's the case.

David

> Another thing is there seems to be too much copying of frames from one place
> in memory to another. For multi-megabyte frames that can take a significant
> amount of time on a low end cpu.
> 
> Peter

-- 
David Engel
david at istwok.net