Mailing List Archive

20180705 Android Observations
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
--
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 05, 2018 at 09:54:37PM -0500, David Engel wrote:
> Peter,
>
> Here are my initial observations using your 20180705 patch.
>
> [...]
>
> 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.

I mainly watched 720p content with a tiny bit of 1080 content. I
didn't notice anything specific to either resolution. I did, however,
have a handful of playback tiemouts during fast forwards and alsoin
skips, so there's something still going on there. Except for those
timeouts, the experience was very good.

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 5, 2018 at 8:55 PM David Engel <david@istwok.net> wrote:

> Peter,
>
> Here are my initial observations using your 20180705 patch.
>
> <snip>

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

A little bit of a tangent...

My local CBS and FOX stations are now both on the same transport -- 13.1
(1080i) and 13.2 (720p). In addition, they have added another SD channel
at 13.3. All jammed into 19 mbit. The result is that the quality of those
channels is pathetic to say the least.

When using VDPAU for decoding those mpeg2 stream, I now get lots of
pixelization when watching CBS and some when watching FOX. I have found
that I can get rid of the pixelization if I use VDPAU for the renderer but
Standard for the decoder. ffmpeg seems to be much more tolerant of the
errors than VDPAU.

When using the standard (ffmpeg) decoder, though, I do see "residue" frames
being shown (flickering) when jumping to another position. This does not
happen when using VDPAU for decoding. It sounds like this the same same
thing that David is seeing on the Shield. I figured I would relay this
story just in case it helps to understand the issue.

John
Re: 20180705 Android Observations [ In reply to ]
On Fri, Jul 06, 2018 at 09:17:38AM -0600, John P Poet wrote:
> On Thu, Jul 5, 2018 at 8:55 PM David Engel <david@istwok.net> wrote:
>
> > Peter,
> >
> > Here are my initial observations using your 20180705 patch.
> >
> > <snip>
>
> >
> > 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.
> >
>
> A little bit of a tangent...
>
> My local CBS and FOX stations are now both on the same transport -- 13.1
> (1080i) and 13.2 (720p). In addition, they have added another SD channel
> at 13.3. All jammed into 19 mbit. The result is that the quality of those
> channels is pathetic to say the least.

I've heard of that happening in some places as the number of
frequencies available to TV stations keeps getting encroach upon. I
think ABQ wouldn't have enough stations for it to be a problem. It's
probably a cose savings thing. It still stinks, whatever the reason.

> When using VDPAU for decoding those mpeg2 stream, I now get lots of
> pixelization when watching CBS and some when watching FOX. I have found
> that I can get rid of the pixelization if I use VDPAU for the renderer but
> Standard for the decoder. ffmpeg seems to be much more tolerant of the
> errors than VDPAU.

I've seen that too at various times over the years. My guess has
always been the local station has their encoder either set wrong or
use options that aren't widely/properly supported. Itt's always
gotten fixed after a while. I suspect after enough complaints are
reported.

> When using the standard (ffmpeg) decoder, though, I do see "residue" frames
> being shown (flickering) when jumping to another position. This does not
> happen when using VDPAU for decoding. It sounds like this the same same
> thing that David is seeing on the Shield. I figured I would relay this
> story just in case it helps to understand the issue.

Yes, that sounds exactly like the flickering skip problem I see.

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/06/2018 11:17 AM, John P Poet wrote:
> A little bit of a tangent...
>
> My local CBS and FOX stations are now both on the same transport --
> 13.1 (1080i) and 13.2 (720p).  In addition, they have added another SD
> channel at 13.3.  All jammed into 19 mbit.  The result is that the
> quality of those channels is pathetic to say the least.
>
> When using VDPAU for decoding those mpeg2 stream, I now get lots of
> pixelization when watching CBS and some when watching FOX.  I have
> found that I can get rid of the pixelization if I use VDPAU for the
> renderer but Standard for the decoder.  ffmpeg seems to be much more
> tolerant of the errors than VDPAU.
>
See https://lists.gt.net/mythtv/users/609271#609271

