视频【解码】原理（播放器原理），音视频同步等

 1.视频编码格式：H264, VC-1, MPEG-2, MPEG4-ASP (Divx/Xvid), VP8, MJPEG 等。
 2.音频编码格式：AAC, AC3, DTS(-HD), TrueHD, MP3/MP2, Vorbis, LPCM 等。
 3.字幕编码格式：VOB, DVB Subs, PGS, SRT, SSA/ASS, Text。

视频 = 图片、图像(摄像头) + 声音(麦克风) ；

- aac audio_codec; h264,video_codec;25 framerate 25帧;

 - Camera-YUV帧序列-YUV帧预处理（镜像 缩放 旋转）-编码器-H264数据
从摄像头输出的YUV帧经过预处理之后，送入编码器，获得编码好的h264视频流。

   mime：用来表示媒体文件的格式 mp3为audio/mpeg；aac为audio/mp4a-latm；mp4为video/mp4v-es;音频前缀为audio，视频前缀为video 我们可用此区别区分媒体文件内的音频轨道和视频轨道。

  音频轨道和视频轨道，字幕轨道。音视频编码时，音视频同步；音视频解码时，音视频同步。 

> 媒体播放器三大底层架构：MPC、MPlayer和VLC。这3大架构及其衍生品占领了90%的市场，凡是用户能看到的免费媒体播放软件，无一不是源自这3大架构。 
  1.MPC基于DirectShow架构，是Windows系统下元祖级别的播放器。包括KMP之流最早也就是抄来MPC的代码再换个界面。MPCHC则在MPC的原作者Gabest渐渐退出开发后的继承者，MPCHC有很多创新特性，包括开始融入ffmpeg和支持更多DirectX特性和DXVA等等。
  2.如果说MPC是Windows上的元祖，那么mplayer就是linux上媒体播放的元祖了。mplayer使用ffmpeg作为解码核心，也是与ffmpeg结合最紧密的项目，ffmpeg的代码就是由mplayer来host，开发者群也有非常大的交集。借助linux开发/使用者的强大实力，mplayer建立了要比DirectShow稳定的多的工作流程。超越ffmpeg本身的功能外，后来又通过反向工程使之可以调用Windows上的DirectShow Filter DLL，让mplayer架构越来越吸引人，成为兼具稳定性和性能的优秀作品。 
  3.VLC是个后起之秀，开发速度的进展可以说是一只奇葩。虽然同样基于ffmpeg，但可能是相对于“左三年右三年缝缝补补又三年”的mplayer架构来说，VLC的架构在设计之初就很好的考虑到模块化开发，所以使它更吸引年轻的开发人员。成为近年发展非常快的架构。

> 播放器(解码)原理
视音频编解码技术零基础学习方法- https://blog.csdn.net/leixiaohua1020/article/details/18893769
 -- 一般处理视频的步骤都是：
编码：预测 -> 变换+量化处理 -> 熵编码 -> 环路过滤器
解码：熵编码 -> 预测 -> 反量化处理+变幻 -> 环路过滤器

-- 视频解码，视频播放器原理
 视音频技术主要包含以下几点：封装技术，视频压缩编码技术以及音频压缩编码技术。如果考虑到网络传输的话，还包括流媒体协议技术。
 视频播放器播放一个互联网上的视频文件，需要经过以下几个步骤：解协议，解封装，解码视音频，视音频同步。如果播放本地文件则不需要解协议，为以下几个步骤：解封装，解码视音频，视音频同步。
  1.解协议的作用，就是将流媒体协议的数据，解析为标准的相应的封装格式数据。视音频在网络上传播的时候，常常采用各种流媒体协议，例如HTTP，RTMP，或是MMS等等。这些协议在传输视音频数据的同时，也会传输一些信令数据。这些信令数据包括对播放的控制（播放，暂停，停止），或者对网络状态的描述等。解协议的过程中会去除掉信令数据而只保留视音频数据。例如，采用RTMP协议传输的数据，经过解协议操作后，输出FLV格式的数据。
  2.解封装的作用，就是将输入的封装格式的数据，分离成为音频流压缩编码数据和视频流压缩编码数据。封装格式种类很多，例如MP4，MKV，RMVB，TS，FLV，AVI等等，它的作用就是将已经压缩编码的视频数据和音频数据按照一定的格式放到一起。例如，FLV格式的数据，经过解封装操作后，输出H.264编码的视频码流和AAC编码的音频码流。
  3.解码的作用，就是将视频/音频压缩编码数据，解码成为非压缩的视频/音频原始数据。音频的压缩编码标准包含AAC，MP3，AC-3等等，视频的压缩编码标准则包含H.264，MPEG2，VC-1等等。解码是整个系统中最重要也是最复杂的一个环节。通过解码，压缩编码的视频数据输出成为非压缩的颜色数据，例如YUV420P，RGB等等；压缩编码的音频数据输出成为非压缩的音频抽样数据，例如PCM数据。

   4.音视频的同步 。

