Discussion:
[gst-devel] 0.8 in 2.6 ?
(too old to reply)
i***@public.uni-hamburg.de
2003-10-06 07:19:14 UTC
Permalink
Hi people,
I'm out for opinions again.
There's 2 questions I really want to get nailed down, because I want to steer
our development and Rhythmbox into the right direction.

1) Do we want GStreamer 0.8 released in time for Gnome 2.6?
This means: Can we add all the features to the core that are needed for
everything we want supported with that release? We do not need to get all the
plugins feature-complete as they can be extended later on. Another thing is
obviously: Do apps using GStreamer need 0.8 or are they all happily using 0.6?

2) What features do we need that need API/ABI changes and that should go into
0.8?

I'd like to get that sorted out now so I know if there are deadlines we
need/want to meet. Some people said we want that while others weren't sure we'd
be able to meet that deadline.
And I definitely don't want to look bad again in front of the release team when
we slip schedules again.


As for my personal opinion:
1)
I want 0.8 in 2.6. I hate it that loads of our developers power is lost on some
dead-end branch where it could put to use to do important stuff on the branch
that has a future.
2)
The features that come to mind immediately are
- interactivity
- tags
- gettext support
- interfaces

Features that could be implemented without breaking API/ABI later on - during a
stable 0.8 branch:
- more interfaces/implementing interfaces in the plugins
- a new autoplugger
- more plugins
- an extensive testsuite


So much for me,
Benjamin
Julien MOUTTE
2003-10-06 07:31:07 UTC
Permalink
Gstreamer player and Totem will probably need to switch to 0.8 when we
will want to implement software video scaling, interactivity (DVD),
etc..

I m already planning to branch gst-player to maintain a 0_6 compliant
release of it and start switching to the newest GstVideoSink
architecture.

Cheers

dolphy.
Post by i***@public.uni-hamburg.de
Hi people,
I'm out for opinions again.
There's 2 questions I really want to get nailed down, because I want to steer
our development and Rhythmbox into the right direction.
1) Do we want GStreamer 0.8 released in time for Gnome 2.6?
This means: Can we add all the features to the core that are needed for
everything we want supported with that release? We do not need to get all the
plugins feature-complete as they can be extended later on. Another thing is
obviously: Do apps using GStreamer need 0.8 or are they all happily using 0.6?
2) What features do we need that need API/ABI changes and that should go into
0.8?
I'd like to get that sorted out now so I know if there are deadlines we
need/want to meet. Some people said we want that while others weren't sure we'd
be able to meet that deadline.
And I definitely don't want to look bad again in front of the release team when
we slip schedules again.
1)
I want 0.8 in 2.6. I hate it that loads of our developers power is lost on some
dead-end branch where it could put to use to do important stuff on the branch
that has a future.
2)
The features that come to mind immediately are
- interactivity
- tags
- gettext support
- interfaces
Features that could be implemented without breaking API/ABI later on - during a
- more interfaces/implementing interfaces in the plugins
- a new autoplugger
- more plugins
- an extensive testsuite
So much for me,
Benjamin
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
gstreamer-devel mailing list
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
--
Julien MOUTTE (aka Dolphy)

Homepage : http://dolphy-tech.net
Ted Gould
2003-10-06 08:33:12 UTC
Permalink
Hey cool, I had this same question.

I'd love to see 0.8 for 2.6, I believe that there is support of mixing
elements (like intefacing to the driver mixing) in 0.8. This would make
it so that the volume controls could support both OSS and ALSA in a
single build (which would be cool).

I'll also say that it would be nice if this was decided quickly, as
there is much work to do if it does make it in. Volume control will
pretty much have to be rewritten.

--Ted
Post by i***@public.uni-hamburg.de
Hi people,
I'm out for opinions again.
There's 2 questions I really want to get nailed down, because I want to steer
our development and Rhythmbox into the right direction.
1) Do we want GStreamer 0.8 released in time for Gnome 2.6?
This means: Can we add all the features to the core that are needed for
everything we want supported with that release? We do not need to get all the
plugins feature-complete as they can be extended later on. Another thing is
obviously: Do apps using GStreamer need 0.8 or are they all happily using 0.6?
2) What features do we need that need API/ABI changes and that should go into
0.8?
I'd like to get that sorted out now so I know if there are deadlines we
need/want to meet. Some people said we want that while others weren't sure we'd
be able to meet that deadline.
And I definitely don't want to look bad again in front of the release team when
we slip schedules again.
1)
I want 0.8 in 2.6. I hate it that loads of our developers power is lost on some
dead-end branch where it could put to use to do important stuff on the branch
that has a future.
2)
The features that come to mind immediately are
- interactivity
- tags
- gettext support
- interfaces
Features that could be implemented without breaking API/ABI later on - during a
- more interfaces/implementing interfaces in the plugins
- a new autoplugger
- more plugins
- an extensive testsuite
So much for me,
Benjamin
_______________________________________________
gnome-multimedia mailing list
http://mail.gnome.org/mailman/listinfo/gnome-multimedia
Ronald Bultje
2003-10-07 02:37:44 UTC
Permalink
Hi Ted,
Post by Ted Gould
I'd love to see 0.8 for 2.6, I believe that there is support of mixing
elements (like intefacing to the driver mixing) in 0.8. This would make
it so that the volume controls could support both OSS and ALSA in a
single build (which would be cool).
The OSS one is written. The ALSA one isn't written yet, because I don't
have a single clue on how ALSA works. I'm hoping for some other
interested person to add mixing support to ALSA. I'm willing to maintain
that part of the ALSA plugin, but can't write it myself, I'm affraid.
Post by Ted Gould
I'll also say that it would be nice if this was decided quickly, as
there is much work to do if it does make it in. Volume control will
pretty much have to be rewritten.
I have a sample mixer available in CVS, you can just copy that. It looks
exactly the same as the gnome mixer, just without images, i18n and a11y.
These should be easy to add yourself, you can just copy the code from
the old mixer. I've had a look and it doesn't look too hard. I'm just
not very much interested in each of these, I'm more a system coder than
a UI coder, I'm affraid. ;).

Oh, and given our LGPL madness, I'd love to relicense the mixer under
the LGPL while we're at it, so that we can use closed-source
(GPL-incompatible) plugins with the mixer, too. However, that's a minor
issue.

And nice to see you're interested in this gst-based mixer, thanks! Gives
me the feeling that the work was actually useful. ;).

Ronald
--
Ronald Bultje <***@ronald.bitfreak.net>
Linux Video/Multimedia developer
iain
2003-10-07 09:58:08 UTC
Permalink
Post by Ronald Bultje
The OSS one is written. The ALSA one isn't written yet, because I don't
have a single clue on how ALSA works.
Is there anyone who does?

iain
--
"The greatest evils in the world will not be carried out by men with guns,
but by men in suits sitting behind desks" - C. S. Lewis
Joshua Haberman
2003-10-08 14:30:02 UTC
Permalink
Post by iain
Post by Ronald Bultje
The OSS one is written. The ALSA one isn't written yet, because I don't
have a single clue on how ALSA works.
Is there anyone who does?
I've spent a lot of time with the ALSA PCM interface, but none with the
mixer. I have a feeling that writing a *good* mixer plugin for ALSA
that does the right thing on a variety of different soundcards will be
very tricky. ALSA takes the approach of being extremely flexible and
generic at the cost of providing a very complex interface to the
programmer.

