[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-multimedia
Subject:    Re: gstreamer instead of mpeglib
From:       Carsten Griwodz <griff () ifi ! uio ! no>
Date:       2001-04-02 5:50:35
[Download RAW message or body]

Hi,

I looked at the gstreamer for the first time when Martin sent the pointer
a few days ago. I didn't look with data processing in mind, but for the
possibility to integrate network protocols and data forwarding.

I was interested in details that we need for our RTSP/RTP proxy cache and
client. I would have been quite happy to adopt their code because we don't
have any reasonable graph managment, no reasonable negotation of data
types between stream handler etc etc.

The following things are not there:
- they will consider seeking in the future, we have to have it now
- their pipes are static, we need threadsafe dynamic plugging and
  unplugging (an RTSP client pauses, data forwarding is stopped, but data
  is still stored on the disk)
- we need control data travelling upstream as well as downstream (RTCP
  packet loss notifications)
- we need events going from the stream handlers to the graph manager,
  which must be able to react by reconfiguring parameters or rearranging
  the graph without stopping the flow

I am not sure whether any of those points are important for you.

CU, Carsten


On Mon, 2 Apr 2001, Stefan Westerfeld wrote:

>    Hi!
> 
> On Sat, Mar 31, 2001 at 04:56:53PM +0200, Martin Vogt wrote:
> > GStreamer seems to have a nice design and it supports
> > much more formats, even encoding!
> > Anyone interested in writing GStreamer/Arts 
> > PlayObject plugins?
> > 
> > I don't say that we should rm -rf mpeglib now, but
> > in the future (KDE 3.0?) GStreamer will be the
> > better option.
> 
> I am not too sure about it. Of course, interoperability is a nice thing to
> have. But GStreamer uses glib (which currently no other part of KDE/aRts
> requires - although aRts /supports/ glib style main loops), and a C based
> object oriented model based on that.
> 
> Ultimately, having a native aRts lowpass filter for sound or native aRts
> mp3 decoder will be more optimal. The code will be prettier, the performance
> might be better, the dependancies might be less, the look&feel and integration
> in the IDL stuff and flow system might work more sane.
> 
> Although I see that some work might be left to do - currently mpeglib decoders
> are not integrated the way in aRts that I would wish they were: a lot of talk
> has gone into this (seeking/streaming PlayObjects). If you ask for my personal
> opinion, I'd be more happy with cleaner, more aRts-ish PlayObjects for mp3s
> than with depending on GStreamer to do such a simple task as playing an mp3.
> 
> But well, it's up to whoever writes the code to choose what to do ;)
> 
>    Cu... Stefan
> -- 
>   -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany
>      KDE Developer, project infos at http://space.twc.de/~stefan/kde *-         
> _______________________________________________
> Kde-multimedia mailing list
> Kde-multimedia@master.kde.org
> http://master.kde.org/mailman/listinfo/kde-multimedia
> 

_______________________________________________
Kde-multimedia mailing list
Kde-multimedia@master.kde.org
http://master.kde.org/mailman/listinfo/kde-multimedia

[prev in list] [next in list] [prev in thread] [next in thread]