透過 DASH 提交 YouTube 直播內容

本文提供相關指南，說明如何使用基於 HTTP 的動態自動調整串流 (DASH) 傳送格式，從編碼器在 YouTube 上串流直播資料。編碼器供應商可藉此在產品中新增 DASH 傳送支援功能。

瞭解 DASH

以下列出一些重要的 DASH 功能和屬性：

  • 以開放標準為基礎。
  • 以 HTTP 為準。因此，DASH 適合網際網路基礎架構，且可穿透防火牆。
  • 支援高傳輸位元率。DASH 支援多個同步 HTTP 工作階段和非循序片段傳送，因此比依賴單一 TCP 連線的通訊協定更具彈性。
  • 透過 HTTPS 安全傳送。
  • 透過 HTTP 和 HTTPS 無損傳輸。
  • 與轉碼器無關。
  • 支援含有 H264 和 AAC 的 MP4，以及含有 VP8/VP9 和 Vorbis/Opus 的 WebM。

規格

需求條件

以下小節說明使用 DASH 將直播內容傳送至 YouTube 的規定。

時間

YouTube DASH 端點的運作方式類似被動 HTTP 伺服器，會記錄編碼器傳送的 PUT 方法呼叫。

  • DASH 端點支援同時 TCP 連線。您可以根據 HTTP/1.1 重複使用連線。
  • MPD 和初始化區段應在第一個媒體區段的 3 秒內 PUT。(建議您在 MPD 中加入初始化區段)。
  • 每個區隔或 MPD 都必須使用個別的 PUT 要求；系統不支援多個區隔的多部分上傳。
  • 媒體片段的 PUT 作業可能會在時間上重疊，以提升上傳頻寬。
  • 區隔可在約 3 秒的時間範圍內，以非連續順序提供。
  • MPD 和初始化片段應至少每 60 秒更新一次，並提供更新後的 availabilityStartTime 和 startNumber。(如上所述，初始化區隔可以納入 MPD。在這種情況下，一個 PUT 要求即可更新兩個區隔。)

網址結構

編碼器必須在 YouTube 端點基本網址後方附加字串，藉此形成 PUT 網址。你必須使用 YouTube Live Streaming API 建立 DASH 攝入端點。

編碼器隨後可透過 YouTube Live Streaming API，以程式輔助方式取得端點的基本網址。如要手動將網址提供給編碼器，也可以在 YouTube Live Events 使用者介面中查看基本網址。

附加至基本網址的字串可包含下列 ASCII 字元集：

  • 小寫字母：a-z
  • 大寫字母：A-Z
  • 數字：0 至 9
  • 特殊字元：_ (底線)、- (連字號)、. (句號) 鍵

MPD 網址

除了上述規定外，MPD 網址結尾必須為 .mpd，方便 YouTube 伺服器輕鬆識別 MPD。其他區隔網址不得以 .mpd 結尾。

初始化和媒體片段網址

如果資料位於 ISO BMFF 容器中，初始化區段網址和所有媒體區段網址都必須以 .mp4 結尾；如果資料位於 WebM 容器中，則必須以 .webm 結尾。

MPD 內容

MPD 必須完整且符合 DASH 標準。必須包含下列每個元素各一個。這份清單列出 YouTube 規定的必要元素，DASH 標準可能會列出其他必要元素。這些元素以 XPath 語法表示，且符合 DASH 標準。

  • /mpd:MPD/attribute::type
  • /mpd:MPD/mpd:Period
  • /mpd:MPD/mpd:Period/mpd:AdaptationSet
  • /mpd:MPD/mpd:Period/mpd:AdaptationSet/attribute::mimeType (video/mp4 or video/webm)
  • /mpd:MPD/mpd:Period/mpd:AdaptationSet/mpd:SegmentTemplate
  • /mpd:MPD/mpd:Period/mpd:AdaptationSet/mpd:SegmentTemplate/attribute::media
  • /mpd:MPD/mpd:Period/mpd:AdaptationSet/mpd:SegmentTemplate/attribute::initialization
  • /mpd:MPD/mpd:Period/mpd:AdaptationSet/mpd:SegmentTemplate/attribute::startNumber

請注意元素值須符合下列規定：

  • <MPD> 元素的 minimumUpdatePeriod 屬性必須設為小於或等於 60 秒 (PT60S) 的值。
  • <SegmentTemplate> 元素的 media 屬性必須指定媒體片段網址是使用 $Number$ 產生。(startNumber 屬性會識別要指派給第一個媒體片段的號碼)。

初始化區段長度

初始化區隔不得超過 100 KB。(通常初始化區隔會比這個小得多)。如果 MPD 中包含初始化片段，則包含該片段的 data: 網址不得超過 100 KB。

