[gst-devel] 0.8 in 2.6 ?

[Ronald Bultje]

Hi Benjamin,

On Mon, 2003-10-06 at 16:18, in7y118 at public.uni-hamburg.de wrote:
> 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.

> 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.

> 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 <rbultje at ronald.bitfreak.net>
Linux Video/Multimedia developer