Gstreamer [WAS: Variable Framerate, plugin based video editing tool]

* Steve Lhomme <[email protected]> [2004-01-29 22:16:54 +0100]:

<snip>
> You should know then that they simply don't want to cooporate with us. 
> (just collaborate with we agree with all they say and work their way)
rich felker doesnt want to cooperate. other probably will, but they
have high requirements. I personally wanna see media-api to fulfil
these. So we have to read the mplayer-g2 list carefully. Its very
interesting.

<snip>
> We are going to investigate the GStreamer way and see if it's enough. 
> That would be a lot of work already done (I'm very lazy ;).
On a first view I see some problems w/ gstreamer:

* muxers are implemented as filters (how shoud this work ?!)
  this brings us huge trouble! muxers brigde between frame-sequences
  and binary streams. we need a _clear_ decision between them, i.e.
  frames have timestamps/time intervals, binary streams are simply bytes
  
* what are the factories for ?! 
  why cant we simply have list of codecs, which transform from encoding
  A to B ? Allocating one should look like this:
  
    mmapi_codec_alloc ( 'mp3', 'pcm16' );
    
  Also we require a query interface to list off the installed codecs
  (this list could also be read from a config file, so we can support 
  load-on-call)
  
* the pads could be left off, if we would divide all devices into 
  strict groups. For example a codec always converts _one_ stream
  from A to B - so it always has _one_ input and _one_ output.
 
* gstreamer relies on glib - I do _not_ want to use it, since its
  bloated (in times of 1.x it was good), and many other projects 
  also dont want it. these days glib is good for GUI-centric 
  applications (together w/ gtk), but not for fundamental codec APIs.

>From start of this project, we were talking about a _CODEC_ API,
_NOT_ an allround a/v-processing-library.

Gstreamer mixers things together, which are completely different
(i.e. codecs, io-streams, muxers, filters), so it implies a very
generic api for all this kind of objects. This is nice for intuitive
design of filter chains, but adds unnecessary overhead in things
like realtime applications.
    
So Gstreamer may be seen as a superset of our media-api, but I wan 
to keep the media-api small and performant, otherwise other projects
won't use it.


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT services

  phone:     +49 36207 519931         www:       http://www.metux.de/
  fax:       +49 36207 519932         email:     [email protected]
  cellphone: +49 174 7066481
---------------------------------------------------------------------
 DSL-Zugang ab 0 Euro. -- statische IP -- DSL-Flatfrate            --
 Diese Mail wurde mit UUCP versandt.      http://www.metux.de/uucp/
---------------------------------------------------------------------