編碼器輸出內容

初始化區段和媒體區段必須構成多工 ISO BMFF 或 WebM 檔案串流，且包含封閉 GOP (畫面群)。

  • GOP 大小應約為 2 秒，且不得超過 8 秒。
  • 多工串流必須同時包含音軌和視訊軌。

其他最佳做法

加密

YouTube 支援透過 HTTPS 加密串流。我們強烈建議您使用這項功能。

媒體顯示說明 (MPD) 中的初始化區段

您可以根據 RFC 2397，使用 data: URL 直接在 MPD 中呈現初始化片段。這樣可簡化串流設定，並降低初始化區段與串流其餘部分不符的可能性。

這個元素的 XPath 為：

/mpd:MPD/mpd:Period/mpd:AdaptationSet/mpd:SegmentTemplate/attribute:data

目標區隔時間長度

為確保擷取效能良好，並在總處理量和延遲之間取得平衡，媒體片段長度應介於 1 到 5 秒。強烈建議您使用下列兩個元素，在 MPD 中傳達這些區段的目標時間長度：

  • /mpd:MPD/mpd:Period/mpd:AdaptationSet/mpd:SegmentTemplate/attribute::duration
  • /mpd:MPD/mpd:Period/mpd:AdaptationSet/mpd:SegmentTemplate/attribute::timescale

根據這些屬性計算出的時間長度，應在所有實際區段時間長度的 2 倍以內，否則串流效能可能會受到影響。

請注意，擷取目標時間長度不等於 YouTube 製作的直播區塊時間長度。YouTube 會轉碼並重新分塊輸入內容，輸出目標時間長度則取決於串流是針對串流品質還是延遲時間進行最佳化。

重試和指數輪詢

執行所有 HTTP PUT 要求時，都必須設定逾時時間。建議您將逾時時間設為比區隔時間長 500 毫秒的值。

如果媒體區段 PUT 要求失敗 (無論是逾時或其他錯誤)，影片串流就會出現間斷。因此，您應使用隨機二進位指數輪詢重試這類要求：

  1. 失敗後，請等待 [0 ... 100] 毫秒之間的隨機時間，然後重試要求。
  2. 如果要求再次失敗，請等待 [0 ... 200] 毫秒之間的隨機時間，然後重試要求。
  3. 如果要求再次失敗，請等待 [0 ... 400] 毫秒之間的隨機時間，然後重試要求。
  4. 其他

請注意，如果重複發生失敗情況，應通知編碼器操作人員，因為這表示廣播失敗。

HTTP 回應代碼

以下各節說明 YouTube 在回應透過 DASH 傳送的片段時，傳回的回應代碼。

200 (OK)

HTTP 200 (OK) 回應表示 YouTube 伺服器收到預期作業，並已成功處理。

202 (Accepted)

如果對任何 PUT 或 POST 作業的回應是 HTTP 202 (已接受)，表示作業非預期，但已接受延後處理。不過，延遲作業可能會成功或失敗，因此回應不保證 YouTube 實際上能夠成功處理作業。

如果區段並非依序傳送，最常會發生這種回應。通常 YouTube 收到前幾個片段後，就能正確處理接受的片段，因此你不需要重新傳送片段。

舉例來說，在下列任一情況下，YouTube 都可能會傳回 202 回應：

  • 在 MPD 之前收到初始化片段。
  • 媒體片段會在 MPD 和初始化片段之前收到。
  • 媒體片段的接收時間早於先前的片段，例如片段 3 的接收時間早於片段 2。

不過，如果 YouTube 在收到 POST 或 PUT 要求時無法完全驗證 ID，202 回應也可能表示項目 ID 不正確。舉例來說，YouTube 在收到 MPD 前接收並接受初始化區隔，但該區隔無效時，就會發生這種情況。在這種情況下，YouTube 會接受初始化區隔並傳回 202，然後在收到 MPD 時判斷區隔是否有效。如要避免這種情況，請在 MPD 中加入初始化區段。

400 (錯誤的要求)

HTTP 400 (錯誤的要求) 回應表示發生下列其中一個問題：

  • 網址格式有誤。
  • 貼文過大 (超過 10 MB)。
  • 無法剖析 MPD。
  • MPD 中的初始化區段已損毀。

401 (未獲授權)

HTTP 401 (Unauthorized) 回應表示 YouTube DASH 端點的基準網址已毀損或過期。

405 (不允許的方法)

HTTP 405 (禁用方法) 回應表示傳送的要求不是 POST 或 PUT。

409 (Conflict)