-- 对视频播放的流程总结一下就是：读取下一帧 —>解码 —>播放 —>不断往复。
 1.解协议：从原始的流媒体协议数据中去掉信令数据只保留音视频数据,如采用RTMP协议传输的数据，经过解协议后输出flv格式的数据。
 2.解封装：分离音频压缩编码数据和视频压缩编码数据,常见的封装格式mp4,mkv,rmvb,ts,flv,avi这些格式的作用就是将已经压缩编码的视频数据和音频数据放到一起,例如FLV格式的数据经过解封装后输出H.264编码的视频码流和AAC编码的音频码流。
 3.解码：将视频，音频压缩编码数据，还原成非压缩的视频，音频原始数据,音频的压缩编码标准包括AAC,MP3，AC-3等，视频压缩编码标准包含H.264,MPEG2,VC-1等,经过解码，得到非压缩的视频颜色数据如YUV420P,RGB和非压缩的音频数据如PCM等。
 4.音视频同步：将同步解码出来的音频和视频数据分别送至系统声卡和显卡播放。

-- 播放器基本原理（播放四步法）- https://www.jianshu.com/p/82e778eb618b
 播放视频前得知道要播放的视频是什么格式的，所以第一步是数据接收。接受完数据后，需要对视频做一个解复用（demux）的处理，分解为图像轨道（track)、音频轨道、字幕轨道。分解完之后，则需要进行解码，图像解码、音频解码，解码完才是输出，调用显示设备播放。
 播放器也采用分而治之的办法，大问题可以分解为四个小问题：1，数据接收;2，数据解析;3，数据解码;4，数据输出。编码格式涉及到的I帧，P帧，B帧，分别对应帧内解码，帧间预测，双向预测的编解码方式。

 视频直播技术详解之现代播放器原理- https://blog.csdn.net/qiansg123/article/details/80125641
 视频播放器控制原理： ffplay 播放器源代码分析- https://cloud.tencent.com/developer/article/1004559
 播放器原理：对音视频帧序列的控制。今天所有的付费视频服务都基于DRM管理，而DRM则很大程度上依赖于平台或者设备。多媒体引擎中的DRM管理器是更底层解码器中内容解密API的包装。
 一个典型的播放器可以分解成三部分：UI、多媒体引擎和解码器；新的基于HTTP的流媒体格式需要一种全新的组件来处理和控制新的复杂性：解析声明文件、下载视频片段、自适应码率监控以及决策指定等甚至更多。多媒体引擎中也有非常多的不同组件和特性，从字幕到截图到广告插入等。
-- 现代多媒体处理引擎中各组件的细节：1. 声明文件解释和解析器；2. 下载器（下载声明文件、多媒体片段以及密钥）；3. 流播放引擎；4. 资源质量参数预估器（带宽、CPU和帧率等）；5. ABR切换控制器；6. DRM管理器（可选组件）；7. 格式转换复用器（可选组件）

> 音视频的同步
深入理解Android音视频同步机制（五）- https://blog.csdn.net/nonmarking/article/details/78747369
音视频同步的播放器- https://github.com/zhanghuicuc/simplest_android_avplayer
MediaSync的音视频同步结果，研究背后的原理- https://github.com/zhanghuicuc/MediaSyncExample

同步优化this sample shows how to use MediaCodec and AudioTrack to build an android player, with avsync optimization-
https://github.com/zhanghuicuc/simplest_android_avplayer