This was the inspiration for 538f99e0a6. Using that new feature I now
have my playback profile set (on the frontends that use VDPAU) so that
they use standard decoding for mpeg2 and VDPAU decoding for other video
formats.

> When using the standard (ffmpeg) decoder, though, I do see "residue"
> frames being shown (flickering) when jumping to another position. 
> This does not happen when using VDPAU for decoding.  It sounds like
> this the same same thing that David is seeing on the Shield.  I
> figured I would relay this story just in case it helps to understand
> the issue.
>
I don't recall seeing that. Maybe it is associated with deinterlacing.
Is it only with recordings from those stations? I actually watch most of
my NBC recordings on a raspberry pi (openmax decoder) and this does not
have the pixellation problem that I see with VDPAU. Do you actually see
a wrong frame displayed?
> John

_______________________________________________
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 06, 2018 at 11:45:40AM -0400, Peter Bennett wrote:
> On 07/06/2018 11:17 AM, John P Poet wrote:
> > A little bit of a tangent...
> >
> > My local CBS and FOX stations are now both on the same transport -- 13.1
> > (1080i) and 13.2 (720p).? In addition, they have added another SD
> > channel at 13.3.? All jammed into 19 mbit.? The result is that the
> > quality of those channels is pathetic to say the least.
> >
> > When using VDPAU for decoding those mpeg2 stream, I now get lots of
> > pixelization when watching CBS and some when watching FOX.? I have found
> > that I can get rid of the pixelization if I use VDPAU for the renderer
> > but Standard for the decoder.? ffmpeg seems to be much more tolerant of
> > the errors than VDPAU.
> >
> See https://lists.gt.net/mythtv/users/609271#609271
>
> This was the inspiration for 538f99e0a6. Using that new feature I now have
> my playback profile set (on the frontends that use VDPAU) so that they use
> standard decoding for mpeg2 and VDPAU decoding for other video formats.
>
> > When using the standard (ffmpeg) decoder, though, I do see "residue"
> > frames being shown (flickering) when jumping to another position.? This
> > does not happen when using VDPAU for decoding.? It sounds like this the
> > same same thing that David is seeing on the Shield.? I figured I would
> > relay this story just in case it helps to understand the issue.
> >
> I don't recall seeing that. Maybe it is associated with deinterlacing. Is it
> only with recordings from those stations? I actually watch most of my NBC
> recordings on a raspberry pi (openmax decoder) and this does not have the
> pixellation problem that I see with VDPAU. Do you actually see a wrong frame
> displayed?

I've only seen it on my Oreo Shield with 1080i content. 720p is fine.
I didn't try 480i, but will try to remember to do it. I did not see
it on my Nougat Mecool.

It looks like part of a seemlingly random frame gets inserted for
about 1/30 or 1/60 of a second. I can take a video of it with my
phone and send it to you if you like.

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 Fri, Jul 6, 2018 at 3:32 PM David Engel <david@istwok.net> wrote:
...
> I've heard of that happening in some places as the number of
> frequencies available to TV stations keeps getting encroach upon. I
> think ABQ wouldn't have enough stations for it to be a problem. It's
> probably a cose savings thing. It still stinks, whatever the reason.

It was an FCC thing (well, partially an FCC thing).
Nexstar acquired some stations, and had to sell
one(?) to get below the FCC ownership restriction
limits in the market. As I recall, the acquirer decided
to move the station to be a Telemundo affiliate (I
believe all of their stations are now spanish mostly),
leaving Fox having to adjust. Nexstar (apparently)
made an agreement to add in a Fox mux.

While some of the regs have recently gone through
some modification, the regs were what the regs
were at the time of the Nexstar acquisitions. Longer
term the entire debate of what (if any) are the
correct market limits in today's media environment
will continue.
_______________________________________________
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/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 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.

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
_______________________________________________
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 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@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/06/2018 03:09 PM, David Engel wrote:
> 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.
Frame Buffers -
libmythtv/videoout_opengl.cpp - VideoOutputOpenGL::CreateBuffers
The normal values - vbuffers.Init(31, true, 1, 12, 4, 2);
In my patch - vbuffers.Init(4, true, 1, 2, 2, 1);

