流媒体 - 01 gstreamer简介

一. 定义

gstreamer

	1. 用于开发流媒体应用的开源框架
	2. 采用了基于插件（plugin）和管道（pipeline）的体系结构
	3. 不限于处理音视频，只要是有明显的数据流特征都能应用
	4. 所有的 GStreamer 对象都可以采用 GObject 继承的方法进行扩展
	5. 所有的插件都可以被动态装载,可以独立的扩展或升级
	6. GStreamer 采用了信号与对象属性的机制

元件(Elements)

1. GstElement 的属性大多通过标准的 GObject 对象实现的
         使用 GObject 方法可以对GstElement 实行查询、设置、获取属性的值
         GParamSpecs 也被支持
3. 多个元件连接成pipelines 或 Bins
4. 数据流在被连接的元件间传输
5. 元件之间的链接依靠Pads, 链接成功条件: 只有在两个Pads允许通过的数据类型一致才被建立
6. 元件类型:  
         源元件, 不接收数据, 仅产生数据
         过滤器(Filters)以及类过滤元件同时拥有输入和输出衬垫
         接收元件是媒体管道的末端,它接收数据但不产生任何数据

箱柜(Bins)和管道(pipelines)

1. 箱柜是一个可以装载element的容器, 能够象操作普通元件一样的操作一个箱柜
2. 通过改变一个箱柜的状态来改变箱柜内部所有元件的状态
3. 箱柜可以发送总线消息(bus messages)给它的子集元件
		消息包括: 错误消息(error messages)
		          标签消息(tag messages)
		          EOS 消息(EOS messages))
4. 管道是箱柜的一个特殊的子类型, 可以操作包含在它自身内部的所有元件
5. 管道将在一个单独的线程中运行
6. 管道用于安排数据流图，明确数据流处理过程, 通过数据协商机制和同步机制来处理流式数据

衬垫(Pads)

1. 元件数据(buffers 和 events)输出(source Pads)和输入(sink Pads)都是通过Pads
2. Pads用于多个元件的链接,从而让数据流能在这样的链接中流动, 可看作是一个元件插座或端口
3. Pads有处理特殊数据的能力:一个衬垫能够限制数据流类型的通过
4. 数据类型的设定使用 caps negotiation 方法, 被GstCaps 变量所描述
   (1) 一个 GstCaps 对象会包含一个或多个GstStructure
   (2) 一个 GstStructure 描述一种媒体类型, 结构中只包含固定的值
   (3) 被数据流通过的衬垫(negotiated pad)存在功能集(capabilities set)
       每种功能只包含一个 GstStructure结构。
5. 衬垫拥有三种类型的时效性: 永久型(always)、 随机型(sometimes)、 请求型(on request)
6. 功能: 
    • 自动填充, 根据元件的功能自动找到可连接的元件
    • 兼容性检测, 连接并验证两个衬垫是否兼容的过程叫”功能谈判”(caps negotiation)
    • 元数据, 通过读取衬垫的功能,应用程序能够提供有关当前流经衬垫的正在播放的媒体类型信息
    • 过滤, 通过衬垫的功能来给两个交互的衬垫之间的媒体类型加以限制

总线

1. 总线是一个简单的系统, 采用自己的线程机制将一个管道线程的消息分发到一个应用程序当中
2. 优势是当使用 GStreamer 时,应用程序不需要线程识别,即便GStreamer 已经被加载了多个线程
3. 每一个管道默认包含一个总线, 应用程序只需在总线上设置一个消息处理器。

消息

