[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