Phân phối nội dung phát trực tiếp trên YouTube thông qua DASH

Tài liệu này cung cấp hướng dẫn về cách sử dụng định dạng phân phối Truyền phát thích ứng động qua HTTP (DASH) để phát trực tiếp dữ liệu trực tiếp trên YouTube từ một bộ mã hoá. Định dạng này nhằm giúp các nhà cung cấp bộ mã hóa thêm tính năng hỗ trợ phân phối DASH cho sản phẩm của họ.

Tìm hiểu về DASH

Danh sách dưới đây liệt kê một số tính năng và thuộc tính chính của DASH:

  • Dựa trên các tiêu chuẩn mở.
  • Dựa trên HTTP. Do đó, DASH thân thiện với cơ sở hạ tầng Internet và có thể truyền tải qua tường lửa.
  • Hỗ trợ tốc độ bit chuyển cao. DASH hỗ trợ nhiều phiên HTTP đồng thời và phân phối phân đoạn không tuần tự, giúp đảm bảo khả năng phục hồi cao hơn so với các giao thức dựa vào một kết nối TCP duy nhất.
  • Phân phối an toàn qua HTTPS.
  • Phân phối không tổn hao thông qua HTTP và HTTPS.
  • Không phụ thuộc vào bộ mã hoá và giải mã.
  • Hỗ trợ MP4 chứa H264 và AAC cũng như WebM chứa VP8/VP9 và Vorbis/Opus.

Thông số kỹ thuật

Yêu cầu

Các tiểu mục sau đây giải thích các yêu cầu đối với việc sử dụng DASH để phân phối sự kiện phát trực tiếp lên YouTube.

Thời gian

Điểm cuối DASH của YouTube hoạt động như một máy chủ HTTP thụ động, ghi lại các lệnh gọi phương thức PUT do bộ mã hoá gửi.

  • Điểm cuối DASH hỗ trợ đồng thời các kết nối TCP. Bạn có thể sử dụng lại kết nối theo HTTP/1.1.
  • Phân đoạn MPD và Khởi tạo phải được PUT trong vòng 3 giây kể từ phân đoạn nội dung nghe nhìn đầu tiên. (Bạn nên thêm phân đoạn Khởi tạo trong MPD.)
  • Mỗi phân đoạn hoặc MPD phải sử dụng một yêu cầu PUT riêng biệt; không hỗ trợ tải nhiều phần của nhiều phân đoạn lên.
  • Hoạt động PUT cho các phân đoạn nội dung nghe nhìn có thể trùng lặp kịp thời để cải thiện băng thông tải lên.
  • Bạn có thể cung cấp các phân đoạn theo thứ tự không tuần tự trong khoảng thời gian khoảng 3 giây.
  • Phân đoạn MPD và Khởi tạo phải được cập nhật ít nhất 60 giây một lần bằng availabilityStartTime và startNumber đã cập nhật. (Như đã lưu ý ở trên, phân đoạn Khởi tạo có thể được đưa vào MPD. Trong trường hợp đó, một yêu cầu PUT có thể cập nhật cả hai phân khúc.)

Cấu trúc URL

Bộ mã hoá của bạn phải tạo URL PUT bằng cách thêm một chuỗi vào URL cơ sở của điểm cuối trên YouTube. Bạn cần tạo điểm cuối truyền dẫn DASH bằng cách sử dụng API phát trực tiếp trên YouTube.

Sau đó, bộ mã hoá có thể lấy URL cơ sở của điểm cuối theo phương thức lập trình thông qua API phát trực tiếp trên YouTube. URL cơ sở cũng hiển thị trong giao diện người dùng Sự kiện trực tiếp trên YouTube nếu bạn muốn cung cấp URL cho bộ mã hoá theo cách thủ công.

Chuỗi được thêm vào URL cơ sở có thể chứa bộ ký tự ASCII sau:

  • Chữ thường: a-z
  • Chữ cái viết hoa: A-Z
  • Chữ số: 0-9
  • Ký tự đặc biệt: _ (dấu gạch dưới), - (dấu gạch nối), . (dấu chấm)

URL MPD

Ngoài yêu cầu nêu trên, URL của MPD phải kết thúc bằng .mpd. Điều này sẽ giúp máy chủ YouTube dễ dàng xác định MPD đó.URL phân khúc khác không được kết thúc bằng .mpd.

URL phân đoạn nội dung đa phương tiện và khởi tạo