-- 引起音视频不同步的原因主要有两种：一种是终端处理数据引起的，发送端在数据的采集、编码、打包等模块和接收端在处理解包、解压、回放等模块时，由于音频和视频的数据量以及编码算法不同而引起的时间差。并且发送端没有统一的同步时钟；另一种是网络传输延时，网络传输是受到网络的实时传输带宽、传输距离和网络节点的处理速度等因素的影响，在网络阻塞时，媒体信息不能保证以连续的“流”数据方式传输，特别是不能保证数据量大的视频信息的连续传输，从而引起媒体流内和流间的失步。

-- 直播中音视频同步
可以用WebRTC来做视频直播吗？
android音视频点/直播模块开发- https://www.jianshu.com/p/8436c7353296
（教育，游戏，娱乐，体育，跑步，餐饮，音乐等）领域做音视频直播/点播功能。
-- 常见的封装格式
* MPEG : 编码采用的容器，具有流的特性。里面又分为 PS，TS 等，PS 主要用于 DVD 存储，TS 主要用于 HDTV.
* MPEG Audio Layer 3 :大名鼎鼎的 MP3，已经成为网络音频的主流格式，能在 128kbps 的码率接近 CD 音质
* MPEG-4(Mp4) : 编码采用的容器，基于 QuickTime MOV 开发，具有许多先进特性;实际上是对Apple公司开发的MOV格式(也称Quicktime格式)的一种改进.
* MKV: 它能把 Windows Media Video，RealVideo，MPEG-4 等视频音频融为一个文件，而且支持多音轨，支持章节字幕等;开源的容器格式
* 3GP : 3GPP视频采用的格式， 主要用于流媒体传送;3GP其实是MP4格式的一种简化版本,是手机视频格式的绝对主流.
* MOV : QuickTime 的容器，恐怕也是现今最强大的容器，甚至支持虚拟现实技术，Java等，它的变种 MP4,3GP都没有这么厉害;广泛应用于Mac OS操作系统，在
Windows操作系统上也可兼容，但是远比不上AVI格式流行
* AVI : 最常见的音频视频容器,音频视频交错（Audio Video Interleaved）允许视频和音频交错在一起同步播放.
* WAV : 一种音频容器，大家常说的 WAV 就是没有压缩的 PCM 编码，其实 WAV 里面还可以包括 MP3 等其他 ACM 压缩编码

1.播放    流程: 获取流–>解码–>播放 
2.录制播放路程: 录制音频视频–>剪辑–>编码–>上传服务器–>别人播放. 
3.直播   过程 : 录制音视频–>编码–>流媒体传输–>服务器—>流媒体传输到其他app–>解码–>播放；
              采集 —>处理—>编码和封装—>推流到服务器—>服务器流分发—>播放器流播放 ；

  音视频可能在不同的线程进行采集的，因此可能会有不同步的情况，比如音频已经开始了，视频还没出来。细节，比如音视频同步，传输过程中的QOS等。流服务器才是关键呀！流媒体服务可以用nginx的rtmp、hls模块，red5等，收费的有fms ，wowza。视频上很容易就可以做到倍速播放，一般的视频格式都是每秒固定的帧数，按比例跳帧就可以了。

-- 音视频的同步有三种方式：
 1.参考一个外部时钟，将音频与视频同步至此时间。我首先想到这种方式，但是并不好，由于某些生物学的原理，人对声音的变化比较敏感，但是对视觉变化不太敏感。所以频繁的去调整声音的播放会有些刺耳或者杂音吧影响用户体验。（ps：顺便科普生物学知识）。
 2.以视频为基准，音频去同步视频的时间。不采用，理由同上。
 3.以音频为基准，视频去同步音频的时间。 所以这个办法了。

    所以，原理就是以音频时间为基准，判断视频快了还是慢了，从而调整视频速度。其实是一个动态的追赶与等待的过程。一般会选择视频向音频同步。视音频同步的作用，就是根据解封装模块处理过程中获取到的参数信息，同步解码出来的视频和音频数据，并将视频音频数据送至系统的显卡和声卡播放出来。

