【发布时间】:2013-03-26 10:02:49
【问题描述】:
与 stagefright 相比,使用 gstreamer 有哪些优势?谁能指出其中的区别。
【问题讨论】:
-
@Ruchi.. 我试图回答你的问题。如果您正在寻找更具体的内容,请发表评论,因为这个问题有点开放。
标签: gstreamer stagefright
与 stagefright 相比,使用 gstreamer 有哪些优势?谁能指出其中的区别。
【问题讨论】:
标签: gstreamer stagefright
首先,一个非常笼统的评论。 GStreamer 是否优于 Stagefright 是非常值得商榷的。但是,要回答您的问题的一些要点如下。
Stagefright 仅依赖于OMX / OpenMax 接口用于所有编解码器,而GStreamer 编解码器插件可以覆盖non-OMX 接口。例如,即使软件编解码器在Stagefright框架中被封装到SoftOMXComponent中,而同样可以很容易地转换成GstElement,而不必具有OMX接口。
在Stagefright 中,两个组件之间的通信接口非常通用,通常是MediaBuffer。这不是hard 绑定,而是通过粘合层 更方便,即实现OMXCodec 或MediaExtractor 或AwesomePlayer。
在GStreamer中,典型的通信接口是通过Pads,其中有特定的GstCaps。两个组件的焊盘通过gst_pad_link 互连。
GStreamer 提供标准模板bins,例如CameraBin 或PlayerBin,而在Stagefright 中,您有一个cameraHal 实现camera。对于玩家,有 2 个潜在的玩家引擎实现,例如 StagefrightPlayer 或 NuPlayer。
在Stagefright 中,数据处理由来自source 的sink(下游)PULL-ing 数据驱动。在GStreamer 中,数据处理可能由source 创建缓冲区并将其PUSH-ing 到下游触发(参考:here)。
最后一点,Gstreamer 与 Stagefright 相比被广泛部署,Stagefright 目前是特定于 android 的。
虽然列表可以继续,但两个框架之间有很多相似之处。例如,
两个框架都创建了像parsers 或codecs 到Factory Methods 这样的组件,即它们采用Factory 模式。
两个框架都使用plugin 接口来集成更新的组件,例如parsers。
【讨论】:
Stagefright 变得更加通用,所有构建块都在Java 层可见。虽然没有GStreamer 那样丰富的功能,但它确保了底层硬件功能对最终用户的影响越来越大。因此,该框架远比仅解决播放问题更为通用。我很想听听你对这个话题的看法。
Stagefright 可能更通用。我完全错过了录音部分。我的重点是 Stagefright 仅限于 Android,而不是 Stagefright 本身的限制。我们可以从抽象的 Extractor/Codec/Writer/Render 编写通用播放器、录音机、转码器、后处理器(它们非常好)。我想让它们在 Android 之外使用,遗憾的是,Stagefright 在其当前状态下与平台 (AOSP) 源代码(例如:平台标头、Android Native Buffer 和 OMX 编解码器的怪癖)根深蒂固。
我对 StageFright 不熟悉,但我要指出 GStreamer 提供了一些非常成熟的调试功能,包括转储 GraphViz(“点”)数据,这些数据可用于构建图形播放图的文字、可视化图形,包括在施工期间,甚至在某些类型的部分故障之后。提供多个调试级别以及某些类型的过滤。
我绝对会建议任何出于开发目的在这两个库之间进行选择的人比较它们的调试和故障排除能力,尤其是在排除管道饥饿和同步方面。
(哦,顺便说一句——将这些点转储转换为 SVG 的最佳格式。我通常在 Firefox 中打开它们。)
【讨论】: