2013-04-04 71 views
5

在stagefright上使用gstreamer有什么优势?任何人都可以指出差异。Stagefright vs Gstreamer

+0

@Ruchi ..我试图回答你的问题。请评论,如果你正在寻找更具体的问题,因为这个问题有点不确定。 – Ganesh 2013-04-04 14:59:25

回答

15

关于发病,一个非常通用的评论。如果GStreamerStagefright有优势,这是非常有争议的。但是,有些要回答你的问题的点如下。

StagefrightOMX/OpenMax接口的所有编解码器的依赖,而GStreamer编解码器插件,可以写在non-OMX接口。例如,即使软件编解码器也被封装在SoftOMXComponentStagefright框架中,而同样可以容易地将其转换为GstElement而不必具有OMX接口。

Stagefright中,两个组件之间的通信接口非常通用,通常为MediaBuffer。这不是hard结合,而是通过胶层(即OMXCodecMediaExtractorAwesomePlayer的实现)的更多促进。

GStreamer中,典型的通信接口是通过Pads,它具有特定的GstCaps。两个组件的焊盘通过gst_pad_link相互链接。

GStreamer提供标准模板binsCameraBinPlayerBin而在Stagefright你有cameraHal实施camera。对于玩家来说,有2个潜在的玩家引擎实现,如StagefrightPlayerNuPlayer

Stagefright,数据处理由sink(下游)驱动PULLsource -ing数据。在GStreamer中,数据处理可能会由创建缓冲区的source和将其下游(参考:here)触发。

Stagefright相比,Gstreamer被广泛部署,它目前是特定于Android的。

虽然列表可以继续,但在两个框架之间有很多的相似之处。例如,

  1. 两个框架创建通过Factory Methods即像parserscodecs组分他们采用Factory图案。

  2. 这两个框架都采用接口来集成更新的组件,例如parsers

+0

谢谢洛特。这真的有帮助。 :) – Ruchi 2013-04-05 04:58:23

+1

很好的答案。以下是我的个人观点: i)GStreamer与过时的Microsoft DirectShow过滤器非常相似,我不确定谁影响谁; ii)Stagefright正在走向异步模式(ACodec取代OMXCodec; ALooper和AHandler易于使用库); iii)GStreamer在其问题陈述中更加成熟和普遍,Stagefright的目标是解决Android的播放问题,并且存在不同libstagefright.so中的供应商特定怪癖。 – leesei 2014-01-10 11:06:30

+0

@leesei ..我对最后一部分的看法略有不同..''Stagefright'正在变得更加通用,所有的构建块在'Java'层可见。尽管不像“GStreamer”那样功能丰富,但它确保了最终用户对底层硬件功能的覆盖范围正在不断扩大。因此,该框架比解决播放问题要普遍得多。我很想听听你对这个主题的看法。 – Ganesh 2014-01-10 13:40:29

0

我不熟悉的怯场,但我想指出的GStreamer提供了一些非常成熟的调试功能,包括倾销GraphViz的,可用于构建的文字,视觉图(“点”)的数据形象化的回放图,包括在施工期间,甚至在某些部分故障后。多个调试级别可用,以及某些类型的过滤。

我肯定会推荐任何人这两个库用于开发目的之间选择比较它们的调试和故障排除功能,尤其是对于故障排除管道饥饿和同步。

(哦,对了方式 - 最佳格式的转换点转储是SVG。我通常在Firefox中打开它们。)