一个视频功能上线，架构债务会在3秒内暴露：掉帧、发热、弹窗提示"该应用耗电异常"。选错视频栈的代价是性能、工时，有时还有法务部的深夜电话。
卡顿很少是UI团队的锅，是管道问题：编解码器回退策略错误、硬件加速路径缺失、Android ABI（应用程序二进制接口）不匹配、原生库体积膨胀到用户想卸载。我见过团队把同一个流媒体栈重建三次，每次优化的维度都错了——第一次追包体大小，第二次追延迟，第三次才发现许可证合规性没审。
你需要一个可重复的评分表，和一个最小化的、带埋点的迁移路径，再谈选型。
许可证不是复选框，是工程约束
FFmpeg的LGPL/GPL许可证会改变你的链接方式（静态还是动态）、决定功能放在客户端还是服务端、甚至影响发版节奏。等发版前一周才审许可证，等于在代码里埋了定时炸弹。
评估任何视频SDK，建议按三个维度打分：性能、许可证、功能匹配度。把每个维度当成加权输入，而非二极管式的过/不过。
性能：该测什么，别测什么
别只跑实验室帧率。真实场景下要盯这些指标：
冷启动首帧时间：从用户点击到画面出现，超过800ms就有人在后台杀进程。直播场景下这个阈值更苛刻。
内存峰值与抖动：视频解码是内存大户，峰值决定了低端机能不能跑，抖动决定了会不会被系统回收。用Android Profiler或Instruments抓实际曲线，别信平均数。
电池消耗与发热：持续播放30分钟后的温升和电量曲线。硬件解码（MediaCodec/VideoToolbox）vs软件解码的差距，在这里会拉开一个数量级。
APK增量与ABI拆分：FFmpeg全量打包可能+15MB，按需拆分arm64-v8a和armeabi-v7a能省多少？用Android App Bundle测实际下载体积。
网络自适应表现：模拟3G-4G-WiFi切换时的缓冲次数和画质跳变。ABR（自适应码率）算法的优劣，用户用身体感受。
许可证：真实雷区
FFmpeg的许可证矩阵比它的命令行参数还复杂。核心区分：
FFmpeg核心库是LGPL 2.1+，允许动态链接闭源商用。但部分编解码器模块是GPL，比如libx264、libx265。一旦静态链接或修改源码，触发GPL的传染条款，你的整个应用可能被迫开源。
合规路径：动态链接FFmpeg、禁用GPL组件、用OpenH264替代libx264（需付MPEG LA专利费），或把敏感处理搬到服务端。
ExoPlayer是Apache 2.0，商用友好，Google背书。MediaCodec是Android系统API，无额外许可负担。
商业SDK（Bitmovin、THEOplayer、JW Player）走订阅制或按量付费，许可证干净，但成本模型要算进TCO（总拥有成本）。
功能匹配：必须有的 vs 最好有的
先列死线功能，再排优先级：
DRM支持：Widevine（L1/L3）、PlayReady、FairPlay，分别对应Android、Windows/Mac、iOS。自研方案接Widevine CDM的复杂度，足够让一个五人团队耗半年。
直播与点播的协议覆盖：HLS、DASH、RTMP、WebRTC？FFmpeg全都能解，但直播低延迟和ABR平滑切换需要额外工程。
字幕与多音轨：ExoPlayer内置支持，FFmpeg需要自研渲染管线。
后台播放与画中画：系统API调用 vs 自定义悬浮窗，合规性差异巨大。
分析埋点：播放起播时间、卡顿事件、错误码上报。商业SDK自带仪表盘，自研需要对接Sentry或自建。
三类方案的工程原型
把选项当成工程原型，而非产品名来理解：
FFmpeg：瑞士军刀，但每把刀片都要自己磨
命令行示例：
ffmpeg -i input.mov -c:v libx264 -preset veryfast -crf 23 -c:a aac -b:a 128k output.mp4
硬件加速标志和编码器名称因平台和编译版本而异，-hwaccel和-c:v参数需要针对每个构建版本验证。Android上的MediaCodec集成、iOS上的VideoToolbox调用，都需要写JNI或Objective-C++胶水代码。
适用场景：需要自定义滤镜链、离线转码、服务器端批处理、或深度控制编码参数。不适合快速迭代的C端播放需求。
ExoPlayer：Android流媒体的默认答案
集成代码：
val player = ExoPlayer.Builder(context).build() val mediaItem = MediaItem.fromUri(uri) player.setMediaItem(mediaItem) player.prepare() player.play()
ExoPlayer把流媒体功能的实现摩擦降到了最低。它封装了MediaCodec的硬件加速路径，内置了HLS/DASH的ABR逻辑，DRM模块可插拔。Google内部YouTube、Google TV都在用，社区生态成熟。
代价是iOS无官方版本（需找第三方移植或自研），复杂定制需要 fork 源码，包体增量约2-3MB。
MediaCodec/VideoToolbox：裸机操控
Android端代码：
MediaFormat format = MediaFormat.createVideoFormat("video/avc", width, height); MediaCodec decoder = MediaCodec.createDecoderByType("video/avc"); decoder.configure(format, surface, null, 0); decoder.start();
iOS端对应VideoToolbox和AVFoundation。这是系统级API，零第三方依赖，包体最小，性能天花板最高。但你需要自己处理：缓冲区管理、渲染时序、错误恢复、格式协商。一个SurfaceView的同步问题就能卡两周。
适用场景：对包体极度敏感（<5MB）、有专职多媒体工程师、或需要跨平台统一底层行为。
商业播放器：买时间，买确定性
Bitmovin、THEOplayer、JW Player这类方案，打包的是工程密集型功能：跨设备一致性、托管DRM集成、设备集群上调优过的ABR启发式算法、企业级SLA。对于有规模或严格 uptime/法务要求的公司，这种支持能省下数百小时的调试和合规审查。
定价通常按播放次数或订阅制，小团队前期可能肉疼，但算进机会成本和风险敞口后，未必贵。
一个反直觉的判断
别因为"FFmpeg什么都能做"就选它。如果你要做的是带DRM的流媒体播放、可变网络环境下的平滑体验，ExoPlayer+MediaCodec或商业SDK能避开巨大的维护面，电池表现通常更好。
FFmpeg的真正主场是：离线处理、服务器端转码、需要自定义滤镜链的编辑场景、或对编码参数有偏执级控制需求。
我见过太多团队把FFmpeg塞进播放SDK，结果为了追一个低延迟bug，在JNI层和C++线程模型里折腾三个月。最后切到ExoPlayer，两周上线。
决策矩阵实操
给三个维度设权重，建议：性能40%、许可证30%、功能匹配30%。然后打分：
性能分 = (首帧时间逆序排名 × 0.3 + 内存效率 × 0.3 + 电池表现 × 0.2 + 包体控制 × 0.2)
许可证分 = 合规清晰度 × 0.5 + 工程灵活性 × 0.3 + 长期风险 × 0.2
功能匹配分 = 死线功能覆盖率 × 0.6 + 扩展能力 × 0.4
别追求满分，追求没有致命短板。一个方案如果在许可证上踩红线，性能再高分也是零。
迁移路径：最小化验证
选型前必须跑通的验证清单：
用生产环境的视频样本，在目标设备矩阵（至少覆盖高端、中端、低端各一台）上跑通核心场景。别用测试片，用真实的、有DRM的、有广告切片的流。
埋点监控接入：起播成功率、卡顿率、错误码分布。没有数据反馈的优化是盲人摸象。
许可证审计：列出所有依赖的许可证，标记GPL/LGPL/Apache/商业许可，确认链接方式和分发合规性。让法务签字，别自己拍脑袋。
包体与性能基线：记录APK增量、内存峰值、电池消耗，作为后续迭代的参照系。
回滚方案：如果新方案出问题，能否热切换到旧实现？这个能力在A/B测试阶段能救命。
热门跟贴