GStreamer Daemon - GStreamer Daemon Basics

From RidgeRun Developer Wiki


  Index Next: Building GStreamer Daemon




GStreamer Daemon is, as it name states, a process that runs independently and exposes a public interface for other processes to communicate with and control the daemon. 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 applications from scratch. As such, clients can focus on application-specific code accelerating time-to-market. This also removes the need to become a gobject expert and worry about memory leaks that often occur to engineers coding up GStreamer applications the first time.

The gstd public interface is exposed over a variety of Inter-Process Communication (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 and desktop test frameworks may leverage the accompanying TCP client tool that is distributed with the gstd project. In the current release, only a TCP IPC mechanism is supported.

Design

The design behind GStreamer Daemon follows a MVC architecture. Figure 1 shows a high-level diagram of the design. 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.

Figure 1: GStreamer Daemon MVC Architectural Design
  1. GStreamer Daemon provides the core and IPC endpoint.
    1. The Gstd Core holds the current state of the GStreamer daemon, such as pipelines created along with their respective states, elements in each pipeline, properties in each element, etc.. In the MVC terminology the Gstd core would represent the model.
    2. The IPC allows client applications to alter the state of the Gstd core using an interprocess communication mechanism, i.e: TCP, HTTP, DBus, sockets, etc... In the MVC terminology, the IPC would represent the controller. Custom applications use the IPC/controller to modify the state of the Gstd core. Examples of this would be: create a new pipeline, set the state to play, or change an element property while the pipeline is running. The Gstd core is, deliberately, unaware of the IPC being used and, furthermore, has no knowledge of the application which is using the controller. In fact, several custom applications could be interacting at the same time with the Gstd core.
  2. The custom application provides view and client logic.
    1. The View is the part of the system that provides visual feedback of the Gstd core state to the user. This is typically a graphical user interface (GUI), a web page, a cmdline application, etc... In the MVC terminology, the GUI represents the view. The user will see the view, which in turn is updated by the model.
    2. The client logic provides the application's custom functionality. This is, for example, send the pipeline creation request when the user presses the respective button, or tear down a running pipe when an "out of space" error is received on the bus. In the MVC terminology, the client logic represents the user. The user will use the IPC/controller to modify the Gstd core/model and will receive feedback via the GUI/view.

An alternative representation is the layer diagram shown in Figure 2.

Figure 2: GStreamer Daemon layer representation

Gstd's core is a standalone process that sits on top of the GStreamer Framework. To the right of the core are other standalone processes, which communicate with GStreamer Daemon via the IPC. Note that these processes do not depend on GStreamer API, since Gstd already handles this.

Distributed with the project, there is a GstdClient: a simple, cmdline based application that talks via TCP with GStreamer Daemon. This application is ideal for quick prototyping and for shell script automation. GstdClient is like gst-launch as you can create and start pipelines. Unlike gst-launch, GstdClient allow 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 this wiki will provide examples using the cmdline application.


  Index Next: Building GStreamer Daemon