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_capabilitiesprint_capsprint_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状态变化时打印autoaudiosinksink pad。在输出中你能看到一个最初的caps (Pad Template的caps)是如何逐步完善的知道它们完全固定(Caps只包含一个无范围的类型)。

总结

这篇教程展示了:

  • 什么是Pad CapabilitiesPad 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?