如果對任何 PUT 或 POST 作業的回應是 HTTP 409 (Conflict)，表示 YouTube 無法處理要求。舉例來說，如果要求者已傳送大量媒體片段，但 YouTube 仍未收到 MPD 或初始化片段 (或兩者皆未收到)，就可能發生這種情況。在該範例中，編碼器必須重新傳輸 MPD 和初始化區段，才能重試失敗的要求。

500 (內部伺服器錯誤)

HTTP 500 (Internal Server Error) 回應表示伺服器無法處理要求。如果發生這個錯誤，建議您以指數輪詢重試要求。

範例

網址序列

下列網址序列顯示透過 DASH 傳送內容時，會發出的一連串 PUT 要求。這個序列假設 YouTube DASH 端點的基準網址為：

http://upload.youtube.com/dash_upload?cid=xxxx-xxxx-xxxx-xxxx&copy=0&file=

這個序列顯示 MPD 和初始化片段是分開傳送。不過，初始化區隔可以直接在 MPD 中表示，建議您採用這種做法。此外，MPD 和初始化片段至少每 60 秒應更新一次。因此，這些片段的網址最終會再次出現在這個序列中，然後是更多媒體片段的網址。

PUT upload.youtube.com/dash_upload?cid=xxxx-xxxx-xxxx-xxxx&copy=0&file=dash.mpd
PUT upload.youtube.com/dash_upload?cid=xxxx-xxxx-xxxx-xxxx&copy=0&file=init.mp4
PUT upload.youtube.com/dash_upload?cid=xxxx-xxxx-xxxx-xxxx&copy=0&file=media001.mp4
PUT upload.youtube.com/dash_upload?cid=xxxx-xxxx-xxxx-xxxx&copy=0&file=media002.mp4
PUT upload.youtube.com/dash_upload?cid=xxxx-xxxx-xxxx-xxxx&copy=0&file=media003.mp4
...

WebM 片段

內含初始化區隔的 MPD

以下 MPD 範例在 RFC 2397 資料網址中嵌入了初始化區段。建議您以這種方式嵌入初始化區隔，而非另外傳送。

這個範例符合將 WebM (VP8 或 VP9、Opus) 檔案上傳至 YouTube 的規定。為了方便閱讀，資料網址的大部分內容已省略：

<?xml version="1.0" encoding="UTF-8"?>
<MPD xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xmlns="urn:mpeg:dash:schema:mpd:2011"
     xsi:schemaLocation="urn:mpeg:dash:schema:mpd:2011 DASH-MPD.xsd"
     type="dynamic" 
     profiles="urn:mpeg:dash:profile:isoff-live:2011" 
     minimumUpdatePeriod="PT60S"
     minBufferTime="PT12S"
     availabilityStartTime="2016-04-13T20:52:58" >
  <Period start="PT0S" id="1">
    <AdaptationSet mimeType="video/webm">
      <ContentComponent contentType="video" id="1"/>
      <SegmentTemplate timescale="1000"
           duration="2000"
           startNumber="1"
           initialization="data:video/mp4;base64,AAAAGGZ0eXBpc...AAA"
           media="/dash_upload?cid=xxxx-xxxx-xxxx-xxxx&copy=0&file=media-$Number%09d$.webm"/>
      <Representation id="1" width="1920" height="1080">
        <SubRepresentation contentComponent="1"/>
      </Representation>
    </AdaptationSet>
  </Period>
</MPD>

MPD

以下範例 MPD 沒有內嵌的初始化區段，但仍符合 YouTube 的 WebM (VP8 或 VP9、Opus) 擷取規定：

<?xml version="1.0" encoding="UTF-8"?>
<MPD xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xmlns="urn:mpeg:dash:schema:mpd:2011"
     xsi:schemaLocation="urn:mpeg:dash:schema:mpd:2011 DASH-MPD.xsd"
     type="dynamic" 
     profiles="urn:mpeg:dash:profile:isoff-live:2011" 
     minimumUpdatePeriod="PT60S"
     minBufferTime="PT12S"
     availabilityStartTime="2016-04-13T20:52:58" >
  <Period start="PT0S" id="1">
    <AdaptationSet mimeType="video/webm">
      <ContentComponent contentType="video" id="1"/>
      <SegmentTemplate timescale="1000"
           duration="2000"
           startNumber="1"
           initialization="/dash_upload?cid=xxxx-xxxx-xxxx-xxxx&copy=0&file=init.webm"
           media="/dash_upload?cid=xxxx-xxxx-xxxx-xxxx&copy=0&file=media-$Number%09d$.webm"/>
      <Representation id="1" width="1920" height="1080">
        <SubRepresentation contentComponent="1"/>
      </Representation>
    </AdaptationSet>
  </Period>