I have just recently discovered how to write an ALSA application that
shows you your soundcards by name (this is in PortAudio CVS), and AFAIK
this is the first program for Linux that has ever offered this
capability. With OSS it was always /dev/dspX and with ALSA it has
always been hw:X.

In any case, I think the challenge for a gstreamer ALSA mixer plugin
will be deducing what channels of mixer do what based on the information
ALSA gives you.

Josh
Joshua N Pritikin
2003-10-08 22:53:03 UTC
Permalink
Post by Joshua Haberman
Post by iain
Post by Ronald Bultje
The OSS one is written. The ALSA one isn't written yet, because I don't
have a single clue on how ALSA works.
Is there anyone who does?
In any case, I think the challenge for a gstreamer ALSA mixer plugin
will be deducing what channels of mixer do what based on the information
ALSA gives you.
It may be possible for consumer cards.

Pro-cards like the RME HDSP have 24 input and 24 output audio
channels with a hardware matrix mixer for the output channels.
There is a special hdspmixer app in alsa-tools to manage it.
--
A new cognitive theory of emotion, http://savannah.nongnu.org/projects/aleader
Ronald Bultje
2003-10-09 00:55:06 UTC
Permalink
Hi Joshua,
Post by Joshua Haberman
I have just recently discovered how to write an ALSA application that
shows you your soundcards by name (this is in PortAudio CVS), and AFAIK
this is the first program for Linux that has ever offered this
capability. With OSS it was always /dev/dspX and with ALSA it has
always been hw:X.
(FYI, for OSS, this is struct mixerinfo.name.) I'd be interested in
knowing how to do this, since you surely want a mixer to show the device
name. ;).

And well, yes, from previous attempts of several people in writing an
ALSA plugin for GStreamer, I've gotten as far as to understand that ALSA
is pretty hard. ;). I hope it'll work out. I'm not an ALSA expert,
fortunately. ;).

Ronald
--
Ronald Bultje <***@ronald.bitfreak.net>
Linux Video/Multimedia developer
Ted Gould
2003-10-09 07:28:10 UTC
Permalink
Okay,

I guess we should look back to the original purpose for this thread...
is Gstreamer 0.8 going to be ready for 2.6? I don't see anyone saying
no.

I don't think that the lack of an ALSA mixer should be a blocking issue,
because we don't have one now either (atleast 0.9, which is the one that
I think everyone will be using). It's really not a regression.
(Ofcourse, I'd still love to have one ;)

--Ted
Mark Finlay
2003-10-09 12:38:08 UTC
Permalink
Don't forget that with Linux 2.6 coming out Alsa support will be vital
for both Gnome and Gstreamer. This really has no effect on which
gstreamer to support, just that Alsa support should be pretty high on
the priorities list..
Post by Ted Gould
Okay,
I guess we should look back to the original purpose for this thread...
is Gstreamer 0.8 going to be ready for 2.6? I don't see anyone saying
no.
I don't think that the lack of an ALSA mixer should be a blocking issue,
because we don't have one now either (atleast 0.9, which is the one that
I think everyone will be using). It's really not a regression.
(Ofcourse, I'd still love to have one ;)
--Ted
--
Mark Finlay
Computer Science Student

E-Mail: sisob_AT_tuxfamily_DOT_org
Jabber: sisob_AT_jabber_DOT_org
Blog: http://sisob.tuxfamily.org
http://advogato.org/person/sisob
Ronald Bultje
2003-10-10 00:34:05 UTC
Permalink
Reading the mixer thread I have thought several times that ... why this
guys don't look into the alsamixer code to learn how to do it? Maybe it
is a silly answer, I have no knowledge about ALSA code ... only a ALSA
user for the moment ;-)
That code is likely GPL, and we (or: I) want a LGPL mixer (there's some
legal reasons for this).

Ronald
--
Ronald Bultje <***@ronald.bitfreak.net>
Linux Video/Multimedia developer
Thomas Vander Stichele
2003-10-10 00:46:04 UTC
Permalink
you can look, but not copy. Ie, figure out the one missing bit you
don't have, then write it from memory.

Thomas
Post by Ronald Bultje
Reading the mixer thread I have thought several times that ... why this
guys don't look into the alsamixer code to learn how to do it? Maybe it
is a silly answer, I have no knowledge about ALSA code ... only a ALSA
user for the moment ;-)
That code is likely GPL, and we (or: I) want a LGPL mixer (there's some
legal reasons for this).
Ronald
Dave/Dina : future TV today ! - http://davedina.apestaart.org/
<-*- thomas (dot) apestaart (dot) org -*->
Baby you cry too much I'm tired of the sound
You're such a baby
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! - http://urgent.rug.ac.be/
Joshua Haberman
2003-10-10 04:16:03 UTC
Permalink
Post by Thomas Vander Stichele
you can look, but not copy. Ie, figure out the one missing bit you
don't have, then write it from memory.
It is not nearly that simple. If you want to see the kind of analysis
that goes into deciding whether a program is infringing, I would
recommend reading the lengthy Computer Associates v. Altai opinion:

http://www.bitlaw.com/source/cases/copyright/altai.html

If by "write it from memory" you mean "reproduce the part you need
verbatim, but from memory" then that is certainly inadequate. The
mechanics of how you copy (copy/paste vs. memorize/recall) are
immaterial to whether infringement has occurred.

Probably a better approach to the situation is to ask whoever wrote
alsamixer if they have any problem with it being used as a model for an
LGPL mixer.

Josh
Post by Thomas Vander Stichele
Thomas
Post by Ronald Bultje
Reading the mixer thread I have thought several times that ... why this
guys don't look into the alsamixer code to learn how to do it? Maybe it
is a silly answer, I have no knowledge about ALSA code ... only a ALSA
user for the moment ;-)
That code is likely GPL, and we (or: I) want a LGPL mixer (there's some
legal reasons for this).
Ronald
Dave/Dina : future TV today ! - http://davedina.apestaart.org/
<-*- thomas (dot) apestaart (dot) org -*->
Baby you cry too much I'm tired of the sound
You're such a baby
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! - http://urgent.rug.ac.be/
Alvaro del Castillo
2003-10-13 07:02:05 UTC
Permalink
hi!
Post by Joshua Haberman
Post by Thomas Vander Stichele
you can look, but not copy. Ie, figure out the one missing bit you
don't have, then write it from memory.
It is not nearly that simple. If you want to see the kind of analysis
that goes into deciding whether a program is infringing, I would
http://www.bitlaw.com/source/cases/copyright/altai.html
If by "write it from memory" you mean "reproduce the part you need
verbatim, but from memory" then that is certainly inadequate. The
mechanics of how you copy (copy/paste vs. memorize/recall) are
immaterial to whether infringement has occurred.
alsamixer if they have any problem with it being used as a model for an
LGPL mixer.
Or one person can read the amixer code and then answer the questions
that the GStreamer mixer developer could have.

I think that is is called a "clean implementation" or something like
that. One person take the knowledge from the code, transform it in a
document or something like that and then other person can take that
document to implement a new version without not following the laws ;-)

Ups, I love the GPL ... this is something the "enemy" could use against
it ;-)

Cheers
Post by Joshua Haberman
Josh
Post by Thomas Vander Stichele
Thomas
Post by Ronald Bultje
Reading the mixer thread I have thought several times that ... why this
guys don't look into the alsamixer code to learn how to do it? Maybe it
is a silly answer, I have no knowledge about ALSA code ... only a ALSA
user for the moment ;-)
That code is likely GPL, and we (or: I) want a LGPL mixer (there's some
legal reasons for this).
Ronald
Dave/Dina : future TV today ! - http://davedina.apestaart.org/
<-*- thomas (dot) apestaart (dot) org -*->
Baby you cry too much I'm tired of the sound
You're such a baby
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! - http://urgent.rug.ac.be/
Alvaro del Castillo
2003-10-10 04:16:02 UTC
Permalink
Hi guys!

