[gst-devel] Gstreamer design questions

[Ronald S. Bultje]

Hi,

On Tue, 2004-03-16 at 08:10, lopez5 at gmx.de wrote: 
> 0.) Are the 'Application Development Manual 0.7.4.1' (manual.pdf) and
> 'Plugin Writer's Guide 0.7.4.1' (pwg.pdf) still up to date? If not,
> what are the major points that have changed?
Mostly and yes. The AppDevMan is uptodate except that it doesn't mention
many of the new features in 0.8.0. The stuff in there all still applies,
though. The Plugin Writer's Guide is uptodate. Chapter 4 and small
bits'n'pieces in chapter 3 (MIDI, clocking) still need to be written
some day. Once that's done, I might update the AppDevMan, too.

> 1.) 
> http://www.freedesktop.org/~gstreamer/features/ : 
> here it says: 
> 
>   'Pluggable scheduling system capable of dealing with most pipeline
>   structures'
> 
> what does 'most' mean? In which cases will scheduling not work? Also,
> there are a couple of emails in the archive complaining about bad
> synchronization, what is the status with this because there is no
> documentation about ?
Martin Soto sent one of these emails, in which the whole clocking was
explained. That will soon become the Clocking chapter in the PWG. So
there will soon be documentation about this.

'Most' is a theoretical disclaimer for weird people with weird ideas.
Practically, any pipeline with a reasonable setup as taught in the
AppDevMan will play.

> 2.)
> 
> http://www.freedesktop.org/~gstreamer/data/doc/gstreamer/head/manual/html/chapter-hello-world.html#section-hello-world
> here it says:
>  
>   g_object_set (G_OBJECT (filesrc), "location", argv[1], NULL); 
> 
> Is this to only way to set up things on gstreamer elements? I mean, using
> a string seams error-prone,. And, where are all these strings
> documented? (ok, I can query them during run-time, but ...)
Strings? No, it's any type. For details, read the gobject documentation.
For an integer, you'd do:

gint bla = 0;

g_object_set (G_OBJECT (element), "property", bla, NULL);

And yes, that's how this works (note that it says that you're supposed
to be familiar with gobject when reading this guide ;) ). There's also
other ways (g_object_set_value()) which use exact internal types
(GValue), then you know what's going on internally if you use those
functions.

Other ways are signals (see below) or interfaces (see chapter 3 in the
PWG). Interfaces are one of the things missing in the AppDevMan.

> 3.)
> 
> http://www.freedesktop.org/~gstreamer/data/doc/gstreamer/head/pwg/html/chapter-building-signals.html:
> here it says: 
> 
>   'Note, however, that the application needs to be aware of signals
>   and their meaning, so if you're looking for a generic way for
>   application- element interaction, signals are probably not what
>   you're looking for.'
> 
> If signals are not the right way, what other way is
> there?
Interfaces. It really depends on what you want. For simple things,
signals are perfect. For complex things where you need to throw objects
hence and forth between element and application, interfaces may be more
appropriate.

The point made is simply that signals have limitations if you use
different signals in each element. If you have one element calling a
signal 'foo' and another one calling it 'bar', there's nothing that will
tell this. No compiler warning, etc. Secondly, signals aren't really
useful for multi-function API interactions. Too much protocol weirdness
to bother. But we're using signals for many simple things. Device
open/close, for example, uses 'open' and 'close' signals in many
elements. In 0.6.x, even stream metadata was a signal ('metadata').
Metadata is - in 0.8.x - an interface plus some object code for the
application.

> 4.)
> http://www.freedesktop.org/~gstreamer/data/doc/gstreamer/head/pwg/html/chapter-advanced-events.html
> here it says: 
> 
>   'It is very important to understand how both of those methods work
>   because if one element in the pipeline is not handling them
>   correctly the whole event system of the pipeline is broken.'
> 
> Could you give some more details on this,
> please.
Consider an element with this event handler:

GstEvent *event = GST_EVENT (data);

switch (GST_EVENT_TYPE (event)) {
  case GST_EVENT_SOME_TYPE:
    blabla ();
    break;
  default:
    g_warning ("help!");
    return;
}

This is wrong. Why? Because you drop the event instead of forwarding it.
Those elements break events inside a pipeline. Events must *always* be
forwarded when the element doesn't use them internally. Events are
GStreamer's way of sending control messages:

switch (GST_EVENT_TYPE (event)) {
  case GST_EVENT_SOME_TYPE:
    blabla ();
    /* note that if I *know* that I don't need to forward the event,
     * I don't have to. But normally, you would (so just teach yourself
     * to do it properly and forward any event for now). */
    gst_pad_event_default (pad, event);
    break;
  default:
    gst_pad_event_default (pad, event);
    return;
}

> 5.)
> http://www.freedesktop.org/~gstreamer/data/doc/gstreamer/head/pwg/html/section-events-definitions.html
> here it says: 
> 
>   'Events are stored in a GstEvent structure, which is simply a big C
>   union with the types for each event in it.'
> 
> How can I add a custom event? Will I have to rebuild everything then?
> Will I have to add code to each and every plug-in then?
Extra events can be added in extra headers, by extending the same
structure. That prevents the recompile. It's sort of tricky because you
have to be sure that you're not using more space than the allocated spac
for a GstEvent in our current ABI.

In 0.9.x, events will be a GstStructure so this problem then disappears.

> 6.) Chapter 24 and 25 of the Plugin Writer's Guide are
> missing:
> http://www.freedesktop.org/~gstreamer/data/doc/gstreamer/head/pwg/html/chapter-other-ntoone.html
> http://www.freedesktop.org/~gstreamer/data/doc/gstreamer/head/pwg/html/chapter-other-nton.html
> 
> Does this mean that I currently cannot implement multiplexers with
> gstreamer? 
You can, I just didn't write those chapters yet. If you want to write
any undocumented element type, just take an existing one as your example
(mplex, matroskamux, avimux).

> If I can create a gstreamer pipeline that does audio/video
> transcoding, i.e. demultiplex a/v -> transcode a/v -> multiplex a/v/ ,
> what is the syntax for 'gst-launch' ?

MPEG->AVI example:

gst-launch avimux name=mux ! filesink location=file.avi { filesrc
location=file.mpg ! mpegdemux name=demux .video_00 ! { queue ! mpeg2dec
! ffcolorspace ! divxenc ! queue ! mux.video_%d } { demux.audio_00 ! mad
! lame ! queue ! mux.audio_%d } }

gst-launch is bad use for applications and all. Write a test app if you
intend to create elements and test them using such a thing.

HTH,
Ronald