For the meaning of the parameters - videobuffers.cpp - VideoBuffers::Init
see the comments above that method.

This is a temporary fix. Changing it here may not be the eventual
solution because this changes it for every place OpenGL is used. Some
conditional logic may be needed to use different settings for different
cases.

The default value of 31 buffers probably never considered the
possibility of 4K video, and also was probably set up 10 or 15 years ago
for lower powered machines than are currently used. The fact that it
works reasonably well with one eighth of the number of buffers is
interesting.

I suspect that the reason for your jerkiness is that with deinterlacing
the 1080i video becomes 60 fps. Perhaps some logic somewhere that
increases the number of buffers depending on the fps may be useful.

Also significant - Frontend setup - Video - Playback - General Playback
- Audio Read Ahead. this controls buffers on the input side and will
make a difference, especially since changing the number of Frame buffers
affects the video pipeline. Try setting this higher to see if it helps.
I have it set at 300 ms on the shield. Increasing this has less memory
impact than increasing the frame buffers because this is compressed data
that is being buffered.

>
> 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.
Could you describe more fully what you see. You just said "playback
timeouts" during FF.
>> 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.
Swap space - not good. As an experiment I tried playing a 4K video on
raspberry Pi. It immediately started swapping, the hard drive was going
crazy and everything froze. Swapping tends to kill response times.
>> 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.
I need to figure out how to do the surface stuff. It sounds like it
requires creating a new video output method along the lines of VDPAU. (A
lot of work).

I am hoping the OpenGL can give us a good start. It may be possible to
reduce the amount of copying of frames that is being done. I will
investigate that.


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 7/7/2018 6:15 AM, Peter Bennett wrote:
>
>
> On 07/06/2018 03:09 PM, David Engel wrote:
>> 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.
> Frame Buffers -
> libmythtv/videoout_opengl.cpp - VideoOutputOpenGL::CreateBuffers
> The normal values - vbuffers.Init(31, true, 1, 12, 4, 2);
> In my patch - vbuffers.Init(4, true, 1, 2, 2, 1);
>
> For the meaning of the parameters - videobuffers.cpp - VideoBuffers::Init
> see the comments above that method.
>
> This is a temporary fix. Changing it here may not be the eventual
> solution because this changes it for every place OpenGL is used. Some
> conditional logic may be needed to use different settings for
> different cases.
>
> The default value of 31 buffers probably never considered the
> possibility of 4K video, and also was probably set up 10 or 15 years
> ago for lower powered machines than are currently used. The fact that
> it works reasonably well with one eighth of the number of buffers is
> interesting.
>
> I suspect that the reason for your jerkiness is that with
> deinterlacing the 1080i video becomes 60 fps. Perhaps some logic
> somewhere that increases the number of buffers depending on the fps
> may be useful.
>
> Also significant - Frontend setup - Video - Playback - General
> Playback - Audio Read Ahead. this controls buffers on the input side
> and will make a difference, especially since changing the number of
> Frame buffers affects the video pipeline. Try setting this higher to
> see if it helps. I have it set at 300 ms on the shield. Increasing
> this has less memory impact than increasing the frame buffers because
> this is compressed data that is being buffered.
>
>>
>> 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.
> Could you describe more fully what you see. You just said "playback
> timeouts" during FF.
>>> 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.
> Swap space - not good. As an experiment I tried playing a 4K video on
> raspberry Pi. It immediately started swapping, the hard drive was
> going crazy and everything froze. Swapping tends to kill response times.
>>> 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.
> I need to figure out how to do the surface stuff. It sounds like it
> requires creating a new video output method along the lines of VDPAU.
> (A lot of work).
>
> I am hoping the OpenGL can give us a good start. It may be possible to
> reduce the amount of copying of frames that is being done. I will
> investigate that.
I have the start of an android surface framework but it is currently
disabled and doesn't even compile. I can share this if you like (patch).
I stopped looking at it as I got opengl working well enough and it
should be roughly equivalent in performance for rendering purposes.

