【播放器】播放器/短视频 SDK 架构设计
Android中，我们可以直接使用MediaRecord来进行录像，但是在很多适合MediaRecord并不能满足我们的需求，比如我们需要对录制的视频加水印或者其他处理后，所有的平台都按照同一的大小传输到服务器等。 用Android4.1增加的API MediaCodec和 Android 4.3增加的API MediaMuxer进行Mp4视频的录制。
音视频编解码用到的MediaCodec是Android 4.1新增的API，音视频混合用到的MediaMuxer是Android 4.3新增的API。
github上十二款最著名的Android播放器开源项目-https://www.jianshu.com/p/53581512ba3f
VideoPlayerManager- https://github.com/danylovolokh/VideoPlayerManager 介绍：帮助控制MediaPlayer类的项目。可以方便的在ListView和RecyclerView中使用MediaPlayer。它还能跟踪滚动列表当前可视范围最大的item，并提供回调的api。
推流拉流同时进行- https://github.com/huangjingqiang/jjdxm_ijkplayer-master
列表上自动播放视频： JiaoZiVideoPlayer,autovideoplayer播放器；
– SDK 性能的指标 Android：
GC ：可以通过 GC 日志记录，Mirror GC 和 Full GC 的频次和时间，Full GC * 会造成比较明显的卡顿，需要评估
UI Loop 就是 VSync Loop ：反映 SDK 对 App 流畅度的影响，理论上 60 fps 是最流畅的值。
Memory ：反映 SDK 占用内存的大小
CPU Usage ：反映 SDK 占用计算资源的大小
- SDK 性能的指标 iOS：
UI Loop ：反映 SDK 对 App 流畅度的影响，理论上 60 fps 是最流畅的值。
Memory ：反映 SDK 占用内存的大小
CPU Usage ：反映 SDK 占用计算资源的大小
1)影响视频清晰度的指标：帧率；码率；分辨率；量化参数（压缩比）
2)影响视频流畅度的指标：码率；帧率
3)其他重要指标，直播是流量和性能的消耗大户：耗电量；发热（不好量化，大部分情况发热和耗电量正比，可以使用耗电量暂时替代）。
短视频 SDK
如何设计一款优秀的短视频 SDK- http://blog.51cto.com/ticktick/1955243
移动视频播放SDK框架ijkplayer: https://github.com/Bilibili/ijkplayer
七牛推出免费Android 平台的播放器 SDK- https://github.com/pili-engineering/PLDroidPlayer
Video-recorder项目- https://github.com/zhanxiaokai/Android-as_video_recorder
Video-Player项目- https://github.com/zhanxiaokai/Android-as_video_player
– 短视频 SDK 架构设计实践- http://blog.csdn.net/dev_csdn/article/details/78683826
短视频开发需要的预备知识及难点：贴纸，特效/美颜/混音/内置滤镜等SO，不使用 ffmpeg 的软解软编，而是尽量使用 Android 和 iOS 的系统 API 进行硬编硬解。水印、文字特效、背景音乐、多音频混音等
- 音视频领域固有门槛
深刻理解音视频编码格式 H.264 和 AAC 的编码细节；混音时如何将两个音频调整到一致的参数，使用什么样的算法去混合等等。 - 图形图像、OpenGL 处理
摄像头预览数据，图像处理，音视频编解码都需要了解 RGB 和 YUV 色彩空间的数据格式，以及它们之间转换的方式等等；其中部分操作可以利用更高效的 OpenGL 去完成，如美颜滤镜，图层混合，放大/缩小，旋转，还有图像裁剪等等。 - 平台相关
要对相应平台的摄像头、麦克风、编解码、多媒体处理等 API 十分熟悉，否则它们的一些坑会耗费你大量时间。 - 高级功能
视频编辑少不了特色和高级的功能，例如美颜，滤镜，MV 特效，倍数拍摄，文字特效等，每一个高级功能都对各方面技术提出很高的要求。 - 系统版本，机型等兼容性问题
这算是一个老生常谈的问题，无论 iOS 还是 Android，机型和系统版本都越来越多了，必然会带来兼容性问题。比如会有小部分 Android 机型编码的视频在 iOS 端播放不了的情况，类似这种兼容性问题都是需要进行解决的。 - 性能以及资源占用的优化
移动应用的计算资源受到相应系统的严格制约，在进行音视频采集，渲染，编码等复杂计算的同时，还要确保应用有足够的资源流畅运行，这要求开发人员有丰富的调优能力。
快手、秒拍、美拍等短视频 App。当时我正好在 YY 从事短视频 App 相关的工作，来到七牛后，在客户端团队先后参与直播、连麦 SDK 的开发，后面开始主研短视频 SDK，致力做最优秀最好用的短视频 SDK。
短视频的生产模式：从 UGC 到 PGC，再到最新的 MCN（Multi-Channel Network），内容的产能和质量均得到了巨大提升。
短视频 SDK 的架构设计，包括架构设计理念、架构图、整体数据流程、模块架构设计等。
输入模块支持通过两种方式采集数据，一种是通过摄像头和麦克风采集数据，采集到的数据可以进行数据处理（美颜、人脸识别等），另一种则是通过文件导入并进行解码处理；编辑模块有着十分丰富的功能比如添加字幕、MV 特效、添加背景音乐等等；编码模块主要支持 H.264 软编/硬编以及 ACC 软编/硬编；编码之后的数据会进行 MP4 封包，此后进入输出模块，可以存储到本地也可以使用 HTTP 进行上传。
目前 MediaMuxer 在 Android 7.0+ 才支持对 B 帧封包，因此除非你的 APP 最低兼容到 7.0，否则建议选择使用 FFMpeg 进行封包。
– 短视频客户端SDK设计与实现- https://blog.csdn.net/vn9PLgZvnPs1522s82g/article/details/79017326
短视频SDK核心场景分为录播场景和直播场景：对于录播场景，主播端或者内容贡献者需要录制一个视频，后期对视频和音频频添加特效，比如主题、贴纸、混音、BGM等等，最终把视频上传到服务器，观众端则需要使用播放器播放以及社交互动即可；而对于直播场景同样包含这两个角色，主播端需要将内容进行实时直播，并针对于观众的一些行为完成实时互动，观众端则需要使用定制的播放器观看，这个场景下的播放器并非使用系统提供的播放器即可，必须加以定制化。
针对于录播和直播两个场景，他们的共同特点都包含视频录制器和视频播放器；区别则主要体现在是否具有实时交互性；他们需要在各自场景下做一些特殊的配置，比如对于直播来说推流的稳定性和拉流的秒开，对于录播则是后期视频处理和上传。
音频轨、视频轨以及字幕轨拆解出来，然后进行解码过程，一般采用采用硬件+软件解码的方案。开源音频Lame或者视频FFmpeg等。
视频播放器中中间处理过程使用的并不算很多，音频处理上可以做一些混音或者EQ处理，画面处理则是画质增强，如自动对比度、去块滤波器等，当然播放器处理中非常重要的一环就是音视频同步，目前一般有三种模式：音频向视频同步、视频向音频同步以及统一向外部时钟同步。我们一般会选择视频向音频同步，这主要是由于两方面的原因：一方面是由人的生理特性决定的，相比于画面，人对声音的感受会更加强烈；另一方面音频PCM是线性的，我们可以信赖播放器也是线性的播放，因此在用视频帧向音频帧同步时，我们允许对视频帧进行丢帧或重复帧渲染。最后，输出则主要包含音频渲染和视频渲染两部分。
SDK中技术含量较高的主要有两点：跨平台的视频处理系统和跨平台的推流系统构建。跨平台的视频处理系统实际可以说是跨平台的图片滤镜系统，它所应用的场景主要有实现美颜、瘦脸这种单帧图片的处理，也有如雨天、老照片等主题效果，以及贴纸效果这几种。为了达到效果，我们通过OpenGL ES来实现，如果用软件(CPU中计算)做视频处理是非常消耗性能的，尤其在移动端无法接受。因此它的输入是纹理ID和时间戳，时间戳主要用于主题和贴纸场景的处理。输出则是处理完毕的纹理ID。
–短视频 SDK 功能点技术实现方式详解- https://tech.upyun.com/article/230/短视频 SDK 功能点技术实现方式详解.html
自定义背景音乐功能实现，首先需要将视频源分离成两个轨道：音频轨道和视频轨道。背景音乐素材剥离出音频轨道，将背景音乐音频轨道插入原声的音频轨道中。可以通过 AVMutableAudioMixInputParameters 来调整原声和背景音乐的音量。背景音乐插入成功之后，再将得到的音频轨道与之前的视频轨道通过调用 AVMutableComposition 相关类进行合成，最后导出为短视频。
摄像预览其实就是Android的Camera开发，对于Android的Camera开发，一般有两种方式，一种是借助Intent和MediaStroe调用系统Camera App程序来实现拍照和摄像功能，另外一种是根据Camera API自写Camera程序，自然第一种不能作为我们的滤镜开发，所以我们采用第二种方式。
– 移动平台（iOS/Android）播放器以及主站HTML5播放器等。视频编解码技术、移动视频技术开发、流媒体技术、应用于多媒体领域的云计算/大数据/模式识别/数据挖掘、视频异构开发等领域。以视频编解码算法作为主要研究方向。
其实无论是多么复杂精密的多媒体系统，其整体架构都离不开这几个结构，以视频信号为例，视频采集→视频预处理→视频编码与封装→数据的存储/传输→视频解封装/解码→视频后处理→视频输出。根据系统的规模和需求不同，每一个模块的复杂度和规模可能有非常巨大的不同。
最常用的有像视频的去噪、图像增强等。对于各种直播软件，各种美颜工具也极为重要。
视频的编码和封装可谓是整个系统的心脏，很多时候甚至直接决定了整个系统的性能和使用体验。编码/封装器用于将数据量庞大的图像数据压缩为某种格式的视频码流，压缩的性能直接影响后期进行存储和传输的代价，编码的运算速度又影响了整个系统的输入——输出延迟。因此，这一步骤的工作常常成为整个系统的焦点所在。
“多专全能”型的人才，从数学基础、网络技术、多端开发（server/client/web）、多种不同的编程语言（如C/C++/asm/Java/Objective-C/JS等）、多种不同系统平台（如Windows/Linux/MacOS/iOS/Android）等。还需要了解多种不同的系统架构等知识。可以说，任何一个合格的多媒体技术工程师，都有成为全栈/架构师的潜质。
读书和培训都已经传统的方式，只采用这样的方式在现在已经不够。个人感觉其实目前对自身提高最有效率的方式莫过于分享。分享有多种形式，包括在技术研讨会上做报告、写博客和开源项目都是很好的方式。比如CSDN的博客/论坛、微信公众号、微博文章等媒体都是相当有效的渠道。
– SDK设计中的技术细节
1.OpenGL实现美颜 Android? 直播时美颜滤镜，拍照美颜滤镜
Android 关于美颜/滤镜 从OpenGl录制视频的一种方案- http://www.jianshu.com/p/12f06da0a4ec
Android+JNI+OpenGL开发自己的美图秀秀-http://blog.csdn.net/oshunz/article/details/50537631
Android 关于美颜/滤镜 利用PBO从OpenGL录制视频- http://www.jianshu.com/p/3bc4db687546
硬编码无法设置fps？BGRA转ARGB转YUV420
最先找到的就是GPUImage - https://github.com/CyberAgent/android-gpuimage
后来找到了MagicCamera-https://github.com/a483210/MagicCamera-ImageReader https://github.com/wuhaoyu1990/MagicCamera
MagicCamera采用的是录制方案来自于grafika- https://github.com/google/grafika
MediaCodec就可以通过这个Surface录制出H264，具体代码可以看VideoEncoderCore- MediaCodec录制出来的是H264，而ImageReader拿出来的是BGRA的。
Yasea is an Android streaming client. It encodes YUV and PCM data from camera and microphone to H.264/AAC, encapsulates in FLV and transmits over RTMP. https://github.com/begeekmyfriend/yasea
滤镜的开发主要是写opengl片段着色器,从而实现各种滤镜效果。水印通过canvas画draw上去
GPUImage详细解析（六）-用视频做视频水印,文字水印和动态图像水印.
2.AAC 的编码细节?
AAC最多的是LC和HE(适合低码率)。流行的Nero AAC编码程序只支持LC，HE，HEv2这三种规格，编码后的AAC音频，规格显示都是LC。HE其实就是AAC（LC）+SBR技术，HEv2就是AAC（LC）+SBR+PS技术；AAC的音频文件格式有ADIF ＆ ADTS：
无噪解码实际上就是哈夫曼解码，通过反量化(Dequantize)、联合立体声（Joint Stereo），知觉噪声替换（PNS）,瞬时噪声整形（TNS），反离散余弦变换（IMDCT），频段复制 （SBR）这几个模块之后，得出左右声道的PCM码流，再由主控模块将其放入输出缓冲区输出到声音播放设备。
FFmpeg 可以支援 4 个 AAC-LC 编码器 (aac, libfaac, libfdk_aac, libvo_aacenc) 与两个 AAC-HE 编码器 (libaacplus, libfdk_aac)。
3.弹幕？
关于直播的技术细节其实就是两个方面一个是推流一个是拉流，而弹幕的实现核心在即时聊天，使用聊天室的就能实现，只是消息的展示方式不同而已。
JieCaoVideoPlayer是基于MediaPlayer的写的，不是基于ijkplayer封装的-https://github.com/lipangit/JiaoZiVideoPlayer
直播播放器+弹幕 Demo 直播的播放器+弹幕的解决方案- https://github.com/Hemumu/HLiveDemo/tree/master
libndkbitmap.so(ndk)源码：https://github.com/Bilibili/NativeBitmapFactory
4.RGB 和 YUV 色彩空间的数据格式？
5.代码去解析音视频文件？视频数据与视频头、头文件？
6.拍照的API？滤镜相机GPUImage性能升级成纯GPU + GPUImageRenderer
7.模拟视频信号、数字视频信号？
8.音视频同步？
采样频率是指将模拟声音波形进行数字化时，每秒钟抽取声波幅度样本的次数。每一帧音频或视频都有一个持续时间：duration。正常人听觉的频率范围大约在20Hz~20kHz之间，根据奈奎斯特采样理论，为了保证声音不失真，采样频率应该在40kHz左右。
常用的音频采样频率有8kHz、11.025kHz、22.05kHz、16kHz、37.8kHz、44.1kHz、48kHz等，如果采用更高的采样频率，还可以达到DVD的音质对采样率为44.1kHz的AAC音频进行解码时，一帧的解码时间须控制在23.22毫秒内。
一帧 1024个 sample；采样率 Samplerate 44100Hz，每秒44100个sample, 所以根据公式，音频帧的播放时间=一个AAC帧对应的采样样本的个数/采样频率；当前AAC一帧的播放时间是= 1024*1000000/44100= 22.32ms(单位为ms)
以音频的播放时长为基准，将视频同步到音频上以实现视音频的同步播放的。视频和音频的同步实际上是一个动态的过程，同步是暂时的，不同步则是常态。以选择的播放速度量为标准，快的等待慢的，慢的则加快速度，是一个你等我赶的过程。
– 播放速度标准量的的选择一般来说有以下三种：
1.将视频同步到音频上，就是以音频的播放速度为基准来同步视频。视频比音频播放慢了，加快其播放速度；快了，则延迟播放。
2.将音频同步到视频上，就是以视频的播放速度为基准来同步音频。
3.将视频和音频同步外部的时钟上，选择一个外部时钟为基准，视频和音频的播放速度都以该时钟为标准。
在视音频流中的包中都含有DTS和PTS；DTS，Decoding Time Stamp，解码时间戳，告诉解码器packet的解码顺序；PTS，Presentation Time Stamp，显示时间戳，指示从packet中解码出来的数据的显示顺序。
视频的编码要比音频复杂一些，特别的是预测编码是视频编码的基本工具，这就会造成视频的DTS和PTS的不同。这样视频编码后会有三种不同类型的帧：
I帧 关键帧，包含了一帧的完整数据，解码时只需要本帧的数据，不需要参考其他帧。
P帧 P是向前搜索，该帧的数据不完全的，解码时需要参考其前一帧的数据。
B帧 B是双向搜索，解码这种类型的帧是最复杂，不但需要参考其一帧的数据，还需要其后一帧的数据。
I帧的解码是最简单的，只需要本帧的数据；P帧也不是很复杂，值需要缓存上一帧的数据即可，总体来说都是线性，其解码顺序和显示顺序是一致的。B帧就比较复杂了，需要前后两帧的顺序，并且不是线性的，也是造成了DTS和PTS的不同的“元凶”，也是在解码后有可能得不到完整Frame的原因。
即时通讯，音视频同步技术。网络延迟、抖动、网络传输条件变化等因素引起的音视频不同步的问题。
引起音视频不同步的原因主要有两种：一种是终端处理数据引起的，发送端在数据的采集、编码、打包等模块和接收端在处理解包、解压、回放等模块时，由于音频和视频的数据量以及编码算法不同而引起的时间差。并且发送端没有统一的同步时钟；另一种是网络传输延时，网络传输是受到网络的实时传输带宽、传输距离和网络节点的处理速度等因素的影响，在网络阻塞时，媒体信息不能保证以连续的“流”数据方式传输，特别是不能保证数据量大的视频信息的连续传输，从而引起媒体流内和流间的失步。
播放 流程: 获取流–>解码–>播放
录制播放路程: 录制音频视频–>剪辑–>编码–>上传服务器 别人播放.
直播 过程 : 录制音视频–>编码–>流媒体传输–>服务器—>流媒体传输到其他app–>解码–>播放
9.视频处理功能如美颜、视频水印、滤镜、连麦等？
点播服务
点播服务普遍采用了HTTP作为流媒体协议，H.264作为视频编码格式，AAC作为音频编码格式。采用HTTP作为点播协议有以下两点优势：一方面，HTTP是基于TCP协议的应用层协议，媒体传输过程中不会出现丢包等现象，从而保证了视频的质量；另一方面，HTTP被绝大部分的Web服务器支持，因而流媒体服务机构不必投资购买额外的流媒体服务器，从而节约了开支。点播服务采用的封装格式有多种：MP4，FLV，F4V等，它们之间的区别不是很大。视频编码标准和音频编码标准是H.264和AAC。这两种标准分别是当今实际应用中编码效率最高的视频标准和音频标准。视频播放器方面，无一例外的都使用了Flash播放器。