Reading the mixer thread I have thought several times that ... why this
guys don't look into the alsamixer code to learn how to do it? Maybe it
is a silly answer, I have no knowledge about ALSA code ... only a ALSA
user for the moment ;-)

Cheers
Post by Ronald Bultje
Hi Joshua,
Post by Joshua Haberman
I have just recently discovered how to write an ALSA application that
shows you your soundcards by name (this is in PortAudio CVS), and AFAIK
this is the first program for Linux that has ever offered this
capability. With OSS it was always /dev/dspX and with ALSA it has
always been hw:X.
(FYI, for OSS, this is struct mixerinfo.name.) I'd be interested in
knowing how to do this, since you surely want a mixer to show the device
name. ;).
And well, yes, from previous attempts of several people in writing an
ALSA plugin for GStreamer, I've gotten as far as to understand that ALSA
is pretty hard. ;). I hope it'll work out. I'm not an ALSA expert,
fortunately. ;).
Ronald
Christian Fredrik Kalager Schaller
2003-10-09 12:38:08 UTC
Permalink
Post by Joshua Haberman
Post by iain
Post by Ronald Bultje
The OSS one is written. The ALSA one isn't written yet, because I don't
have a single clue on how ALSA works.
Is there anyone who does?
I've spent a lot of time with the ALSA PCM interface, but none with the
mixer. I have a feeling that writing a *good* mixer plugin for ALSA
that does the right thing on a variety of different soundcards will be
very tricky. ALSA takes the approach of being extremely flexible and
generic at the cost of providing a very complex interface to the
programmer.
I have just recently discovered how to write an ALSA application that
shows you your soundcards by name (this is in PortAudio CVS), and AFAIK
this is the first program for Linux that has ever offered this
capability. With OSS it was always /dev/dspX and with ALSA it has
always been hw:X.
In any case, I think the challenge for a gstreamer ALSA mixer plugin
will be deducing what channels of mixer do what based on the information
ALSA gives you.
Josh
Is a PortAudio plugin for GStreamer a viable option? It seems to support
a lot of architectures and if having a PortAudio output plugin and mixer
is possible I guess that at least for ordinary
desktop applications it might be a good way to increase our support for
different audio systems ?

Christian
Leif Johnson
2003-10-07 13:06:07 UTC
Permalink
Hi Ronald -
Post by Ronald Bultje
Hi Ted,
Post by Ted Gould
I'd love to see 0.8 for 2.6, I believe that there is support of
mixing elements (like intefacing to the driver mixing) in 0.8. This
would make it so that the volume controls could support both OSS and
ALSA in a single build (which would be cool).
The OSS one is written. The ALSA one isn't written yet, because I
don't have a single clue on how ALSA works. I'm hoping for some other
interested person to add mixing support to ALSA. I'm willing to
maintain that part of the ALSA plugin, but can't write it myself, I'm
affraid.
I'm willing to take a look at the ALSA element. Once upon a time, I
tried to extract knowledge from the ALSA docs. : )
Post by Ronald Bultje
I have a sample mixer available in CVS, you can just copy that. It
looks exactly the same as the gnome mixer, just without images, i18n
and a11y.
Where is this ? I'd like to check it out.

leif

--
Leif Morgan Johnson : http://ambient.2y.net/leif/
David Schleef
2003-10-07 13:11:09 UTC
Permalink
Post by Leif Johnson
Post by Ronald Bultje
I have a sample mixer available in CVS, you can just copy that. It
looks exactly the same as the gnome mixer, just without images, i18n
and a11y.
Where is this ? I'd like to check it out.
gst-sandbox/gst-mixer



dave...
David Schleef
2003-10-06 12:15:13 UTC
Permalink
Post by i***@public.uni-hamburg.de
Hi people,
I'm out for opinions again.
There's 2 questions I really want to get nailed down, because I want to steer
our development and Rhythmbox into the right direction.
1) Do we want GStreamer 0.8 released in time for Gnome 2.6?
Yes. I don't think we ever intended to go so long with 0.6. IMO,
I think that shows how well 0.6 has held up. But there are definitely
signs that applications need more power from GStreamer, and that
pressure will only increase. Better to have a good 0.8 release
soon rather than a great 0.8 release later.
Post by i***@public.uni-hamburg.de
2) What features do we need that need API/ABI changes and that should go into
0.8?
We need a general API cleanup. In particular, all the dust corners
of the language bindings should be checked so that we can make ABI
ABI-incompatible changes sooner. This is unlikely to be done unless
someone adopts the project and follows through.

Also, I'd like to do a caps implementation rewrite -- I've already
done much of it. If it misses 0.8, no big loss, though.



dave...
Andy Wingo
2003-10-12 02:56:05 UTC
Permalink
Post by David Schleef
Yes. I don't think we ever intended to go so long with 0.6. IMO,
I think that shows how well 0.6 has held up.
YAAY US! US! US! US!

Sorry, I was just at a merit awards ceremony for my students -- I'm big
on positivity right now ;)
Post by David Schleef
We need a general API cleanup. In particular, all the dust corners
of the language bindings should be checked so that we can make ABI
ABI-incompatible changes sooner.
Um, I look in gst-guile's gstreamer-support.h and I see functions like:

GList* gst_element_class_get_pad_templates (GstElementClass *klass);

GType gst_element_factory_get_element_type (GstElementFactory *factory);
guint16 gst_element_factory_get_rank (GstElementFactory *factory);
GList* gst_element_factory_get_pad_templates (GstElementFactory *factory);

GList* gst_props_get_list (GstProps *props);

These things just deal with gstreamer types, they're not custom
wrappings. Should they (and any others like them) be added to HEAD?
Typically these functions are in the category of "things that you can
access with macros or struct fields but not with functions". Do we want
functions for these? What kinds of dust corners are you thinking about?

Regards,

wingo.
Ronald Bultje
2003-10-13 02:05:03 UTC
Permalink
Hi Andy,
Post by Andy Wingo
GList* gst_element_class_get_pad_templates (GstElementClass *klass);
GType gst_element_factory_get_element_type (GstElementFactory *factory);
guint16 gst_element_factory_get_rank (GstElementFactory *factory);
GList* gst_element_factory_get_pad_templates (GstElementFactory *factory);
GList* gst_props_get_list (GstProps *props);
These things just deal with gstreamer types, they're not custom
wrappings. Should they (and any others like them) be added to HEAD?
Typically these functions are in the category of "things that you can
access with macros or struct fields but not with functions". Do we want
functions for these? What kinds of dust corners are you thinking about?
Well, you'll end up with having macros and functions for each of these,
while they all do the same thing. Consider GST_STATE (element) vs.
gst_element_get_state (element) and so on.

I prefer macros, but I suppose it doesn't matter. I know Benjamin
prefers functions because that gives more flexibility. I don't mind
having both, but that sort of defeats the point of having the function.
;).

