[gst-devel] D-BUS based multimedia server
Steve Baker
steve at stevebaker.org
Wed Mar 12 01:18:24 CET 2003
On Wed, 2003-03-12 at 00:33, Owen Fraser-Green wrote:
> Hi,
>
> Following on from the unconcluded discussion on sound (preferably
> multimedia) servers I'd like to throw another idea into the pool. I was just
> following the status on the D-BUS project
> (http://www.freedesktop.org/software/dbus/) and it occured to me that maybe
> there lay in there a solution to the biggest obstacle for the idea of
> Gnostream as a multimedia server, namely bonobo with respect to KDE interop.
> It strikes me that D-BUS is an altogether more suitable (simpler, thinner
> and hopefully acceptance in both Gnome and KDE) way of doing much the same
> thing I'd planned to do with bonobo in Gnostream. The basic concept instead
> of the client application using gstreamer directly:
>
> +------------+
> | MP3 player |
> +------------+
> | UI +
> +------------+
> | gstreamer |
> +------------+
> | |
> | |
> ^ v
> file audio
>
> the client talks to a server which does all the gstreamer stuff for it:
>
>
> +------------+
> | MP3 player |
> +------------+
> | UI +
> +------------+
> :
> : <some protocol>
> :
> +------------+
> | server if |
> +------------+
> | gstreamer |
> +------------+
> | |
> | |
> ^ v
> file audio
>
> There is one server which handles the streaming needs of all the clients.
> When a network is involved this happens:
>
>
> +------------+
> | MP3 player |
> +------------+
> | UI +
> +------------+
> :
> : <some IPC protocol>
> :
> +------------+ +-----------+
> | server if | .....................| server if |
> +------------+ <some IPC protocol> +-----------+
> | gstreamer | | gstreamer |
> +------------+ +-----------+
> | |
> | |
> ^ v
> file audio
>
>
> I believe D-BUS could fit the picture here better than Bonobo so maybe
> Gnostream could start making some sense again.
I've also thought about using D-BUS as a transport protocol for a media
server. My immediate concern would be D-BUS not delivering the kinds of
latency required by multimedia applications. It might not be engineered
to optimally deliver continuous chunks of media data. Also any stream
would have to go through *2* IPC message passes to reach a media server
(app -> d-bus-daemon -> media server)
I'm sure the actual performance of this could be measured with some
easily coded tests.
message-bus-list peeps might be able to enlighten us with their expert
opinions as well.
cheers
--
Steve Baker <steve at stevebaker.org>
More information about the gstreamer-devel
mailing list