Basic tutorial 6: Media formats and Pad Capabilities
Capabilities if GstPad.
目标
Pad的Capabilities时GStreamer的一个基本元素,由于大部分时间都由框架自动处理它们,所以用户很少感觉到它们的存在。这篇略微理论化的教程将展示:
什么是Pad Capabilities。
如何检索它们。
什么时候检索它们。
为什么用户需要了解他们。
介绍
Pads
如之前介绍的一般,Pads允许信息进出elements。Pad的Capabilities(简称为Caps)指定了Pad能够传递什么类型的信息。例如,“320x200分辨率,30FPS的RGB视频”,或是“16位音频样本,5.1通道,采样率44100Hz”,或者是mp3和h264这类的压缩格式。
Pads可以支持多种Capabilities(例如一个video sink可以支持不同格式的RGB/YUV视频)并且Capabilities的值可以是一个范围(例如一个audio sink能够支持从1hz到48000hz的采样率)。然而,真正在Pad之间传递的信息必须只有一种明确制定的类型。 通过一个称为“协商”的过程,两个连接的pad就一个公共类型达成一致,从而pad的capability固定下来(它们只有一种类型,不包含范围)。下面的例程讲向你清楚的展现这个协商的过程。
两个elements支持的Capabilities类型必须有交集它们才能连接,否则它们无法理解彼此传递的数据,这就是Capabilities的主要设计目的。
作为一个应用程序开发者,你经常需要通过连接elements来构建piepline,因此你需要了解你所使用的elements的Pad Caps,或者至少当GStreamer elements因为“协商”错误而连接失败能够知道它们具体是什么。
Pad templates
Pads从Pad Templates生成,Pad Templates指明了一个Pad所有可能的Capabilities。模版对于创建一个相似的Caps时很有用的,并且允许提前拒绝elements之间的连接:假如两个elements的Pad模版的Capabilities没有交集,就没有必要进行更深入的“协商”。
Pad模版可以视作“协商”过程的第一步,随着过程的发展,实际的Pads被实例化并且Pads的Capabilities也不断被完善固定下来(或者“协商“失败)。
Capabilities examples
这是一个element的永久sink pad(暂时不讨论Availablility)。它支持2种媒体格式,都是音频的原始数据audio/x-raw-int,16位的小端序符号数和8位的无符号数。方括号表示一个范围,例如,频道channels的范围是1到2.
video/x-raw表示这个source pad输出原始格式的视频。它支持一个很广的维数和帧率,一系列的YUV格式(用花括号列出了)。所有这些格式都显示不同的图像编码格式和子采样程度。
注解
用户可以使用gst-inspect-1.0工具学习所有GStreamer element是Caps信息。
注意有些elements需要查询底层硬件以获得支持的格式,并相应地提供它们的Pad Caps(通常在element的READY状态或者更早)。因此同一个element在不同平台上支持的Caps有可能不同,甚至某两次运行之间就会有所不同(虽然这种情况很少见)。
这篇教程实例化了两个elements(通过GstElementFactory的方式),展示了他们的Pad模版,连接它们并将pipeline设置为播放状态。在每个状态变化的阶段,展示了sink element的Pad的Capabilities,你能够观察到在整个“协商”过程中Pad Caps固定之前的所有变化。
A trivial Pad Capabilities Example
basic-tutorial-6.c
工作流
print_pad_capabilities, print_caps,print_pad_templates以一种友好的形式简单展示了capabilities的结构体。假如你想了解GstCaps的内部结构,请阅读GstCaps。
gst_element_get_static_pad()用于根据Pad name检索给定element的pad结构体,这个pad是静态的,因为它会一直存在。关于Pad的的更多内容请阅读GstPad。
获取pad之后我们调用gst_pad_get_current_caps()来获取这个pad当前的capabilities,可能是固定的也可能不是,这取决于当前“协商”过程的状态。pad甚至可能还未生成capabilities,在这种情况下,我们调用gst_pad_query_caps()来获取一个当前可接受的Pad Capabilities。这个当前可接受的Caps是Pad Template在NULL状态下的Caps,它不是固定的,因为还会查询实际的硬件。
然后我们打印这些获得的Capabilities信息。
在之前的教程中我们使用gst_element_factory_make()来创建GStreamer element并且跳过了factories的讨论,可以明确的是一个GstElementFactory管理着一个特定类型的GStreamer element的实例化,以factory name区分(可以理解为一个GstElementFactory代表一个插件,一个插件可以实例化多个GStreamer element对象)。
gst_element_factory_make()是gst_element_factory_create()和gst_element_factory_create()的简洁形式。
通过工程,Pad模板实际上已经可以访问了,所以factories一建立我们立刻打印这些信息。
我们跳过pipeline的创建和启动部分,直接跳到状态切换消息的处理:
上述代码将在每次pipeline状态变化时打印autoaudiosink的sink pad。在输出中你能看到一个最初的caps (Pad Template的caps)是如何逐步完善的知道它们完全固定(Caps只包含一个无范围的类型)。
总结
这篇教程展示了:
什么是
Pad Capabilities和Pad Template Capabilities。如何使用
gst_pad_get_current_caps()和get_pad_query_caps()检索它们。它们根据pipeline的不同状态有不同的含义(在初始化时它们表示所有可能的Capabilities,在这之后表示当前Pad的特定Caps)。
事先知道elements支持的Caps类型对于elements的连接至关重要。
可以使用
gst_inspect-1.0查看element支持的Pad Caps。
Last updated
Was this helpful?