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

[David I. Lehn]

* Yoann Vandoorselaere <yoann at mandrakesoft.com> [20010515 15:31]:
> On 15 May 2001 13:23:03 -0400, David I. Lehn wrote:
> > 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.
> 

Yes.  We all have time issues.  And yes, it's hard to continue coding on
a project when a company eats one of the main developers. ;)  But hey,
we did fire off the first official release at one point.


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

I'm not sure what point you are trying to make.  It's not just that OMS
happens to be hard to understand (for me at least).  I think it will
require a -lot- of work to get to the point of being as flexible and
complete as GStreamer is -now-.  And even if someone put the time into
improving the OMS core, I'm not sure what advantages this has in the
end.

I didn't just randomly pick GStreamer.  I did look around at other
frameworks and projects to see their status and where they were headed.
After hanging out with the GStreamer developers for a while I figured
they had the most interesting code with a high likely hood of jumping
over the competition.  And yes, the competition includes OMS.

It really doesn't take long to understand the high level GStreamer API.
And it's a lot more flexible than what OMS has right now.  It's easy to
switch around which elements of a pipeline are in threads and easy to
add filters and so on.

I also looked at other issues OMS has been trying to handle.  I think it
will be rather easy (maybe even trivial) to add GStreamer support for
hardware decoders.  It's just a matter of creating the element and
hooking up the data flow graph properly.  Hardware decoder support in
OMS has been a bit shady as far as I can tell.  I don't have a hardware
decoder on principle ;) but it's nice to see a framework design where it
looks straightforward how to support such devices.


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


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

I'm certainly not trying to battle anyone here.  I really just want a
great media player that can play DVDs.  And I'd like to see it done with
maximum code sharing and reuse.  I've got lots of ideas for improvements
to how commercial players work... and I fear the current OMS core is
just too immature to handle it and will take too long to bring it up to
where a GStreamer core will bring it.

Everyone: please take a look at GStreamer and point out anything I may
be missing.  The few things like QoS and event (EOS, etc) improvements
will happen at some point but even without those I really can't see
-any- disadvantages to using gst libraries in OMS.  Worst case is we
just use the core gst lib and rewrite all the plugins we need.  Even in
that case I think we'd be better off.

Flames? Comments?

-dave
-- 
David I. Lehn <dlehn at vt.edu>  | http://www.lehn.org/~dlehn/
Computer Engineering Graduate @ Virginia Tech in sunny Blacksburg, VA