URL phân đoạn Khởi tạo và tất cả URL phân đoạn nội dung đa phương tiện phải kết thúc bằng .mp4 nếu dữ liệu nằm trong vùng chứa ISO BMFF hoặc bằng .webm nếu dữ liệu nằm trong vùng chứa WebM.

Nội dung MPD

MPD phải hoàn chỉnh và tuân thủ tiêu chuẩn DASH. Phần tử này phải chứa đúng một trong các phần tử sau. Danh sách này xác định các phần tử bắt buộc cụ thể theo yêu cầu của YouTube và tiêu chuẩn DASH có thể xác định các phần tử bắt buộc bổ sung. Các phần tử được biểu thị bằng cú pháp vai trò và phù hợp với tiêu chuẩn 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

Xin lưu ý các yêu cầu sau đây đối với giá trị phần tử:

  • Bạn phải đặt thuộc tính minimumUpdatePeriod của phần tử <MPD> thành một giá trị bằng hoặc nhỏ hơn 60 giây (PT60S).
  • Thuộc tính media của phần tử <SegmentTemplate> phải chỉ định rằng URL phân khúc nội dung nghe nhìn được tạo bằng $Number$. (Thuộc tính startNumber xác định số sẽ được chỉ định cho phân khúc nội dung nghe nhìn đầu tiên.)

Độ dài phân đoạn khởi tạo

Phân đoạn Khởi tạo không được dài hơn 100 KB. (Thông thường, phân đoạn Khởi tạo nhỏ hơn nhiều.) Nếu phân đoạn Khởi tạo có trong MPD, thì URL data: (chứa phân đoạn) không được dài hơn 100 kb.

Đầu ra bộ mã hoá

Phân đoạn Khởi tạo và các phân đoạn nội dung đa phương tiện phải tạo thành luồng tệp ISO BMFF hoặc WebM đa kênh có các GOP (nhóm hình ảnh) đóng.

  • Kích thước GOP phải dài khoảng 2 giây và phải nhỏ hơn 8 giây.
  • Luồng đa kênh phải chứa cả bản âm thanh và video.

Các phương pháp hay nhất khác

Mã hoá

YouTube hỗ trợ việc mã hoá sự kiện phát trực tiếp qua HTTPS. Bạn nên sử dụng tính năng này.

Phân đoạn khởi tạo trong MPD

Bạn có thể biểu thị phân đoạn Khởi tạo trực tiếp trong MPD bằng URL data: theo RFC 2397. Việc này giúp đơn giản hoá việc thiết lập luồng và giảm khả năng phân đoạn Khởi chạy sẽ không tương ứng với phần còn lại của luồng.

NETWORK cho phần tử này là:

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

Thời lượng của phân khúc mục tiêu

Để có hiệu suất nhập tốt cũng như cân bằng tốt giữa công suất và độ trễ, thời lượng của các phân đoạn nội dung nghe nhìn nên nằm trong khoảng từ 1 đến 5 giây.Bạn nên thông báo thời lượng mục tiêu của các phân đoạn đó trong MPD bằng cách sử dụng 2 phần tử sau:

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

Thời lượng được tính toán từ các thuộc tính đó phải nằm trong hệ số 2 của tất cả thời lượng phân đoạn thực tế, nếu không hiệu suất phát trực tuyến có thể bị ảnh hưởng.

Lưu ý rằng thời lượng mục tiêu cho quá trình truyền dẫn không bằng thời lượng phân đoạn của sự kiện phát trực tiếp mà YouTube tạo ra. YouTube chuyển mã và phân đoạn lại dữ liệu đầu vào, còn thời lượng mục tiêu đầu ra phụ thuộc vào việc một sự kiện phát trực tiếp được tối ưu hoá cho chất lượng phát trực tiếp hay cho độ trễ.

Số lần thử lại và thời gian đợi luỹ thừa

Bạn nên thực hiện tất cả các yêu cầu PUT HTTP với thời gian chờ. Bạn nên đặt thời gian chờ này thành giá trị lớn hơn thời lượng của phân đoạn ít hơn 500 mili giây.

