[Bug 761611] Android (hardware accelerated) playback doesn't recover well if decoding gets too late (pile up of frame drop)

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=761611

--- Comment #9 from Matthew Waters (ystreet00) <ystreet00 at gmail.com> ---
There are no missed callbacks missing around the time of the stutter.

$ cat ~/tmp/log | awk '{$1=$3=$4=$5=$6=$8=$9=""; print $0}' | grep -e
unsuccessfully
23:23:54.497 0:00:16.875213622 gl_sync 0xaed566b0 unsuccessfully waited for
frame 3
23:23:54.500 0:00:16.878204346 gl_sync 0xaed566e0 unsuccessfully waited for
frame 4
23:23:54.503 0:00:16.880859375 gl_sync 0xaed56650 unsuccessfully waited for
frame 5

And

$ cat ~/tmp/log | awk '{$1=$3=$4=$5=$6=$8=$9=""; print $0}' | grep -e
on_frame_available
23:23:54.498 0:00:16.876800536 gl_sync 0xaed566e0 possible 'on_frame_available'
listener miss detected, attempting to work around. Jumping forward 0 frames for
frame 4
23:23:54.502 0:00:16.880004883 gl_sync 0xaed56650 possible 'on_frame_available'
listener miss detected, attempting to work around. Jumping forward 0 frames for
frame 5

And

$ cat ~/tmp/log | awk '{$1=$3=$4=$5=$6=$8=$9=""; print $0}' | grep -e "frame 3
available"
23:23:54.499 0:00:16.877746582 frame 3 available
$ cat ~/tmp/log | awk '{$1=$3=$4=$5=$6=$8=$9=""; print $0}' | grep -e "frame 4
available"
23:23:54.502 0:00:16.880645752 frame 4 available
$ cat ~/tmp/log | awk '{$1=$3=$4=$5=$6=$8=$9=""; print $0}' | grep -e "frame 5
available"
23:23:54.504 0:00:16.882720947 frame 5 available

So the missed frames do turn up a couple of ms later.

Further investigation into the timing of the frames reveals that after the
start of the jerkiness, the timings of the input/output of the frames takes a
few (3-5) ms longer which I believe puts you over your frame budget of 20ms. 
As amcvideodec doesn't drop frames before decoding, if decoding suddenly takes
3-5ms longer, we will never be able to catch up.  I'm not exactly sure where or
why this occurs or who/what's suddenly taking the extra time but there's
nothing wrong with the amcvideodec GL frame handling (which involves the
listener).

The slowdown could be any number of things:
1. Power management downclocking CPU/GPU/decoder
2. A stream change causes a different, more expensive code path to be used
"somewhere"
3. Hardware is incapable of keeping up with your stream.
(1440×1280×50)÷(1920×1080×30) = 1.481481481 which means you're pushing ~50%
more bytes per second through than the more thoroughly tested 1080p at 30 video
streams.

Unfortunately, this all requires careful deduction of all parameters to
determine what the problem is which is unavailable without your exact setup.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.