流媒体（音视频、直播）的认识
我们日常能看到的视频、语音和现在比较流行的直播等，都是基于流媒体实现的，作为开发者，我们要想去彻底的准备或开发与视频、语音、直播相关的东西，了解其原理也是非常重要的。
什么是流媒体，为什么要用流媒体
流媒体就是指在Internet/Intranet上使用流式传输技术的连续时基媒体。
媒体一般都是很大的文件，我们在平常使用时必须先下载下来才能使用，大大浪费了我们的时间，流媒体就解决了这个问题，可以在数据发送时就能来时播放等。
采用了"流式传输"技术，文件象水流那样流动。文件不是一次读取发送所有的数据，而是首先在线路中发送音频或视频剪辑的第一部分。在第一部分开始播放的同时，数据的其余部分源源不断的流出，及时达到目的地供播放使用。为保证在阻塞造成网络速度下降的情况下播放不会发生中断，播放器在开始播放前先采集一小部分所谓缓冲的预备数据。如果数据流动速度保持足够快的话，播放是连续的。无论文件长30秒还是30分钟，用户只是在观看文件 前等上几秒钟生成这个缓冲数据
流媒体的原理
流式传输的实现途径与过程
首先，多媒体数据进行预处理才能适合流式传输，这是因为目前的网络带宽对多媒体巨大的数据流量来说还显得远远不够。预处理主要包括两方面：一是降低质量；二是采用先进高效的压缩算法。
其次，流式传输的实现需要缓存。这是因为Internet以包传输为基础进行连续的异步传输，对一个实时A/V源或存储的A/V文件，在传输中它们要被分解为许多包，由于网络是动态变化的，每个包选择的路由可能不尽相同，故到达客户端的时间延迟也就不等，甚至先发的数据包还有可能后到。为此，使用缓存系统来弥补延迟和抖动的影响，并保证数据包的顺序正确，从而使媒体数据能连续输出，而不会因为网络暂时阻塞使播放出现停顿。通常高速缓存所需容量并不大。这是因为高速缓存使用环行链表结构来存储数据：通过丢弃已经播放的内容，"流"可以重新利用空出的高速缓存空间来缓存后续尚未播放的内容。
再次，流式传输的实现需要合适的传输协议。WWW技术是以HTTP协议为基础的，而HTTP又建立在TCP协议基础之上。由于TCP需要较多的开销，故不太适合传输实时数据，在流式传输的实现方案中，一般采用HTTP/TCP来传输控制信息，而用RTP/UDP来传输实时声音数据。
流式传输的过程通常如下：
（1）、用户选择某一流媒体服务后，Web浏览器与Web服务器之间使用HTTP/TCP交换控制信息，以便把需要传输的实时数据从原始信息中检索出来；然后客户机上的Web浏览器启动A/V Helper程序，使用HTTP从Web服务器检索相关参数对Helper程序初始化。这些差数可能包括目录信息、A/V数据的编码类型或与A/V检索相关的服务器地址。
（2）、A/V Helper程序及A/V服务器运行实时流控制协议（RTSP），以交换A/V传输所需的控制信息。RTSP提供了操纵播放、快进、快倒、暂停及录制等命令的方法。
（3）、A/V服务器使用RTP/UDP协议将A/V数据传输给A/V客户程序，一旦A/V数据抵达客户端，A/V客户程序即可播放输出。
在流式传输中，使用RTP/UDP和RTSP/TCP两种不同的通信协议与A/V服务器建立联系，是为了能够把服务器的输出重定向到一个不同于运行A/V Helper程序所在客户机的目的地址。
了解完流媒体，改到我们客户端解码工作了->FFmpeg
FFmpeg是相当强大的多媒体编解码框架
当我们打开一个多媒体文件之后，第一步就是解复用Demux。
为了传输过程的方便，一般音频和视频会捆绑在一起压缩过后进行传输。所以我们解码的第一步就是将这些绑在一起的音频和视频流分开来，也就是传说中的解复用，所以一句话，解复用这一步就是将文件中捆绑在一起的音频流和视频流分开来以方便后面分别对它们进行解码
第二步就是解码。
Ffmpeg中Demux这一步是通过avformat_open_input（）这个api来做的，这个api读出文件的头部信息，并做demux，在此之后我们就可以读取媒体文件中的音频和视频流，然后通过av_read_frame()从音频和视频流中读取出基本数据流packet，然后将packet送到avcodec_decode_video2()和相对应的api进行解码。
基于FFmpeg的ijkplayer问题集：https://github.com/Bilibili/ijkplayer/issues
近期接触直播这方面的东西，先认识下基础，后期会更新新的学习进度，有这方面兴趣的可以加个好友。
