开源圆桌 Q&A 集锦

       前排致谢       

Content Credit：杨成立、郭叶军、李忠、段维伟、陈诚

  懂的都懂. 

  不懂的...... 

→ → → 

Many thanks to 杨成立

 陈诚——AV1 编解码优化的更新 

• 比 2018 年 AV1 版本，提升了18% 压缩效率，提升 1.5 倍速度，减少 50% 内存消耗。比 VP9 提升了 35%。

• Google 的音视频产品，已经使用了 AV1。WebRTC 也已经支持了 AV1。

• 针对移动端的解码器 libgav1，比 libaom 提高 3 倍速度，降低了 55% 的内存消耗。

• 编码技术：non-local temporal filter, multi-model ML，2pass 码率控制。

/Q&A.

• Q：能直接用在ffmpeg推流吗？

  陈诚：都集成在了 libaom，可以在 FFmpeg 中使用。

• Q：用机器学习模型，普通机器的算力会不会不足？

  陈诚：目前使用了比较简单的模型，不会造成算力不足。

• Q：请问feature怎么更好的提取呢？

  陈诚：feature 是编码过程里的有用信息，比如在块划分中，周围块的划分情况，已经尝试的划分模块的 rate distortion cost. 以及运动向量等。总的来说需要理解编码的过程中哪些信息是关键信息，才能帮助机器学习的模型做出更好的决策。

• Q：有硬件支持了吗？

  陈诚：AV1 已经有了硬件支持，包括手机端和电视端都有，并且在不断扩充。更详细的硬件的信息更新在 livevideostack 的网站中有 Google 其他同事的介绍。

• Q：对视频场景有要求吗，还是所有场景都可以？

  陈诚：所有场景都可以。我们的编码器优化增益是通用的。

 段维伟-使用 Flutter 2.0 开发多平台 VOIP/WebRTC 客户端 

• Android/iOS/macOS/Windows 通话都已经支持，PC 上还需要有些屏幕捕获等需要完善。

• API定义和原生的定义差不多，基本上和 JS 的 API 可以对应起来。

• 很多都基于 Flutter 在开发。SRS 的 WebRTC 直播是用的 flutter-webrtc，可以 AppStore 搜：SRS 直播。

• flutter-sip 协议栈，可以和 SIP 设备对接，安防或会议领域。

/Q&A.

• Q：支持 Windows 吗？

  段维伟：支持。有些 API 还没有支持，估计 2 到 3 个月会比较完善。

• Q：和原生 API 的差别大吗？

  段维伟：更接近 JS 的规范。

• Q：Flutter-sip 是否是单独的仓库？

  段维伟：独立的仓库，SIP 协议栈用的是 dart 实现的。

• Q：会不会和各平台原生对比性能上有差异？

  段维伟：Flutter 底层使用 OpenGL 绘制 UI，性能几乎和原生一样，在正常编译优化后可达 60 fps，Flutter 有完整的性能分析工具，可以分析出代码中每帧消耗时长，以便开发者进行细致优化.

 杨成立- SRS 直播连麦和 SFU 

• Star超指数增长：未来会考虑如何和 tensorflow 对接，扩展 AI 的场景。

• 更新了 RTC SFU demo，包括一对一通话，直播连麦，多人通话等。

• 零声学院更新了SRS免费入门课程，包括环境搭建，WebRTC推拉流等。

• 从一个Bug看SRS的技术态度：https://shimo.im/docs/5rk9dr8Kmmu6NZqx/read

• srs-docker 全面支持静态链接 SRT：https://shimo.im/docs/Wr3DVnZpXjI4rPkJ/read

• SRS更新RTC性能和延迟数据：https://github.com/ossrs/srs/tree/4.0release#rtc-benchmark

SRS未来更新：

• 成立：SRS 4.0 进入 Bugfix+UTest+Regression 阶段，然后是 alpha、beta、release。

• 连响：SRS 支持 OBS 推流，WHIP 协议，预计本周。

• 志宏：SRS 5.0 支持 RTC 级联，预计六月份。

• 海博：每周解决一个 bug。

• 立新：RTC 转 RTMP 优化。

/Q&A.

• Q：和Janus、Mediasoup差别是什么？

  杨成立：SRS 定位是视频服务器，直播和 RTC 两个互联网场景。国内的音视频业务跑得比较快，应用场景也很多，比如直播连麦吵架、低延迟直播、超大方会议等等，这些场景都是直播和RTC结合的场景，我们需要的不是直播和RTC分开的技术方案，而是结合起来解决业务问题的基础方案。Janus 和Mediasoup 是 RTC 的 SFU，不支持直播。

