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

[Loïc Molinari]

Hello,

2005/7/18, Emmanuel Raulo <raulo at tamaris.tm.fr>:
> It seems to me that all decent OpenGL drivers nowadays support
> non-power-of-two (NPOT) textures through the
> GL_ARB_texture_non_power_of_two extension (now part of GL 1.5 AFAIK)
> which just extends existing texturing-related functions to NPOT textures
> as well and adds no extra functions.

I don't know this extension, and unfortunately, I can't test it since my
graphical card is too old :(
But I'm interested in performance benchs between this solution and the
gstvideoscale plugin. 

2005/7/18, Maciej Katafiasz <ml at mathrick.org>:
> Dnia 18-07-2005, pon o godzinie 18:15 +0200, Loïc Molinari napisał:
> > The problem is that I need to know width and height of the stream
> > before the instanciation of the sink, and I do not find how to do that
> > ! I tried to get caps of the elements of the decodebin element when
> > the new-decoded-pad signal fired, but I could not.
> 
> Why do you need that? Isn't negotiation phase enough for you?

2005/7/19, Ronald S. Bultje <rbultje at ronald.bitfreak.net>:
> On Mon, 2005-07-18 at 18:15, Loïc Molinari wrote:
> > I am writing a little piece of software aimed to display video streams
> > on OpenGL textures. Like the GStreamer manual advices, I choose to
> > write my own sink element instead of using the fakesink way. My
> > class_init takes two readable properties, the width and the height.
> > OpenGL needs pow2 values, so I put width and height to the pow2 upper
> > values in the sink.
> >
> > Here is my pipeline :
> > gnomevfssrc <-> decodebin <-> ffmpegcolorspace <-> videoscale <-> mysink
> >
> > The problem is that I need to know width and height of the stream
> > before the instanciation of the sink
> 
> Why? We have a negotiation phase to decide on this whole thing.
> 
> > I tried to get caps of the elements of the decodebin element when
> > the new-decoded-pad signal fired, but I could not.
> 
> Read up on how negotiation works (or could've worked :) ) in the
> documentation on our website.
> 
> > Is adding a new property telling width and height destination values
> > in the videoscale element a good idea ?
> 
> No. Read up on filtered caps while you're at it, too. It'll do what you
> want. See e.g. gst_element_link_pads_filtered(),
> gst_element_link_filtered() or gst_pad_link_filtered().

I read up on how negotiation phase work in the Plugin Writer's Guide, take a
look at the API Reference and read some simple plugins implementation in
the gst-plugins tarball. It magically became more clear.
So I use filtered caps to implement the stuff like that :

GstCaps *pot_filtered_caps = NULL;

const gchar *str_pot_filtered_caps =
  "video/x-raw-rgb, "							\
  "bpp = (int) 24, "							\
  "depth = (int) 24, "							\
  "endianness = (int) BIG_ENDIAN, "					\
  "red_mask = (int) 0x00FF0000, "					\
  "green_mask = (int) 0x0000FF00, "					\
  "blue_mask  = (int) 0x000000FF, "					\
  "width = (int) { 16, 32, 64, 128, 256, 512, 1024, 2048 }, "	\
  "height = (int) { 16, 32, 64, 128, 256, 512, 1024, 2048 }, "	\
  "framerate  = (double) [ 0, max ]";

[...]

pot_filtered_caps = gst_caps_from_string (str_pot_filtered_caps);
gst_element_link_filtered (scaler, GST_ELEMENT (mysink), pot_filtered_caps);

The caps negotiation phase successes and the stream takes place correctly in
the OpenGL textures ! Thanks devs.

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.
Is it possible ?

    Loïc.

--
Loïc Molinari <loic.molinari at gmail.com>