[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.

I always use a news program with scrolling ticker for this testing.
Where is the number of buffers defined?  I'll try a couple of things
(# of buffers and 4k vs. 1080p TV) to see if I can get 1080i to be as
smooth as 720p.

> 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.

You should try more testing.  I had several cases where a 1 hour
ff/rew passed without issue.  The problem is intermittent and
sometimes takes multiple attempts before it happens.

> 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.

Most Linux systems probably have more memory and/or swap space to
better deal with low memory issues.

> 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.

I expect using Surface for rendering instead of OpenGL will fix that.

David
-- 
David Engel
david at istwok.net