Why RidgeRun Loves GStreamer: Difference between revisions
Line 17: | Line 17: | ||
= Separating control application from video streaming application = | = Separating control application from video streaming application = | ||
You can think of the above GStreamer pipeline being implemented in a separate application, which we call the Streaming Media Server (sms). The customer's application simply instructs sms with simple commands, like start streaming, mux selection, take a snapshot, etc. There is no confusion or complexity by mixing the customer's proprietary application with the Streaming Media Server | You can think of the above GStreamer pipeline being implemented in a separate application, which we call the Streaming Media Server (sms). The customer's application simply instructs sms with simple commands, like start streaming, mux selection, take a snapshot, etc. There is no confusion or complexity by mixing the customer's proprietary application with the Streaming Media Server. | ||
Another advantage for using a Streaming Media Server is testing. Since the Streaming Media Server is designed to be controlled by an external process, it is very easy to create automated acceptance tests and automated endurance tests. | Another advantage for using a Streaming Media Server is testing. Since the Streaming Media Server is designed to be controlled by an external process, it is very easy to create automated acceptance tests and automated endurance tests. | ||
Line 34: | Line 34: | ||
There can be many more, relating to setting frame rate, resolution, etc. This list is just to give you a feel for how the customer's application interacts with the Streaming Media Server. | There can be many more, relating to setting frame rate, resolution, etc. This list is just to give you a feel for how the customer's application interacts with the Streaming Media Server. | ||
If you want to see a real example, complete with source code, check out [https://github.com/RidgeRun/gstd/wiki GStreamer Daemon] (which is the Streaming Media Server) and gst-client (which is a command line program which is this dicussion is either the customer's application or the automated acceptance test / automated endurance test application). | If you want to see a real Streamng Media Server example, complete with source code, check out [https://github.com/RidgeRun/gstd/wiki GStreamer Daemon] (which is the Streaming Media Server) and gst-client (which is a command line program which is this dicussion is either the customer's application or the automated acceptance test / automated endurance test application). | ||
= System tuning = | |||
Also, setting thread priorities is much easier. A common example, but not for this customer since the device doesn't support audio, is audio drop under heavy customer application load. We can use a GStreamer element that allows us to set the audio thread priority to resolve the contention for the processor. | |||
[[Category:GStreamer]] | [[Category:GStreamer]] |
Revision as of 15:20, 30 January 2014
Introduction
In a recent customer call, we created a simplified diagram for the GStreamer pipeline RidgeRun implemented for the customer. When I looked at the diagram, I couldn't imagine how the customer could have gotten similar funcationality without using GStreamer. It would have been a nightmare to try to support so much functionality if you had to write it all from scratch or use strange video APIs that are SoC specific.
This got me thinking why RidgeRun loves GStreamer and I thought I would share my thoughts with you.
Real customer pipeline
Here is the GStreamer pipeline being used by a customer. The only difference is I also added RTSP streaming out the device (bottom left GStreamer bin).
A mux is used to select the video source, since the SoC being used by the customer can only handle one video source at a time. (Some chips, like iMX6 and DM81xx can handle several video streams at one time). There are several sources of video, from the network, from a file, from a built-in camera, from an external device using Transport Stream over UDP.
There are several destinations for the streaming video, all of which can be active at the same time. The video can be displayed on an LCD on the customer's hardware, high resolution snapshots and/or video saved to the a storage device on the customer's product, or streamed over the network using different protocols (and different resolutions if needed).
Separating control application from video streaming application
You can think of the above GStreamer pipeline being implemented in a separate application, which we call the Streaming Media Server (sms). The customer's application simply instructs sms with simple commands, like start streaming, mux selection, take a snapshot, etc. There is no confusion or complexity by mixing the customer's proprietary application with the Streaming Media Server.
Another advantage for using a Streaming Media Server is testing. Since the Streaming Media Server is designed to be controlled by an external process, it is very easy to create automated acceptance tests and automated endurance tests.
You can think of the Streaming Media Server as providing a remote API (using one of the interprocess communication mechanisms, such as D-Bus or even a simple TCP port). Often RidgeRun will provide a small libsms library which is linked with customer's application. libsms provides a real API to the customer's application and hides all the logic on how libsms makes the interprocess communication call.
For the GStreamer pipeline above, you can guess some of the key remote APIs:
- Start / stop stream
- Video input select
- Source video filename
- Take a snapshot (providing a filename if desired)
- Save video to file (again providing a filename if desired)
- Set source RTSP video IP address
There can be many more, relating to setting frame rate, resolution, etc. This list is just to give you a feel for how the customer's application interacts with the Streaming Media Server.
If you want to see a real Streamng Media Server example, complete with source code, check out GStreamer Daemon (which is the Streaming Media Server) and gst-client (which is a command line program which is this dicussion is either the customer's application or the automated acceptance test / automated endurance test application).
System tuning
Also, setting thread priorities is much easier. A common example, but not for this customer since the device doesn't support audio, is audio drop under heavy customer application load. We can use a GStreamer element that allows us to set the audio thread priority to resolve the contention for the processor.