6

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

Ruchi
  • 449
  • 2
  • 7
  • 15
  • @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. – Ganesh Apr 04 '13 at 14:59

2 Answers2

17

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.

leesei
  • 6,020
  • 2
  • 29
  • 51
Ganesh
  • 5,880
  • 2
  • 36
  • 54
  • 1
    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. – leesei Jan 10 '14 at 11:06
  • @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. – Ganesh Jan 10 '14 at 13:40
  • 2
    @Ganesh 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). – leesei Jan 13 '14 at 03:51
  • @leesei.. precisely in the point you have rightly highlighted, `GStreamer` scores over the `Android` `Stagefright` as it has the building blocks as standard `API`s and is far more widely adopted in the `linux` community. Thanks for the great discussion !! – Ganesh Jan 13 '14 at 08:08
  • 1
    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. – breakpoint Jun 07 '17 at 23:35
0

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.)

breakpoint
  • 916
  • 9
  • 16