Yêu cầu PUT phân đoạn nội dung nghe nhìn không thành công, cho dù do hết thời gian chờ hay các lỗi khác, tương ứng với một khoảng trống trong luồng video. Do đó, bạn nên thử lại bất kỳ yêu cầu nào như vậy bằng cách sử dụng thuật toán thời gian đợi luỹ thừa nhị phân ngẫu nhiên:

  1. Sau khi không thành công, hãy đợi một khoảng thời gian ngẫu nhiên trong khoảng [0 ... 100] mili giây rồi thử lại yêu cầu.
  2. Nếu yêu cầu lại không thành công, hãy đợi một khoảng thời gian ngẫu nhiên trong khoảng [0 ... 200] mili giây rồi thử lại yêu cầu.
  3. Nếu yêu cầu lại không thành công, hãy đợi một khoảng thời gian ngẫu nhiên trong khoảng [0 ... 400] mili giây rồi thử lại yêu cầu.
  4. v.v.

Lưu ý rằng lỗi lặp lại phải được báo hiệu cho toán tử bộ mã hoá vì chúng tương ứng với một sự kiện phát sóng không thành công.

Mã phản hồi HTTP

Các phần sau đây giải thích các mã phản hồi mà YouTube trả về để phản hồi các phân đoạn được phân phối qua DASH.

200 (OK)

Phản hồi HTTP 200 (OK) cho biết máy chủ YouTube đã nhận được thao tác dự kiến và đã xử lý thành công.

202 (Được chấp nhận)

Phản hồi HTTP 202 (Chấp nhận) cho bất kỳ thao tác PUT hoặc POST nào cho biết rằng thao tác này không như mong đợi và được chấp nhận để xử lý chậm. Tuy nhiên, thao tác bị trì hoãn có thể thành công hoặc không thành công. Vì vậy, phản hồi không đảm bảo rằng YouTube sẽ thực sự có thể xử lý thành công thao tác này.

Phản hồi này xảy ra thường xuyên nhất khi một phân khúc được phân phối không tuần tự. Thông thường, YouTube có thể xử lý chính xác phân đoạn được chấp nhận sau khi nhận được các phân đoạn trước đó và bạn không cần gửi lại phân đoạn đó.

Ví dụ: YouTube có thể trả về phản hồi 202 trong bất kỳ trường hợp nào sau đây:

  • Phân đoạn khởi chạy được nhận trước MPD.
  • Phân khúc nội dung đa phương tiện sẽ nhận được trước phân khúc MPD và Khởi tạo.
  • Phân khúc nội dung nghe nhìn được nhận trước phân khúc trước đó, chẳng hạn như phân khúc 3 được nhận trước phân khúc 2.

Tuy nhiên, phản hồi 202 cũng có thể cho biết giá trị nhận dạng mặt hàng không chính xác nếu YouTube không thể xác thực đầy đủ giá trị nhận dạng đó khi nhận được yêu cầu POST hoặc PUT. Ví dụ: một trong những trường hợp điều này xảy ra là khi YouTube nhận và chấp nhận phân đoạn khởi chạy trước khi nhận được MPD, nhưng phân đoạn khởi chạy lại không hợp lệ. Trong trường hợp này, YouTube chấp nhận phân đoạn khởi tạo và trả về mã 202 rồi xác định xem phân đoạn đó có hợp lệ hay không sau khi nhận được MPD. Bạn có thể tránh trường hợp cụ thể này bằng cách thêm phân đoạn Khởi chạy trong MPD.

400 (Yêu cầu không hợp lệ)

Phản hồi HTTP 400 (Yêu cầu không hợp lệ) cho biết đã xảy ra một trong các sự cố sau đây:

  • URL không đúng định dạng.
  • Bài đăng quá lớn (> 10MB).
  • Không thể phân tích cú pháp MPD.
  • Phân đoạn Khởi tạo trong MPD bị lỗi.

401 (Trái phép)

Phản hồi HTTP 401 (Trái phép) cho biết URL cơ sở dành cho điểm cuối DASH của YouTube bị lỗi hoặc đã hết hạn.

405 (Phương pháp không được phép)

Phản hồi HTTP 405 (Phương pháp không được phép) cho biết rằng một yêu cầu không phải là POST hoặc PUT đã được gửi.

409 (Xung đột)

Phản hồi HTTP 409 (Xung đột) cho bất kỳ tác vụ PUT hoặc POST nào cho biết YouTube không thể xử lý yêu cầu. Ví dụ: phản hồi này có thể xảy ra nếu người yêu cầu đã gửi nhiều phân đoạn nội dung nghe nhìn nhưng YouTube vẫn không có MPD, phân đoạn Khởi tạo hoặc cả hai. Trong ví dụ đó, bộ mã hoá sẽ cần truyền lại các phân đoạn MPD và Khởi tạo trước khi thử lại yêu cầu không thành công.

