[gst-devel] a new direction for oms

[David I. L. <dl...@vt...>]

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.

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.

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

One interesting feature of GStreamer is autoplugging.  OMS has the start
of such a system to pick decaps and codecs based on magic data
detection.  But GStreamer has a more advanced system.  The theory is
that eventually 'gstmediaplay /dev/dvd' would create a dvd player out of
low level parts.  But I think there is much work to do with nav and so
on that may be beyond such a system... not sure yet.  It may be that
custom apps like OMS are needed to deal with such things in a sane
manner.

What have I done so far?  I've gutted OMS.  Really gutted.  Massive
reduction in code size.  There are some little test apps in GStreamer
CVS called mpeg2parse#.  They do basic playing of VOBs.  They look like
they are in sync... but I'm not sure how to really test this.  Plan is
to hook that up to a DVD source, and add a nav component to control the
data flow.  I'm sure it's not as easy as hooking up legos but we shall
see.

What needs to be done?  Quality of Service.  There's some basic support
for this (maybe) but I think it's going to be reworked in the somewhat
near future.  This is really needed to drop frames when we are behind.
UI issues: user feedback, highlighting, still frame things (must store
and redraw sometimes I think).  Maybe some subpic work... I haven't
tried the GStreamer code for that yet.  Plus all the DVD VM and menus
and so on.

In the end I think this would be a good direction to take.  It would let
LiViD people concentrate on DVD and UI related issues rather than a
whole media framework that will probably end up duplicating pieces of
GStreamer poorly.

As always, I don't know when this will get done.  If anyone wants to
help let me know.

Comments?

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