Stagefright vs Gstreamer

Question

What are the advantages of using gstreamer over stagefright? Could anyone please point out the difference.

Boyd

@Ruchi.. I have tried to answer your question. Please comment if you were looking for something more specific as the question is a bit open-ended. – Trypanosome

Answer 1

On the onset, one very generic comment. It is very debatable if GStreamer is advantageous over Stagefright or not. However, some points to answer your question are as below.

Stagefright relies only on OMX / OpenMax interface for all the codecs, whereas GStreamer codec plugin can be written over non-OMX interfaces. For example, even software codecs are encapsulated into SoftOMXComponent in Stagefright framework, whereas the same can easily be converted into a GstElement without necessarily having a OMX interface.

In Stagefright, the communication interface between 2 components is very generic and typically is MediaBuffer. This is not a hard binding, but more facilitated through the Glue Layer i.e. implementation of the OMXCodec or MediaExtractor or AwesomePlayer.

In GStreamer, the typical communication interface is through the Pads which have specific GstCaps. Two components' pads are inter-linked through gst_pad_link.

GStreamer provides standard template bins like CameraBin or PlayerBin whereas in Stagefright you have a cameraHal implementation for camera. For players, there are 2 potential player engine implementations like StagefrightPlayer or NuPlayer.

In Stagefright, data processing is driven by the sink (downstream) PULL-ing data from the source. In GStreamer, the data processing can potentially be triggered by the source creating the buffer and PUSH-ing it to downstream (Reference: here).

A last point, Gstreamer is widely deployed as compared to Stagefright which is currently android specific.

While the list can continue, there are a lot of similarities between the 2 frameworks. For example,

1. Both frameworks create the components like parsers or codecs through Factory Methods i.e. they employ a Factory pattern.

2. Both frameworks employ a plugin interface to integrate newer components like for example parsers.

Trypanosome

Great answer. Here's my personal view: i) GStreamer is very similar to the deprecated Microsoft DirectShow filters, I'm not sure whose influencing who; ii) Stagefright is moving towards an asynchronous model (ACodec replacing OMXCodec; ALooper and AHandler are easy to use libraries); iii) GStreamer is more mature and general in its problem statement, Stagefright's goal is to solve Android's playback and there are vendor-specific quirks buried in different libstagefright.so. – Strasser

@leesei.. I have a slightly different view on the last part.. Stagefright is becoming far more generic with all building blocks becoming visible at the Java layer. Though not as feature rich as GStreamer, it is ensuring an increasing reach of underlying HW capabilities to end user. Hence, the framework is far more generic than to solve only the playback problem. I would love to hear your view on this topic. – Trypanosome

@Trypanosome Thanks for pointing that out, I agree that Stagefright could be more generic. I missed the recording part totally. My focus was Stagefright being limited to Android and not the limitation of Stagefright itself. We can write generic player, recorder, trancoders, post-processors from the abstracted Extractor/Codec/Writer/Render (they are pretty good). I would like to have them outside of Android, sadly Stagefright at its current state is deeply entrenched with the platform (AOSP) source code (e.g.: platform headers, Android Native Buffer and quirks of OMX codecs). – Strasser

@leesei.. precisely in the point you have rightly highlighted, GStreamer scores over the Android Stagefright as it has the building blocks as standard APIs and is far more widely adopted in the linux community. Thanks for the great discussion !! – Trypanosome

Yes, having worked with both DirectShow and GStreamer, they are extremely similar in terms of being streaming media graph systems. It's worth noting, however, that neither is the first example of such a system. – Anissa

Answer 2

I'm not familiar with StageFright, but I would point out that GStreamer offers some very mature debugging capabilities, including dumping GraphViz ("dot") data that can be used to construct literal, visual graphs of your figurative playback graphs, including during construction, even after certain kinds of partial failure. Multiple debug levels are available, along with certain kinds of filtering.

I would definitely recommend anyone choosing between these two libraries for development purposes compare their debugging and troubleshooting capabilities, especially with respect to troubleshooting pipeline starvation and synchronization.

(Oh, and by the way-- the best format to convert those dot dumps to is SVG. I usually open them in Firefox.)

Anissa