[gst-devel] 1:n, n:1 element event handling

[Stefan Kost <ensonic@ho...>]

hi,

I recently changed collectpads NEWSEGEMNT behaviour for newsegment
events to forward them instead of swallowing them. Without this change
adder was eating these events, thus they never reached the sink.

Tim pointed out that this might not the correct fix, as we ideally want
collect the newsegment-events and send one unified event instead. [1]

I looked over our source (basically did a search for
gst_pad_set_event_function() and looked at muxer/demux elements). I
found some FIXME comments :)

Below is my current analysis. I welcome comments and ideas :)

Stefan

[1] http://bugzilla.gnome.org/show_bug.cgi?id=340060



                                        Demux             Mux
                        UP DOWN     Sink     Src      Sink    Src
GST_EVENT_FLUSH_START    x    x     .        .        .       spread
GST_EVENT_FLUSH_STOP     x    x     .        .        .       spread
GST_EVENT_EOS            -    x     .        .        collect -
GST_EVENT_NEWSEGMENT     -    x     .        .        merge   -
GST_EVENT_TAG            -    x     .        .        .       -
GST_EVENT_BUFFERSIZE     -    x     .        .        .       -
GST_EVENT_QOS            x    -     spread   -        -       spread
GST_EVENT_SEEK           x    -     spread   -        -       spread
GST_EVENT_NAVIGATION     x    -     spread   -        -       spread
GST_EVENT_DRAIN          ?

use gst_pad_set_event_function() to set a custom event function

= Operations =

spread:
send a copy of the event to all opposite pads

collect:
wait until the event came on all pads, then emit and clear flags

merge:
somehow merge multiple equal events (same events should be send just
once). we can remember the last newsegment event for each pad. if we
have received some events, when can we know that a new merged newsegment
should be generated and sent out?

= Changes =
collectspads:
* collect for eos, merge for newsegment

Re: [gst-devel] Problem selecting input on tuner with v4l2src

[Fredrik Persson <frepe@br...>]

I think this question is irrelevant and "wrong", please look at my email with 
subject "About using the tuner interface in python" instead.

Sorry about spamming like this.

/Fredrik

On Sunday 30 April 2006 21:14, Fredrik Persson wrote:
> Hi!
>
> I'm writing a small Python app where I use a Pinnacle USB tuner with
> v4l2src. The hardware have three different inputs; "Television",
> "Composite1" and "S-video". I found those using the command "v4l-info".
> That gave me this output:
>
> /.../
> channels
>     VIDIOCGCHAN(0)
>         channel                 : 0
>         name                    : "Television"
>         tuners                  : 1
>         flags                   : 0x1 [TUNER]
>         type                    : TV
>         norm                    : 0
>     VIDIOCGCHAN(1)
>         channel                 : 1
>         name                    : "Composite1"
>         tuners                  : 0
>         flags                   : 0x0 []
>         type                    : CAMERA
>         norm                    : 0
>     VIDIOCGCHAN(2)
>         channel                 : 2
>         name                    : "S-Video"
>         tuners                  : 0
>         flags                   : 0x0 []
>         type                    : CAMERA
>         norm                    : 0
> /.../
>
> "gst-inspect v4l2src" gives me this:
>
> /.../
>   input               : input/output (channel) to switch to
>                         flags: readable, writable
>                         String. Default: null Current: null
>   frequency           : frequency to tune to (in Hz)
>                         flags: readable, writable
>                         Unsigned Long. Range: 0 - 18446744073709551615
> Default: 0 Current: 0
> /.../
>
> So I assumed that "input" corresponds to the three input methods described
> above.
>
> This is what I did in python:
>
> source = gst.element_factory_make("v4l2src",name="Pinnacle PCTV USB2.0")
> source.set_property("input","Composite1")
>
> ... and then I build a pipeline using that source element. This does not
> work, I don't get the signal from the composite input. (And I know it's
> there, because when I run xawtv and select "Composite1", I can see the
> video stream.)
>
> So my question is; how do I make it so that the v4l2src element properly
> tells the v4l2 driver to select the composite (or S-video) input? (In
> python, preferably.)
>
> Thank you in advance!
>
> /Fredrik Persson

[gst-devel] About using the tuner interface in python

[Fredrik Persson <frepe@br...>]

Hi!

