在具体的业务领域，你可以慢慢沉淀下来，用自己的努力和时间换来对领域知识的深入理解和积累，逐渐从一个开发小白走向最懂这个行业的专家。
-- 无论什么平台，他们的学习曲线其实是类似的，都要经历差不多如下的环节：
1.学习对应平台的编程语言，如：C/C++，Java，Object C，Javascript 等
2.熟悉对应平台提供的 API，如：UI 库，网络，文件，数据库， 图片处理，多媒体处理 等等
3.掌握平台相关的特性、框架和原理，如：Windows 的 WINSOCK，ODBC，WPF 等，Unix 的设计哲学，Android 的四大组件，iOS 的 MVC 模式等等
4.通过具体的项目，熟悉和练手，达到可完成任意功能的开发.
-- 音视频几个重要的环节:
1.录制音视频 AudioRecord/MediaRecord
2.视频剪辑 mp4parser 或ffmpeg
3.音视频编码 aac&h264
4.上传大文件 网络框架,进度监听,断点续传
5.流媒体传输 流媒体传输协议rtmp rtsp hls
6.音视频解码 aac&h264
7.渲染播放 MediaPlayer
- 视频组成：音频 视频 字幕。
封装格式：MKV/WebM, AVI, MP4/MOV, MPEG-TS/PS (including basic EVO support), FLV, OGG, 以及其他ffmpeg支持的格式！
视频编码：H264, VC-1, MPEG-2, MPEG4-ASP (Divx/Xvid), VP8, MJPEG 等。
音频编码：AAC, AC3, DTS(-HD), TrueHD, MP3/MP2, Vorbis, LPCM 等。
字 幕：VOB, DVB Subs, PGS, SRT, SSA/ASS, Text
--对于多媒体开发入门及提升:(MPEG阵营和Google开源阵营)
1.首先，务必明确自己的目标和定位。用互联网式的语言说，就是场景在哪里、有什么样的痛点，最终学习/开发出的技术方案/软件产品需要满足哪些可量化的指标。我个人建议在入门阶段不要过早聚焦在一个技术点上，而应该更多建立一个偏全局、偏框架性的概念理解。早早地手捧一份类似ISO/IEC 14496-10的大部头生掰硬啃，收获的可能只有心理上的高大上。不如先以外行心态、以给产品经理或者商务销售讲技术的心态，仅仅从通用性的逻辑层面来入门学习。把大象放进冰箱需要3步，那么一个实时视频聊天系统有哪几个逻辑模块呢？从一方好友开始呼叫、到双方建立连接、开始数据通信直至最终会话终止，其间的协议交互和流程是怎样的呢？不考虑具体的Codec实现及复杂的应用场景技术指标要求，就当是加强版的CS通信，比起某年初学socket API调用时的DEMO代码如何？……由此一层层、一步步用自己熟悉的技术类比、反推和延伸，并逐步理解主要环节的实现原理及技术难点，最终能给自己明确一两个点进行后续的深究挖掘，例如：彻底排查和理清实时通话中时延的原因并优化、寻找系统中能够影响图像质量的因素并进行优化等。
2.其次，针对一个具体的、“局部性”问题不妨以“庖丁解牛”“掘地三尺”的态度来对待。因为音视频技术有一定的数学基础和较清晰的年代演进历程，所以我个人非常主张追根溯源式的学习。例如我在公司内开设视频压缩原理的课程时，一定会先讲一次图像压缩的课程。看似古老的JPEG压缩框架，能够非常直接地理解Spatial domain到Transform domain的意义、DCT频带数据特征之于人类视觉的影响、量化及量化表的由来、变长字编码的设计理念等等。这些技术环节构成了视频压缩的半壁江山，而且虽然历经二十余年的发展，很多环节不断演进更迭，但其数学理论根基和工程设计理念得以传承和延续。再略微进一步，体会下WebP和JPEG流程上的差异与改进，Intra prediction的设计理念与作用已然清晰。至此，视频编码框架下I frame的主干流程跃然眼前；剩下的细节，比如Intra prediction如何从H.264/AVC的9种模式演变到HEVC的35种，虽是匠心不改、历经雕琢、但可作为锦上添花之物了。
3.再次，当一个个小的局部性问题逐个攻克后，就需要回归全局性视角，对之前已有的结论和观点再次推敲。多媒体项目产品中往往会遇到技术指标之间的冲突和矛盾，例如：开启复杂的算法工具可以获得更高的压缩效率，即同等码率下可以有更高的图像清晰度，但在中低端设备上复杂度过高会导致编码帧率上不来，严重时用户甚至会觉得画面有明显的顿挫感、通话质量不好。如何在一对对矛盾中取得权衡，既需要对每个指标背后的技术原理有深刻的理解，同时更要求对整体业务需求和应用场景有所把控。懂得取舍、合理平衡，也是多媒体开发进阶的必由之路。
4.最后，身处互联网行业，自然要重视信息的交流。但我个人不建议白纸一张时就盲目交流，也对很多自媒体鼓吹的碎片化干货学习保留怀疑。我建议初学者在具备一定基础后，带着自己的理解、感悟和困惑去交流，切勿人云亦云、东施效颦，对所谓大公司的“成功案例”、“领先指标”最好在充分对比业务场景、成本投入、平台差异、目标用户群等等因素后进行消化，并为我所用。
--《视音频基础知识》包括下面内容：
1.视频播放器原理
2.封装 格式（MP4，RMVB，TS，FLV，AVI）
3.视频编码数据（H.264，MPEG2，VC-1）
4.音频编码数据（AAC，MP3，AC-3）
5.视频像素数据（YUV420P，RGB）
6.音频采样数据（PCM）
-- 2012,2013年总结：在视音频技术道路上摸索-
研究视频质量评价的。做一个网络视音频方面的项目，需要研究网络协议。究RTSP+RTP/RTCP这样的流媒体协议。这样的协议组合很适合IPTV系统。实际互联网视频分析。对一个未知领域的摸索 。找到开源的优秀的视音频项目，花费了大量的时间。有实际应用价值的很多视音频项目都是不开源的商业项目。FLV是互联网上相当通用的封装格式，H.264也是相当通用的视频编码标准。文章《100行代码实现最简单的基于FFMPEG+SDL的视频播放器》。
为了寻找互联网视频使用较多的协议，我做了很多的分析工作。比如说，用WireShark抓取正在播放的互联网视频的数据报。然后把数据报的内容取出来进行分析。在多次的尝试之后，我发现：直播使用最多的是RTMP，主要因为它可以实现无插件直播；点播使用最多的是HTTP，主要因为它不丢包，而且节约服务器资源。基于HTTP的点播其实不用多学，因为实际上它和下载文件差不多。直播的RTMP协议则是需要学习的。
RTMP大部分文章都是协议破解之类的文章。后来找到了协议规范。把libRTMP看一看。libRTMP差不多是我看的第一个视音频工程内部的代码了，通过查看libRTMP的源代码，我渐渐的掌握了RTMP。
教室直播，学习的JavaEE，再结合新学的流媒体技术，自己设计前台，后台，各种界面；前台用div + css + jQuery，后台用Struts2 + Spring + Hibernate，流媒体技术采用RTMP相关技术，搞出了一个Demo。
用Eclipse + MinGW搭建了一个环境后就开始看起了FFMPEG的源代码。FFMPEG不仅仅局限于视频解码。事实上，它可以做和视音频相关的方方面面的工作。掌握了它，基本上就掌握了视音频处理技术了。互联网视音频的播放，码流分析，图像分析的系统。
视频质量评价技术其实很重要，是衡量视频好坏的关键技术。互联网视频技术，重点应该是质量评价。网络，视频，音频，编解码，质量评价。
-- Android 音视频开发入门指南- http://blog.51cto.com/ticktick/1956269 Android 音视频从入门到提高 —— 任务列表》，如果你认真把所有任务都完成了，你一定会成为音视频人才招聘市场的香饽饽
1. 在 Android 平台绘制一张图片，使用至少 3 种不同的 API，ImageView，SurfaceView，自定义 View
2. 在 Android 平台使用 AudioRecord 和 AudioTrack API 完成音频 PCM 数据的采集和播放，并实现读写音频 wav 文件
3. 在 Android 平台使用 Camera API 进行视频的采集，分别使用 SurfaceView、TextureView 来预览 Camera 数据，取到 NV21 的数据回调
4. 学习 Android 平台的 MediaExtractor 和 MediaMuxer API，知道如何解析和封装 mp4 文件
5. 学习 Android 平台 OpenGL ES API，了解 OpenGL 开发的基本流程，使用 OpenGL 绘制一个三角形
6. 学习 Android 平台 OpenGL ES API，学习纹理绘制，能够使用 OpenGL 显示一张图片
7. 学习 MediaCodec API，完成音频 AAC 硬编、硬解
8. 学习 MediaCodec API，完成视频 H.264 的硬编、硬解
9. 串联整个音视频录制流程，完成音视频的采集、编码、封包成 mp4 输出
10. 串联整个音视频播放流程，完成 mp4 的解析、音视频的解码、播放和渲染
11. 进一步学习 OpenGL，了解如何实现视频的剪裁、旋转、水印、滤镜，并学习 OpenGL 高级特性，如：VBO，VAO，FBO 等等
12. 学习 Android 图形图像架构，能够使用 GLSurfaceviw 绘制 Camera 预览画面
13. 深入研究音视频相关的网络协议，如 rtmp，hls，以及封包格式，如：flv，mp4
14. 深入学习一些音视频领域的开源项目，如 webrtc，ffmpeg，ijkplayer，librtmp 等等
15. 将 ffmpeg 库移植到 Android 平台，结合上面积累的经验，编写一款简易的音视频播放器
16. 将 x264 库移植到 Android 平台，结合上面积累的经验，完成视频数据 H264 软编功能
17. 将 librtmp 库移植到 Android 平台，结合上面积累的经验，完成 Android RTMP 推流功能
18. 上面积累的经验，做一款短视频 APP，完成如：断点拍摄、添加水印、本地转码、视频剪辑、视频拼接、MV 特效等功能
-- 推荐的参考资料：
1. 《雷霄骅的专栏》：
2. 《Android音频开发》：http://ticktick.blog.51cto.com/823160/d-15
3. 《FFMPEG Tips》：http://ticktick.blog.51cto.com/823160/d-17
4. 《Learn OpenGL 中文》：https://learnopengl-cn.readthedocs.io/zh/latest/
5. 《Android Graphic 架构》：https://source.android.com/devices/graphics/
-- 实时音视频技术入门提纲-
-音视频开发，就是要掌握图像、音频、视频的基础知识，并且学会采集、渲染、处理、传输等：
采集：它解决的是，数据从哪里来的问题
渲染：它解决的是，数据怎么展现的问题
处理：它解决的是，数据怎么加工的问题
传输：它解决的是，数据怎么共享的问题
- 音视频第三方库：
1）图像处理：OpenGL，OpenCV，libyuv，ffmpeg 等；
2）视频编解码：x264，OpenH264，ffmpeg 等；
3）音频处理：speexdsp，ffmpeg 等；
4）音频编解码：libfaac，opus，speex，ffmpeg 等。
源码库：kxMovie，GPUImage，FFmpeg，WebRTC，lame
-研究音视频传输，其实就是在研究协议，具体有哪些协议呢 ？
1）音视频在传输前，怎么打包的，如：FLV，ts，mpeg4 等；
2）直播推流，有哪些常见的协议，如：RTMP，RSTP 等；
3）直播拉流，有哪些常见的协议，如：RTMP，HLS，HDL，RTSP 等；
4）基于 UDP 的协议有哪些？如：RTP/RTCP，QUIC 等。
> 进阶研究
movie player for iOS using ffmpeg- https://github.com/kolyvan/kxmovie
腾讯音视频实验室：基于音视频细分场景的技术创新探索-
直面音视频质量评估之痛——走进腾讯音视频质量体系-
视频推荐中用户兴趣建模、识别的挑战和解法-
腾讯视频全网清晰度提升攻坚战-
多媒体技术领域，国家多媒体软件工程技术研究中心-http://multimedia.whu.edu.cn/index.php?m=content&c=index&a=show&catid=123&id=89
-- 视频编码解码器流程概述：
1.编码
(1)打开视频文件,获得视频流；
(2)从视频流中解包得到帧；
(3)帧不完整，重复从视频流中取；
(4)某些情况下需要将RGB格式的颜色空间转换到YUV格式的；
(5)对帧进行编码工作，也就是压缩的过程；
(6)重复第二步；
2.解码
(1)打开视频文件,获得视频流；
(2)从视频流中解包得到帧；
(3)帧不完整，重复从视频流中取；
(4)对帧进行解码工作；
(5)某些情况下需要将YUV格式的颜色空间转换到RGB格式；
(6)通过显示设备显示到显示器上；
(7)重复第二步；
3.编码器的核心为编码，解码器的核心在解码，二者是一个互为可逆的过程。
-- 音视频中的数据
-- 1.码流/每一帧中的哪些信息值得关注 ？
[ ] 是否包含：音频、视频；
[ ] 码流的封装格式；
[ ] 视频的编码格式；
[ ] 音频的编码格式；
[ ] 视频的分辨率、帧率、码率；
[ ] 音频的采样率、位宽、通道数；
[ ] 码流的总时长；
[ ] 其他 Metadata 信息，如作者、日期等；
[ ] 音频帧还是视频帧；
[ ] 关键帧还是非关键帧；
[ ] 帧的数据和大小；
[ ] 时间戳信息；
2.为什么需要拿到这些信息 ？
[ ] 码流的封装格式 -> 解封装；
[ ] 音频、视频的编码格式 -> 初始化解码器；
[ ] 视频的分辨率、帧率、码率 -> 视频的渲染；
[ ] 音频的采样率、位宽、通道数 -> 初始化音频播放器；
[ ] 码流的总时长 -> 展示、拖动；
[ ] 其他 Metadata 信息 -> 展示；
[ ] 音频帧还是视频帧 -> 分别送入音频/视频解码器；
[ ] 关键帧还是非关键帧 -> 追帧优化；
[ ] 帧的数据和大小 -> 取出帧的内容；
[ ] 时间戳信息 -> 音视频同步；
-- 音视频产品典型的场景
音视频产品往往需要权衡和取舍，以争取到端到端的整体表现和用户体验。以下有3个典型的场景举例：
1）点对点视频聊天、视频会议场景。这类用户场景对时延的要求很高，以至于传输协议很多时候是基于UDP的私有协议。甚至可以说，时延以及图像声音的连续性就决定了用户体验，而单帧图像的分辨率、纹理细腻度等，应该让位给前者。换言之，Codec的压缩率可以作出一定程度牺牲。因为可以预期的是，我们输入的图像分辨率不会太大、目标输出码率也不会太高，所以我们可以选择baseline方案、关闭B Frame类型、限制P Frame的参考范围等等。这种场景下，对Codec的更大期望，反而是追求输出码率的平稳，尽量避免发送数据量的陡变。
2）个人直播、典型的1 vs. N场景。这类应用对时延的要求相比会议应用要宽松不少，协议侧往往使用RTMP推流(主播端)和HTTP FLV/HLS播放(观众端)。显然，用户对图像质量有了较高的期望，图像分辨率和码率会向高位倾斜。此时的Codec应该尽力迎合质量的要求，提升压缩率、提升宝贵的上行带宽利用率，但需要留意的底线是Codec编码效率切勿直接造成(发送端)帧率低下、或者码流输出的严重滞后。如上文所言，我们需要建立和完善机型能力模型，另外APP内部具备不同档位码流切换的策略和能力。
3）拍摄类短视频场景。严格意义上这个不算实时场景，但考虑拍摄环节所见即所得的用户体验要求，我也一并讨论。这个场景下，对图像质量的要求极高，拍摄阶段需要尽可能快地响应用户回看、编辑等操作，发表阶段则一般是异步式的文件上传，所以时延完全是个伪命题。重点说下拍摄阶段的Codec要求，因为图像质量极高，所以按理应该极致追求压缩率，但如此一来，几乎必然影响用户回看操作的响应时间。可行的方案是转换思维，在拍摄阶段尽可能快、且保留图像细节，硬件Codec、高码率、“粗糙”的压缩算法配置为先；等待拍摄完成后，再开启复杂的Codec算法工具，作二次压缩，提高压缩率、保障发布阶段的上行效率。
-- 音视频容器中的视频和音频轨、字幕轨
平时看到的视频文件有许多格式，比如 avi， mkv， rmvb， mov， mp4等等，这些被称为容器（Container）， 不同的容器格式规定了其中音视频数据的组织方式（也包括其他数据，比如字幕等）。容器中一般会封装有视频和音频轨，也称为视频流（stream）和音频流，播放视频文件的第一步就是根据视频文件的格式，解析（demux）出其中封装的视频流、音频流以及字幕（如果有的话），解析的数据读到包 （packet）中，每个包里保存的是视频帧（frame）或音频帧，然后分别对视频帧和音频帧调用相应的解码器（decoder）进行解码， 比如使用 H.264编码的视频和MP3编码的音频，会相应的调用H.264解码器和MP3解码器，解码之后得到的就是原始的图像(YUV or RGB)和声音(PCM)数据，然后根据同步好的时间将图像显示到屏幕上，将声音输出到声卡，最终就是我们看到的视频。
-- 音视频领域
包括基础乐理知识；音频的处理（音效处理，混音处理等），处理视频，比如美颜、比如视频合唱等；跨平台的视频处理系统（VideoEffectProcessor-基于OpenGL ES的跨平台视频帧处理系统），实现了美颜、贴纸以及视频主题的功能；开发我了想和你唱的视频、音频联动的玩法；直播产品线，从录播做到直播；音频直播 视频直播；多媒体领域其实是很大的一个领域，包括但不限于采集、处理、编码、传输，解码，渲染等；比如传输，大家最常用的可能就是RTMP和HLS，而基于UDP的一些协议可能就会更加复杂一些，比如kcp、srt、rtp/rtcp；从人的生理感知能力来讲，文字->图片->语音->视频->直播->实时交互，这是感知的层级递进关系；秀场直播的连麦、PK，教育行业的一对一教学或者小班课的产品，游戏行业狼人杀等实时互动的桌游产品。
-- 视频功能
视频上很容易就可以做到倍速播放，一般的视频格式都是每秒固定的帧数，按比例跳帧就可以了。
音频加速，把相邻时钟周期内的声音电平信号取平均，或者用高斯平均值代替原信号，再精细点可以自适应地在音调信号比较丰富的地方设置比较高的权重来尽量少压缩保持音色。
音视频编码时，音视频同步；音视频解码时，音视频同步。
-- NV21，YUV，420SP，420P，NV21TOARGB，NV21TOYUV
YUV定义：分为三个分量，“Y”表示明亮度（Luminance或Luma），也就是灰度值；而“U”和“V” 表示的则是色度（Chrominance或Chroma），作用是描述影像色彩及饱和度，用于指定像素的颜色。
一般来说，直接采集到的视频数据是RGB24的格式，RGB24一帧的大小size＝width×heigth×3 Bit，RGB32的size＝width×heigth×4，如果是I420（即YUV标准格式4：2：0）的数据量是 size＝width×heigth×1.5 Bit。 在采集到RGB24数据后，需要对这个格式的数据进行第一次压缩。即将图像的颜色空间由RGB2YUV。
YUV420有打包格式(Packed)，一如前文所述。同时还有平面格式(Planar)，即Y、U、V是分开存储的，每个分量占一块地方，其中Y为 width*height，而U、V合占Y的一半，该种格式每个像素占12比特。根据U、V的顺序，分出2种格式，U前V后即YUV420P，也叫 I420，V前U后，叫YV12(YV表示Y后面跟着V，12表示12bit)。另外，还有一种半平面格式(Semi-planar)，即Y单独占一块地 方，但其后U、V又紧挨着排在一起，根据U、V的顺序，又有2种，U前V后叫NV12，在国内好像很多人叫它为YUV420SP格式；V前U后叫 NV21。 对手机摄像头采集的原始帧做Rotate或者Scale.
YCbCr不是一种绝对色彩空间，是YUV压缩和偏移的版本。
Y（Luma，Luminance）视讯，也就是灰阶值。UV 视作表示彩度的 C（Chrominance或Chroma）。主要的采样（subsample）格式有YCbCr 4:2:0、YCbCr 4:2:2、YCbCr 4:1:1和 YCbCr 4:4:4。YUV的表示法称为 A:B:C 表示法：
* 4:4:4 表示完全取样。
* 4:2:2 表示 2:1 的水平取样，没有垂直下采样。
* 4:2:0 表示 2:1 的水平取样，2:1 的垂直下采样。
* 4:1:1 表示 4:1 的水平取样，没有垂直下采样。
-- IPB帧，DTS，PTS
I帧编码是为了减少空间域冗余，P帧和B帧是为了减少时间域冗余。
GOP是由固定模式的一系列I帧、P帧、B帧组成。常用的结构由15个帧组成，具有以下形式 IBBPBBPBBPBBPBB。GOP中各个帧的比例的选取和带宽、图像的质量要求有一定关系。例如因为B帧的压缩时间可能是I帧的三倍，所以对于计算 能力不强的某些实时系统，可能需要减少B帧的比例。
DTS：Decoding Time stamp 解码时间戳 ;
PTS: Presentation Time Stamp 显示时间戳
-- 对于语音采样：
8,000 Hz - 电话所用采样率, 对于人的说话已经足够
11,025 Hz
22,050 Hz - 无线电广播所用采样率
32,000 Hz - miniDV 数码视频 camcorder、DAT (LP mode)所用采样率
44,100 Hz - 音频 CD, 也常用于 MPEG-1 音频（VCD, SVCD, MP3）所用采样率
47,250 Hz - Nippon Columbia (Denon)开发的世界上第一个商用 PCM 录音机所用采样率
48,000 Hz - miniDV、数字电视、DVD、DAT、电影和专业音频所用的数字声音所用采样率
50,000 Hz - 二十世纪七十年代后期出现的 3M 和 Soundstream 开发的第一款商用数字录音机所用采样率
50,400 Hz - 三菱 X-80 数字录音机所用所用采样率
96,000 或者 192,000 Hz - DVD-Audio、一些 LPCM DVD 音轨、Blu-ray Disc（蓝光盘）音轨、和 HD-DVD （高清晰度 DVD）音轨所用所用采样率
2.8224 MHz - SACD、 索尼 和 飞利浦 联合开发的称为 Direct Stream Digital 的 1 位 sigma-delta modulation 过程所用采样率。
50 Hz - PAL 视频
60 / 1.001 Hz - NTSC 视频
13.5 MHz - CCIR 601、D1 video
-- MPEG到目前为止已经制定并正在制定以下和视频相关的标准：
MPEG-1： 第一个官方的视訊音訊压缩标准，随后在Video CD中被采用，其中的音訊压缩的第三级（MPEG-1 Layer 3）简称MP3， 成为比较流行的音訊压缩格式。
MPEG-2： 广播质量的视訊、音訊和传输协议。被用于無線數位電視-ATSC、DVB以及ISDB、数字卫星电视（例如DirecTV）、 数字有线电视信号，以及DVD视频光盘技术中。
MPEG-3： 原本目标是为高解析度电视（HDTV）设计，随后發現MPEG-2已足夠HDTV應用，故 MPEG-3的研發便中止。
MPEG- 4：2003 年发布的视訊压缩标准，主要是扩展MPEG-1、MPEG-2等標準以支援視訊／音訊物件（video/audio "objects"）的編碼、3D內容、低位元率編碼（low bitrate encoding）和數位版權管理（Digital Rights Management），其中第10部分由ISO/IEC和ITU-T联合发布，称为H.264/MPEG-4 Part 10。参见H.264。
MPEG-7：MPEG-7并不是一个视訊压缩标准，它是一个多媒体内容的描述标准。
MPEG-21：MPEG-21是一个正在制定中的标准，它的目标是为未来多媒体的应用提供一个完整的平台。
在MPEG-4制定之前，MPEG-1、MPEG-2、H.261、H.263都是采用第一代压缩编码技术，着 眼于图像信号的统计特性来设计编码器，属于波形编码的范畴。第一代压缩编码方案把视频序列按时间先后分为一系列帧，每一帧图像又分成宏块以进行运动补偿和编码，这种编码方案存在以下缺陷：
1.将图像固定地分成相同大小的块，在高压缩比的情况下会出现严重的块效应，即马赛克效应；
2.不能对图像内容进行访问、编辑和回放等操作；
3.未充分利用人类视觉系统（HVS，Human Visual System）的特性。
MPEG-4则代表了基于模型/对象的第二代压缩编码技术，它充分利用了人眼视觉特性，抓住了图像信息传输的本质，从轮廓、纹理思路出发，支持基于视觉内容的交互功能，这适应了多媒体信息的应用由播放型转向基于内容的访问、检索及操作的发展趋势。
MPEG-4实现基于内容交互的首要任务就是把视频/图像分割成不同对象或者把运动对象从背景中分离出来，然后针对不同对象采用相应编码方法，以实现高效压缩。因此视频对象提取即视频对象分割，是MPEG-4视频编码的关键技术，也是新一代视频编码的研究热点和难点。
音视频同步通讯SDK源码包分享：Android：http://down.51cto.com/data/711001