If we could render a frame directly to opengl video mem, that would be
even better but I dont understand the structure (or opengl) well enough
to even know where to start (yet).

Android qt also has the restriction that you only have 1 gl context that
has to be shared between theme and video and I think that restricts
things quite a bit.

Peter, you mentioned excessive unnecessary copying of frames. It would
be good to anlayse this and optimise this first. I also have a gut
feeling that the memory bandwidth has a big impact on performance e.g.
DDR3 box vs DDR4. It would be nice to get a memory audit on the whole
application. I suspect themes are also a big memory hog.
It could be s/w decoding would work for 4k with less frame duplication.

Also if there is something else gl could do algo-wise I have a bit of an
understanding of gl code now having mucked around with it a bit.

Mark
_______________________________________________
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 06, 2018 at 04:15:29PM -0400, Peter Bennett wrote:
>
>
> On 07/06/2018 03:09 PM, David Engel wrote:
> > 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.
> Frame Buffers -
> libmythtv/videoout_opengl.cpp - VideoOutputOpenGL::CreateBuffers
> The normal values - vbuffers.Init(31, true, 1, 12, 4, 2);
> In my patch - vbuffers.Init(4, true, 1, 2, 2, 1);
>
> For the meaning of the parameters - videobuffers.cpp - VideoBuffers::Init
> see the comments above that method.

Thanks. I will do some testing with various values this weekend.

> This is a temporary fix. Changing it here may not be the eventual solution
> because this changes it for every place OpenGL is used. Some conditional
> logic may be needed to use different settings for different cases.
>
> The default value of 31 buffers probably never considered the possibility of
> 4K video, and also was probably set up 10 or 15 years ago for lower powered
> machines than are currently used. The fact that it works reasonably well
> with one eighth of the number of buffers is interesting.
>
> I suspect that the reason for your jerkiness is that with deinterlacing the
> 1080i video becomes 60 fps. Perhaps some logic somewhere that increases the
> number of buffers depending on the fps may be useful.
>
> Also significant - Frontend setup - Video - Playback - General Playback -
> Audio Read Ahead. this controls buffers on the input side and will make a
> difference, especially since changing the number of Frame buffers affects
> the video pipeline. Try setting this higher to see if it helps. I have it
> set at 300 ms on the shield. Increasing this has less memory impact than
> increasing the frame buffers because this is compressed data that is being
> buffered.

Increasing this to 300 helped quite a bit on my 1080p TV, though, any
timestretching above 1x made it jerky again. It helped some on my 4k
TV. It fluctuated between short periods of smoothness and jerkyness.

> > 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.
> Could you describe more fully what you see. You just said "playback
> timeouts" during FF.

Easy. Playback hangs and is unresponsive for about 40 seconds.
Eventually, the watch recordings screen reappears with a popup stating
that "Video frame buffering failed too many times."

> > > 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.
> Swap space - not good. As an experiment I tried playing a 4K video on
> raspberry Pi. It immediately started swapping, the hard drive was going
> crazy and everything froze. Swapping tends to kill response times.

That wasn't a suggestion to use swap. It was merely an explanation
why desktop or HTPC Linux can cope betteer when RAM is tight. In
those cases, most anything that is not MythTV can be swapped out to
make room for MythTV when it is run. Granted, Android can suspend
apps, but I don't know the details of what it actually does.

> > > 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.
> I need to figure out how to do the surface stuff. It sounds like it requires
> creating a new video output method along the lines of VDPAU. (A lot of
> work).

My understanding is that VDPAU has custom code to render the OSD. If
that's correct, a Surface video output method should be simpler. I
believe the only new code would be to render just the video surfaces.
The OSD would still be rendered with OpenGL.

