<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
So, if I get this right, then the decoder would check if downstream
supports this caps feature. If so, it sets the caps to format=RGBA
and feature=gluploadmeta. Internally, the buffer holds I420 data,
but the Vivante direct texture based upload code will then
transparently convert to RGBA. So far so good.<br>
<br>
But what if there is a branch downstream, for example because of a
tee element, and one element supports this caps feature, the other
doesn't?<br>
<br>
<div class="moz-cite-prefix">Am 2015-09-04 um 17:08 schrieb Nicolas
Dufresne:<br>
</div>
<blockquote cite="mid:1441379301.30997.2.camel@collabora.com"
type="cite">
<pre wrap="">Le vendredi 04 septembre 2015 à 16:02 +0200, Carlos Rafael Giani a
écrit :
</pre>
<blockquote type="cite">
<pre wrap="">Well the main problem was that the Vivante stuff can implicitely do
color space conversion, transparently exposing YUV textures as RGB(A)
ones to OpenGL ES shaders, and this is not possible with this meta,
since you cannot specify two caps (the input format - typically some
YUV format - and the format that the glimagesink textures - some RGB
format).
</pre>
</blockquote>
<pre wrap="">
That's something you can negotiate. This is the same thing with VAAPI
btw. Use a caps feature "meta:GLUpload" and if you have this feature,
set format=RGBA. Same as gtreamer-vaapi here.
Nicolas</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
gstreamer-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a>
<a class="moz-txt-link-freetext" href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a>
</pre>
</blockquote>
<br>
</body>
</html>