阿里和腾讯的云视频点播方案比较成熟，集成度高，且能力丰富，稳定性及效率也很高。但两者成本较高，需要收费，且SDK大小均在15M以上，对于我们的业务场景来说有些过于臃肿，定制性较弱，无法迅速的支持我们做定制性扩展。
当时的大众点评App UGC方案，基础能力是满足的，但因业务场景差异：
- 比如外卖的视频拍摄功能要求在竖屏下保证16:9的视频宽高比，这就需要对原有的采集区域进行截取，视频段落的裁剪支持不够等，业务场景的差异导致了实现方案存在巨大的差异，故放弃了大众点评App UGC方案。其他的一些开源方案（比如Grafika等），也无法满足要求，这里不再一一赘述。
通过技术调研和分析，吸取各开源项目的优点，并参考大众点评App UGC、Google CTS方案，对核心流程做了最终的方案选型，打造一个适合我们业务场景的方案，如下表所示：
2. 视频格式选型
- 采用H.264的视频协议：H.264的标准成熟稳定，普及率高。其最大的优势是具有很高的数据压缩比率，在同等图像质量的条件下，H.264的压缩比是MPEG-2的2倍以上，是MPEG-4的1.5～2倍。
- 采用AAC的音频协议：AAC是一种专为声音数据设计的文件压缩格式。它采用了全新的算法进行编码，是新一代的音频有损压缩技术，具有更加高效，更具有“性价比”的特点。
整体架构
我们整体的架构设计，用以满足业务扩展和平台化需要，可复用、可扩展，且可快速接入。架构采用分层设计，基础能力和组件进行下沉，业务和视频能力做分离，最大化降低业务方的接入成本，三方业务只需要接入视频基础SDK，直接使用相关能力组件或者工具即可。
整体架构分为四层，分别为平台层、核心能力层、基础组件层、业务层。
- 平台层：依赖系统提供的平台能力，比如Camera、OpenGL、MediaCodec和MediaMuxer等，也包括引入的平台能力，比如ijkplayer播放器、mp4parser。
- 核心能力层：该层提供了视频服务的核心能力，包括音视频编解码、音视频的转码引擎、滤镜渲染能力等。
- 基础能力层：暴露了基础组件和能力，提供了播放、裁剪、录屏等基础组件和对应的基础工具类，并提供了可定制的播放面板，可定制的缓存接口等。
- 业务层：包括段落拍摄、自由拍摄、视频空间、拍摄模版预览及加载等。
我们的视频能力层对业务层是透明的，业务层与能力层隔离，并对业务层提供了部分定制化的接口支持，这样的设计降低了业务方的接入成本，并方便业务方的扩展，比如支持蜜蜂App的播放面板定制，还支持缓存策略、编解码策略的可定制。整体设计如下图所示：
实践经验
在视频开发实践中，因业务场景的复杂性，我们遇到了多种问题和挑战。下面以核心功能为基点，围绕各功能遇到的问题做详细介绍。
视频播放
播放器是视频播放基础。针对播放器，我们进行了一系列的方案调研和选择。在此环节，遇到的挑战如下：
1. 兼容性问题
2. 缓存问题
针对兼容性问题，Android有原生的MediaPlayer，但其版本兼容问题偏多且支持格式有限，而我们需要支持播放本地视频，本地视频格式又无法控制，故该方案被舍弃。ijkplayer基于FFmpeg，与MediaPlayer相比，优点比较突出：具备跨平台能力，支持Android与iOS；提供了类似MediaPlayer的API，可兼容不同版本；可实现软硬解码自由切换，拥有FFmpeg的能力，支持多种流媒体协议。基于上述原因，我们最终决定选用ijkplayer。
但紧接着又发现ijkplayer本身不支持边缓存边播放，频繁的加载视频导致耗费大量的流量，且在弱网或者3G网络下很容易导致播放卡顿，所以这里就衍生出了缓存的问题。
针对缓存问题，引入AndroidVideoCache的技术方案，利用本地的代理去请求数据，先本地保存文件缓存，客户端通过Socket读取本地的文件缓存进行视频播放，这样就做到了边播放边缓存的策略，流程如下图：