> I am hoping the OpenGL can give us a good start. It may be possible to
> reduce the amount of copying of frames that is being done. I will
> investigate that.

OpenGL rendering was definitely the best, first step as it didn't
require any, well, probably not much, new, rendering code. There's a
reason, though, that all of the other players have Surface rendering
as therir first and default choice. That is the output of the decoder
can be used directly without any additional copying and conversion.

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/06/2018 09:13 PM, David Engel wrote:
> Increasing this to 300 helped quite a bit on my 1080p TV, though, any
> timestretching above 1x made it jerky again. It helped some on my 4k
> TV. It fluctuated between short periods of smoothness and jerkyness.
You can try increasing it more, for example try 2000.

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 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@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 Sat, Jul 07, 2018 at 12:46:30PM -0400, Peter Bennett wrote:
>
>
> On 07/06/2018 09:13 PM, David Engel wrote:
> > Increasing this to 300 helped quite a bit on my 1080p TV, though, any
> > timestretching above 1x made it jerky again. It helped some on my 4k
> > TV. It fluctuated between short periods of smoothness and jerkyness.
> You can try increasing it more, for example try 2000.

Going that high didn't seem to make much difference.

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/08/2018 03:15 PM, David Engel wrote:
> 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

Please share with me what you found to be the best buffer values. For
the meantime I should add them to the patch with an #ifdef for android.
Then I can work on timestretch with those buffer values.

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 Tue, Jul 10, 2018 at 01:58:09PM -0400, Peter Bennett wrote:
> On 07/08/2018 03:15 PM, David Engel wrote:
> > 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
>
> Please share with me what you found to be the best buffer values. For the
> meantime I should add them to the patch with an #ifdef for android.
> Then I can work on timestretch with those buffer values.

I don't have the best values yet. Bumping them by roughly 50 to 100%
(vbuffers.Init(8, true, 1, 4, 3, 2)) got the 1x playback smooth, but
didn't make any difference at speeds greater than 1x. I've since
changed course and want to try to get the >1x playback smooth first.
To do that, I reset the buffer values back to original and captured
some playback logs at 1x and 1.5x for 720p and 1080i yesterday. I
still need to analyze those logs.

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/10/2018 02:31 PM, David Engel wrote:
> On Tue, Jul 10, 2018 at 01:58:09PM -0400, Peter Bennett wrote:
>> On 07/08/2018 03:15 PM, David Engel wrote:
>>> 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
>>
>> Please share with me what you found to be the best buffer values. For the
>> meantime I should add them to the patch with an #ifdef for android.
>> Then I can work on timestretch with those buffer values.
> I don't have the best values yet. Bumping them by roughly 50 to 100%
> (vbuffers.Init(8, true, 1, 4, 3, 2)) got the 1x playback smooth, but
> didn't make any difference at speeds greater than 1x. I've since
> changed course and want to try to get the >1x playback smooth first.
> To do that, I reset the buffer values back to original and captured
> some playback logs at 1x and 1.5x for 720p and 1080i yesterday. I
> still need to analyze those logs.
>
> David
Look at the new patch. I don't know if it will help with the time
stretch, but maybe, since I fixed a time calculation. The FF is still
problematic but at least hopefully does not fail any more. See the
comments in the ticket.

I did not actually get to look at your logs yet, so maybe I will still
be able to fix it better once i have seen them.