1. 所有的消息都有一个消息源、类型和时间戳, 消息源能被用来判断由哪个元件发出消息
2. 消息类型:
     (1) 错误、警告和消息提示
     (2) 数据流结束提示, 管道的状态不会改变, 但之后的媒体操作将会停止, 可通过这消息来跳到播放列表的下一首歌
     (3) 标签(Tags), 当元数据在数据流中被找到时被发送.一个管道可以发出多个 Tag, 如流的比特率
                     应用程序应该将元数据存储在缓存里
     (4) 状态转换, 状态成功的转换时发送该消息
     (5) 缓冲, 当缓冲网络数据流时被发送
     (6) 元件消息, 是一组特殊的消息, 用以标识一个特定元件
     (7) Application-specific 消息, 将取得的消息结构解析出来,从而得到有关 Application-specific 消息的任何信息

精灵衬垫

1. 来自于箱柜中某些元件,它同样可以在该箱柜中被直接访问, 类似文件系统中的符号链接

通信

1. Gstreamer为应用提供的通信机制：
   • buffer 用于element间数据传递, 保存媒体数据,传输方向永远是从src到sink pad
   • event, element间或app到元件的信息传输, 保存控制数据.event既可向下也可向上传输。
   • message 由元件向app传输, 传输 errors, tags, state changes, buffering state, redirects等
   • queries 通常由app向pipeline发送, 请求一些持续时间和播放点等信息

queries的应答是同步的。element也可使用queries来向相邻element请求相应的信息

缓存区

1. 包含创建的管道里的数据流
2. 通常一个源元件会创建一个新的缓冲区,同时元件还将会把缓冲区的数据传递给下一个元件
3. 组成:
	• 指向某块内存的指针
	• 内存的大小
	• 缓冲区的时间戳
    • 一个引用计数,指出了缓冲区所使用的元件数

事件

1. 事件是一系列控制数据, 随着缓冲区被发送到管道的上游和下游
   •下游事件通知流状态相同的元件,事件包括中断, flush, 流的终止信号等
   •应用程序与元件之间的交互以及事件与事件之间的交互中, 上游事件被用于改变管道中数据流的状态

架构

简介

1. GStreamer的核心功能是为插件的数据流和媒体类型处理/协商提供框架
   框架如下:
   
2. Gstreamer框架源码目录：
   • gstreamer: 包含core framework及core elements.
   • gst-plugins-base: gstreamer应用所需的必要插件.
   • gst-plugins-good: 高质量的采用LGPL授权的插件.
   • gst-plugins-ugly: 高质量, 但使用了GPL等其他授权库的插件, 比如GPL的x265.
   • gst-plugins-bad: 质量有待提高的插件，成熟后可以移到good插件列表中.
   • gst-libav: 对libav封装，使其能在gstreamer框架中使用.

Media Applications

1. 应用层
 •gstreamer自带的一些工具(gst-launch，gst-inspect等)
 •基于gstreamer封装的库(gst-rtsp-server,gst-editing-services等),根据不同场景实现的应用

Core Framework

 •上层应用所需接口
 •Plugin的框架
 •Pipline的框架
 •数据在各个Element间的传输及处理机制
 •多个媒体流（Streaming）间的同步（比如音视频同步）
 •其他各种所需的工具库

Plugins

1. 底层插件
   •实现具体的数据处理及音视频输出
   •应用不需要关注插件的细节，会由Core Framework层负责插件的加载及管理
   •主要分类为：
       - Protocols：负责各种协议的处理，file，http，rtsp等。
       - Sources：负责数据源的处理，alsa，v4l2，tcp/udp等。
       - Formats：负责媒体容器的处理，avi，mp4，ogg等。
       - Codecs：负责媒体的编解码，mp3，vorbis等。
       - Filters：负责媒体流的处理，converters，mixers，effects等。
       - Sinks：负责媒体流输出到指定设备或目的地，alsa，xvideo，tcp/udp等。

debug

1. GST_DEBUG=“GST_TRACER:7”
2. 生成dot文件
   (1) GST_DEBUG_DUMP_DOT_DIR=. gst-launch-1.0 videotestsrc ! fakesink
   (2) 生成.dot文件
   (3) sudo apt-get install xdot 安装dot显示工具