Question

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

Was it helpful?

Solution

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.

OTHER TIPS

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

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top