• Q：怎么做的性能分析，能否公开？可讲一下出传输的方案与优化吗？

  杨成立：性能优化设计非常多的东西，是一个比较宽泛的话题，而且会有不断新的优化话题，之前我们有一篇文章《SRS性能(CPU)、内存优化工具用法》，SRS 4.0 的优化可以看《性能优化：SRS为何能做到同类的三倍》，未来我们会分享更多的性能优化方法和总结。

• Q：SRT级联是否有意义？

  杨成立：级联是为了水平扩展。直播的水平扩展我们用的是RTMP，也就是Origin-Edge 集群。RTC 的水平扩展我们是用的 QUIC，也就是 Origin 之间的级联。SRT 当然也是可以的，但我们选择 QUIC 是因为未来 QUIC 不仅仅可以用在级联，还可以用在和客户端的接入传输。

 李忠-FFmpeg 开源项目的稳定性建设 

• CodeReview：每个 Patch 都需要签名，API 的改动讨论要充分，每个 Patch要尽量少。

• Fuzz test，FATE 单元测试和覆盖率，valgrid 查内存泄漏。

• 明城墙的启示：每块砖都有签名，就像每次代码的提交。

/Q&A.

• Q：ffmpeg的开发从哪里入手，怎么开始呢？

  李忠： 首先可以先通读下FFmpeg的官方网站（https://www.ffmpeg.org/）， 上面有详细的技术文档（中文文档可以参考大师兄的《FFmpeg从入门到精通》）， 订阅FFmpeg社区mail list（https://www.ffmpeg.org/contact.html#MailingLists）， 在这个基础上可以从两方面的工作参与FFmpeg的代码开发：

  1. 阅读和完善FFmpeg example代码（https://github.com/FFmpeg/FFmpeg/tree/master/doc/examples）

  2. 参与社区的一些Bug fix工作（https://trac.ffmpeg.org/）。之后就可以进行更复杂的功能和架构开发了。如果你恰好是在校学生，还可以参与FFmpeg GSOC（https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2021）的项目开发， 会有众多FFmpeg maintainer作为项目的mentor来手把手教学哦 ：） 。

 郭叶军-FFmpeg 中目标检测和识别 

• 超分：支持 SRCNN 和 ESPCN 两种模型，支持的 YUV 格式。

• 目标检测 (dnn_detect) 和识别 (dnn_calssify)：输入视频后，可以标识出目标。

/Q&A.

• Q：目前支持的backend有哪些？

  郭叶军： 目前支持的 backend 有 TensorFlow、OpenVINO 和 Native，在ppt 的 high level design 页有写到。

• Q：这个编解码器有性能对比图吗？

  郭叶军：FFmpeg DNN 模块主要是支持 filter 用，目前和编解码器没有直接关系，我这边没有编解码器的性能对比图。

• Q：这个方案可以解决前端网络的问题，可以讲一下与OWT的区别吗？

  郭叶军： 问题中的 OWT 是指之前 LVS 分享的  Open WebRTC Toolkitm 吗？那是基于 GStreamer 以及 OpenVINO 构建的。这里的介绍是基于 FFmpeg，而不是 Gstreamer。这里不仅支持 OpenVINO，也支持 TensorFlow 等。

• Q：目标识别会反馈优化编码吗？

  郭叶军：目前 FFmpeg upstream 中还没有直接反馈到编码。如果需要的话，可以自己再加个一个 filter，分析目标识别的结果，并且和编码连接起来。可能更加简单直观的方法，是增加一个新的视频分析 filter，基于深度学习模型，其输出是当前视频（当前场景）所属的类别，比如运动类、卡通类、剧情类等，然后决定编码策略，确定编码参数，这样，就可以直接和已有编码器连接起来了。目标检测是 FFmpeg upstream 中第一个基于深度学习模型的视频分析 filter，在代码完成后还经过了两三个月的讨论 review 才进去，10 来个 active maintainer 参与讨论，将近 100 封邮件来往。所以，现在社区对这类功能已经比较了解了，新的 filter 更容易进去。欢迎各种 patch！

Decode the Week选取新鲜有趣的音视频（技术/非技术）新闻与大家分享——也欢迎你通过后台留言或邮件（[email protected]）与我们分（爆）享（料）圈内趣闻。