[gst-devel] Re: [livid-dev] a new direction for oms

[Yoann Vandoorselaere]

On 15 May 2001 18:28:20 -0400, David I. Lehn wrote:
> * Yoann Vandoorselaere <yoann at mandrakesoft.com> [20010515 15:31]:
> > On 15 May 2001 13:23:03 -0400, David I. Lehn wrote:

[...]

> > > What I've been trying to do is use GStreamer as a core part of OMS.
> > > After looking at the code for a while I think I've figured out how to do
> > > a first pass at a conversion.  This is an arms length from a complete
> > > OMS rewrite.  It basically throws out a ton of OMS code:
> > > 
> > >  * plugin system
> > >  * most plugins (codecs, input, video, audio)
> > >  * buffering (which was a horrible mess IMHO)
> > 
> > Sorry, but this probably proof you did not understood the concept... At
> > least give arguments.
> > 
> 
> I'm confused here.  Understand what concept?  I've certainly been really
> confused by most of the OMS code.  I think that's a bad sign.  I suggest
> taking a look at how GStreamer does things.  It really is much more
> elegant than what OMS has now.  Feel free to disagree...

I was talking about the buffering model, what do you have against it ?
It surely would have being cleaner to use atomic operation (fairly
portable), and operating on an array to avoid locking (I think that is
the way Gstreamer does. I may be wrong trought.) But AFAICT you were one
of the person to disagree with it :)

> > >  * threading model
> > >  * what little sync there was
> > >  * um... the API
> > > 
> > > and replaces everything possible with GStreamer parts:
> > > 
> > >  * plugin system
> > >  * the absurd number of supported plugins for -everything-
> > >  * data passing model, threads, cothreads, all that jazz
> > >  * sync (!)
> > > 
> > > There's more to GStreamer than just that but those are some major
> > > hurdles that OMS code would no longer have to deal with directly.  Other
> > > significant advantages of using GStreamer:
> > > 
> > >  * actively developed
> > >  * there are people at RidgeRun who are -paid- to work on this stuff
> > >  * core will improve without us lack-of-time-livid-people
> > >  * can eventually do fancy gst stuff like autoplugging (see below)
> > >  * improvements we make can propagate back to GStreamer to help all
> > >    GStreamer apps (ie, new plugins, bug fixes, etc)
> > > 
> > > So what is left for OMS to do?  Navigation and UI.  This really hasn't
> > > been looked at too deeply by the current GStreamer test apps.  There are
> > > a number of issues to deal with and plenty of code to write.
> > 
> > This is total nonsense !
> > In this case, why don't we just all jump in Gstreamer development,
> > instead of stilling it's code, and working on a fork of it.
> > You should have remembered the lesson with the libvo experience.
> > 
> > And do you think OMS is just about Navigation and UI ? No it's not, 
> > people here are also interested with core stuff. At least I am, and 
> > probably lot of other developers too.
> > 
> > As one of the most active developers (in the time it was being developed),
> > I really think that if our product isn't at the Gstreamer level, we should 
> > just jump in Gstreamer development. Instead of trying to win a battle that 
> > does not exist.
> > 
> 
> I think there is a misunderstanding here.  I'm not suggesting a fork or
> "stealing" code.  I'm suggesting using GStreamer libraries.  And what's
> wrong with jumping in GStreamer development?  That's what I'm doing. ;)
> 
> I know it's fun to hack on core APIs with the hope millions of people
> will use the code.  But it's hard, takes lots of time, takes a few
> revisions, probably a few people, much motivation, and [here's the
> important part] has already been done.
> 
> I guess I should state my goals for all this:  I want to watch DVDs on
> my Linux box using free software.  That's just about it.  If this work
> happens to create a nice media player or framework too, well great.  But
> I personally don't have the time to reinvent the wheel or wait around
> for other people to do it.  Media frameworks are complex beasts.
> Getting DVDs to work is a hard enough challenge.  There are numerous
> projects working on it now and no one has shown a player nearly as
> complete as even a terrible commercial one.

I agree.

> If you or whoever else would like to work on another core, great!  But
> first I'd ask that you take a serious look at frameworks such as
> GStreamer.  Then post here and gstreamer-devel list with improvements
> you intend to make in your core.  The GStreamer developers would -much-
> rather help to resolve any of these issues than see a repeat of the
> massive effort it takes to create a clone of what they already have
> done.

Didn't said that. If I continue working on a media player, it will be on
the one that is the more evoluted, and have the best perspective that I
can think of... It clearly would probably be Gstreamer at this time.

[...]

-- 
Yoann Vandoorselaere | C makes it easy to shoot yourself in the foot. C++ makes
MandrakeSoft         | it harder, but when you do, it blows away your whole
                     | leg. - Bjarne Stroustrup