[gst-devel] Doing new releases

Ronald Bultje rbultje at ronald.bitfreak.net
Wed Aug 20 07:54:11 CEST 2003


On Wed, 2003-08-20 at 15:44, in7y118 at public.uni-hamburg.de wrote:
> > What's even more worrisome is that there is not really a good reason to
> > start doing 0.8 anytime soon at all.  The more important things we
> > should be working on, like support for DVD, rework of event system, ...
> > (ie, all the reasons we thought we needed a 0.7 branch for :)) has been
> > largely untouched.  The debug rewrite looks good, and other things look
> > good to, but ultimately they have very little effect on our stated goals
> > for 0.7.x
> > 
> I think you're looking at it the wrong way. The features that have been put in 
> place are a solid foundation for changes that we wanted to do. And they 
> certainly are user visible- Debugging is available to apps and plugins in HEAD 
> (they only need to start using it ;)) - I did this only because Rhythmbox 
> debugging sucks compared to GStreamer and I wanted a good debugging system 
> there. The caps rewrite allows better colorspace conversions and MPEG4 
> integration - which means more supported video formats.
> The next thing you'll see from me is tagging which will be very visible for 
> Rhythmbox. Actually all my work in HEAD is directly geard towards the 
> development of Rhythmbox as my primary goal right now is to get a Music Player 
> into GNOME that is based on GStreamer to get more users using our lib. 
> Currently we're losing too many bug reporters to xine.

I strongly agree with Benjamin here. What we've been doing until 0.6.x
was to lay out a basic foundation for a good multimedia framework. What
our *primary* goal for 0.8.0 has to be, is to simply "make things work".
Sorensen decoding should work. Period. ASF demuxing should work. No
discussion.

What we're currently doing, is to extend these 0.6.x foundations to be
able to do what we want to do, but still in a nice, solid and clean
fashion. Sure, I could write a muxer that needs 3 properties set
(framerate, bitrate, is_streaming) in order to function, but that's
*not* gstreamer'ish. In gstreamer, it just works, no matter what you
throw at it. And else, it'll give a visible and clear error to the user,
stating what went wrong ("Error: you cannot connect a cowsource to a
mousesink") and optionally how to resolve this ("use a mouthsink
instead"). We don't do this yet, but we're close. All basics are there.
Other products ("competitors") simply cannot do this.

Sure, DVD playback is one of our pointers for 0.8.0, but my *primary*
focus will be playback of common formats in a gstreamer'ish fashion in
gst-player/totem. My secondary focus will be gst-rec in a gstreamer'ish
fashion (look at avimux in 0.6.x - it's horrible - not that avimux in
HEAD is perfect, but it works quite ok). I've broken ABI, API and all
interfaces a couple of times in HEAD, simply to make sure that 0.8.0
will rock! Benjamin is doing the same thing with tagging right now.
Sure, he'll break things. But in the end, it'll be better! And Dave is
probably #1 bug closer in Gnome's bugzilla statistics right now. ;).

DVD playback is "just" another thing. Martin Soto has been working on
this for a while, and he had a good basis. I think he wanted to work on
integrating DVD events in the Gst event system next (and user input
events, too, i.e. all the things Thomas just listed), but I didn't see
any results yet. :-(. However, that doesn't mean it won't get fixed. In
short, don't worry, 0.8.0 isn't there yet. Our one and only goal for
0.8.0 should be to make it *rock*. Rock means that it works, rock means
that it's foundation is steady and is broadly appliccable, and it
especially means 'gstreamer'ish'ity'.

As long as these are our goals and we know how to get there (and we
do!), and as long as we're having the current development pace (face it:
we have a relatively big team of very active developers), I know we'll
end up where we wanted to be.

Just a small pep-up-talk. ;).

Ronald

-- 
Ronald Bultje <rbultje at ronald.bitfreak.net>





More information about the gstreamer-devel mailing list