https://depthlove.github.io/2015/04/22/talk-about-knowledge-points-of-developing-iOS-player/
http://www.cnblogs.com/my_life/articles/6423503.html
要开发一套属于自己的播放器库，不利用移动设备上自带的播放器来播放音频、视频，要用到哪些知识点呢，下面以我熟悉公司播放器库的前提下，说一说我的看法。
任何客户端只要跟服务器打交道，少不了通讯协议。音视频这块涉及的实时流相关协议很多，有RTSP、RTMP、MMS、HLS、RTP、RTCP、SDP、TCP、UDP、HTTP等。
客户端从服务器上获取到的音视频数据，要知道容器与编码方式的区别http://www.cnblogs.com/my_life/articles/6422877.html，
封装音视频数据的容器类型主要有AVI(.avi), MPG(.mpg/.mpeg/.dat), VOB(.vob), MP4, 3GP, ASF(.wmv/.asf), RM(.rm/.rmvb), MOV(.mov), MKV, WAV, TS。
客户端从服务器上获取到了音视频数据，该如何进行解码显示，首先要知道音频、视频的的编码方式，客户端要显示音视频数据需要根据编码的方式进行相应的解码操作，目前常见的编码类型有MPEG系列、H.26X系列、微软windows media系列、Real Media系列、QuickTime系列。
上面说到了一些流媒体协议、流媒体数据的封装类型以及编码方式。而我们要做一款播放器首先是要对以上知识要了解的。
公司的业务涉及最多的是rtsp这块。服务器端为rtsp流媒体服务器，客户端也就是播放器库采用FFMpeg进行解码、OPenGL ES进行YUV视频数据渲染。
播放器库与服务器端进行交互，涉及到RTSP协议的请求，传输层协议采用的TCP、UDP协议。
播放器库对从服务器上请求到的音频、视频rtp包，要进行解包（通讯协议的解包），就是去掉一些协议的头获取到音视频数据段。获取到这些数据后，不能直接播放，需要进行解码操作。视频解码出来一般为Planar 4:2:0 YUV格式。要显示YUV视频图像就需要利用OPenGL ES进行渲染了。
播放器在工作时，视频数据要进行解码放入数据缓存区，数据缓存区的解码后的数据被取出交给OpenGL进行渲染，所以多线程是必不可少的环节了。开辟2个线程，一个线程进行解码处理，另一个线程进行视频数据的渲染。
https://depthlove.github.io/2016/05/09/live-broadcast-development-process/
移动端直播应用的开发流程
Part 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 框架。
http://blog.csdn.net/leixiaohua1020/article/details/50535082
http://blog.csdn.net/leixiaohua1020/article/details/18893769
解协议的作用，就是将流媒体协议的数据，解析为标准的相应的封装格式数据。视音频在网络上传播的时候，常常采用各种流媒体协议，例如HTTP，RTMP，或是MMS等等。这些协议在传输视音频数据的同时，也会传输一些信令数据。这些信令数据包括对播放的控制（播放，暂停，停止），或者对网络状态的描述等。解协议的过程中会去除掉信令数据而只保留视音频数据。例如，采用RTMP协议传输的数据，经过解协议操作后，输出FLV格式的数据。
解封装的作用，就是将输入的封装格式的数据，分离成为音频流压缩编码数据和视频流压缩编码数据。封装格式种类很多，例如MP4，MKV，RMVB，TS，FLV，AVI等等，它的作用就是将已经压缩编码的视频数据和音频数据按照一定的格式放到一起。例如，FLV格式的数据，经过解封装操作后，输出H.264编码的视频码流和AAC编码的音频码流。
解码的作用，就是将视频/音频压缩编码数据，解码成为非压缩的视频/音频原始数据。音频的压缩编码标准包含AAC，MP3，AC-3等等，视频的压缩编码标准则包含H.264（MPEG4-Part 10），MPEG2，VC-1等等。解码是整个系统中最重要也是最复杂的一个环节。通过解码，压缩编码的视频数据输出成为非压缩的颜色数据，例如YUV420P，RGB等等；压缩编码的音频数据输出成为非压缩的音频抽样数据，例如PCM数据。
视音频同步的作用，就是根据解封装模块处理过程中获取到的参数信息，同步解码出来的视频和音频数据，并将视频音频数据送至系统的显卡和声卡播放出来。
2. 流媒体协议
流媒体协议是服务器与客户端之间通信遵循的规定。当前网络上主要的流媒体协议如表所示。
主要流媒体协议一览
|
名称 |
推出机构 |
传输层协议 |
客户端 |
目前使用领域 |
|
RTSP+RTP |
IETF |
TCP+UDP |
VLC, WMP |
IPTV |
|
RTMP |
Adobe Inc. |
TCP |
Flash |
互联网直播 |
|
RTMFP |
Adobe Inc. |
UDP |
Flash |
互联网直播 |
|
MMS |
Microsoft Inc. |
TCP/UDP |
WMP |
互联网直播+点播 |
|
HTTP |
WWW+IETF |
TCP |
Flash |
互联网点播 |
RTSP+RTP经常用于IPTV领域。因为其采用UDP传输视音频，支持组播，效率较高。但其缺点是网络不好的情况下可能会丢包，影响视频观看质量。因而围绕IPTV的视频质量的研究还是挺多的。
因为互联网网络环境的不稳定性，RTSP+RTP较少用于互联网视音频传输。互联网视频服务通常采用TCP作为其流媒体的传输层协议，因而像RTMP，MMS，HTTP这类的协议广泛用于互联网视音频服务之中。这类协议不会发生丢包，因而保证了视频的质量，但是传输的效率会相对低一些。
此外RTMFP是一种比较新的流媒体协议，特点是支持P2P。
3. 封装格式
封装格式的主要作用是把视频码流和音频码流按照一定的格式存储在一个文件中。现如今流行的封装格式如下表所示：
主要封装格式一览
|
名称 |
推出机构 |
流媒体 |
支持的视频编码 |
支持的音频编码 |
目前使用领域 |
|
AVI |
Microsoft Inc. |
不支持 |
几乎所有格式 |
几乎所有格式 |
BT下载影视 |
|
MP4 |
MPEG |
支持 |
MPEG-2, MPEG-4, H.264, H.263等 |
AAC, MPEG-1 Layers I, II, III, AC-3等 |
互联网视频网站 |
|
TS |
MPEG |
支持 |
MPEG-1, MPEG-2, MPEG-4, H.264 |
MPEG-1 Layers I, II, III, AAC, |
IPTV，数字电视 |
|
FLV |
Adobe Inc. |
支持 |
Sorenson, VP6, H.264 |
MP3, ADPCM, Linear PCM, AAC等 |
互联网视频网站 |
|
MKV |
CoreCodec Inc. |
支持 |
几乎所有格式 |
几乎所有格式 |
互联网视频网站 |
|
RMVB |
Real Networks Inc. |
支持 |
RealVideo 8, 9, 10 |
AAC, Cook Codec, RealAudio Lossless |
BT下载影视 |
由表可见，除了AVI之外，其他封装格式都支持流媒体，即可以“边下边播”。有些格式更“万能”一些，支持的视音频编码标准多一些，比如MKV。而有些格式则支持的相对比较少，比如说RMVB。
这些封装格式都有相关的文档，在这里就不一一例举了。
我自己也做过辅助学习的小项目：
4. 视频编码
视频编码的主要作用是将视频像素数据（RGB，YUV等）压缩成为视频码流，从而降低视频的数据量。如果视频不经过压缩编码的话，体积通常是非常大的，一部电影可能就要上百G的空间。
主要视频编码一览
|
名称 |
推出机构 |
推出时间 |
目前使用领域 |
|
HEVC(H.265) |
MPEG/ITU-T |
2013 |
研发中 |
|
H.264 |
MPEG/ITU-T |
2003 |
各个领域 |
|
MPEG4 |
MPEG |
2001 |
不温不火 |
|
MPEG2 |
MPEG |
1994 |
数字电视 |
|
VP9 |
|
2013 |
研发中 |
|
VP8 |
|
2008 |
不普及 |
|
VC-1 |
Microsoft Inc. |
2006 |
微软平台 |
当前使用最多的视频编码方案就是H.264。
4.1 主流编码标准
H.264仅仅是一个编码标准，而不是一个具体的编码器，H.264只是给编码器的实现提供参照用的。
基于H.264标准的编码器还是很多的，究竟孰优孰劣？可参考：MSU出品的 H.264编码器比较（2011.5）
实际中使用最多的就是x264了，性能强悍（超过了很多商业编码器），而且开源。其基本教程网上极多，不再赘述。
Google推出的VP8属于和H.264同一时代的标准。总体而言，VP8比H.264要稍微差一点。
此外，我国还推出了自己的国产标准AVS，性能也不错，但目前比H.264还是要稍微逊色一点。不过感觉我国在视频编解码领域还算比较先进的，可参考：视频编码国家标准AVS与H.264的比较（节选）
5. 音频编码
音频编码的主要作用是将音频采样数据（PCM等）压缩成为音频码流，从而降低音频的数据量。
主要音频编码一览
|
名称 |
推出机构 |
推出时间 |
目前使用领域 |
|
AAC |
MPEG |
1997 |
各个领域（新） |
|
AC-3 |
Dolby Inc. |
1992 |
电影 |
|
MP3 |
MPEG |
1993 |
各个领域（旧） |
|
WMA |
Microsoft Inc. |
1999 |
微软平台 |
6. 现有网络视音频平台对比
现有的网络视音频服务主要包括两种方式：点播和直播。点播意即根据用户的需要播放相应的视频节目，这是互联网视音频服务最主要的方式。绝大部分视频网站都提供了点播服务。直播意即互联网视音频平台直接将视频内容实时发送给用户，目前还处于发展阶段。直播在网络电视台，社交视频网站较为常见。
6.1 直播平台参数对比
现有网络视音频平台参数对比
|
名称 |
协议 |
封装 |
视频编码 |
音频编码 |
播放器 |
|
CNTV |
私有 |
||||
|
华数TV |
RTMP |
FLV |
H.264 |
AAC |
Flash |
|
六间房 |
RTMP |
FLV |
H.264 |
AAC |
Flash |
|
中国教育电视台 |
RTMP |
FLV |
H.264 |
AAC |
Flash |
|
北广传媒移动电视 |
RTMP |
FLV |
H.264 |
AAC |
Flash |
|
上海IPTV |
RTSP+RTP |
TS |
H.264 |
MP2 |
机顶盒 |
可以看出，直播服务普遍采用了RTMP作为流媒体协议，FLV作为封装格式，H.264作为视频编码格式，AAC作为音频编码格式。
采用RTMP作为直播协议的好处在于其被Flash播放器支持。而Flash播放器如今已经安装在全球99%的电脑上，并且与浏览器结合的很好。因此这种流媒体直播平台可以实现“无插件直播”，极大的简化了客户端的操作。
封装格式，视频编码，音频编码方面，无一例外的使用了FLV + H.264 + AAC的组合。FLV是RTMP使用的封装格式，H.264是当今实际应用中编码效率最高的视频编码标准，AAC则是当今实际应用中编码效率最高的音频编码标准。视频播放器方面，都使用了Flash播放器。
6.2 点播平台参数对比
主流网络视音频平台点播服务的参数对比如表所示：
现有互联网视音频平台参数对比
|
名称 |
协议 |
封装 |
视频编码 |
音频编码 |
播放器 |
|
CNTV |
HTTP |
MP4 |
H.264 |
AAC |
Flash |
|
CNTV（部分） |
RTMP |
FLV |
H.264 |
AAC |
Flash |
|
华数TV |
HTTP |
MP4 |
H.264 |
AAC |
Flash |
|
优酷网 |
HTTP |
FLV |
H.264 |
AAC |
Flash |
|
土豆网 |
HTTP |
F4V |
H.264 |
AAC |
Flash |
|
56网 |
HTTP |
FLV |
H.264 |
AAC |
Flash |
|
音悦台 |
HTTP |
MP4 |
H.264 |
AAC |
Flash |
|
乐视网 |
HTTP |
FLV |
H.264 |
AAC |
Flash |
|
新浪视频 |
HTTP |
FLV |
H.264 |
AAC |
Flash |
可以看出，点播服务普遍采用了HTTP作为流媒体协议，H.264作为视频编码格式，AAC作为音频编码格式。
采用HTTP作为点播协议有以下两点优势：一方面，HTTP是基于TCP协议的应用层协议，媒体传输过程中不会出现丢包等现象，从而保证了视频的质量；另一方面，HTTP被绝大部分的Web服务器支持，因而流媒体服务机构不必投资购买额外的流媒体服务器，从而节约了开支。
点播服务采用的封装格式有多种：MP4，FLV，F4V等，它们之间的区别不是很大。视频编码标准和音频编码标准是H.264和AAC。这两种标准分别是当今实际应用中编码效率最高的视频标准和音频标准。视频播放器方面，无一例外的都使用了Flash播放器。