做美食网站的模板,wordpress文章会员,wordpress 宽屏 主题,成都电商平台网站设计// 编者按#xff1a;客户端作为直接面向用户大众的接口#xff0c;随着技术的发展进化与时俱进#xff0c;实现更好的服务是十分必要的。FFmpeg作为最受欢迎的视频和图像处理开源软件#xff0c;被相关行业的大量用户青睐#xff0c;而随着HEVC标准的发布到广泛使用客户端作为直接面向用户大众的接口随着技术的发展进化与时俱进实现更好的服务是十分必要的。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和DASHRTMP/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- 更多有趣的事情 最后和大家分享一些有趣的事情。首先是关于FFmpeg6.1准备发布了当然也可能会跳过。主要的操作包含实现了Muxer和Demuxer的拆分实现了format和commandline层的多线程支持相较于历史版本单线程处理DASH、HLS、MXF等大数据量音视频封装的方式进一步提升了速度scale支持切slice多线程处理缩放、色彩转换的性能得到大幅提升支持了VVC解码支持了软件无线电Software Defined Radio可以收听一些广播节目支持了Enhanced FLV和Enhanced RTMP。 然后我同其他作者共同编写了《深入理解FFmpeg》一书此次在介绍FFmpeg基本组成的基础上进一步结合实例讲解了API的使用目前已经全渠道开售了大家可以在京东、当当、淘宝买到。 我本次的分享就到这里谢谢大家 ▼点击下方阅读原文 ▼ 进入LiveVideoStackCon 2023深圳站官网 了解更多精彩演讲
