Re: GMF (was Re: GScrea..., um, GStreamer 0.0.9 released)

[Erik Walthinsen <omega cse ogi edu>]

On 1 Nov 1999, Elliot Lee wrote:

> This isn't quite true - I did a fair amount of workk on it in June/July, got
> it to the point of having a working media player and basic set of plugins,
> and then had other stuff to do (OG).
That is about 4 months ago, though.  I am definitely impressed by the set
of plugins you've got, though I haven't had a chance to get all the pieces
together to actually run a QT movie through it.

> Again, this isn't quite true. GMF uses what makes sense, and since a lot of
> DirectShow makes sense, I used some of those ideas in its design. I also
> looked at a lot of other architectures, used ideas from them, and came up
> with new solutions to some problems that DShow solved in different ways.
OK, I haven't looked at it close enough, and yes, that was a bit of a
knee-jerk reaction based on my just under the surface scan of it.  I don't
know enough practical DirectShow (as in, I've never coded against it) to
be able to make a good comparison, but I have read extensively through the
docs and a section of a book on it, and it does look very similar
(roughly the same namespace, same connection structure, timing and QoS
stuff looks similar).

> It is just as illogical to say that all of DirectShow is bad and should be
> ignored or left at a distance as it is to say that all of DirectShow is
> good.
I never said that, just implied that ;-)  Actually, I do think DirectShow
got a lot of things right, but I also know that they got some things
wrong.  I've been doing research in this exact field for a year and a half
now, working with a somewhat crufty (old age, a lot of code over-designed)
pipeline doing bleeding-edge research.  We've collectively discussed these
issues for thousands of hours in heated debates and such, and I think I've
gotten a pretty good idea of what's wanted and not wanted, in the context
of both our own code and others, like DirectShow. (one of the guys who did
a lot of the transport code also 'got to' port the stuff over to 
NT/DirectShow, and had only a few good things to say about the experience) 

My goals in writing GStreamer were two-fold: provide something for the
world to use that kicked some DirectShow butt, and provide something to
replace the setup we have at work.  With some relatively minor changes in
GStreamer to bring it up to what they want, it sounds at this point like
the latter might happen.  Pretty much everything we agree is broken with
our current software is fixed in GStreamer, and the recent explanation of
our next grant by the head Prof almost precisely described what I have
(I'd had about 75% of 0.0.9's state at the time he gave us that overview). 

> Why will plugin writers care about what libgmf is using to implement the
> framework? They don't have to pay attention to it.
Last I checked (confirmed just now) every plugin has some CORBA code in
it.  This is something I'd like to avoid, since IMO it's not necessary. 
The concensus at work is the same.  It's just too heavy to use when timing
is critical (media applications need sub-millisecond timings in certain
circumstances), even given a scary-fast ORB like ORBit.

> I don't think you've looked at GMF closely enough to be able to give a good
> commentary of the issues involved. If you see actual problems, fine, I just
> dislike people's speculation. (i.e. If you have benchmarked it and speed
> sucks, that is one thing, but saying that you think that CORBA will slow it
> down without you even knowing how it works is entirely another).
Granted, I haven't benchmarked it.  It would be interesting to do so, if
we can either get equivalent filter code running, or just microbenchmark
the library code.  I would suspect that the benchmarks would bear out my
claim that using CORBA is going to be slower than doing things directly.

There's still the open question of what advantages exactly CORBA does
provide.  Network transparency, maybe, but I'm not so sure that's a useful
thing, given transport protocols that are designed to handle *all* the
stream communication, not just the bitstream. Embedding, maybe, but having
CORBA objects for each filter is only useful if you're going to be mucking
with them (as far as I understand CORBA), and I can't see anyone mucking
with a filter graph via Bonobo or DOM or some other higher-level
abstraction.  Doing filter-graph stuff pretty specialized, so having a
relatively specialized API for doing so makes sense.

If there are advantages I haven't thought of, please let me know, it may
accelerate my schedule for adding a CORBA layer on top of GStreamer. 

> But, I don't want to discourage people from working on their favorite
> projects, and it's not like I have put much work into GMF lately. Maybe
> next weekend I will make a new release for people to try out, we'll see.
May the best library win ;-)

TTYL,
    Omega

         Erik Walthinsen <omega@cse.ogi.edu> - Staff Programmer @ OGI
        Quasar project - http://www.cse.ogi.edu/DISC/projects/quasar/
   Video4Linux Two drivers and stuff - http://www.cse.ogi.edu/~omega/v4l2/
        __
       /  \             SEUL: Simple End-User Linux - http://www.seul.org/
      |    | M E G A           Helping Linux become THE choice
      _\  /_                          for the home or office user