GStreamer 从摄像头获取图像 转264

　　1、这里有个简单的例子，可以看看GStreamer如何编程的。

　　2、GStreamer  GstAppSink的官方Document，翻译了一下它的描述部分，点击这里。

　　3、GStreamer  GstAppSrc的官方Document，翻译了以下它的描述部分，点击这里。

　　4、GStreamer中的Padscapabilities

Pads 允许信息进入或者离开一个element，这个Capabilities（简称Caps）就是指定哪些信息可以通过Pad来传输。例如：“RGB视频，尺寸为320*200并且每秒30帧”或者“16位的音频采样，5.1声道，每秒采样44.1k” 甚至可以是类似于mp3/h264之类的压缩格式。

　　Pads支持多重Capabilities（比如，一个视频的sink可以支持RGB输出或者YUV输出），Capabilites可以指定一个范围而不必须是一个特定值（比如，一个音频sink可以支持从1~48000的采样率）。然而，数据从一个pad流向另一个pad的时候，必须是一个双方都能支持的格式。某一种数据形式是两个pad都能支持的，这样pads的Capabilities就固定下来，这个过程就被称为协商。

　　作为一个应用开发者，我们通常都是用连接一个个element的方法来建立pipeline的，在这里，你需要了解使用的element的Pad的Caps。

　　5、Pad模板

　　Pad是由Pad模板创建的，模板里面会列出一个Pad所有可能的Capabilities。模板对于创建几个相似的Pad是很有帮助的，但也会比较早的判断出两个element是否可以连接：如果两个Pad的模板都不具备共同的子集的话，就没有必要进行更深层的协商了。

　　Pad模板检查是协商流程的第一步。随着流程的逐步深入，Pad会正式初始化，也会确定他们的Capability（除非协商失败）

　　6、queue

　　queue element会创建一个新的线程。通常来说，有多于一个sink element时就需要使用多个线程。这是因为在同步时，sink通常是阻塞起来等待其他的sink都准备好，如果仅仅只有一个线程是如法做到这一点的。

　　7、tee

　　tee比较特别但很有用，tee有1个输入pad而没有输出pad,需要有申请，tee才会生成。通过这种方法，输入流可以被复制成多份。和Always Pad比起来，Request Pad因为并非一直存在，所以是不能自动连接element的。

　　例子：

　　建立一个如上的pipeline的步骤如下：

　　1）初始化GStreamer；

　　2）创建上图中的所有element；

　　3）创建pipeline；

　　4）配置element；

　　5）把element放进pipeline中，然后将可以连接起来的原件连接起来；

　　    （1）app source -> tee  （2）audio_queue -> audio_convert -> audio_resample -> audio_sink  (3)video_queue ->wave_scope->video_convert->video_sink

　　6) 手工连接tee->audio_queue和tee->video_queue;

　　7)设置pipeline状态为PLAYING;

　　8)监测BUS信号即可。

　　上诉过程的代码可以参考官方文档：https://gstreamer.freedesktop.org/documentation/tutorials/basic/multithreading-and-pad-availability.html

　　同时也可以参考《GStreamer讲解.pdf》 P56。

　　关于上面的第6步，两个参考讲解还有一点不一致，官方文档更简单，需要进一步测试才能确定这两种方式是不是都可行。