要开展下一步，我们就要能访问实际的AV1 / RTP数据包，即弄清楚如何检测关键帧。最重要的是将捕获的数据包转换为可播放的媒体文件。AV1 / RTP规范有一些不清楚的地方，加上（对我而言）AV1序列标的隐秘性（即存储一些类似比特流分辨率的元数据的地方），使转换操作尤其具有挑战性。但最后我还是解决了这个问题。比如下面这张屏幕快照显示了mplayer应用程序播放的媒体文件，该文件是使用Janus后处理器工具，从AV1记录中转换而来的。
另外！Janus的AV1也支持录音！这是否意味着我们大功告成了？现在来讲也许是的。但是实际上将来还会有更多工作要做。更准确地说，AV1 / RTP规范记录了一个新的伴随RTP扩展，可能会使SFU和其他中介更容易处理AV1流。尽管现有的实现方式尚不支持该扩展，但将来可能会支持。这意味着我们需要考虑到这一点。此外，WebRTC中AV1如此重要的关键因素之一是其对本机SVC的支持。这将是AV1面临的一大挑战（前段时间我们曾对VP9中出现的相同问题进行了部分处理）。而且它要先在客户端实现，现在担心还为时尚早。
H.265怎么样呢？
如果你热衷于专利技术，那可能你会想进一步了解WebRTC中H.265的状态，这方面的改进比比皆是。
正如Alex博士在这篇文章中所解释的那样，得益于CoSMo、Apple和Intel在最近的IETF Hackathon Intel中的通力合作，Intel实际上已经完成了部分实现，在libwebrtc 中实现了更好的集成。因此，只要在实验设置中手动启用使用TP（技术预览），你就可以在Safari中使用有H.265的WebRTC了。
这是如何运行的呢？首先，与AV1不同，H.265的RTP分组化的标准化过程实际上是在IETF内进行的，并且有RFC（RFC 7798）对其进行了记录。此外，在SDP中协商基本的H.265会话，实际上与其在H.264中的工作原理非常相似，所以这部分很容易处理。
换句话说，尽管有可用的实现，但我无法对其进行测试。因为我是Linux用户，无法访问Mac OS计算机，并且由于疫情被困在家里，所以我无法用办公室里的设备来测试。但幸运的是，Janus社区赶来救场，帮我做了一些测试。其中有工作人员确认了EchoTest在使用Safari并强制使用H.265时，可以按预期工作，并且他们给了我一个已交换RTP数据包的未加密捕获，供我深入研究。
至于AV1样本，在用实际H.265 RTP数据包打包的示例做实验时，这个捕获非常宝贵，帮助我修复H.265记录的后期处理。恕我不能共享快照录制的内容，因为该视频不是我拍的视，用户可能不同意放出来。但既然我说它可行了，相信我是没错的！如果你不信，可以自己编译分支去尝试一下。
以防大家好奇（不管怎样我必须分享这一点），正如在使用AV1序列标和H.264 SPS之前，实际上我们大部分时间都花在了理解H.265 SPS——视频宽度和高度之类的信息所在之处（我们需要用它来填充生成的可播放文件的元数据）上。不知道是谁想出这么个深奥的版本，也不知为什么他们用不同的形式使用它，但我很确定，不管是谁，肯定都很反人类！
现在怎么办？
通过研究现有客户端实现中这两种编解码器的状态，Janus已准备就绪。现在我计划合并这两种编解码器。同时我们会确保大多数插件都知道他俩。举个例子，这意味着你可以在VideoRoom SFU中同时使用它们。也就是说，（如果不是因为它们在浏览器中的可用性有限）很可能在相当长的一段时间内，你不会使用它们，但使其得到支持，对于将来的使用是很有用的。当然，我们的计划是跟踪它们的发展方式——我们提到的针对AV1或SVC的自定义扩展程序。当它们推出后，两者都会更有前景。
在其变为现实之前，放开嗨吧！
相关阅读：
文章地址：https://www.meetecho.com/blog/av1-h265-janus/
原文作者：Lorenzo Miniero