-- 对于播放器来说，音视频同步是一个关键点，同时也是一个难点，同步效果的好坏，直接决定着播放器的质量。通常音视频同步的解决方案就是选择一个参考时钟（主 clock），播放时读取音视频帧上的时间戳，同时参考当前时钟参考时钟（主 clock）上的时间来安排播放。
 1.如果音视频帧的播放时间大于当前参考时钟上的时间，则不急于播放该帧，直到参考时钟达到该帧的时间戳；
 2.如果音视频帧的时间戳小于当前参考时钟上的时间，则需要“尽快”播放该帧或丢弃，以便播放进度追上参考时钟。
-- 参考时钟的选择也有多种方式：
 1.选取视频时间戳作为参考时钟源；
 2.选取音频时间戳作为参考时钟源；
 3.选取外部时间作为参考时钟源；
考虑人对视频、和音频的敏感度，在存在音频的情况下，优先选择音频作为主时钟源。

视频方面，我们关注的是同步逻辑对视频码流的pts做了哪些调整。 
音频方面，我们关注的是同步逻辑中是如何获取“Audio当前播放的时间”的。

-- 音频轨、视频轨以及字幕轨拆解出来，然后进行解码过程，一般采用采用硬件+软件解码的方案。开源音频Lame或者视频FFmpeg等。
- 音视频中都有DTS与PTS:
DTS ，Decoding Time Stamp，解码时间戳，告诉解码器packet的解码顺序。
PTS ，Presentation Time Stamp，显示时间戳，指示从packet中解码出来的数据的显示顺序。

--  对播放器架构演进、流媒体存储传输、视频编解码标准及图像声音信号处理，既对数学要求较高又与当时全民IT热相结合的专业——(计算机)信息安全，精妙绝伦的数论及密码学。
  既能应用密码学的知识技能又能和声色并茂的多媒体场景结合起来的信息隐藏和数字水印，音视频技术是互联网品质生活的连接器。连接器”的另一头则连接且聚合着信息论、最优化理论、图形图像学、声学、人类视觉系统等一众根基深厚、源远流长的学派。

  一套完整的音视频产品，要打造端到端的用户体验，需要考虑CDN调度接入、媒体文件存储分发、流媒体传输、客户端网络连接等等环节，其间相互配合、制约、平衡，哪里是单纯的Codec或者某个算法就能决定得了。 

-- 音视频同步
音视频同步原理解析；音频编码和解码原理- http://blog.csdn.net/real_myth/article/details/52512119
音视频同步实现视频播放器- http://blog.csdn.net/vista1995/article/details/54631588
  基准时间，在音视频同步，我们是以音频的时间戳为基准时间的.
  音视频同步的思路如下。首先获取第一帧的音视频之间的时间差mTimeSourceDeltaUs，理论上如果是同步的音视频的话，在任何时刻它们之间的差都是mTimeSourceDeltaUs这么多。如果某一个时刻它们的差不是mTimeSourceDeltaUs了，就说明不同步了。

  DTS（解码时间戳）和PTS（显示时间戳）分别是解码器进行解码和显示帧时相对于SCR（系统参考）的时间戳。SCR可以理解为解码器应该开始从磁盘读取数据时的时间。从技术上来说，解决音视频同步问题的最佳方案就是时间戳：首先选择一个参考时钟（要求参考时钟上的时间是线性递增的）；生成数据流时依据参考时钟上的时间给每个数据块都打上时间戳（一般包括开始时间和结束时间）；在播放时，读取数据块上的时间戳，同时参考当前参考时钟上的时间来安排播放（如果数据块的开始时间大于当前参考时钟上的时间，则不急于播放该数据块，直到参考时钟达到数据块的开始时间；如果数据块的开始时间小于当前参考时钟上的时间，则“尽快”播放这块数据或者索性将这块数据“丢弃”，以使播放进度追上参考时钟）。
  避免音视频不同步现象有两个关键：一是在生成数据流时要打上正确的时间戳。第二个关键的地方，就是在播放时基于时间戳对数据流的控制，也就是对数据块早到或晚到采取不同的处理方法。

-- 音视频同步通讯SDK源码包分享：
Android：http://down.51cto.com/data/711001
Windows：http://down.51cto.com/data/715497
Linux：http://download.csdn.net/detail/weixiaowenrou/5169796
IOS：http://down.51cto.com/data/715486
WEB：http://down.51cto.com/data/710983

-- 音视频编解码流程：