[Bug 697112] Revamp GstSurfaceMeta

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Wed Apr 10 02:48:41 PDT 2013


https://bugzilla.gnome.org/show_bug.cgi?id=697112
  GStreamer | gst-plugins-base | git

--- Comment #5 from Sebastian Dröge <slomo at circular-chaos.org> 2013-04-10 09:48:36 UTC ---
So what we would have in the end would be support for RGBA, RGB with one
texture, NV12/NV21 with one texture (custom texture format that needs to be
just copied and not touched by shaders) and with two textures (that need to be
converted to RGBA via shaders if there's no special YUV support), I420/etc with
one texture (custom texture format that needs to be just copied and not touched
by shaders) and with three textures (that need to be converted to RGBA via
shaders if there's no special YUV support)

As what can be produced depends on the "provider" of the GLTextureUploadMeta
(i.e. the decoder):
a) We need to negotiate the format with the caps, e.g. select I420
b) Inside the meta we would store the exact format or at least the number of
textures 1 vs. 2 or 3
c) The user of the meta would know the format from that caps and the exact
representation from the meta, and would need to handle 1 and 2 (or 3) textures
properly.

Is there any other possible texture representation for the formats, other than
1 texture (independent of number of planes and just needs to be copied) and 1
texture per plane (where each plane contains one of RGB, RGB, Y, U, V or UV)?

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- 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