Ronald
--
Ronald Bultje <***@ronald.bitfreak.net>
Linux Video/Multimedia developer
Andy Wingo
2003-10-20 05:41:06 UTC
Permalink
Post by Ronald Bultje
Post by Andy Wingo
GList* gst_element_class_get_pad_templates (GstElementClass *klass);
[...]
Post by Ronald Bultje
Well, you'll end up with having macros and functions for each of these,
while they all do the same thing. Consider GST_STATE (element) vs.
gst_element_get_state (element) and so on.
What dust-corners of the API exist that language bindings could shine a
light on?

Macros vs. functions is one such corner, I think. Macros are faster for
C programming, which is important. However, functions are easier to
wrap. I was just saying, if you are concerned with increasing
wrappability (I just made a new word), these should prolly be added.

Thoughts? Esp. from Dave (Lehn) and Murray. I can always keep these
functions in gst-guile, but if they are also wrapped manually in your
languages it might make sense to make functions for the core.

Regards,

wingo.

Ronald Bultje
2003-10-07 02:56:07 UTC
Permalink
Hi Benjamin,
Post by i***@public.uni-hamburg.de
1) Do we want GStreamer 0.8 released in time for Gnome 2.6?
Yes. I'm not totally sure whether we'll make it, there's some work
needing to be done, but I think we can make it. We should try, at least.
Post by i***@public.uni-hamburg.de
This means: Can we add all the features to the core that are needed for
everything we want supported with that release? We do not need to get all the
plugins feature-complete as they can be extended later on. Another thing is
obviously: Do apps using GStreamer need 0.8 or are they all happily using 0.6?
Totem needs 0.8. Rhythmbox needs it for proper typefinding (well, it's
not perfect, but better than in 0.6). And it includes some stuff needed
for new applications like the mixer in gnome-media (Ted said he's
willing to move it over, yay!), etc. Also, gst-rec requires 0.7, so if
0.8.0 becomes maintstream, I'd be very happy about that.
Post by i***@public.uni-hamburg.de
2) What features do we need that need API/ABI changes and that should go into
0.8?
You're working on element/scheduler thingies, aren't you? That'll
require some changes, I guess. I'm currently not in need of any core
change except for the GstInterface -> GstObjectSupportsInterface name
change (or something similar).

The ABI stability date is somewhere early december. I'm willing to do a
lot of coding to make that date, but I (surely) can't do more than where
my mind starts breaking. I'm hoping others will do their work, too.

As for implementation of interface in elements: we should implement it
where it breaks ABI. In xvideosink, for example, it will break the way
you setup the X/Xv window in your application, so I think we should move
it over to the Xoverlay interface asap if we want to do that at all (do
we?). Same for sdlvideosink. Also, an ALSA mixer implementation would be
nice to show off why interfaces are so cool, but is not needed before
early december. Surely, I'd like that to be there before 0.8.0 is
released.

Oh, and documentation... Before 0.8.0, we need to document our API
changes and need to show what each new feature does. I'm bad at
documenting things, I need to work on that. ;).

My TODO list before december:
* make GstInterface -> GstObjectSupportsInterface name change
* finish design of several interfaces and declare their ABI stable

My TODO list before 0.8.0:
* have a fairly working test version of gst-rec and have sample
applications (gst-mixer, gst-tv) for our interfaces
* implement interfaces in as many elements as possible where applicable
(xoverlay: xvideosink/sdlvideosink, maybe aasink-for-x (yes, there's a
special aasink-for-x-mode in aasink) plugins? colorbalance in the
videobalance plugin, mixer in the volume/alsa plugins)
* properly test all existing muxers and encoders
* make several existing demuxers/decoders work together. Quicktime
(sorensen) & ASF (WMV/WMA) comes to mind here.

I hope I can finish all that. Thomas said he was willing to help on
interface implementations in Barcelona, so I'll want to add some of this
as a enhancement in bugzilla so others can work on it, too. Of course, I
hope others will also work on finishing metadata, interactivity, so all
this is ready before december & 0.8.0. :).

Lastly, I'd like some comments if others are supporting the idea of
implementing the xoverlay interface in sdlvideosink / xvideosink /
aasink (in x-mode). It's not much more than a one-function API, but
interfaces are a nice type-checked definition of an API, I prefer them
over properties in cases where type-checking is needed and where it
becomes a general inter-plugin API.

Hmm, long email. Sorry for that. ;).

Ronald
--
Ronald Bultje <***@ronald.bitfreak.net>
Linux Video/Multimedia developer
iain
2003-10-07 09:59:02 UTC
Permalink
Post by Ronald Bultje
Totem needs 0.8. Rhythmbox needs it for proper typefinding (well, it's
not perfect, but better than in 0.6). And it includes some stuff needed
for new applications like the mixer in gnome-media (Ted said he's
willing to move it over, yay!), etc. Also, gst-rec requires 0.7, so if
0.8.0 becomes maintstream, I'd be very happy about that.
Marlin does too, and soundscrape.
iain
--
"Miss Celine Dion sings lovesongs while our cities burn"
Leif Johnson
2003-10-07 13:15:14 UTC
Permalink
Hi Ronald -

When will you be back on #gstreamer ? : )
Post by Ronald Bultje
* have a fairly working test version of gst-rec and have sample
applications (gst-mixer, gst-tv) for our interfaces
* implement interfaces in as many elements as possible where applicable
(xoverlay: xvideosink/sdlvideosink, maybe aasink-for-x (yes, there's a
special aasink-for-x-mode in aasink) plugins? colorbalance in the
videobalance plugin, mixer in the volume/alsa plugins)
And a sequencer interface for the playondemand plugin.

I'd also like to work on an alsamidisink/src and possibly have an
alsamidisequencer plugin. Anyone want to help with MIDI stuff ? : )

leif

--
Leif Morgan Johnson : http://ambient.2y.net/leif/
Ronald Bultje
2003-10-08 00:42:02 UTC
Permalink
Hi Leif,
Post by Leif Johnson
When will you be back on #gstreamer ? : )
Uh, when I've got internet at my new home. I occasionally hang out there
during working hours, but I'm trying to limit that as much as possible,
I'm supposed to actually do some work here. ;). If you've got quick
questions, just send me an email, I usually respond within a few hours
(I do have internet at my work here ;) ).

Oh, btw, thanks for taking the job! :).

Ronald
--
Ronald Bultje <***@ronald.bitfreak.net>
Linux Video/Multimedia developer
Ramón García
2003-10-07 03:02:09 UTC
Permalink
Are you suggesting not to use the standard mechanism
of GLib? That is GST_IS_<INTERFACE>(object)
GST_<INTERFACE>(object).

In that case, why?

Ramon


___________________________________________________
Yahoo! Messenger - Nueva versión GRATIS
Super Webcam, voz, caritas animadas, y más...
http://messenger.yahoo.es
Ronald Bultje
2003-10-07 03:15:03 UTC
Permalink
Hi Ramon,
Post by Ramón García
Are you suggesting not to use the standard mechanism
of GLib? That is GST_IS_<INTERFACE>(object)
GST_<INTERFACE>(object).
We do that, but we need to define the API of the interfaces, too. That's
what we need to do before the API/ABI freeze in december. :).

Ronald
--
Ronald Bultje <***@ronald.bitfreak.net>
Linux Video/Multimedia developer
Leif Johnson
2003-10-07 13:11:54 UTC
Permalink
Hi Benjamin -
Post by i***@public.uni-hamburg.de
2) What features do we need that need API/ABI changes and that should
go into 0.8?
The features that come to mind immediately are
- interactivity
- tags
- gettext support
- interfaces
Features that could be implemented without breaking API/ABI later on -
- more interfaces/implementing interfaces in the plugins
- a new autoplugger
- more plugins
- an extensive testsuite
I'd like to see some SCHED_FIFO (lowlatency scheduling) action in
GStreamer. Whether or not this could make it in by 0.8 is debatable.

