[Bug 757285] androidmedia: Zerocopy decoding potentially slower than before due to missing queueing
GStreamer (GNOME Bugzilla)
bugzilla at gnome.org
Mon Nov 16 20:31:10 PST 2015
https://bugzilla.gnome.org/show_bug.cgi?id=757285
Matthew Waters <ystreet00 at gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
Target Milestone|git master |1.7.1
--- Comment #1 from Matthew Waters <ystreet00 at gmail.com> ---
commit f2ca0eaf27c54cba7bce3868be07e205f35545b5
Author: Matthew Waters <matthew at centricular.com>
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.
https://bugzilla.gnome.org/show_bug.cgi?id=757285
commit fcd0faa0556b045cc32dd6aaebd8ab24a677fb43
Author: Matthew Waters <matthew at centricular.com>
Date: Tue Nov 10 15:37:05 2015 +1100
glimagesink: add support for rendering external-oes textures
https://bugzilla.gnome.org/show_bug.cgi?id=757285
commit 79f4efb02ada1ab282690859ac8f93b81e1fc4eb
Author: Matthew Waters <matthew at centricular.com>
Date: Tue Nov 10 14:54:02 2015 +1100
glviewconvert: add support rectangle/external-oes textures
https://bugzilla.gnome.org/show_bug.cgi?id=757285
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
More information about the gstreamer-bugs
mailing list