使用gstreamer相对于stagefright的优势有哪些?能否请有经验的人指出它们之间的区别。
使用gstreamer相对于stagefright的优势有哪些?能否请有经验的人指出它们之间的区别。
起初,有一个非常普遍的评论。是否GStreamer比Stagefright优势是非常有争议的。然而,以下是回答你问题的一些要点。
Stagefright仅依赖于OMX / OpenMax接口来支持所有编解码器,而GStreamer编解码器插件可以在非OMX接口上编写。例如,即使是软件编解码器,也会被封装到Stagefright框架中的SoftOMXComponent中,而同样的内容可以轻松转换为GstElement,而不必具备OMX接口。
在Stagefright中,两个组件之间的通信接口非常普遍,通常是MediaBuffer。这不是一个硬约束,而是通过Glue层(即实现OMXCodec、MediaExtractor或AwesomePlayer)更加便捷地实现的。
在GStreamer中,典型的通信接口是通过具有特定GstCaps的Pads。通过gst_pad_link连接两个组件的pads。
GStreamer提供标准模板bins,如CameraBin或PlayerBin,而在Stagefright中,你需要使用camera的cameraHal实现。对于播放器,有两种潜在的播放器引擎实现,如StagefrightPlayer或NuPlayer。
在Stagefright
中,数据处理由下游的 sink
驱动,通过从 source
PULL 数据来进行。在 GStreamer
中,数据处理潜在地可以由 source
创建缓冲区并将其PUSH 到下游来触发 (参考: 这里)。Stagefright
相比,Gstreamer
已经广泛部署。两种框架都通过工厂方法(即采用工厂模式)创建像 parsers
或 codecs
这样的组件。
两种框架都采用插件接口来集成新组件,例如 parsers
。
Stagefright
正变得更加通用,所有构建块都在 Java
层可见。虽然不如 GStreamer
功能丰富,但它确保了底层硬件功能向最终用户的覆盖范围增加。因此,这个框架比仅解决播放问题要通用得多。我很想听听你对这个话题的看法。 - GaneshStagefright
可能更通用。我完全错过了录制部分。我的重点是 Stagefright
仅限于 Android,而不是 Stagefright
本身的限制。我们可以从抽象的 Extractor/Codec/Writer/Render 编写通用播放器、录音机、转码器、后处理器(它们非常好)。我希望它们在 Android 之外,但遗憾的是,Stagefright
在当前状态下与平台(AOSP)源代码深度纠缠(例如:平台头文件、Android Native Buffer 和 OMX 编解码器的怪癖)。 - leeseiGStreamer
在标准 API
方面得分高于 Android
的 Stagefright
,并且在 linux
社区中被广泛采用。感谢您的精彩讨论!! - Ganesh我不熟悉StageFright,但我想指出GStreamer提供了一些非常成熟的调试功能,包括转储GraphViz(“dot”)数据,可用于构建您的比喻播放图形的文字和视觉图形,包括在构建期间,甚至在某些部分失败后。多个调试级别可用,还有某些过滤器。
我肯定会建议任何选择这两个库进行开发的人比较它们的调试和故障排除能力,特别是与管道饥饿和同步故障排除相关的能力。
(哦,顺便说一下 - 将这些点转储转换为最佳格式是SVG。我通常在Firefox中打开它们。)