And it isn't necessary at the moment ; we can use GStreamer apps with
JACK in non-realtime mode. But if we really want to support professional
audio processing on Linux (yeah ! yeah !), we'll need to be able to do
lowlatency scheduling.

leif

--
Leif Morgan Johnson : http://ambient.2y.net/leif/
Andy Wingo
2003-10-12 02:56:05 UTC
Permalink
Post by Leif Johnson
Post by i***@public.uni-hamburg.de
2) What features do we need that need API/ABI changes and that should
go into 0.8?
I'd like to see some SCHED_FIFO (lowlatency scheduling) action in
GStreamer. Whether or not this could make it in by 0.8 is debatable.
Whether the support could make it there is hit-or-miss, yeah. But the
API could be added. Inspecting thread I see:

priority : The scheduling priority of the thread
Enum "GstThreadPriority" (default 1, "Normal
Scheduling")
(0): Low Priority Scheduling
(1): Normal Scheduling
(2): High Priority Scheduling
(3): Urgent Scheduling

WTF is "urgent scheduling"? But although these map onto
GThreadPriority, they are actually a different enum. Odd.

I think this is the proper place to add realtime priorities
(SCHED_FIFO). At the least we can add (4) Realtime Scheduling. Maybe
even we can get this integrated into GLib. Leif, you up to it? ;)
Post by Leif Johnson
And it isn't necessary at the moment ; we can use GStreamer apps with
JACK in non-realtime mode.
And if Jack has compiled-in capabilities support (this might be going
away, dunno), the libjack thread (that ends up iterating the GStreamer
pipeline) is given RT scheduling.
Post by Leif Johnson
But if we really want to support professional audio processing on
Linux (yeah ! yeah !), we'll need to be able to do lowlatency
scheduling.
<echo>yeah! yeah!</echo> (refusing to punctuate a la francaise)

This is a larger issue than just realtime scheduling. Some scheduler
(maybe opt?) will need to be tweaked not to malloc *anything* while in
PLAYING, and all elements involved in a pipeline will need to do
anything non-rt safe. Perhaps elements can have flags to indicate if
they are RT-safe (like LADSPA)? I think this would also be nice,
GST_ELEMENT_HARD_RT_CAPABLE like LADSPA_PROPERTY_HARD_RT_CAPABLE:

/* Property LADSPA_PROPERTY_HARD_RT_CAPABLE indicates that the plugin
is capable of running not only in a conventional host but also in a
`hard real-time' environment. To qualify for this the plugin must
satisfy all of the following:

(1) The plugin must not use malloc(), free() or other heap memory
management within its run() or run_adding() functions. All new
memory used in run() must be managed via the stack. These
restrictions only apply to the run() function.

(2) The plugin will not attempt to make use of any library
functions with the exceptions of functions in the ANSI standard C
and C maths libraries, which the host is expected to provide.

(3) The plugin will not access files, devices, pipes, sockets, IPC
or any other mechanism that might result in process or thread
blocking.

(4) The plugin will take an amount of time to execute a run() or
run_adding() call approximately of form (A+B*SampleCount) where A
and B depend on the machine and host in use. This amount of time
may not depend on input signals or plugin state. The host is left
the responsibility to perform timings to estimate upper bounds for
A and B. */

(1) and (3) apply directly. (4) just says that the loop or chain
function is O(N) where N is the number of samples. (2) can be relaxed to
say "The plugin will only use APIs known to comply with these realtime
restrictions". Thoughts?

Again, other than that, we just need to add a GstThreadPriority for
REALTIME, and possibly see about getting it into GLib. RT-safety is
difficult, but doesn't require too many A[PB]I changes.

Regards,

wingo.
Benjamin Otte
2003-10-07 16:15:07 UTC
Permalink
Post by iain
Post by Ronald Bultje
The OSS one is written. The ALSA one isn't written yet, because I don't
have a single clue on how ALSA works.
Is there anyone who does?
Not me.
I don't have a clue about the mixer either, so I'm not more qualified than
anyone else anyway :)

Benjamin
Ronald Bultje
2003-10-08 00:38:03 UTC
Permalink
Hi Benjamin,
Post by Benjamin Otte
Post by iain
Post by Ronald Bultje
The OSS one is written. The ALSA one isn't written yet, because I don't
have a single clue on how ALSA works.
Is there anyone who does?
Not me.
I don't have a clue about the mixer either, so I'm not more qualified than
anyone else anyway :)
Well, at least you've found the ALSA docs, which is an accomplishment an
sich. ;).

But yeah, an ALSA mixer is gonna be a problem if noone knows how to do
it, and we really do need one. Iain, who wrote the ALSA part in
gnome-volume-control? I can copy that and let others test that code. ;).

Ronald
--
Ronald Bultje <***@ronald.bitfreak.net>
Linux Video/Multimedia developer
Ted Gould
2003-10-08 01:10:02 UTC
Permalink
Post by Ronald Bultje
But yeah, an ALSA mixer is gonna be a problem if noone knows how to do
it, and we really do need one. Iain, who wrote the ALSA part in
gnome-volume-control? I can copy that and let others test that code. ;).
Unfortunately that code is an older version of ALSA, apparently the API
changed significantly with ALSA 0.9. David Lazaro <dlazaro at well dot
com> volunteered for doing this a while ago, I don't know if he's still
interested.

--Ted
Ronald Bultje
2003-10-08 02:28:02 UTC
Permalink
Hi Ted,
Post by Ted Gould
Unfortunately that code is an older version of ALSA, apparently the API
changed significantly with ALSA 0.9. David Lazaro <dlazaro at well dot
com> volunteered for doing this a while ago, I don't know if he's still
interested.
Leif [CC'ed] just volunteered to have a look at the ALSA docs and see
how hard it is to write an ALSA mixer interface implementation for the
GStreamer ALSA plugin. Let's see how that goes.

Now, it'd be even cooler if Sun would also help us a tiny bit and write
a native sound output GStreamer plugin (and HP, and ... etc.); that way,
we'd have automatic mixer support for Sun's Solaris, too. :). You can
track down audio elements that support a mixer automatically, this isn't
implemented in the gst-mixer example program yet, but it's not hard to
do either - gst-editor shows how to do this, and with a tiny
modification, it's usable in gst-mixer (or gnome-volume-control-2) too.
I can try to implement this so you've got an example of how to do this
if you want me to.

(This is nasty, btw, because how is the mixer going to know which device
properties (and in what format) are needed by the element? For ALSA,
this works completely different than for OSS)

Ronald
--
Ronald Bultje <***@ronald.bitfreak.net>
Linux Video/Multimedia developer
iain
2003-10-08 03:26:47 UTC
Permalink
Post by Ronald Bultje
But yeah, an ALSA mixer is gonna be a problem if noone knows how to do
it, and we really do need one. Iain, who wrote the ALSA part in
gnome-volume-control? I can copy that and let others test that code. ;).
I didn't write it.
I tried to write the 0.9 one, but had no clue what was going on.

iain
--
"Miss Celine Dion sings lovesongs while our cities burn"
Ramón García
2003-10-08 11:36:05 UTC
Permalink
Post by Ronald Bultje
We do that, but we need to define the API of the
interfaces, too.
Wrapping the GLib interface mechanism? Why?

Ramon

___________________________________________________
Yahoo! Messenger - Nueva versión GRATIS
Super Webcam, voz, caritas animadas, y más...
http://messenger.yahoo.es
Ronald Bultje
2003-10-09 00:45:07 UTC
Permalink
Post by Ramón García
Post by Ronald Bultje
We do that, but we need to define the API of the
interfaces, too.
Wrapping the GLib interface mechanism? Why?
No, no. We need to define the API of the *interface*, not of the
interface *mechanism*. So if I make a mixer interface, I need to define
the API of this mixer interface.

Ronald
--
Ronald Bultje <***@ronald.bitfreak.net>
Linux Video/Multimedia developer
Leif Johnson
2003-10-11 01:03:02 UTC
Permalink
Post by Ramón García
Post by Ronald Bultje
We do that, but we need to define the API of the
interfaces, too.
Wrapping the GLib interface mechanism? Why?
Check out gstreamer/gst/gstinterface.c ; GStreamer needs interface
support at the instance level, while GLib (like Java) provides interface
support only at the class level. Pretty cool, IMHO. :)

leif

--
Leif Morgan Johnson : http://ambient.2y.net/leif/
Ramón García
2003-10-13 04:08:03 UTC
Permalink
You suggest that it is necessary to offer the
functionality of deciding inside each different object
whether to expose an interface or not.

Can you post a use case that shows that this is
useful? I think that if different objects expose
different interfaces, they should belong to different
classes (though one can inherit from the other). The
only restriction that this enforces is that an object
cannot make the decission of exposing an interface
dynamically based on its state. However, in that case,
rather than "implementing" an interface, the object
"has got" or "has not got" something. Thus the class
of that object can have a function Interface*
getInterface() to get an instance of that interface,
which can return NULL. That should be different than
implementing an interface.

Ramon

___________________________________________________
Yahoo! Messenger - Nueva versión GRATIS
Super Webcam, voz, caritas animadas, y más...
http://messenger.yahoo.es
Ronald Bultje
2003-10-13 06:52:01 UTC
Permalink
Hi Ramon,
Post by Ramón García
You suggest that it is necessary to offer the
functionality of deciding inside each different object
whether to expose an interface or not.
Can you post a use case that shows that this is
useful?
The OSS specs define that a sound card does not necessarily expose a
mixer. Professional soundcards have hardware mixers. See the 'Note' box
on page 18 of the OSS programming guide, available from
http://www.opensound.com/.

This means that for an object that wraps oss, like osselement, the
question of having a mixer can only be defined at runtime, so you need
to ask the element for whether it implements the mixer interface for
this specific instance or not.

