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 các nguyên tắc sử dụng định dạng phân phối Truyền phát thích ứng động qua HTTP (DASH) để truyền trực tuyến dữ liệu trực tiếp trên YouTube từ một bộ mã hoá. Tài liệu này nhằm giúp các nhà cung cấp bộ mã hoá thêm tính năng hỗ trợ phân phối DASH vào 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ể vượt qua tường lửa.
  • Hỗ trợ tốc độ truyền dữ liệu cao. DASH hỗ trợ nhiều phiên HTTP đồng thời và việc phân phối phân đoạn không tuần tự, mang lại 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 thông qua HTTPS.
  • Phân phối không mất dữ liệu thông qua HTTP và HTTPS.
  • Không phụ thuộc vào codec.
  • Hỗ trợ tệp MP4 chứa H264 và AAC cũng như tệp WebM chứa VP8/VP9 và Vorbis/Opus.

Thông số kỹ thuật

Yêu cầu

Các phần phụ sau đây giải thích các yêu cầu khi sử dụng DASH để phân phối luồng phát trực tiếp đế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ợ các kết nối TCP đồng thời. Bạn có thể sử dụng lại các kết nối theo HTTP/1.1.
  • MPD và các phân đoạn 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 đưa phân đoạn Khởi tạo vào MPD.)
  • Mỗi phân đoạn hoặc MPD phải sử dụng một yêu cầu PUT riêng; không hỗ trợ tải nhiều phân đoạn lên nhiều phần.
  • Các thao tác PUT đối với phân đoạn nội dung nghe nhìn có thể trùng lặp theo thời gian để cải thiện băng thông tải lên.
  • Các phân đoạn có thể được cung cấp theo thứ tự không tuần tự trong khoảng thời gian khoảng 3 giây.
  • Bạn nên cập nhật MPD và phân đoạn Khởi tạo ít nhất 60 giây một lần bằng availabilityStartTime và startNumber mới. (Như đã lưu ý ở trên, bạn có thể đưa phân đoạn Khởi tạo 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 đoạn.)

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 YouTube. Bạn cần tạo điểm truyền dẫn DASH bằ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 xuất hiện trong giao diện người dùng của sự kiện phát 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 tập hợp các ký tự ASCII sau:

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

URL MPD

Ngoài yêu cầu nêu trên, URL MPD phải kết thúc bằng .mpd để máy chủ YouTube có thể dễ dàng xác định MPD. Các URL phân đoạn khác không được kết thúc bằng .mpd.

Khởi tạo và URL phân đoạn nội dung nghe nhìn

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

Nội dung MPD

MPD phải đầy đủ và tuân thủ tiêu chuẩn DASH. Nó phải chứa đúng một phần tử của mỗi phần tử sau. Danh sách này xác định những phần tử mà YouTube yêu cầu cụ thể, còn tiêu chuẩn DASH có thể xác định thêm những phần tử bắt buộc khác. Các phần tử được biểu thị bằng cú pháp XPath và tuân theo 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

Vui lòng lưu ý các yêu cầu sau đố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 đoạn 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 đoạn 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 quá 100 kb. (Thông thường, phân đoạn Khởi tạo nhỏ hơn nhiều so với phân đoạn này.) 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 quá 100 KB.

Đầu ra của bộ mã hoá

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

  • Kích thước GOP phải khoảng 2 giây và không được quá 8 giây.
  • Luồng ghép kênh phải chứa cả bản âm thanh và bản video.

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

Mã hoá

YouTube hỗ trợ mã hoá luồng phát 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ị trực tiếp phân đoạn Khởi tạo trong MPD bằng cách sử dụng URL data:, theo RFC 2397. Điều này giúp đơn giản hoá việc thiết lập luồng phát và giảm khả năng phân đoạn Khởi tạo sẽ không tương ứng với phần còn lại của luồng phát.

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

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

Thời lượng phân đoạn mục tiêu

Để có hiệu suất nhập tốt và sự cân bằng hợp lý giữa thông lượng và độ trễ, độ dài của các phân đoạn nội dung nghe nhìn phải từ 1 đến 5 giây. Bạn nên truyền đạt thời lượng mục tiêu của những 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 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.

Xin lưu ý rằng thời lượng mục tiêu để truyền tải không bằng thời lượng đoạn của sự kiện phát trực tiếp mà YouTube tạo ra. YouTube chuyển mã và chia lại đầu vào thành các đoạn nhỏ, đồng thời thời lượng mục tiêu của đầu ra phụ thuộc vào việc luồng được tối ưu hoá cho chất lượng phát trực tuyến hay độ trễ.