If programming in c, it seems that I can get a cast from source element to 
tuner like this: 

tuner = GST_TUNER (video_source);

This seems to be needed in order to use the list_channels, get_channel and 
set_channel methods that selects inputs (composite, S-video and so on) on 
capture cards.

Does anyone know what the equivalent would be in python? At first I thought 
that these methods could be used on a v4l2src element like so:

source = gst.element_factory_make("v4l2src",name="Pinnacle PCTV USB2.0")
print source.get_channel()

This does not work. I get the following error message when running that:

(mypythontest.py:21507): GStreamer-CRITICAL **: gst_implements_interface_cast: 
assertion `gst_element_implements_interface (GST_ELEMENT (from), iface_type)' 
failed
Segmentation fault

So my question is, how do I select the composite input on my capture card 
using gstreamer and python?

Thank you!

/Fredrik Persson

[gst-devel] Problem selecting input on tuner with v4l2src

[Fredrik Persson <frepe@br...>]

Hi!

I'm writing a small Python app where I use a Pinnacle USB tuner with v4l2src. 
The hardware have three different inputs; "Television", "Composite1" 
and "S-video". I found those using the command "v4l-info". That gave me this 
output:

/.../
channels
    VIDIOCGCHAN(0)
        channel                 : 0
        name                    : "Television"
        tuners                  : 1
        flags                   : 0x1 [TUNER]
        type                    : TV
        norm                    : 0
    VIDIOCGCHAN(1)
        channel                 : 1
        name                    : "Composite1"
        tuners                  : 0
        flags                   : 0x0 []
        type                    : CAMERA
        norm                    : 0
    VIDIOCGCHAN(2)
        channel                 : 2
        name                    : "S-Video"
        tuners                  : 0
        flags                   : 0x0 []
        type                    : CAMERA
        norm                    : 0
/.../

"gst-inspect v4l2src" gives me this:

/.../
  input               : input/output (channel) to switch to
                        flags: readable, writable
                        String. Default: null Current: null
  frequency           : frequency to tune to (in Hz)
                        flags: readable, writable
                        Unsigned Long. Range: 0 - 18446744073709551615 
Default: 0 Current: 0
/.../

So I assumed that "input" corresponds to the three input methods described 
above. 

This is what I did in python:

source = gst.element_factory_make("v4l2src",name="Pinnacle PCTV USB2.0")
source.set_property("input","Composite1")

... and then I build a pipeline using that source element. This does not work, 
I don't get the signal from the composite input. (And I know it's there, 
because when I run xawtv and select "Composite1", I can see the video 
stream.)

So my question is; how do I make it so that the v4l2src element properly tells 
the v4l2 driver to select the composite (or S-video) input? (In python, 
preferably.)

Thank you in advance!

/Fredrik Persson

[gst-devel] cesarmfpinto@gmail.com

[<cesarmfpinto@gm...>]

cesarmfpinto@...

Re: [gst-devel] core and GLib

[Edward Hervey <bilboed@gm...>]

Hi,

  I'd also be in favour of dropping the hacks we have in gst-python
for supporting glib < 2.8, and bumping up the requirement to
glib/pygtk >=3D 2.8.

  Everyone ok with that ?

  Edward

On 4/6/06, Thomas Vander Stichele <thomas@...> wrote:
> Hi all,
>
> we discussed this before, and my thoughts have changed on the matter and
> I want to bring it up again.
>
> We've had various reports from people switching between GLib 2.6 and 2.8
> while upgrading, or people installing a 2.8 compiled version of GST on a
> 2.6 glib version, and more fun things.
>
> While in theory I still feel we should have supported 2.6 correctly, in
> practice we haven't, and we shouldn't lie to people pretending that we
> do.
>
> Therefore I propose that after the next core release, we require GLib
> 2.8 and remove the compatibility hacks through the stack.
>
> What do you all think ?
>
> Thomas
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting langua=
ge
> that extends applications into web and mobile media. Attend the live webc=
ast
> and join the prime developer group breaking into this new coding territor=
y!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&dat=
=3D121642
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel@...
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>


--
Edward Hervey
Junior developer / Fluendo S.L.
http://www.pitivi.org/

Re: [gst-devel] internal data stream error

[Stefan Kost <ensonic@ho...>]

Hi Thomas,

+1 to use the generic message. For the user there is nothing to do
anyway and for the developer it just mean, fire up gdb and prepend
GST_DEBUG="*:5" to see whats going on :)

Stefan

Am Samstag, den 29.04.2006, 00:02 +0200 schrieb Thomas Vander Stichele:
> We have a lot of locations where we use a string to say the equivalent
> of "internal data flow error".
> 
> Looking at this snippet of .po file makes me feel a little silly:
> 
> #: plugins/elements/gstqueue.c:781
> msgid "Internal data flow error."
> msgstr "Interne fout met gegevensdoorvoer."
> 
> #: libs/gst/base/gstbasesink.c:1849
> msgid "Internal data flow problem."
> msgstr "Intern probleem met gegevensdoorvoer."
> 
> #: libs/gst/base/gstbasesink.c:1980
> #, fuzzy
> msgid "Internal data stream error."
> msgstr "Interne fout met gegevensdoorvoer."
> 
> So, two questions:
> 
> - do we want to add a STREAM error for this ? If so, what should it be
> called ? Personally, I think this should just be the generic FAILED,
> with the generic message it already has as default: GStreamer
> encountered a general stream error.
> 
> I fail to see how "Internal data flow/stream error/problem" is more
> descriptive anyway.
> 
> Comments welcome,
> Thomas
> 
> 
> 
> 
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel@...
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

Re: [gst-devel] Re: [gst-cvs] ensonic gstreamer: gstreamer/ gstreamer/gst/ gstreamer/plugins/elements/

[Stefan Kost <ensonic@ho...>]

hi tim,

oh yes, this was found by the coverty checker. Mike and I fixed the same
issues. I've changed it back. Still this looks confusing, as with this
way we kindof know that if(!typefind->store) we need to do the
GST_ELEMENT_ERROR anyway. I reflowed the section to make it a bit more
obvious.

Stefan

Am Freitag, den 28.04.2006, 20:46 +0100 schrieb Tim Müller:
> On Fri, 2006-04-28 at 18:55 +0000, Stefan Kost wrote:
> 
> Hi Stefan,
> 
> > Log message:
> > * plugins/elements/gsttypefindelement.c:
> > (gst_type_find_element_handle_event):
> > make GstElementDetails const
> 
>   ...
> 
> > diff -u -d -r1.78 -r1.79
> > --- gsttypefindelement.c	28 Apr 2006 13:43:03 -0000	1.78
> > +++ gsttypefindelement.c	28 Apr 2006 18:55:17 -0000	1.79
> > @@ -63,7 +63,7 @@
> >  GST_DEBUG_CATEGORY_STATIC (gst_type_find_element_debug);
> >  #define GST_CAT_DEFAULT gst_type_find_element_debug
> > -static GstElementDetails gst_type_find_element_details =
> > +static const GstElementDetails gst_type_find_element_details =
> >  GST_ELEMENT_DETAILS ("TypeFind",
> >      "Finds the media type of a stream",
> > @@ -476,16 +476,17 @@
> >            if (typefind->store) {
> >              caps = gst_type_find_helper_for_buffer (GST_OBJECT (typefind),
> >                  typefind->store, &prob);
> > -          }
> > -          if (caps && prob >= typefind->min_probability) {
> > -            g_signal_emit (typefind, gst_type_find_element_signals[HAVE_TYPE],
> > -                0, prob, caps);
> > -          } else {
> > -            GST_ELEMENT_ERROR (typefind, STREAM, TYPE_NOT_FOUND,
> > -                (NULL), (NULL));
> > +            if (caps && prob >= typefind->min_probability) {
> > +              g_signal_emit (typefind, gst_type_find_element_signals[HAVE_TYPE],
> > +                  0, prob, caps);
> > +            } else {
> > +              GST_ELEMENT_ERROR (typefind, STREAM, TYPE_NOT_FOUND,
> > +                  (NULL), (NULL));
> > +            }
> > +            gst_caps_replace (&caps, NULL);
> >            }
> > -          gst_caps_replace (&caps, NULL);
> >            stop_typefinding (typefind);
> >            res = gst_pad_event_default (pad, event);
> >            break;
> > 
> 
> The last change isn't mentioned in the ChangeLog - did you really mean
> to commit that?
> 
> (I hope not, because it doesn't seem entirely correct, as with it
> typefind won't throw a TYPE_NOT_FOUND error message any longer when an
> EOS is received but no data has been received so far. Mike has already
> fixed the issue of initializing caps to NULL here earlier in case your
> fix was supposed to be for the same issue).
> 
> Cheers
>  -Tim
> 
> 
> 
> 
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel@...
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[gst-devel] internal data stream error

[Thomas Vander Stichele <thomas@ap...>]

We have a lot of locations where we use a string to say the equivalent
of "internal data flow error".

Looking at this snippet of .po file makes me feel a little silly:

#: plugins/elements/gstqueue.c:781
msgid "Internal data flow error."
msgstr "Interne fout met gegevensdoorvoer."

#: libs/gst/base/gstbasesink.c:1849
msgid "Internal data flow problem."
msgstr "Intern probleem met gegevensdoorvoer."

#: libs/gst/base/gstbasesink.c:1980
#, fuzzy
msgid "Internal data stream error."
msgstr "Interne fout met gegevensdoorvoer."

So, two questions:

- do we want to add a STREAM error for this ? If so, what should it be
called ? Personally, I think this should just be the generic FAILED,
with the generic message it already has as default: GStreamer
encountered a general stream error.

I fail to see how "Internal data flow/stream error/problem" is more
descriptive anyway.

Comments welcome,
Thomas

[gst-devel] Re: [gst-cvs] ensonic gstreamer: gstreamer/ gstreamer/gst/ gstreamer/plugins/elements/

[Tim <t.i.m@ze...>]

On Fri, 2006-04-28 at 18:55 +0000, Stefan Kost wrote:

Hi Stefan,

> Log message:
> * plugins/elements/gsttypefindelement.c:
> (gst_type_find_element_handle_event):
> make GstElementDetails const

  ...

> diff -u -d -r1.78 -r1.79
> --- gsttypefindelement.c	28 Apr 2006 13:43:03 -0000	1.78
> +++ gsttypefindelement.c	28 Apr 2006 18:55:17 -0000	1.79
> @@ -63,7 +63,7 @@
>  GST_DEBUG_CATEGORY_STATIC (gst_type_find_element_debug);
>  #define GST_CAT_DEFAULT gst_type_find_element_debug
> -static GstElementDetails gst_type_find_element_details =
> +static const GstElementDetails gst_type_find_element_details =
>  GST_ELEMENT_DETAILS ("TypeFind",
>      "Finds the media type of a stream",
> @@ -476,16 +476,17 @@
>            if (typefind->store) {
>              caps = gst_type_find_helper_for_buffer (GST_OBJECT (typefind),
>                  typefind->store, &prob);
> -          }
> -          if (caps && prob >= typefind->min_probability) {
> -            g_signal_emit (typefind, gst_type_find_element_signals[HAVE_TYPE],
> -                0, prob, caps);
> -          } else {
> -            GST_ELEMENT_ERROR (typefind, STREAM, TYPE_NOT_FOUND,
> -                (NULL), (NULL));
> +            if (caps && prob >= typefind->min_probability) {
> +              g_signal_emit (typefind, gst_type_find_element_signals[HAVE_TYPE],
> +                  0, prob, caps);
> +            } else {
> +              GST_ELEMENT_ERROR (typefind, STREAM, TYPE_NOT_FOUND,
> +                  (NULL), (NULL));
> +            }
> +            gst_caps_replace (&caps, NULL);
>            }
> -          gst_caps_replace (&caps, NULL);
>            stop_typefinding (typefind);
>            res = gst_pad_event_default (pad, event);
>            break;
> 

The last change isn't mentioned in the ChangeLog - did you really mean
to commit that?

(I hope not, because it doesn't seem entirely correct, as with it
typefind won't throw a TYPE_NOT_FOUND error message any longer when an
EOS is received but no data has been received so far. Mike has already
fixed the issue of initializing caps to NULL here earlier in case your
fix was supposed to be for the same issue).

Cheers
 -Tim

Re: [gst-devel] dataflow synchronization

[Edgard Lima <edgard.lima@in...>]

If you want something like:

videosrc ! tee tee0. ! queue ! videorendersink tee0. ! queue ! videoencsink

we could make

videosrc ! tee ! queue ! videorendersink tee0. ! queue ! videoreate !  
video/x-raw-yuv, framerate=\(fraction\)15/1   !  videoencsink

Or else

if your "videoencsink" has a rate property


BR,
Edgard Lima - alima
edgard.lima@...



ext Benoit Fouet wrote:

>
>
> Wim Taymans wrote:
>
>>On Thu, 2006-04-27 at 18:39 +0200, Benoit Fouet wrote:
>>  
>>
>>>Hi,
>>>
>>>I've read Gstreamer documentation (i.e. Application Development Manual
>>>and Plugin Writer's Guide) and one point remains obscure to me.
>>>I can't figure out how data is synchronized over the pipeline.
>>>
>>>e.g. when having a pipeline as simple as an audio file source, a decoder
>>>and an audio plugin, the source is able to provide data much more
>>>quickly than the decoder can work, itself more quickly than the audio
>>>sink is able to flush data on driver.
>>>
>>>though, my question is: what is the event that allows an element to
>>>provide data over its source pad ?
>>>is it that gst_pad_push is called in the same thread, and is by the way
>>>blocking the upstream element, or are there other synchronization methods ?
>>>    
>>>
>>
>>Yep, pad_push() eventually blocks somewhere downstream, either in a sink
>>that does
>>synchronisation or another element that rate controls in one way or
>>another (queue, based on buffer size, some network element).
>>All elements in a pipeline share the same clock normally, a typical sink
>>waits for the clock to reach the propor time corresponding to the buffer
>>timestamps before rendering a buffer. As soon as the buffer is rendered
>>(or scheduled for rendering in the case of audio) pad_push() returns and
>>upstream elements can produce new data.
>>
>>Hope that explains,
>>Wim
>>
>>  
>>
> It does explain, thanks :)
> I have a related second question: in case an element has multiple 
> source pads (let's say 2 for instance), is there a way to have one of 
> them blocked and the other one allowed to produce new data ?
> e.g. if a video source element provides data to both a 
> renderer/display (rather quick) and an encoder (slower), is it 
> possible that the display element have access to more frames than the 
> encoder ?
> in other words, let's say you can produce 30 frames per second and you 
> encode at 15 but you want to display 30.
> do the downstream elements have to manage themselves to drop frames 
> they don't need ?
>
> Regards,
> Ben
>
>>  
>>
>>>Thanks,
>>>Ben
>>>
>>>
>>>
>>>-------------------------------------------------------
>>>Using Tomcat but need to do more? Need to support web services, security?
>>>Get stuff done quickly with pre-integrated technology to make your job easier
>>>Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>>>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>>>_______________________________________________
>>>gstreamer-devel mailing list
>>>gstreamer-devel@...
>>>https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>>>    
>>>

Re: [gst-devel] GStreamer in GNOME 2.16

[Thomas Vander Stichele <thomas@ap...>]

Hi,


> Our Illustrious Release Manager is currently travelling back from FISL,
> so I'll give a quick outline here, and let him follow up with more
> details when he has some time.

Back.

I think Mike summed up pretty much.
The only change which we're doing is to rely on at least 2.8 of GLib
exclusively.  Our hacks for supporting 2.6 just don't go far enough in
fixing the threading problems we're working around that are in GLib 2.6.

Of course this doesn't cause any trouble for the next GNOME release.

Other than that, we're only adding to our API, as usual in a stable
series of GStreamer, and we're taking a lot of care ensuring no
regressions exist in the releases (though of course it helps if other
people test our prereleases).

The only thing GNOME may see is gradual migration of a few plug-ins from
-bad to -good, which can only be a good thing.

Speaking personally, I don't expect development on 0.11 to start very
soon, hence I wouldn't worry about us suddenly breaking ABI again and
jumping to 0.12.

So in a nutshell, GNOME + GStreamer = Love.

Happy Hacking,
Thomas

[gst-devel] RELEASE: GStreamer Python Bindings 0.10.4 'Alegre'

[<thomas@ap...>]

This mail announces the release of GStreamer Python Bindings 0.10.4 'Alegre'.


GStreamer Python Bindings is a set of Python bindings for GStreamer, using
the same system as PyGTK.
It also comes with a number of examples.
 
For more information, see [http://gstreamer.freedesktop.org/modules/gst-python.html]
To file bugs, go to [http://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer&component=gst-python]

Re: [gst-devel] problem with g_object properties

[Corentin Baron <corentin.baron@in...>]

James "Doc" Livingston wrote:

>On Fri, 2006-04-28 at 14:33 +0200, Corentin Baron wrote:
>  
>
>>  case ARG_BL_DEVICE:
>>      filter->blinkydevice = g_value_get_string(value);
>>    g_print("gstblinky: set device to %s\n", filter->blinkydevice);
>>    break;
>>    
>>
>
>You need to use g_value_dup_string here. You're using the GValue's copy
>of the string, which will get freed when the GValue is destroyed (before
>g_object_set finishes).
>
>
>Cheers,
>
>James "Doc" Livingston
>  
>
That worked, thanks !

cheers,
Corentin.

Re: [gst-devel] problem with g_object properties

[James \Doc\ Livingston <doclivingston@gm...>]

On Fri, 2006-04-28 at 14:33 +0200, Corentin Baron wrote:
>   case ARG_BL_DEVICE:
>       filter->blinkydevice = g_value_get_string(value);
>     g_print("gstblinky: set device to %s\n", filter->blinkydevice);
>     break;

You need to use g_value_dup_string here. You're using the GValue's copy
of the string, which will get freed when the GValue is destroyed (before
g_object_set finishes).


Cheers,

James "Doc" Livingston
-- 
>> After all, everybody's got a water buffalo. -- Ben Coleman
> in their machine room. -- Nix
with the candlestick. -- Christian Bauernfeind 

Re: [gst-devel] problem with g_object properties

[Corentin Baron <corentin.baron@in...>]

Thomas Vander Stichele wrote:

>(SNIP)
>
>  
>
>>I'm writing a gstreamer plugin for a video streaming library we use at 
>>work (called blinky, but that's not the point here), and I've got a 
>>problem with my plugin's properties. When I set the property at first, 
>>it seems correctly set, but alas when I set the state of my test 
>>pipeline to PLAYING the property is broken.
>>    
>>
>
>You should also show were you register your object properties, it is
>possible you made a mistake there.
>
>Thomas
>  
>
The properties are registered in the class_init function:

static void
gst_blinkysrc_class_init (GstBlinkySrcClass *klass)
{
  GObjectClass *gobject_class;
  GstElementClass *gstelement_class;

  gobject_class = (GObjectClass*) klass;
  gstelement_class = (GstElementClass*) klass;

  parent_class = g_type_class_ref (GST_TYPE_ELEMENT);

  g_object_class_install_property (gobject_class, ARG_SILENT,
    g_param_spec_boolean ("silent", "Silent", "Produce verbose output ?",
                          FALSE, G_PARAM_READWRITE));
  g_object_class_install_property (gobject_class, ARG_BL_DEVICE,
    g_param_spec_string ("device", "Device", "Blinky device to get data
from.",
                          "0", G_PARAM_READWRITE));
  g_object_class_install_property (gobject_class, ARG_BL_SYNCHRONIZE,
    g_param_spec_boolean ("sync", "Synchronize", "Synchronize with
blinky device ?",
                          FALSE, G_PARAM_READWRITE));

  gobject_class->set_property = gst_blinkysrc_set_property;
  gobject_class->get_property = gst_blinkysrc_get_property;

  gstelement_class->change_state = gst_blinky_src_change_state;
}

I used a plugin template perl script made by Luca Ognibene to generate
the skeleton of my plugin.

Thx,
Corentin.

Re: [gst-devel] problem with g_object properties

[Thomas Vander Stichele <thomas@ap...>]

(SNIP)

> I'm writing a gstreamer plugin for a video streaming library we use at 
> work (called blinky, but that's not the point here), and I've got a 
> problem with my plugin's properties. When I set the property at first, 
> it seems correctly set, but alas when I set the state of my test 
> pipeline to PLAYING the property is broken.

You should also show were you register your object properties, it is
possible you made a mistake there.

Thomas

[gst-devel] problem with g_object properties

[Corentin Baron <corentin.baron@in...>]

Hello,

I'm writing a gstreamer plugin for a video streaming library we use at 
work (called blinky, but that's not the point here), and I've got a 
problem with my plugin's properties. When I set the property at first, 
it seems correctly set, but alas when I set the state of my test 
pipeline to PLAYING the property is broken.

Here's the set_property function of my plugin (the g_print()s deserve to 
be deleted):

static void
gst_blinkysrc_set_property (GObject *object, guint prop_id,
                    const GValue *value, GParamSpec *pspec)
{
  GstBlinkySrc *filter;

  g_return_if_fail (GST_IS_BLINKYSRC (object));
  filter = GST_BLINKYSRC (object);

  switch (prop_id)
  {
  case ARG_SILENT:
    filter->silent = g_value_get_boolean (value);
    g_print("gstblinky: set silent to %s\n", 
(filter->silent==TRUE?"true":"false"));
    break;
  case ARG_BL_DEVICE:
      filter->blinkydevice = g_value_get_string(value);
    g_print("gstblinky: set device to %s\n", filter->blinkydevice);
    break;
  case ARG_BL_SYNCHRONIZE:
    filter->blinkysync = g_value_get_boolean(value);
    g_print("gstblinky: set sync to %s\n", 
(filter->blinkysync==TRUE?"true":"false"));
    break;
  default:
    G_OBJECT_WARN_INVALID_PROPERTY_ID (object, prop_id, pspec);
    break;
  }
}

here's my test program instanciation and set_property() part:

pipeline = gst_thread_new("blinkytest");
   
    blinkysrc = gst_element_factory_make("BlinkySrc", "Source");
    if (blinkysrc == NULL) {
        g_print("Error instanciating blinky source.\n");
        return -1;
    }
   
    // Affichage d'infos sur le plugin :
    g_print(" * %s instanciated.\n", gst_element_get_name(blinkysrc));
   
    videosink = gst_element_factory_make("autovideosink", "video");
    g_print(" * %s instanciated.\n", gst_element_get_name(videosink));
   
    g_object_set(G_OBJECT(blinkysrc), "sync", TRUE, NULL);
    g_object_set(G_OBJECT(blinkysrc), "silent", FALSE, NULL);
    g_object_set(G_OBJECT(blinkysrc), "device", argv[1], NULL);
    g_print(" * properties set for %s\n", gst_element_get_name(blinkysrc));

and here's the output of my test program:

$ ./Debug/BlinkyGstTest 2
 * Begin.
 * gst_init done.
 * argc checked.
 * Source instanciated.
 * video instanciated.
gstblinky: set sync to true
gstblinky: set silent to false
gstblinky: set device to 2
 * properties set for Source
 * elements connected and added to the bin
connexion to blinky device \uffff\uffff...
BlinkyConnexion_Create: blinkyBEOpen(\uffff\uffff) failed

I think it could be a pointer problem, but the property seems correctly 
set first, and broken when I try to use it.

Any gst_plugin pro out there who could help?
thx,
Corentin BARON

Re: [gst-devel] core and GLib

[Tim <t.i.m@ze...>]

On Fri, 2006-04-28 at 13:41 +0200, Thomas Vander Stichele wrote:

> > While in theory I still feel we should have supported 2.6 correctly,
in
> > practice we haven't, and we shouldn't lie to people pretending that we
> > do.
> > 
> > Therefore I propose that after the next core release, we require GLib
> > 2.8 and remove the compatibility hacks through the stack.
>
> Nobody have an opinion on this ? If no one is against, I say this can be
> done now.

FWIW, I'm all for it, the sooner the better.

Cheers
 -Tim

Re: [gst-devel] core and GLib

[Wim Taymans <wim@fl...>]

On Fri, 2006-04-28 at 13:41 +0200, Thomas Vander Stichele wrote:
> Nobody have an opinion on this ? If no one is against, I say this can be
> done now.
> 
> If anyone wants to enjoy the pleasure of ripping out hacky compatibility
> code, feel free to step up !
> 
Yes!

Wim

Re: [gst-devel] core and GLib

[Thomas Vander Stichele <thomas@ap...>]

Nobody have an opinion on this ? If no one is against, I say this can be
done now.

If anyone wants to enjoy the pleasure of ripping out hacky compatibility
code, feel free to step up !

Thomas

On Thu, 2006-04-06 at 16:31 +0200, Thomas Vander Stichele wrote:
> Hi all,
> 
> we discussed this before, and my thoughts have changed on the matter and
> I want to bring it up again.
> 
> We've had various reports from people switching between GLib 2.6 and 2.8
> while upgrading, or people installing a 2.8 compiled version of GST on a
> 2.6 glib version, and more fun things.
> 
> While in theory I still feel we should have supported 2.6 correctly, in
> practice we haven't, and we shouldn't lie to people pretending that we
> do.
> 
> Therefore I propose that after the next core release, we require GLib
> 2.8 and remove the compatibility hacks through the stack.
> 
> What do you all think ?
> 
> Thomas
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel@...
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

Re: [gst-devel] Openofficesrc-plugin

[Thomas Vander Stichele <thomas@ap...>]

On Fri, 2006-04-28 at 08:43 +0200, Michael Krog wrote:
> Hi.
> 
> Has anyone been working on a source for openoffice-slidehows?
> Im on a project which might need it in a year or so, and would
> hate to start from scratch i anyone already had something going.
> 
> The idea would be to stream video of the slideshow and control
> the show (forward, back, etc.) + the ability to open all the
> format open office supports.

I wanted to do this to integrate with Flumotion.  OpenOffice ships with
a python interpreter and UNO bindings that allow you to inspect and
manipulate OpenOffice instances running.

The idea was basically to listen for advances in an impress slideshow,
have ooo generate a png from that, and then mux that png into a
Flumotion Ogg stream.

It's definately possible, but OpenOffice's UNO api's are hard to get
through :) After half a day of hacking I was getting OpenOffice to type
whatever text I wanted into a new document, but OOImpress's API was less
documented.

If you are serious about hacking on this, let us know - it would be a
*great* feature to have.

Thomas

Re: [gst-devel] Openofficesrc-plugin

[Michael Krog <mic@ap...>]

Okay. I would think it would be possible using the UNO-framework.
Check out this guy: http://mithrandr.moria.org/blog/447.html

He starts up a headless openoffice and uses the UNO-framework
to open documents and convert to PDF via the remote headless
openoffice instance.

Somehow it must be possible to make openoffice draw on a
custom canvas or frame and let that be the source for imagedata.

-Michael

On Fri, 2006-04-28 at 11:44 +0200, Andy Wingo wrote:
> Hi Michael,
> 
> On Fri, 2006-04-28 at 08:43 +0200, Michael Krog wrote:
> > Has anyone been working on a source for openoffice-slidehows?
> > Im on a project which might need it in a year or so, and would
> > hate to start from scratch i anyone already had something going.
> > 
> > The idea would be to stream video of the slideshow and control
> > the show (forward, back, etc.) + the ability to open all the
> > format open office supports.
> 
> No one that I know is working on this, no; the best idea that we had
> (IMO) for video + openoffice integration was to do desktop sharing on
> the presentation machine via vnc, and capture video via rfb. Mike Smith
> has been poking at this a bit.
> 
> That way you take take an openoffice presentation and make a video out
> of it. You could then seek in it later if you like. Not exactly what you
> were asking for, but hey...
> 
> Cheers,

[gst-devel] RELEASE: GStreamer Base Plug-ins 0.10.6 'Chao'

[<thomas@ap...>]

This mail announces the release of GStreamer Base Plug-ins 0.10.6 'Chao'.


GStreamer Base Plug-ins is a well-groomed and well-maintained collection of
GStreamer plug-ins and elements, spanning the range of possible types of
elements one would want to write for GStreamer.  It also contains helper
libraries and base classes useful for writing elements.
A wide range of video and audio decoders, encoders, and filters are included.

For more information, see [http://gstreamer.freedesktop.org/modules/gst-plugins-base.html]
To file bugs, go to [http://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer&component=gst-plugins-base]

[gst-devel] RELEASE: GStreamer 0.10.5 'Fogo'

[<thomas@ap...>]

This mail announces the release of GStreamer 0.10.5 'Fogo'.


GStreamer is a streaming media framework that allows the construction of
graphs of elements which operate on media data.
Applications using this library can do anything from real-time sound processing
over playing video to capturing audio, video, and even other types of media
data.
Its architecture allows for adding new data types or processing capabilities
simply by installing new plug-ins.
GStreamer is the core module, containing libraries, headers, the basic object
hierarchy, and a set of media-agnostic core elements.
 
For more information, see [http://gstreamer.freedesktop.org/modules/gstreamer.html]
To file bugs, go to [http://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer&component=gstreamer+%28core%29]