本文来自Meetecho的联合创始人Lorenzo Miniero，他分享了如何通过Firefox和WebRTC进行YouTube直播。Meetecho是著名的WebRTC服务器 Janus 的出品公司。LiveVideoStack对原文进行了摘译。
文 / Lorenzo Miniero
译 / 元宝
审校 / Ant
原文 http://www.meetecho.com/blog/firefox-webrtc-youtube-kinda/
我们最近都看到了关于YouTube通过WebRTC进行直播的新闻，但它仅仅适用于您使用谷歌浏览器。火狐浏览器和Edge均不适用，对于苹果浏览器，说实话，我并不太关心.....
我需要完成哪些工作，才能让Firefox通过WebRTC发送内容，并能观看到它推送到YouTube上的直播呢？也许用一些HTML5 canvas的东西可以增加一些趣味。随着Kamailio World Dangerous Demos赛季的开幕，这成了修补它的绝佳机会，这正是我所做的！
我需要的是：
一种在浏览器中捕获视频，然后以某种方式编辑它，并在WebRTC的 PeerConnection中使用它的方法;
WebRTC服务器从浏览器接收流;
某种技术将该流进行转换，使得YouTube的直播更加圆满。
第一部分是很有趣的，因为我之前从未这样做过。或者更确切地说，在过去的几年中，我已经捕获并发布过大量的WebRTC流，但我从未在浏览器端尝试过捕获视频。我知道你可能会使用一些HTML5 canvas元素，但我从来没有使用过它，所以我现在决定这样做。还有朋友，它真的很有趣！它基本上总结为以下几个步骤：
创建一个HTML5 canvas元素来进行绘制;
通过惯用的getUserMedia来获得媒体流;
将媒体流放入一个HTML5的video视频元素中;
开始在canvas中绘制视频帧，加上其他可能会很好的元素（文字叠加，图像等）;
从canvas中使用captureStream（）获取新的媒体流;
使用新的媒体流作为新的PeerConnection的源;
继续在canvas上绘制，就像没有尽头一样！
听起来有很多步骤，但实际上它们很容易设置和完成。在短短几分钟内，我有了一些基本代码来允许我捕捉到我的网络摄像头，并为其添加一些叠加：在右上角加上一个logo，底部加上一个半透明条，还有一些文字的叠加。在修改代码上我也做了动态地修改，以便我可以动态地更新它们。我相信对于很多之前使用过canvas的你们来说，会嘲笑这些例子有多么的荒谬，但对于刚刚入手的我来说，这是一个很大的成就！
不管怎样，最酷的部分是我在测试网页中进行了一些基本的视频编辑工作，以及将其用作PeerConnection源的方法。下一步是将这个WebRTC流送到服务器来让我进行播放。不足为奇的是，我使用了Janus的目的......这个想法很简单：我需要能够接收WebRTC流的东西，然后能够在其它的地方使用上它。考虑到这是我几年前开始研究Janus的关键原因之一，在几年前它是一个完美的选择！具体来说，我决定使用的是Janus VideoRoom插件。实际上，正如预期的那样，我需要一种方法来将传入的WebRTC流提供给外部组件来进行处理，在这种情况下，将其转换为YouTube 直播所期望的用于发布的格式。这个VideoRoom插件，与其集成了SFU功能的相比，还有一个很好的功能，称为“RTP转发器”，这个功能完全允许。我将在后面解释原因以及它的工作原理。
最后，我需要一些东西来将WebRTC流转换为YouTube 直播所期望的格式。正如您可能知道的，传统的方法是使用RTMP。有几种不同的软件可以帮助解决这个问题，但我选择了简单的方式，使用FFmpeg来完成工作：事实上，我并不需要任何剪辑或发布功能（这些我已经实现了），但只有一些东西可以转化为正确的协议和编解码器，这是FFmpeg非常擅长的。显然，为了实现这一点，我首先需要将WebRTC流推送到FFmpeg，在这里上述的“RTP转发器”可以提供帮助。具体来说，顾名思义，“RTP转发器”可以简单地在某处转发RTP数据包：在Janus VideoRoom的文章中，它们提供了一种方法，使用普通（或加密，如果需要的话）的RTP将来自WebRTC发布者的媒体数据包转发到一个或多个远程地址。由于FFmpeg支持普通RTP作为输入格式（使用一个SDP类型来绑定在正确的端口上并指定正在使用的音频/视频编解码器），这是使用WebRTC媒体流提供它的最佳方式！
在这一点上，我得到了我所需要的一切：
浏览器作为编辑/发布软件（canvas + WebRTC）;
Janus作为媒介（WebRTC-to-RTP）;
FFmpeg作为转码器（RTP-to-RTMP）。
也就是说，最后一步是测试所有的这些。在本地测试中，这一切都预期的工作，在测试中使用优秀的老版red5作为开源RTMP服务器，但很显然，真正的挑战是让它与YouTube的 直播一起工作。所以我进入到Meetecho 的YouTube帐户的控制面板来验证它，等待要通常的24小时才获得发布流的必要信息。这些基本上包括要连接的RTMP服务器，以及用于标识流的唯一（和秘密）密钥。
通过四处搜索，我找到了一些不错的代码片段，展示了如何使用FFmpeg流式传输到YouTube Live，我修改了脚本以使用我的源和目标信息，以便在那上面发布而不是在我的本地RTMP服务器上。令人欣喜的是，我让它开始工作了，但它并不总是完美的工作，在某些地方总有一些问题，但是对于一个demo来说，它已经运行的很好了。
就是这样，真的，不需要其他“魔法”。这就可以很容易变成各种各样的服务，可以通过做一些好的canvas上的工作（我做的是非常基础的）来改进编辑部分，并使“RTP Forwarding + FFmpeg + YouTube Live授权证书”部分变得动态化（例如，在端口和帐户的使用方面），以支持多个流媒体和多个事件，但是这些细节都在那里。
是的，我知道你在想什么：我的意思是，我正在使用WebRTC进行推流，并且它最终会进入YouTube 直播中，但这不是一个直接的步骤。我所做的基本上是利用Janus的灵活性来处理WebRTC流，通过使用FFmpeg以YouTube的“Ye Olde”方式进行实际广播。无论如何，它仍然很酷！在客户端使用HTML5 canvas使得以某种方式“编辑”推流部分变得容易了，给了我相当多的创作自由。此外，使用WebRTC仍然给人一种很好的感觉！
