FFmpeg直播能力更新计划与新版本发布-编程知识

编者按：客户端作为直接面向用户大众的接口，随着技术的发展进化与时俱进，实现更好的服务是十分必要的。FFmpeg作为最受欢迎的视频和图像处理开源软件，被相关行业的大量用户青睐，而随着HEVC标准的发布到广泛使用，相信国内很多网络流媒体从业者都在长期关注FFmpeg FLV支持HEVC的官方更新。LiveVideoStackCon 2023 上海站邀请了来自快手的音视频首席架构师刘歧，为大家带来他关于FFmpeg 直播能力的更新计划。

文/刘歧

整理/LiveVideoStack

大家好，下面由我和大家分享近期FFmpeg的最新技术、部分未来的发展方向以及一些我个人的经验思考。

首先向大家做一个自我介绍，本人浸淫音视频行业多年，目前是FFmpeg/SRS社区委员会的成员，曾参与编写《FFmpeg 从入门到精通》一书，也是腾讯云最具价值专家TVP。

我于2007年参加工作，早期曾从事图形图像库、Flash解析引擎开发工作。2011年我正式参与音视频流媒体技术开发。2016年受邀成为FFmpeg维护者。2017年成为FFmpeg官方顾问，创业成立了OnVideo。2019年成为FFmpeg决策委员会委员，并开始担任FFmpeg GSoC Mentor。2020年，OnVideo被快手收购，我也随之进入快手工作。

接下来简单介绍我做出本次分享的契机。

首先，FFmpeg FFplay的官方版本目前仍然无法实现FLV对封装HEVC、VVC、VP9、AV1、OPUS等现代化编码格式的支持，随着音视频技术的发展，FLV需要随之改变。

第二，业界有声音提出重视HLS、DASH、LLHLS、LLDASH等协议。但目前看来，这些协议的实时性还很差。在CDN分发过程中，链路稍有卡顿就很容易影响广域用户的观看体验。

第三是WebRTC等低延迟协议对当前大规模使用的RTMP、FLV发出了挑战。

基于前述的问题和我们开展的工作，本次分享分为以下四部分：一是介绍FFmpeg支持Enhanced FLV的有关情况；二是介绍FFmpeg支持WHIP的进展；最后是关于未来一些更多有趣的事情。

-01-

FFmpeg支持Enhanced FLV

首先，从官方标准来看，目前FLV的视频Codec ID不包括HEVC，但现有Codec ID可从8拓展到15。

目前国内一些大厂出于业务需要会拓展官方标准。例如上图，其中视频codec ID增加了12对应的HEVC。但这种方式不适用同时引入多个编码格式，且各企业、厂商对codec ID不同的自定义风格容易导致公共环境混乱。

官方标准内音频编码的定义已经被占满，引入OPUS等新格式的难度较大。

我也曾进行过类似尝试，于2014年向FFmpeg team提交了关于FLV支持HEVC编码格式的补丁，但由于没有可供参考的公认标准遭到了反对，实际上该版本也无法播放泛式的FLV视频。

2021年，一位活跃的开发者James Almer做了同样的工作，但由于相同的问题最终未能实现合并。

SRS作为国内主要的CDN服务供应端，早期已经实现了对HEVC编码的支持，并曾向FFmpeg team发出了相关呼吁。可以看到，很多音视频从业者都曾为HEVC over HTTP-FLV的官方化做出努力。

后来我们意识到，推动Adobe修订现有参考标准才是关键。于是在接下来一段时间里，我们与Adobe的相关人员积极沟通，询问关于参考标准的修订计划。虽然得到了积极回复，但一直没有实质性的进展。

期间我们也对可用在直播场景的其他网络协议进行了检讨。但目前看来，HLS、DASH、HDS的延迟远大于RTMP/FLV。LLHLS、LLDASH仅在技术上有优于RTMP/FLV的可能，经过实际测试效果并不好。SRT的延迟足够低，但在PC、手机端等多平台的可用性还有不足。

为了加快实现我们的目标，经过查访，我们与RTMP、FLV的实际维护方，Adobe旗下的Veriskope建立了联系。

与此同时，从更好地兼容现状这一角度出发。在和Veriskope沟通前，我们利用FourCC代码完成了Enhanced FLV方案。该方案解决了仅依靠修改视频Codec ID可拓展的编码格式数量有限这一缺陷，可实现无限制数量的拓展。

相较于传统参考标准，我们针对FrameType增加了拓展模式，以定义对应的读包方式和编码格式。

针对不同FourCC值指向的编码格式，可以对其HVCC和VPCC进行拓展读取。

在我们向FFmpeg team提交Enhanced FLV补丁的过程中，有videoline的开发者提出疑问：在拓展RTMP时如何明确服务端支持的编码格式。

我们查找了Enhanced RTMP标准，发现只要在conncet command内加入FourCClist即可解决这个问题。

开发完成后，我使用RTMP通过Youtube测试了AV1推流。但发现无论推流何种格式，最终得到的都是VP9格式的流。针对该现象目前我还在等待Youtube开发者的回复解释。

相较于HLS和DASH，RTMP/FLV的延迟虽然较低，但链路质量变化或推流抖动等因素同样会引起播放的卡顿和延迟累加，因此我们考虑引入WebRTC进行推流。

-02-

FFmpeg支持WHIP

FFmpeg 支持WHIP这一项目的诞生起于SRS作者杨成立的倡导。当时，现场演示端到端普通推流的延迟仅有500毫秒，可以推定，引入WebRTC是十分可行的。

WHIP易于实施。为了建立推流会话，WHIP客户端将向WHIP终端发送包括SDP Offer的HTTP POST请求，返回“201 Created”响应，建立一个SDP。随后WHIP客户端和媒体服务器之间建立ICE/DTLS会话，通过RTP/RTCP开始视频、音频流传输。推流结束后，执行HTTP DELETE请求即可结束ICE/DTLS会话，整个过程只需要实现如上所示的四个简单标准。

我在2023年5月发布了第一版补丁，具体的代码大家可以在Github上找到，Cloudflare的工程师首先响应宣布了支持。

Pion随后也反馈宣布支持。

经过测试，我们发现Janus、Millicast、TRTC等开源服务器均可支持。目前FFmpeg WebRTC可以直接对接这些服务器进行推流。

使用WebRTC从采集、推流到播放的延迟经实测约为132毫秒。

但引入WebRTC也带来了一些风险。首先是有可能导致五花八门的网络传输优化算法泛滥，其次是大幅增加了代码量，提高了维护的难度。

-03-

更多有趣的事情

最后和大家分享一些有趣的事情。首先是关于FFmpeg，6.1准备发布了，当然也可能会跳过。主要的操作包含实现了Muxer和Demuxer的拆分，实现了format和commandline层的多线程支持，相较于历史版本单线程处理DASH、HLS、MXF等大数据量音视频封装的方式进一步提升了速度；scale支持切slice多线程处理，缩放、色彩转换的性能得到大幅提升；支持了VVC解码；支持了软件无线电（Software Defined Radio），可以收听一些广播节目；支持了Enhanced FLV和Enhanced RTMP。

然后，我同其他作者共同编写了《深入理解FFmpeg》一书，此次在介绍FFmpeg基本组成的基础上进一步结合实例讲解了API的使用，目前已经全渠道开售了，大家可以在京东、当当、淘宝买到。