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

[Yoann Vandoorselaere]

On 15 May 2001 13:23:03 -0400, David I. Lehn wrote:
> Hi,
> 
> [This is directed at LiViD people but I thought I'd cc it to GStreamer
> list as well for comments]
> 
> I'm sure most of you have noticed the lack of development on OMS
> recently.  This is mainly due to lack of time and wandering interests of
> the developers.  This is unfortunate because OMS is a neat little
> project in free software land.  We had visions of a better day when this
> all started.

The problem started because Dent didn't have the time to continue
working on it, and that developers didn't had any direction.

> I can't speak for the other developers but I'd like to mention what I've
> been up to in my spare moments.  Mainly I've been playing around with
> GStreamer (http://gstreamer.net/).  It's a really nice media processing
> framework.  You all should go check it out.
> 
> Now why is this important?  Well, GStreamer has all the pieces we need
> to make OMS a whole lot better with minimal effort.  I really don't mean
> to speak ill of the OMS code since dent (who wrote the majority of it)
> has done a great job.  But... well... it's real mess and very hard to
> understand.  I tried.  This is probably why no one wants to jump in and
> help... it's really hard to pick a little piece to work on without
> understanding the whole thing.  It's not as flexible as it could be and
> some issues seem to have been hacked on rather than designed in.  All
> you hackers know what I mean.  Projects tend to do that and over time it
> needs to be fixed.

I think you didn't tryed hard enough.
I'm one of the person that jumped in the development, and OMS, even if
it isn't very well written, is not hard to understand compared to other
projects.

As any other project, there is a learning curve, which is more or less
important depending on what the program is trying to do. In the case of
OMS, we are talking about a media player, which isn't something simple.

Think about the kernel learning curve, you wouldn't get the big picture
in 1 month, nor anyone would do in his whole life.

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

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

-- 
Yoann Vandoorselaere | Murphy's law : If anything can go wrong, it will.
MandrakeSoft         | O'Tool's commentary : Murphy was an optimist.