本文來自Meetecho的聯合創始人Lorenzo Miniero，他分享了如何通過Firefox和WebRTC進行YouTube直播。Meetecho是著名的WebRTC服務器 Janus 的出品公司。LiveVideoStack對原文進行了摘譯。

我們最近都看到了關于YouTube通過WebRTC進行直播的新聞，但它僅僅適用于您使用谷歌瀏覽器?；鸷鼮g覽器和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上的工作（我做的是非?；A的）來改進編輯部分，并使“RTP Forwarding + FFmpeg + YouTube Live授權證書”部分變得動態化（例如，在端口和帳戶的使用方面），以支持多個流媒體和多個事件，但是這些細節都在那里。

是的，我知道你在想什么：我的意思是，我正在使用WebRTC進行推流，并且它最終會進入YouTube 直播中，但這不是一個直接的步驟。我所做的基本上是利用Janus的靈活性來處理WebRTC流，通過使用FFmpeg以YouTube的“Ye Olde”方式進行實際廣播。無論如何，它仍然很酷！在客戶端使用HTML5 canvas使得以某種方式“編輯”推流部分變得容易了，給了我相當多的創作自由。此外，使用WebRTC仍然給人一種很好的感覺！