Thử lại và thời gian đợi luỹ thừa

Bạn nên đặt thời gian chờ cho tất cả các yêu cầu PUT qua HTTP. Chúng tôi khuyên bạn nên đặt thời gian chờ thành một giá trị lớn hơn thời lượng phân đoạ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 (do hết thời gian chờ hoặc 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 mọi yêu cầu 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 thất bại, hãy đợi một khoảng thời gian ngẫu nhiên từ [0 ... 100] mili giây rồi thử lại yêu cầu.
  2. Nếu yêu cầu không thành công lần nữa, hãy đợi một khoảng thời gian ngẫu nhiên từ [0 ... 200] mili giây rồi thử lại yêu cầu.
  3. Nếu yêu cầu không thành công lần nữa, hãy đợi một khoảng thời gian ngẫu nhiên từ [0 ... 400] mili giây rồi thử lại yêu cầu.
  4. v.v.

Xin lưu ý rằng bạn nên báo cáo cho người vận hành bộ mã hoá nếu gặp phải lỗi nhiều lần vì điều này tương ứng với một chương trình 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 mã phản hồi mà YouTube trả về để phản hồi các đoạn video đượ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 một thao tác dự kiến và xử lý thành công thao tác đó.

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

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

Phản hồi này thường xảy ra nhất khi một phân đoạn được phân phối không theo trình 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:

  • Một phân đoạn khởi tạo được nhận trước MPD.
  • Các phân đoạn nội dung nghe nhìn được nhận trước MPD và các phân đoạn Khởi tạo.
  • Một phân đoạn nội dung nghe nhìn được nhận trước một phân đoạn trước đó, chẳng hạn như phân đoạn 3 được nhận trước phân đoạn 2.

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

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

401 (Không được phép)

Phản hồi HTTP 401 (Không được phép) cho biết URL cơ sở cho điểm cuối DASH của YouTube bị hỏng hoặc hết hạn.

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

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

409 (Xung đột)

Phản hồi HTTP 409 (Xung đột) đối với bất kỳ thao tác PUT hoặc POST nào cho biết rằng 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 bên yêu cầu đã gửi nhiều đoạn nội dung nghe nhìn, nhưng YouTube vẫn chưa có MPD, đoạn khởi tạo hoặc cả hai. Trong ví dụ đó, bộ mã hoá sẽ cần truyền lại MPD và các phân đoạn 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 rằng máy chủ không xử lý được yêu cầu. Đối với lỗi này, bạn nên thử lại yêu cầu bằng thuật toán thời gian đợi luỹ thừa.

Ví dụ

Trình tự URL

Chuỗi URL dưới đây cho thấy một loạt 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 MPD và các phân đoạn Khởi tạo được gửi riêng biệt. Tuy nhiên, bạn có thể trực tiếp biểu thị phân đoạn Khởi tạo trong MPD và nên thực hiện theo cách này. Ngoài ra, MPD và các phân đoạn 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, các URL cho những đoạn này sẽ xuất hiện lại theo trình tự này, sau đó là các URL cho những đoạn nội dung nghe nhìn khác.

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 có phân đoạn Khởi chạy đượ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 riêng.

Ví dụ này tuân thủ quy trình nhập WebM (VP8 hoặc VP9, Opus) vào YouTube. Phần lớn URL dữ liệu đã bị 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

Mẫu MPD sau đây cũng tuân thủ việc truyền dẫn WebM (VP8 hoặc VP9, Opus) đến YouTube, nhưng không có phân đoạn Khởi tạo được nhúng:

<?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 tạo WebM mẫu. Phần này bao gồm phần 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à bố cục của một đoạn nội dung đa phương tiện WebM mẫu. Tệ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 có phân đoạn Khởi chạy đượ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 riêng.

Ví dụ này tuân thủ quy trình truyền dẫn ISO BMFF (H.264, AAC) lên YouTube. Phần lớn URL dữ liệu đã bị 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

Mẫu MPD sau đây (không có phân đoạn Khởi tạo nhúng) cũng tuân thủ quy trình tiếp nhậ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ơ đồ sau đây cho thấy bố cục của một phân đoạn Khởi tạo ISO BMFF được ghép kênh mẫu. YouTube không nhất thiết phải sử dụng các phần tử này, nhưng đây là một ví dụ phù hợp. Cụ thể, cả bản âm thanh và bản video đều được biểu thị.

Nội dung nghe nhìn

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

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

Nguồn RTMP và DASH

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