After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 757285 - androidmedia: Zerocopy decoding potentially slower than before due to missing queueing
androidmedia: Zerocopy decoding potentially slower than before due to missing...
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Linux
: Normal normal
: 1.7.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Reported: 2015-10-29 08:22 UTC by Sebastian Dröge (slomo)
Modified: 2015-11-17 04:31 UTC
See Also:
GNOME target: ---
GNOME version: ---

Description Sebastian Dröge (slomo) 2015-10-29 08:22:01 UTC
To solve this we should implement handling of OES textures in libgstgl instead of converting inside the decoder. That way we can have multiple textures queued up to allow smooth playback.

For example with my phone currently, decoding is fast enough on average but very bursty. Some frames take twice the time they should, some frames come out of the decoder together at the same time as other frames.
Comment 1 Matthew Waters (ystreet00) 2015-11-17 04:31:10 UTC
commit f2ca0eaf27c54cba7bce3868be07e205f35545b5
Author: Matthew Waters <>
Date:   Tue Nov 3 13:19:41 2015 +1100

    amcviddec: output external-oes textures
    This provides a performance and power usage improvement by removing
    the texture copy from an OES texture to 2D texture.
    The flow is as follows
    1. Generate the output buffer with the required sync meta with the incrementing
       push counter and OES GL memory
    1.1 release_output_buffer (buf, render=true) and push downstream
    2. Downstream waits for on the sync meta (timed wait) or drops the frame (no wait)
    2.1 Timed wait for the frame number to reach the number of frame callbacks fired
    2.2 Unconditionally update the image when the wait completes (success or fail).
        Sets the affine transformation matrix meta on the buffer.
    3. Downstream renders as usual.
    At *some* point through this the on_frame_callback may or may not fire.  If it
    does fire, we can finish waiting early and render. Otherwise we have to
    wait for a timeout to occur which may cause more buffers to be pused into the
    internal GL queue which siginificantly decreases the chances of the
    on_frame_callback to fire again.  This is because the frame callback only occurs
    when the internal GL queue changes state from empty to non-empty.
    Because there is no way to reliably correlate between the number of buffers
    pushed and the number of frame callbacks received, there are a number of
    workarounds in place.
    1. We self-increment the ready counter when it falls behind the push counter
    2. Time based waits as the frame callback may not be fired for a certain frame.
    3. It is assumed that the device can render at speed or performs some QoS of
       the interal GL queue (which may not match the GStreamer QoS).
    It holds that we call SurfaceTexture::updateTexImage for each buffer pushed
    downstream however there's no guarentee that updateTexImage will result in
    the exact next frame (it could skip or duplicate) so synchronization is not
    guaranteed to be accurate although it seems to be close enough to be unable
    to discern visually.  This has not changed from before this patch.  The current
    requirement for synchronization is that updateTexImage is called at the point in
    time when the buffers is to be rendered.

commit fcd0faa0556b045cc32dd6aaebd8ab24a677fb43
Author: Matthew Waters <>
Date:   Tue Nov 10 15:37:05 2015 +1100

    glimagesink: add support for rendering external-oes textures

commit 79f4efb02ada1ab282690859ac8f93b81e1fc4eb
Author: Matthew Waters <>
Date:   Tue Nov 10 14:54:02 2015 +1100

    glviewconvert: add support rectangle/external-oes textures