</MPD>

初始化

以下顯示 WebM 初始化區段的範例版面配置。這部分包含 WebM 串流，但不含第一個叢集。

媒體

以下顯示 WebM 媒體片段的版面配置範例。其中包含單一 WebM 叢集。與 ISO BMFF 串流一樣，附加至一系列叢集的初始化區段應會產生有效的 WebM 串流。

ISO BMFF 片段

內含初始化區隔的 MPD

以下 MPD 範例在 RFC 2397 資料網址中嵌入了初始化區段。建議您以這種方式嵌入初始化區隔，而非另外傳送。

這個範例符合 ISO BMFF (H.264、AAC) 擷取至 YouTube 的規定。為了方便閱讀，資料網址的大部分內容已省略：

<?xml version="1.0" encoding="UTF-8"?>
<MPD xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns="urn:mpeg:dash:schema:mpd:2011"   
    xsi:schemaLocation="urn:mpeg:dash:schema:mpd:2011 DASH-MPD.xsd" 
    type="dynamic"
    minimumUpdatePeriod="PT30S" 
    availabilityStartTime="2016-05-04T20:47:25" 
    minBufferTime="PT12S" 
    profiles="urn:mpeg:dash:profile:isoff-live:2011">
  <Period start="PT0S" id="1">
    <AdaptationSet mimeType="video/mp4" codecs="avc1.4d401e,mp4a.40.2">
      <ContentComponent contentType="video" id="1"/>
      <ContentComponent contentType="audio" id="2"/>
      <SegmentTemplate timescale="600"
             media="/dash_upload?cid=ug50-xg26-cbc1-2p0h&staging=1&copy=0&file=media$Number%09d$.mp4"
             initialization="data:video/mp4;base64,AAAAGGZ0eXBpc281AA...AA"
             duration="306"
             startNumber="1"/>
      <Representation id="1" width="640" height="360" bandwidth="526952">
        <SubRepresentation contentComponent="1" bandwidth="526952" 
codecs="avc1.4d401e"/>
        <SubRepresentation contentComponent="2" bandwidth="125584" codecs="mp4a.40.2"/>
      </Representation>
    </AdaptationSet>
  </Period>
</MPD>

MPD

以下範例 MPD 沒有內嵌的初始化片段，但仍符合 ISO BMFF (H.264、AAC) 格式，可上傳至 YouTube：

<?xml version="1.0" encoding="UTF-8"?>
<MPD xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xmlns="urn:mpeg:dash:schema:mpd:2011"
     xsi:schemaLocation="urn:mpeg:dash:schema:mpd:2011 DASH-MPD.xsd"
     type="dynamic"
     profiles="urn:mpeg:dash:profile:isoff-live:2011"
     minimumUpdatePeriod="PT60S" 
     minBufferTime="PT12S"
     availabilityStartTime="2016-04-13T20:51:31" >
  <Period start="PT0S" id="1">
    <AdaptationSet mimeType="video/mp4" codecs="avc1.4d401e,mp4a.40.2">
      <ContentComponent contentType="video" id="1"/>
      <ContentComponent contentType="audio" id="2"/>
      <SegmentTemplate timescale="600"
           duration="1200"
           startNumber="1"
           initialization="/dash_upload?cid=xxxx-xxxx-xxxx-xxxx&copy=0&file=init.mp4"
           media="/dash_upload?cid=xxxx-xxxx-xxxx-xxxx&copy=0&file=media$Number%09d$.mp4"/>
      <Representation id="1" width="640" height="360" bandwidth="526952">
        <SubRepresentation contentComponent="1" bandwidth="526952" codecs="avc1.4d401e"/>
        <SubRepresentation contentComponent="2" bandwidth="125584" codecs="mp4a.40.2"/>
      </Representation>
    </AdaptationSet>
  </Period>
</MPD>

初始化

下圖顯示範例多工 ISO BMFF 初始化區段的版面配置。YouTube 不一定會使用原子，但這是符合規範的範例。特別是音軌和視訊軌。

媒體

下圖顯示範例多工 ISO BMFF 媒體片段的版面配置。YouTube 不一定會使用所有原子，但這是符合規範的範例。特別是音軌和視訊軌。可將一系列這類片段附加至初始化片段，產生有效且完整的複合式 ISO BMFF 串流。

已知限制

RTMP 和 DASH 擷取

你無法同時使用 RTMP 和 DASH 擷取功能將影片上傳至 YouTube。這適用於在廣播期間切換兩者，以及將其中一個做為主要擷取方法，另一個做為備份擷取方法。