[gst-devel] Re: Getting width and height before sink instanciation

Emmanuel Raulo raulo at tamaris.tm.fr
Fri Jul 22 07:37:22 CEST 2005


Hello

Loïc Molinari a écrit :

>  "width = (int) { 16, 32, 64, 128, 256, 512, 1024, 2048 }, "	\
>  "height = (int) { 16, 32, 64, 128, 256, 512, 1024, 2048 }, "	\
>
>[...]
>
>Now that it works for me, I just have a question about the behaviour of the
>negotiation. I can remark GStreamer chooses the nearest size in the list, for
>example if the stream size is 720x480, the size in my sink will be 512x512.
>How should I do in order to make GStreamer chooses the upper size ?
>In the case of the previous example the size in my sink would be 1024x512.
>
Well, rather than accepting only power-of-two resolutions, I suggest you 
accept any resolution up to the maximum supported texture size (can't 
remember how exactly to query that but it's possible with glGetIntegerv) 
and only blit the portion of the texture that you use by clamping 
texture coordinates (eg image_width/texture_width for max S coord, etc.).
I can send you some GL code showing how to do that if you like.
In my understanding, using GL for output is interesting because GL can 
perform the back and scalar operations in HW. If you get a scaler 
element to rescale the image for the sole purpose of using a whole 
texture, you lose that optimization.

When possible it would also be nice using GL-accelerated YUV->RGB 
transformation, 'cause doing it by CPU (as ffmpegcolorspace does) is too 
hard for small machines (like mine ;)) but might be accelerated by the 
video card (like mine again ;)). That would need an extension but you 
could check for its presence and run different code wheither YUV 
textures are supported or not (look for GL_MESA_ycbcr_texture 
<http://oss.sgi.com/projects/ogl-sample/registry/MESA/ycbcr_texture.txt> 
and GL_SGIX_ycrcb 
<http://oss.sgi.com/projects/ogl-sample/registry/SGIX/ycrcb.txt>).

Cheers

--
Emmanuel




More information about the gstreamer-devel mailing list