用WebRTC在Firefox上實現YouTube直播

本文來自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元素，但我從來沒有使用過它，所以我現在決定這樣做。還有朋友，它真的很有趣！它基本上總結為以下幾個步驟：

1. 建立一個HTML5 canvas元素來進行繪製;

2. 通過慣用的getUserMedia來獲得媒體流;

3. 將媒體流放入一個HTML5的video視訊元素中;

4. 開始在canvas中繪製視訊幀，加上其他可能會很好的元素（文字疊加，影像等）;

5. 從canvas中使用captureStream（）獲取新的媒體流;

6. 使用新的媒體流作為新的PeerConnection的源;

7. 繼續在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仍然給人一種很好的感覺！