距回顾有关Janus的内容以来已经过去了几周，我们大致陈述了许多不同的改进。现在我觉得是时候深入探讨一个主题了——为使Janus支持AV1和H.265，我们付出了何种努力。
又一次编解码器大战？
如果你和我一样历经WebRTC时代更迭的话，你可能会记得“编解码器一战”。这场战役中VP8和H.264展开了激烈竞争，想置对方于死地。最终两者都没有从市场上消失，但是都变成了MTI（强制实施），这意味着所有WebRTC端点都要同时安装这两者。信不信由你，这确实发生了！当然几乎没有人觉得Apple会真的支持VP8使用（我是绝对没想到的），但事实上这件事已经发生了。
也就是说，虽然VP8和H.264是“朋友”，但现在它们都是“旧”编解码器了。说到一些新功能，比如要提高效率，要支持SVC等，大多数人实际上在寻找新的编解码器，主要有两个备选：AV1和H.265（或者HEVC）。就像VP8和H.264一样，众所周知AV1是免版税的，而H.265则经常有专利侵权的问题。
毋庸置疑，全球WebRTC开发者都对这两个编解码器有着极大兴趣。本篇中我不会深入研究编解码器本身、主要功能或状态。一些博客文章对此已有很详细完美的阐释，例如Alex博士的这篇概述或Tsahi的这篇分析文章。我今天这篇文章的重点是AV1和H.265在我们Janus WebRTC Server中的集成问题，和为了使其正常工作我们必须进行的调整。
编解码器和Janus
Janus是一种通用的WebRTC服务器，也就是说对于不同的编解码器，不同的插件实际上可能有不同的要求。有些可能只需要协商编解码器和/或路由数据包的能力，而另一些可能需要更强能力。
大多数Janus插件不会对媒体数据包进行转码，而只根据每个插件实现的逻辑，对它们进行路由。在这种情况下，Janus需要依靠编解码器，也就是要能够正确地协商SDP中的编解码器，并允许在PeerConnection中使用编解码器。其他一切通常取决于插件本身（比如AudioBridge实际上要解码音频数据包，或生成自己的音频数据包）。
但与此同时，即使只是中继媒体，也可能需要更了解视频编解码器。更具体一点，每当我们致力于增加对新编解码器的支持时，我们都会执行两个附加步骤：
- 查看通过服务器的RTP数据包，以某种方式检测关键帧；
- 用某种方法从RTP数据包中提取媒体帧（RTP解包）。
执行第一个步骤时，最重要的是要知道何时去执行一些操作。比如，如果PeerConnection的媒体源正在实行更改（例如因为正在使用联播），我们需要知道关键帧何时到达，以便我们可以执行切换，从而允许接收者正确解码新流。第二个步骤仅用在了记录中。在Janus中，记录基本上是RTP数据包的结构化转储，然后我们可以通过RTP拆包对它进行“后处理”，而无需完全接触媒体，就可以将记录的数据包转换为一个可播放的媒体文件（例如mp4文件）。
简而言之，由于某些原因，这两个功能都非常重要，并且都有一些亟待解决的问题。如果我们决定增加对AV1和H.265的支持（正是我们在专用分支中所做的事情），这就是我们必须处理的内容。虽然目前两种编解码器都尚未真正普及，甚至目前尚不可用，但我们知道他们的未来可期。所以我们认为，预见到这个现象并为之做好准备是很有必要的。
文章地址：https://www.meetecho.com/blog/av1-h265-janus/
原文作者：Lorenzo Miniero
