[Bug 761014] File can't be played with hardware acceleration in Android gstreamer tutorial 5

[GStreamer (GNOME Bugzilla)]

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

--- Comment #61 from Matthew Waters (ystreet00) <ystreet00 at gmail.com> ---
Those messages are because the mediacodec api and implementation is extremely
suboptimal and means we're essentially performing time-based waits for the next
frame as we don't receive a listener callback (for some reason, could honestly
be anything causing this).  The wait is capped at 30ms after the release of the
buffer which plus some processing time gives approximately 30fps which is the
recommended encoding framerate according to
http://developer.android.com/guide/appendix/media-formats.html.  After
rendering, the next frame is released in an attempt to keep the rendering
smooth. If you're attempting to play a 50fps video and you keep missing
listerners, the video will degrade.  Combined with the caps processing overhead
(between 50-80ms here) as above taking multiple frames, you have a recipe for
disaster performance wise.

On my phone I never get a frame listener miss with stream-* (the "could not
wait" message) however I do with the local-* files (presumably due to the
redundant caps processing).

You can add more debugging of the listener with *amc*:7 which will tell you
what happened and when with regards to the listener.

To get the 1.5 behaviour of amcvideocodec, you need to perform the capsfilter
pipeline above (playbin video-sink="capsfilter caps=video/x-raw ! glimagesink")
which removes the zerocopy path from the decoder and all these waits will
disappear.  However, you're bottleneck is now probably the texture uploads to
glimagesink.

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