FFmpeg停止支持Android 4.4及以下版本

FFmpeg笔记 • 来源：Fun With FFmpeg • 2024年4月26日上午9:45 • 技术文章

如题，我将FFmpeg Android系统最低版本要求设定为Android 5.0，停止支持Android 4.4及以下版本。

好吧，这是一个毫无新意的新闻。

在升级版本要求之前，我在微信群和邮件列表咨询了FFmpeg用户和开发者的意见。不出所料，没人在意Android 5.0之前的系统了。有的开发者表示，他只考虑Android 8.0以后的版本。市面上还有运行旧系统的设备，但很难想象有人会编译FFmpeg 7.1放上面运行。

Android 5.0是2014年发布的，至今刚好十年。所以，升级Android最低版本要求没一点阻力。有人要升级libx264升到最近的版本，社区有挺多人反对。

升级Andoid版本要求，我画的是一条虚线：开发和测试只考虑5.0以后版本，但不限制用户在不开启某些模块的情况下，依然可以编译给旧系统用，留了余地。

升级最大的改动，是把原来dlopen获取的一堆函数，换成直接调用和编译时链接。代码体积会小一丢丢，性能会好一点点，主要是看着舒心。

FFmpeg对iOS的版本要求依然是个模糊地带。在FFmpeg里检查iOS系统API是个非常头疼的问题，至少有四个开发者写出了影响编译的bug，包括我自己。暂时不打算看这个问题，只给大家提供一个直观的感受：

除了升级版本，汇总一下最近的工作。因为太琐碎了，不值得单独拿出来说。有的坑很深，口很窄，掉进去的概率很小，掉进去爬出来很难，这类问题，我称之为知识的稀疏矩阵。

FFmpeg MediaCodec编码增加获取extradata的功能

MediaCodec的系统实现一般不支持提前获取extradata，也就是csd（codec specific data）数据。但是有些应用场景又希望提前获取extradata。我用了一个简单粗暴的方式来解决：

创建完编码器，送一帧空白帧（准确说是绿屏帧）给编码器
发送EOS信号给编码，强制让编码器刷出这一帧来，同时带出extradata
丢掉第一帧编码数据，flush编码器，恢复编码器状态

一般情况是不需要这么做的。libavcodec的API用户可以用extract_extradata bsf从AVPacket里提取extradata，或者muxer自己能完成类似的任务。

RTMPS可选择mbedtls做TLS实现

有用户反馈，用mbedtls作为RTMPS的底层推流失败。我检查发现是FFmpeg mbedtls封装没支持block/unblock模式切换。Bug已修复，不过貌似mbedtls用的人不多，不然早就发现了。用mbedtls来减小包体还是很有价值的。

FFmpeg H.265 Paser bug

这是去年就解决的一个问题，不过最近连续两次有同事碰到同类问题，所以再说下。我们看到H.264/H.265 start code，有时候是0 0 0 1，有时候是0 0 1。什么时候必须用三个0，标准里面是有规定的：

When any of the following conditions are true, the zero_byte syntax element shall be present:

the nal_unit_type within the nal_unit( ) is equal to 7 (sequence parameter set) or 8 (picture parameter set),
the byte stream NAL unit syntax structure contains the first NAL unit of an access unit in decoding order, as specified in clause 7.4.1.2.3.

FFmpeg H.265 parser的一个bug，是把当前一帧的第一个0，错误的划给了上一帧的结尾，导致当前一帧开头变成了0 0 1。这是不符合标准的，只是一般的解码器不较真，都能支持。但遇到兼容性差的软件，影响就大了。比如Android系统的mp4 muxer，给它start code 0 0 1的NALU，竟然直接崩溃了，也是神奇。