500 (Lỗi máy chủ nội bộ)

Phản hồi HTTP 500 (Lỗi máy chủ nội bộ) cho biết máy chủ không thể xử lý yêu cầu. Đối với lỗi này, bạn nên thử lại yêu cầu bằng tính năng thuật toán thời gian đợi luỹ thừa.

Ví dụ

Trình tự URL

Trình tự URL bên dưới hiển thị một loạt các yêu cầu PUT sẽ được thực hiện để phân phối nội dung thông qua DASH. Trình tự này giả định rằng URL cơ sở cho điểm cuối DASH của YouTube là:

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

Trình tự này cho thấy các phân đoạn MPD và Khởi tạo được gửi riêng biệt. Tuy nhiên, phân đoạn Khởi tạo có thể được biểu thị trực tiếp trong MPD và bạn nên áp dụng phương pháp đó. Ngoài ra, các phân đoạn MPD và Khởi tạo phải được cập nhật ít nhất 60 giây một lần. Vì vậy, cuối cùng, URL của các phân đoạn đó sẽ xảy ra lại theo trình tự này và sau đó sẽ được theo sau bởi URL của nhiều phân đoạn đa phương tiện hơn.

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
...

Phân đoạn WebM

MPD với phân đoạn Khởi tạo được nhúng

MPD mẫu sau đây có một phân đoạn Khởi tạo được nhúng trong URL dữ liệu RFC 2397. Bạn nên nhúng phân đoạn Khởi tạo theo cách này thay vì gửi phân đoạn đó riêng.

Ví dụ này phù hợp với việc nhập WebM (VP8 hoặc VP9, Opus) vào YouTube. Phần lớn URL dữ liệu đã được xoá để dễ đọc:

<?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 mẫu sau đây (không có phân đoạn Khởi chạy được nhúng) cũng tuân thủ việc nhập WebM (VP8 hoặc VP9, Opus) vào 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="/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>

Khởi chạy

Sau đây là bố cục của một phân đoạn Khởi động WebM mẫu. Tệp này bao gồm một phần của luồng WebM cho đến nhưng không bao gồm cụm đầu tiên.

Nội dung nghe nhìn

Sau đây là ví dụ về bố cục của một phân đoạn phương tiện WebM mẫu. Lớp này bao gồm một cụm WebM duy nhất. Giống như luồng ISO BMFF, phân đoạn Khởi tạo được thêm vào trước một loạt các cụm sẽ tạo ra một luồng WebM hợp lệ.

Phân đoạn ISO BMFF

MPD với phân đoạn Khởi tạo được nhúng

MPD mẫu sau đây có một phân đoạn Khởi tạo được nhúng trong URL dữ liệu RFC 2397. Bạn nên nhúng phân đoạn Khởi tạo theo cách này thay vì gửi phân đoạn đó riêng.

Ví dụ này tuân thủ để truyền dẫn ISO BMFF (H.264, AAC) vào YouTube. Phần lớn URL dữ liệu đã được xoá để dễ đọc:

<?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 mẫu sau đây (không có phân đoạn Khởi chạy được nhúng) cũng tuân thủ quy trình truyền dẫn ISO BMFF (H.264, AAC) vào 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>

Khởi chạy

Sơ đồ dưới đây cho thấy bố cục của một phân đoạn Khởi chạy ISO BMFF đa kênh mẫu. YouTube không nhất thiết phải sử dụng các nguyên tử, nhưng đây là một ví dụ tuân thủ. Cụ thể, cả bản âm thanh và video đều được thể hiện.

Nội dung nghe nhìn

Sơ đồ dưới đây cho thấy bố cục của một phân đoạn nội dung nghe nhìn đa kênh ISO BMFF mẫu. YouTube không nhất thiết phải sử dụng tất cả các nguyên tử, nhưng đây là một ví dụ phù hợp. Cụ thể, cả bản âm thanh và video đều được thể hiện. Bạn có thể nối một loạt các phân đoạn này vào phân đoạn Khởi tạo để tạo một luồng ISO BMFF đa hợp hợp lệ và hoàn chỉnh.

Các hạn chế đã biết

Truyền dẫn RTMP và DASH

Bạn không thể kết hợp quá trình truyền dẫn RTMP và DASH với YouTube.Điều này áp dụng cho việc chuyển đổi giữa hai thiết bị trong một chương trình phát sóng cũng như sử dụng một phương thức làm phương thức truyền dẫn chính và phương thức còn lại để truyền dẫn dự phòng.