Jury duty tomorrow so not much will get done until that is over.

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 Tue, Jul 10, 2018 at 05:46:43PM -0400, Peter Bennett wrote:
> On 07/10/2018 02:31 PM, David Engel wrote:
> > On Tue, Jul 10, 2018 at 01:58:09PM -0400, Peter Bennett wrote:
> > > On 07/08/2018 03:15 PM, David Engel wrote:
> > > > 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
> > >
> > > Please share with me what you found to be the best buffer values. For the
> > > meantime I should add them to the patch with an #ifdef for android.
> > > Then I can work on timestretch with those buffer values.
> > I don't have the best values yet. Bumping them by roughly 50 to 100%
> > (vbuffers.Init(8, true, 1, 4, 3, 2)) got the 1x playback smooth, but
> > didn't make any difference at speeds greater than 1x. I've since
> > changed course and want to try to get the >1x playback smooth first.
> > To do that, I reset the buffer values back to original and captured
> > some playback logs at 1x and 1.5x for 720p and 1080i yesterday. I
> > still need to analyze those logs.
> >
> > David
> Look at the new patch. I don't know if it will help with the time stretch,
> but maybe, since I fixed a time calculation. The FF is still problematic but
> at least hopefully does not fail any more. See the comments in the ticket.

I just noticed the new patch. I'm building now.

> I did not actually get to look at your logs yet, so maybe I will still be
> able to fix it better once i have seen them.
>
> Jury duty tomorrow so not much will get done until that is over.

I had it 6 weeks ago, but didn't get picked.

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/08/2018 03:15 PM, David Engel wrote:
> 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.
>
By the way, I did get the logs in the email, so you didn't need to do
the google share.

Jury duty over - there was no case so we got sent home after hanging
around for 3 hours.

The timeouts are all the same original issue - IllegalStateException.

I tried all manner of ways to avoid the error in our code, but it seems
to fire randomly during fast forward or skip.

My latest patch (yesterday) fixes it with a sledge hammer and is
certainly not optimal.

I suppose I need to dig into the FFmpeg source code and figure out the 
IllegalStateException and find the correct FFmpeg fix.

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 Wed, Jul 11, 2018 at 02:33:13PM -0400, Peter Bennett wrote:
> On 07/08/2018 03:15 PM, David Engel wrote:
> > 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.
> >
> By the way, I did get the logs in the email, so you didn't need to do the
> google share.

Okay. I'll delete them. I guess it was just the one to the list that
got held up.

> Jury duty over - there was no case so we got sent home after hanging around
> for 3 hours.
>
> The timeouts are all the same original issue - IllegalStateException.
>
> I tried all manner of ways to avoid the error in our code, but it seems to
> fire randomly during fast forward or skip.
>
> My latest patch (yesterday) fixes it with a sledge hammer and is certainly
> not optimal.

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.

> I suppose I need to dig into the FFmpeg source code and figure out the?
> IllegalStateException and find the correct FFmpeg fix.

FYI, this might be related.
https://forums.geforce.com/default/topic/1056259/shield-tv/shield-experience-upgrade-7-0/post/5834167/#5834167
. Kodi doesn't use ffmpeg (AFAIK) for MediaCodec. I don't know about
Plex.

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/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.
> FYI, this might be related.
> https://forums.geforce.com/default/topic/1056259/shield-tv/shield-experience-upgrade-7-0/post/5834167/#5834167
> . Kodi doesn't use ffmpeg (AFAIK) for MediaCodec. I don't know about
> Plex.

Perhaps I need to report this to NVidia

Peter
Re: 20180705 Android Observations [ In reply to ]
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?

Aman


> FYI, this might be related.https://forums.geforce.com/default/topic/1056259/shield-tv/shield-experience-upgrade-7-0/post/5834167/#5834167
> . Kodi doesn't use ffmpeg (AFAIK) for MediaCodec. I don't know about
> Plex.
>
>
> Perhaps I need to report this to NVidia
>
>
> Peter
>
Re: 20180705 Android Observations [ In reply to ]
On Thu, Jul 12, 2018 at 03:39:03PM -0400, Peter Bennett 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).

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.

> > > 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.
> > FYI, this might be related.
> > https://forums.geforce.com/default/topic/1056259/shield-tv/shield-experience-upgrade-7-0/post/5834167/#5834167
> > . Kodi doesn't use ffmpeg (AFAIK) for MediaCodec. I don't know about
> > Plex.
>
> Perhaps I need to report this to NVidia

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.

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

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

1 2  View All