GStreamer Daemon: gst-launch on Steroids
GStreamer Daemon, also called gstd, is a GStreamer framework for controlling
audio and video streaming using an InterProcess Communication protocol.
The goal behind gstd is to abstract much of the complexity of writing custom
GStreamer applications, as well as factoring out lots of boilerplate code required
to write multimedia applications from scratch.
GStreamer Daemon is gst-launch on steroids where you can create a GStreamer pipeline, play, pause, change speed, skip around, and even change element parameter settings, all while the pipeline is active. GStreamer Deamon was created to remove the drudgery of writing GObject based streaming media servers. As such, clients can focus on application-specific code, accelerating time-to-market.
The gstd public interface is exposed over a variety of Inter Process Communcation (IPC) mechanisms. Different products or applications will use the most convenient IPC option. For example:
QT applications may find it easier to communicate with gstd via DBus by auto-generating the respective bindings.
Web pages may find it natural to communicate via HTTP requests.
Desktop test frameworks may leverage the accompanying TCP client tool that is distributed with the gstd project.
Key GStreamer Daemon Features:
The design behind GStreamer Daemon follows MVC architecture. As with any other architectural or design patterns, this only drafts a very high level overview of the system. Custom applications, in conjunction with GStreamer Daemon, will define the complete design.
gstd's core is a standalone process that sits on top of the GStreamer Framework.
Distributed with the project, there is GstdClient: a simple, cmdline based application that talks via TCP with GStreamer Daemon.
GstdClient is like gst-launch as you can create and start pipelines.
Unlike gst-launch, GstdClient allows you to have several pipelines active with the ability to control the pipeline and receive feedback once the pipeline has been created.
The GStreamer Daemon project packages the core, the cmdline client and IPC interfaces. The rest of the wiki will provide examples using the cmdline application.
Note: RidgeRun assumes that there are no hardware issues that would delay the development process (and increase costs). In case of problems with your hardware, RidgeRun will bill up to 20 hours of engineering services for the time needed to inform you of what is wrong.