[gst-devel] Re: [livid-dev] a new direction for oms
yoann at mandrakesoft.com
Wed May 16 00:39:02 CEST 2001
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.
> 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
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
More information about the gstreamer-devel