Stagefright vs Gstreamer

gstreamer, stagefright

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,

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

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

Problem

Original source