There are more ways to do this. You could make a flag for this that's a
property on the element, but that way, you require another API type
(properties) for the mixer interface, which (imo) is ugly.
A second option is that you make a virtual function in the mixer
interface that queries for whether this is supported or not. Another
option looks like this: you add another interface, required by the mixer
interface, that does this. The nice thing is that this prevents code
duplication if you need this supported thing in more than one interface.
Also, it will not mess up the interface API yourself. I chose for this,
mostly because it allows me to wrap the typecast-macro from element to
interface-type inside this supported-virtual function. Consequently, I
can do casts (GstMixer *mixer = GST_MIXER (element)) which return NULL
if this specific instance doesn't implement the interface, or I can do
casts checks (if (GST_IS_MIXER (element) { .. }) to query for this,
which make this look extremely elegant. It works exactly as the rest of
GObject, but with an integrated, automatic implementation-check.

The name GstInterface, as Benjamin has said before, is probably wrong.
It should be called GstInstanceSupportsInterface or
GstElementSupportsInterface.
Post by Ramón García
Thus the class
of that object can have a function Interface*
getInterface() to get an instance of that interface,
which can return NULL. That should be different than
implementing an interface.
This is basically what we do, but a bit more elegant: the application
doesn't actually have to query; instead, it's done automatically inside
the cast or cast-check.

Ronald
--
Ronald Bultje <***@ronald.bitfreak.net>
Linux Video/Multimedia developer
Ronald Bultje
2003-10-14 00:38:02 UTC
Permalink
Hi Murray,
I'm not following this fully, but it sound like you are talking about
implementing Ginterfaces per-instance rather than per Gtype.
Technically, we do it per-class, with an additional function call to
check whether the specific instance supports it. We're perfectly
glib-compatible. Indeed, for C++, the advantage of automatic
instance-checking-on-case will go away and people will still have to
manually check whether the specific instance supports the interface
implementation after having casted it.

This will never lead to crashes. It will, in the worst case, trigger
some g_warning()s because an interface virtual function was called on an
instance not supporting the implementation.

Please, look at the code. It's very obvious once you look at the code,
and you'll see how simple this it.

Ronald
--
Ronald Bultje <***@ronald.bitfreak.net>
Linux Video/Multimedia developer
Ronald Bultje
2003-10-14 02:36:02 UTC
Permalink
Post by Ronald Bultje
Please, look at the code. It's very obvious once you look at
the code, and you'll see how simple this it.
Can you give me a lxr or bonsai link to whatever code is actually being
discussed here?
interface-per-instance layer:
http://cvs.sourceforge.net/viewcvs.py/gstreamer/gstreamer/gst/gstinterface.h?rev=1.3&view=markup
http://cvs.sourceforge.net/viewcvs.py/gstreamer/gstreamer/gst/gstinterface.c?rev=1.3&view=markup

interface example:
http://cvs.sourceforge.net/viewcvs.py/gstreamer/gst-plugins/gst-libs/gst/mixer/mixer.c?rev=1.4&view=markup
(note the prerequisite in the _get_type() function)
http://cvs.sourceforge.net/viewcvs.py/gstreamer/gst-plugins/gst-libs/gst/mixer/mixer.h?rev=1.5&view=markup
(note that the case/castcheck aren't the standard glib ones - instead,
they're our per-instace-checkers)

app example that shows why this is easy:
http://cvs.sourceforge.net/viewcvs.py/gstreamer/gst-sandbox/gst-mixer/src/mixer.c?rev=1.7&view=markup
(note the if (!GST_IS_MIXER (..)) continue;, our *only* code to check
for this - it's extremely easy)

Ronald
--
Ronald Bultje <***@ronald.bitfreak.net>
Linux Video/Multimedia developer
M***@Comneon.com
2003-10-14 02:55:02 UTC
Permalink
Post by Ronald Bultje
Hi Ramon,
Post by Ramón García
You suggest that it is necessary to offer the
functionality of deciding inside each different object whether to
expose an interface or not.
Can you post a use case that shows that this is
useful?
[snip]
Post by Ronald Bultje
The name GstInterface, as Benjamin has said before, is
probably wrong. It should be called
GstInstanceSupportsInterface or GstElementSupportsInterface.
[snip]

I'm not following this fully, but it sound like you are talking about
implementing Ginterfaces per-instance rather than per Gtype.

Please remember that that is an unusual technique so it will lead to
terrible problems for language bindings. For instance, a C++ API is
determined at compile time, not runtime. In this particular case, that means
that we can't decide at runtime whether or not the C++ class inherits from
one of the base classes. I can think of 2 alternative solutions:

1. Error Codes:
The methods of the Interface return FALSE or a Gerror if they are not
supported.

2. Aggregation:
For instance, GtkTreeView has a
GtkTreeSelection* gtk_tree_view_get_selection() method.
In theory, if the GtkTreeSelection functionality was not supported, it could
return NULL.

Sorry, if I have completely misunderstood, but this sounded bad so I had to
speak up.

Murray Cumming
www.murrayc.com
***@usa.net
M***@Comneon.com
2003-10-14 02:55:03 UTC
Permalink
Post by Ronald Bultje
Please, look at the code. It's very obvious once you look at
the code, and you'll see how simple this it.
Can you give me a lxr or bonsai link to whatever code is actually being
discussed here?

Murray Cumming
www.murrayc.com
***@usa.net
Ronald Bultje
2003-10-14 05:48:05 UTC
Permalink
This really does look like per-instance interfaces,
Yes.
and therefore per-instance API.
No. The API/ABI is exactly the same. The functions will still work.

An instance will always *implement* the interface. However, calling the
functions won't do anything except possibly triggering a runtime warning
from within the virtual functions in the object implementing the
interface that this instance doesn't support it.

What happens if GstInterface->supported () returns FALSE? Does the API
change? No. Does the ABI change? Surely not. Does anything change? Of
course not. It's simply a runtime indication that calling the interface
functions on this instance won't have any effect since this specific
instance doesn't support the interface implementation from its Gtype.

I might be misunderstanding you completely; in that case, I'm sorry.
However, as far as I know, there's really nothing to worry about.

Ronald
--
Ronald Bultje <***@ronald.bitfreak.net>
Linux Video/Multimedia developer
David Schleef
2003-10-14 11:41:05 UTC
Permalink
Post by Ronald Bultje
What happens if GstInterface->supported () returns FALSE? Does the API
change? No. Does the ABI change? Surely not. Does anything change? Of
course not. It's simply a runtime indication that calling the interface
functions on this instance won't have any effect since this specific
instance doesn't support the interface implementation from its Gtype.
On a different topic, what happens if you want to write an element
that implements two interfaces, InterfaceA and InterfaceB, and
both InterfaceA and InterfaceB depend on GstInterface? In that
case, to which interface (A or B) does GstInterface->supported()
refer?



dave...
Ronald Bultje
2003-10-14 11:47:17 UTC
Permalink
Hi Dave,
Post by David Schleef
On a different topic, what happens if you want to write an element
that implements two interfaces, InterfaceA and InterfaceB, and
both InterfaceA and InterfaceB depend on GstInterface? In that
case, to which interface (A or B) does GstInterface->supported()
refer?
typedef struct _GstInterfaceClass {
GTypeInterface parent;

/* virtual functions */
gboolean (* supported) (GstInterface *iface,
GType iface_type);

GST_CLASS_PADDING
} GstInterfaceClass;

Note the second argument in supported ().

Ronald
--
Ronald Bultje <***@ronald.bitfreak.net>
Linux Video/Multimedia developer
David Schleef
2003-10-14 12:36:02 UTC
Permalink
Post by Ronald Bultje
typedef struct _GstInterfaceClass {
GTypeInterface parent;
/* virtual functions */
gboolean (* supported) (GstInterface *iface,
GType iface_type);
GST_CLASS_PADDING
} GstInterfaceClass;
Note the second argument in supported ().
And why go to all this trouble instead of putting a supported()
method in the interfaces that require it? Seems like a lot of
extra code.

Please note also that a "supported" method in the interface will
be a lot more obvious in the documentation than a note that the
interface depends on GstInterface.



dave...
Ronald Bultje
2003-10-14 15:24:05 UTC
Permalink
Post by David Schleef
And why go to all this trouble instead of putting a supported()
method in the interfaces that require it? Seems like a lot of
extra code.
I've explained this in Barcelona: it's duplication of code. We need to
define the virtual function supported for each interface that requires
it. The function for each supported function is the same. So why not
generalize it? That's what this is for! Besides, I want to automate this
supported()-checking during the cast, and then a generic macro is
useful. The lot of extra code will end up in the specific interfaces
then.

I need this. I want this. You don't have to use it in your interfaces if
you don't want to. I do.

Ronald
--
Ronald Bultje <***@ronald.bitfreak.net>
Linux Video/Multimedia developer
David Schleef
2003-10-14 16:32:06 UTC
Permalink
Post by Ronald Bultje
Post by David Schleef
And why go to all this trouble instead of putting a supported()
method in the interfaces that require it? Seems like a lot of
extra code.
I've explained this in Barcelona: it's duplication of code. We need to
define the virtual function supported for each interface that requires
it. The function for each supported function is the same. So why not
generalize it?
Contrariwise, why generalize it? You added 248 lines of code to the
core, and a new interface to each class that uses it. The alternative,
unless I am really not understanding something, is approximately one
line of code in each interface header file, and 5 lines of code in
each interface that uses it.

Moreover, having this code in each interface makes it easier to
understand. GstInterface isn't.
Post by Ronald Bultje
That's what this is for! Besides, I want to automate this
supported()-checking during the cast, and then a generic macro is
useful. The lot of extra code will end up in the specific interfaces
then.
I don't like this. You are overriding and changing the meaning
of GInterface. It may be a cute trick, but I have yet to see
any problems it actually solves.

Perhaps I'm really not getting it, but you want to change the API an
application uses to get a "sometimes" interface from an object from:

foo = GST_FOO(some_object);
if (!gst_foo_supported(foo)) {
return;
}

to

foo = GST_FOO(some_object);
if (!foo) {
return;
}

with proper magic in the definition of GST_FOO(). Or perhaps:

supported = GST_INTERFACE(some_object);
if(!gst_interface_supported(supported, GST_TYPE_FOO)){
return;
}
foo = GST_FOO(some_object);

In the second case, you have a macro that mostly acts like a
casting macro, but in certain cases, it will return NULL. This is
unlike anything else in the GObject model.

In the third case, you have more code, and expect the app developer
to comprehend GstInterface, and its relation to other interfaces,
in addition to anything else.

I think I'm the only one that has spent the time trying to figure
out what you're doing. In my opinion, you are _way_ overengineering
this, in an inappropriate way and place. The appropriate place for
doing something like this is in glib, and it is probably best done
as a special kind of GInterface, not as a subclass.

Note that in my first code snippet above, the only documentation
necessary is:

"All gst_foo_* functions must be proceeded by a call to
gst_foo_supported(), to make sure that the object instance
actually handles the GstFoo interface."

This is _simple_.

Again, I may be completely missing the boat. If so, let me know.



dave...
Ronald Bultje
2003-10-15 00:45:05 UTC
Permalink
Hi Dave,
Post by David Schleef
In the third case, you have more code, and expect the app developer
to comprehend GstInterface, and its relation to other interfaces,
in addition to anything else.
I don't want the app developer to comprehend GstInterface. I want it to
be automated.
Post by David Schleef
I think I'm the only one that has spent the time trying to figure
out what you're doing. In my opinion, you are _way_ overengineering
this, in an inappropriate way and place. The appropriate place for
doing something like this is in glib, and it is probably best done
as a special kind of GInterface, not as a subclass.
Overengineering? Maybe. It's simply something I need in more than one
case, so I generalized it. I don't mind it not being part of the core,
don't get me wrong there. That said, I also don't care much about binary
size or anything - I'm not an embedded application developer. My goal is
simply to make something that will be easy for the application developer
to do. I consider this simple and logical. If each of my interfaces has
a supported() function, I'm sure I can write applications too. However,
I'd also expect many questions like "why didn't you generalize that?".

That said, your code snippets are slightly wrong. In any case, you would
always have to check the cast, since not all GstElements implement a
given interface. It will still trigger a warning + return NULL (and then
probably crash, since you didn't check for that) if I cast an avimux
GstElement to a GstMixer, even if you don't use GstInterface's trick. I
_always_ need to check the return value. In my case, I simply combine
these two into one call - that being the cast. So correctly, your code
snippet would look like:

..
if (!GST_IS_MIXER (element))
return;
mixer = GST_MIXER (element);
if (!gst_mixer_supported (mixer))
return;
..

And I can omit the second check because it's automated in the first
check. That's the advantage, I automate all checking into one call. I
like that. That's the _only_ reason why I did it.

Imagine I don't do it. One day, someone else will stand up that does
want to automate it into one call, since having to *always* call two
functions instead of one is annoying. We'll start with adding the
supported() virtual function to GstMixer's interface class struct; next,
we'll make automatic cast-checking like I did in GstInterface because it
saves us from having to manually check for instance-supported()ness. And
in the end, each interface will duplicate all code that is currently in
GstInterface. To *prevent* that, I "overengineered" this to be
generalized from the beginning. I don't consider that overengineering, I
simply consider that design.

You might be able to do this differently (read: easier). If so, please
propose it. But don't make an app developer make two function calls if I
can do it in one.

Ronald
--
Ronald Bultje <***@ronald.bitfreak.net>
Linux Video/Multimedia developer
i***@public.uni-hamburg.de
2003-10-15 08:39:08 UTC
Permalink
Post by Ronald Bultje
if (!GST_IS_MIXER (element))
return;
mixer = GST_MIXER (element);
if (!gst_mixer_supported (mixer))
return;
..
And I can omit the second check because it's automated in the first
check. That's the advantage, I automate all checking into one call. I
like that. That's the _only_ reason why I did it.
You know that in this example the _same_ element could return TRUE or FALSE
depending on the device property or the element's state, right?
Which means you can't rely on typecasts anymore.
That does not look like a good idea to me. Neither in GStreamer nor in glib.

Benjamin
Ronald Bultje
2003-10-16 00:19:07 UTC
Permalink
Hi Benjamin,
Post by i***@public.uni-hamburg.de
You know that in this example the _same_ element could return TRUE or FALSE
depending on the device property or the element's state, right?
Which means you can't rely on typecasts anymore.
I will always have that, no matter what system I choose. Even if I
require every call to my mixer to be preceeded by a call to
->supported() instead of relying on the casted object, I have serious
races.

I don't care. And this is serious. I really don't care. There is no
solution. Except for doing proper programming in one's application.

At least for the oss/v4l/v4l2 elements, they all emit signals for
open()/close(), so by knowing this (maybe I need to document that), I
can know when my casted mixer-object stops being valid.

Ronald
--
Ronald Bultje <***@ronald.bitfreak.net>
Linux Video/Multimedia developer
M***@Comneon.com
2003-10-14 07:01:05 UTC
Permalink
Post by Ronald Bultje
http://cvs.sourceforge.net/viewcvs.py/gstreamer/gstreamer/gst/
gstinterface.h?rev=1.3&view=markup
http://cvs.sourceforge.net/viewcvs.py/gstreamer/gstreamer/gst/gstinterface.c
?rev=1.3&view=markup
http://cvs.sourceforge.net/viewcvs.py/gstreamer/gst-plugins/gst-libs/gst/mix
er/mixer.c?rev=1.4&view=markup
Post by Ronald Bultje
(note the prerequisite in the _get_type() function)
http://cvs.sourceforge.net/viewcvs.py/gstreamer/gst-plugins/gst-libs/gst/mix
er/mixer.h?rev=1.5&view=markup
Post by Ronald Bultje
(note that the case/castcheck aren't the standard glib ones - instead,
they're our per-instace-checkers)
http://cvs.sourceforge.net/viewcvs.py/gstreamer/gst-sandbox/gst-mixer/src/mi
xer.c?rev=1.7&view=markup
Post by Ronald Bultje
(note the if (!GST_IS_MIXER (..)) continue;, our *only* code to check
for this - it's extremely easy)
This really does look like per-instance interfaces, and therefore
per-instance API. It may be easy for you to implement and use, but it's
still going to be a problem for language bindings. A C++ instance can not
decide at runtime what base classes it has. A Java object can not decide at
runtime which Interfaces it implements. Languages such as Python might be
able to do this, but it's always going to be hacky.

I don't see why Aggregation wouldn't work just as well here without
distorting the Gobject system.

Murray Cumming
www.murrayc.com
***@usa.net
M***@Comneon.com
2003-10-14 07:01:05 UTC
Permalink
Post by Ronald Bultje
No. The API/ABI is exactly the same. The functions will still work.
An instance will always *implement* the interface. However,
calling the functions won't do anything except possibly
triggering a runtime warning from within the virtual
functions in the object implementing the interface that this
instance doesn't support it.
Hmm, that's not too bad then, and C++ can probably live with it. It would
just demand more care from the programmer, instead of the compiler checking
the API for him.

I still think that aggregation would be the more obvious way to do it. It's
easier to know that none of the aggregated interface's method would work if
I get a NULL when I try to get the interface itself. I think that's easier
than trying to remember that I need to check the return code of method 1 in
order to call method 2. Again, gtk_tree_view_get_selection() is a fairly
good example of this.

Murray Cumming
www.murrayc.com
***@usa.net
Ramón García
2003-10-16 02:56:07 UTC
Permalink
I do not understand that. Why should a mixer available
only sometimes? And in that case I find it more clear
to have a method get_mixer (which can return NULL).
The word "get" implies something that you might have
or have not. "Implementing" an interface suggest
something that a device "is" (in the permanent sense
of the word) capable of. I agree with using interfaces
dynamically for properties that depend on the
hardware, but are permanent.

Ramon

___________________________________________________
Yahoo! Messenger - Nueva versión GRATIS
Super Webcam, voz, caritas animadas, y más...
http://messenger.yahoo.es
Thomas Vander Stichele
2003-10-17 20:54:02 UTC
Permalink
Post by Ramón García
I do not understand that. Why should a mixer available
only sometimes?
There are devices without software mixers.


Dave/Dina : future TV today ! - http://davedina.apestaart.org/
<-*- thomas (dot) apestaart (dot) org -*->
That's all changed for good
No more worries and doubts
The good will come out
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! - http://urgent.rug.ac.be/
Benjamin Otte
2003-10-16 10:30:03 UTC
Permalink
Post by Ronald Bultje
Hi Benjamin,
Post by i***@public.uni-hamburg.de
Which means you can't rely on typecasts anymore.
I will always have that, no matter what system I choose.
YOU CANNOT RELY ON TYPECASTS ANYMORE!
The glib equivalent of (GstSomething *) may or may not work depending on
situation.

Sounds so bad that it should definitely be different.

Benjamin
Ronald Bultje
2003-10-16 11:54:12 UTC
Permalink
Hi Benjamin,
Post by Benjamin Otte
YOU CANNOT RELY ON TYPECASTS ANYMORE!
The glib equivalent of (GstSomething *) may or may not work depending on
situation.
Yes. We simply extend the meaning of the term 'typecast', we're not
actually breaking something terribly. You see a typecast as a class. I
see it as an instance. Both are valid given the gobject model.
Post by Benjamin Otte
Sounds so bad that it should definitely be different.
Sounds perfect to me. I think we just have different opinions on this,
it's that simple.

Ronald
--
Ronald Bultje <***@ronald.bitfreak.net>
Linux Video/Multimedia developer
Loading...