1 . 音视频处理的一般流程：
数据采集→数据编码→数据传输(流媒体服务器) →解码数据→播放显示
1、数据采集：
摄像机及拾音器收集视频及音频数据，此时得到的为原始数据
涉及技术或协议：
摄像机：CCD、CMOS
拾音器：声电转换装置（咪头）、音频放大电路
2、数据编码：
使用相关硬件或软件对音视频原始数据进行编码处理（数字化）及加工（如音视频混合、打包封装等），得到可用的音视频数据
涉及技术或协议：
编码方式：CBR、VBR
编码格式
视频：H.265、H.264、MPEG-4等，封装容器有TS、MKV、AVI、MP4等
音频：G.711μ、AAC、Opus等，封装有MP3、OGG、AAC等
3、数据传输：
将编码完成后的音视频数据进行传输，早期的音视频通过同轴电缆之类的线缆进行传输，IP网络发展后，使用IP网络优传输
涉及技术或协议：
传输协议：RTP与RTCP、RTSP、RTMP、HTTP、HLS（HTTP Live Streaming）等
控制信令：SIP和SDP、SNMP等
4、解码数据：
使用相关硬件或软件对接收到的编码后的音视频数据进行解码，得到可以直接显示的图像/声音
涉及技术或协议：
一般对应的编码器都会带有相应的解码器，也有一些第三方解码插件等
5、播放显示：
在显示器（电视、监视屏等）或扬声器（耳机、喇叭等）里，显示相应的图像画面或声音
涉及技术或协议：
显示器、扬声器、3D眼镜等
（二） 视频推流与视频拉流的工作过程解析：
1.视频推流端
推流，就是将采集到的音频，视频数据通过流媒体协议发送到流媒体服务器。
一、选择流媒体协议
现在直播应用，采用RTMP协议居多，也有部分使用HLS协议。
采用RTMP协议，就要看下它与流媒体服务器交互的过程，RTMP协议的默认端口是1935，采用TCP协议。并且需要了解FLV的封装格式。
采用HLS协议，因为涉及到切片，延时会比较大，需要了解TS流。
二、采集音视频数据
做直播，数据的来源不可缺少，就是采集摄像头，麦克风的数据。
iOS平台上采集音视频数据，需要使用AVFoundation.Framework框架，从captureSession会话的回调中获取音频，视频数据。
三、硬编码，软编码音视频数据
软编码就是利用CPU资源来压缩音视频数据，硬编码与之相反。
软编码的话，现在广泛采用FFmpeg库结合编码库来实现，FFmpeg+X624来编码视频数据YUV/RGB输出H264数据，
FFmpeg+fdk_aac来编码音频数据PCM输出AAC数据。
四、根据所选流媒体协议封包音视频数据
将音频，视频打包成packet。
五、与服务器交互发送封包数据
根据所选流媒体协议，发送相应指令连接服务器，连接服务器成功后，就可以发送packet数据了。
Part 2. 拉流端
拉流，就是从流媒体服务器获取音频，视频数据。
一、解析协议
播放器端根据URL解析所用的流媒体协议（RTMP，HLS）。
二、解封装
解封装，就是demux的过程，从容器格式（FLV，TS）中，分离出音视频数据。
三、解码
解码，就是把获取到的数据解压缩，恢复成原始数据。解码就是将H264变成YUV，AAC变成PCM。
解码可以使用软解码，硬解码。
软解码就是利用CPU资源去解压缩数据，采用的方式是FFmpeg解码。
硬解码，对于iOS平台来说，可以使用VideoToolbox.Framework（该框架只能在iOS 8.0及以上系统使用）
硬解码视频数据。Android平台上，可以使用MediaCodec来硬解码视频数据。
四、渲染数据
采用OpenGL渲染YUV数据，呈现视频画面。将PCM送入设备的硬件资源播放，产生声音。
iOS播放流式音频，使用Audio Queue 的方式，即，利用AudioToolbox.Framework 框架。
三： iOS开发之iOS直播平台有用的第三方资源共享：
4. 直播相关SDK
5. 直播相关开源库
1. BeautifyFaceDemo 基于GPUImage的图片处理，做美颜方面可以参考一下
2. lf.swift 开源RTMP Swift版的，可以学习一下！好像作者是日本的，或者是在日本工作的，写了不少日文！
3. PLPlayerKit 一个不依赖FFmpeg的播放器，支持RTMP
4. HLS-Demo https://github.com/yangchao0033/HLS-Demo HLS播放demo
5. SmarterStreaming https://github.com/daniulive/SmarterStreaming 直播SDK（支持私有协议和RTMP推流，如windows推流/android推流/iOS推流/windows播放器/android播放器/iOS播放器）
四： iOS开发之 iOS 直播平台 常见的视频直播相关协议详解
1、 RTMP(Real Time Messaging Protocol，实时消息传送协议)
RTMP是Adobe Systems公司为Flash播放器和服务器之间音频、视频和数据传输开发的开放协议。它有三种变种：
1）、工作在TCP之上的明文协议，使用端口1935；
2）、RTMPT封装在HTTP请求之中，可穿越防火墙；
3）、RTMPS类似RTMPT，但使用的是HTTPS连接；
RTMP协议是被Flash用于对象、视频、音频的传输。这个协议建立在TCP协议或者轮询HTTP协议之上。RTMP协议就像一个用来装数据包的容器，这些数据既可以是AMF格式的数据，也可以是FLV中的视音频数据。一个单一的连接可以通过不同的通道传输多路网络流，这些通道中的包都是按照固定大小的包传输的。
2、RTSP(Real Time Streaming Protocol，实时流传输协议)
RTSP定义了一对多应用程序如何有效地通过IP网络传送多媒体数据。RTSP提供了一个可扩展框架，数据源可以包括实时数据与已有的存储的数据。该协议目的在于控制多个数据发送连接，为选择发送通道如UDP、组播UDP与TCP提供途径，并为选择基于RTP上发送机制提供方法。
RTSP语法和运作跟HTTP/1.1类似，但并不特别强调时间同步，所以比较能容忍网络延迟。代理服务器的缓存功能也同样适用于RTSP，并且因为RTSP具有重新导向功能，可根据实际负载情况来切换提供服务的服务器，以避免过大的负载集中于同一服务器而造成延迟。
3、RTP(Real-time Transport Protocol，实时传输协议)
RTP是针对多媒体数据流的一种传输层协议，详细说明了在互联网上传递音频和视频的标准数据包格式。RTP协议常用于流媒体系统（配合RTCP协议），视频会议和一键通系统（配合H.323或SIP），使它成为IP电话产业的技术基础。
RTP是建立在UDP协议上的，常与RTCP一起使用，其本身并没有提供按时发送机制或其它服务质量（QoS）保证，它依赖于低层服务去实现这一过程。
RTP 并不保证传送或防止无序传送，也不确定底层网络的可靠性，只管发送，不管传输是否丢包，也不管接收方是否有收到包。RTP 实行有序传送，RTP中的序列号允许接收方重组发送方的包序列，同时序列号也能用于决定适当的包位置，如在视频解码中，就不需要顺序解码。
4、RTCP(Real-time Transport Control Protocol，实时传输控制协议）
RTCP是RTP的配套协议，为RTP媒体流提供信道外的控制。RTCP和RTP一起协作将多媒体数据打包和发送，定期在多媒体流会话参与者之间传输控制数据。
RTCP的主要功能是为RTP所提供的服务质量（QoS）提供反馈，收集相关媒体连接的统计信息，例如传输字节数，传输分组数，丢失分组数，单向和双向网络延迟等等。网络应用程序可以利用RTCP所提供的信息来提高服务质量，比如限制流量或改用压缩比小的编解码器。