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

Enrico Weigelt wrote:

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

OK ok. I'll have a look.
One issue I'm thinking about with a powerful/flexible media API is the 
way it can handle OGG + Vorbis. Because the timecode can only be known 
by the codec, not the container... That implies a rather tricky design.

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

Well, this is the case in DirectShow too. What is the problem with that ?

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

I haven't checked GStreamer that far yet. One of the major problems of 
GStreamer is that you have to compile the documentation :/

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

I can think of examples with either multiple input or multiple outputs...

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

Well, as long as it runs on many OSes I don't have any problem with it. 
As long as it doesn't do things that are already done (better) in the OS.

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

Mmm, no. My real-time DJing software is a example of things I want to 
do. It's not just about codecs and containers.

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

Maybe GStreamer is not suited for real-time/low-latency. But that's 
another problem. And I really want to know if that's the case or not.

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

Well, maybe the media-api is name is not good. At least it's not what I 
have in mind. It should handle more than just muxing/demuxing. And 
GStreamer/DirectShow is the kind of thing I have in mind.