Phân phối nội dung trực tiếp trên YouTube qua DASH

Tài liệu này hướng dẫn cách sử dụng định dạng Phân phối DASH để phát trực tuyến dữ liệu trực tiếp trên YouTube từ bộ mã hoá. Chương trình này nhằm giúp các nhà cung cấp bộ mã hóa thêm 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 độ 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 theo tuần tự, cung cấp khả năng phục hồi lớn hơn 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 bị mất qua HTTP và HTTPS.
  • Codec không xác định.
  • 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 video 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ã hóa gửi đ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 kết nối theo HTTP/1.1.
  • Các phân đoạn MPD và Khởi chạy phải trong vòng 3 giây của phân đoạn đa phương tiện đầu tiên. (Bạn nên thêm phân đoạn Khởi chạy trong MPD.)
  • Mỗi phân khúc hoặc MPD phải sử dụng một yêu cầu PUT riêng; tính năng tải lên nhiều phần của nhiều phân khúc không được hỗ trợ.
  • Hoạt động PUT cho phân đoạn phương tiện có thể trùng lặp về thời gian để cải thiện băng thông tải lên.
  • Bạn có thể cung cấp các phân khúc theo thứ tự không theo tuần tự trong khoảng 3 giây.
  • Bạn nên cập nhật các phân đoạn MPD và Khởi chạy ít nhất 60 giây một lần với availabilityStartTime và startNumber đã cập nhật. (Như đã lưu ý ở trên, phân khúc Khởi chạy 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 YouTube. Bạn cần tạo điểm cuối nhập 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 bằng cách lập trình thông qua API Phát trực tiếp của YouTube. URL cơ sở cũng sẽ hiển thị trong giao diện người dùng Sự kiện trực tiếp của YouTube nếu bạn muốn cung cấp URL cho bộ mã hóa theo cách thủ công.

Chuỗi được nối vào URL cơ sở có thể chứa bộ 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ủ của YouTube có thể dễ dàng xác định MPD.Các URL phân khúc khác không được kết thúc bằng .mpd.

URL khởi chạy và URL phân đoạn đa phương tiện

URL phân khúc Khởi chạy và tất cả URL phân khúc đa phương tiện đều 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. Nó phải chứa chính xác một trong từng phần tử sau đây. Danh sách này xác định các phần tử mà YouTube yêu cầu cụ thể 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 đích và nhất quán 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 về giá trị phần tử:

  • Thuộc tính minimumUpdatePeriod của phần tử <MPD> phải được đặt 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 đa phương tiện được tạo bằng $Number$. (Thuộc tính startNumber xác định số điện thoại 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 động

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

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

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

  • GOP có kích thước khoảng 2 giây và dưới 8 giây.
  • Luồng kết hợp 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ợ phương thức mã hoá luồng thông qua HTTPS. Bạn nên sử dụng tính năng này.

Các phân đoạn khởi động trong MPD

Bạn có thể biểu thị phân khúc Khởi chạy trực tiếp 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 và giảm khả năng phân khúc Khởi chạy sẽ không tương ứng với phần còn lại của luồng.

đích cho phần tử này là:

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

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

Để có hiệu suất nhập tốt và sự cân bằng tốt giữa thông lượng và độ trễ, thời lượng của 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 các phân khúc đó trong MPD bằng cách sử dụng hai 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 khoảng bằng 2 trong tổng số thời lượng phân khúc thực tế hoặc 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 để nhập không bằng thời lượng phân đoạn cho luồng trực tiếp mà YouTube tạo ra. YouTube chuyển mã và phân loại 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 luồng được tối ưu hóa 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 HTTP PUT. Bạn nên đặt giá trị này lớn hơn 500 mili giây cho thời lượng phân khúc.

Yêu cầu PUT phân đoạn nội dung đa phương tiện không thành công, cho dù do hết thời gian chờ hay 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 gặp lỗi, hãy đợi một khoảng thời gian ngẫu nhiên trong vòng [0 ... 100] mili giây rồi thử yêu cầu lại.
  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 trong vòng [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 trong vòng [0 ... 400] mili giây rồi thử lại yêu cầu.
  4. v.v.

Lưu ý rằng các lỗi lặp lại phải được báo hiệu cho nhà cung cấp dịch vụ mã hóa vì chúng tương ứng với một lỗi truyền phát.

Mã phản hồi HTTP

Phần sau đây giải thích mã phản hồi mà YouTube trả về để đáp ứng 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 rằng 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) đối với 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ý trễ. 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 thực sự có thể xử lý thành công thao tác đó.

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

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 động được nhận trước MPD.
  • Phân khúc nội dung nghe nhìn nhận được trước phân khúc MPD và Khởi chạy.
  • Một phân khúc nội dung nghe nhìn nhận được trước một 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 năm 202 cũng có thể cho biết rằng 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 lần xảy ra trường hợp này là khi YouTube nhận và chấp nhận phân đoạn khởi chạy trước khi nhận MPD, nhưng phân đoạn khởi tạo biến thành không hợp lệ. Trong trường hợp này, YouTube chấp nhận phân đoạn khởi chạy và trả về 202, sau đó xác định xem phân đoạn có hợp lệ khi nhận MPD hay không. Bạn có thể tránh tình huống cụ thể này bằng cách đưa phân đoạn Khởi chạy vào 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 một trong những vấn đề sau đã xảy ra:

  • URL được định dạng không đú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 chạy trong MPD bị hỏng

401 (Chưa được uỷ quyền)

Phản hồi HTTP 401 (Chưa được uỷ quyền) cho biết rằng URL cơ sở dành 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 cho phép)

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

Ví dụ

Trình tự URL

Trình tự URL dưới đây cho thấy một loạt các yêu cầu PUT sẽ được thực hiện để phân phối nội dung qua DASH. Trình tự 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 chạy được gửi riêng. Tuy nhiên, phân khúc Khởi chạy có thể được trình bày trực tiếp trong MPD và bạn nên làm như vậy. Ngoài ra, bạn nên cập nhật phân đoạn MPD và Khởi chạy ít nhất 60 giây một lần. Do đó, cuối cùng thì URL của các phần phân tách đó sẽ xảy ra một lần nữa theo trình tự này, theo sau là URL cho các phân đoạn đa phương tiệ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 với phân đoạn Khởi chạy được nhúng

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

Ví dụ này tuân theo 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

MPD mẫu sau đây không có phân đoạn Khởi chạy được nhúng, cũng phù hợp với 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

Nội dung sau đây hiển thị bố cục của phân đoạn Khởi chạy WebM mẫu. Nó bao gồm phần của luồng WebM đến nhưng không bao gồm cụm đầu tiên.

Nội dung nghe nhìn

Nội dung sau đây hiển thị bố cục của một phân đoạn đa phương tiện WebM mẫu. Nó bao gồm một cụm WebM duy nhất. Cũng giống như luồng ISO BMFF, phân khúc Khởi chạy thêm vào trước một loạt 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 chạy được nhúng

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

Ví dụ này tuân theo quy trình nhập ISO BMFF (H.264, AAC) 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"
    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 phù hợp với việc nhập 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 kết hợp mẫu. YouTube không nhất thiết phải sử dụng nguyên tử, nhưng đây là ví dụ tuân thủ. Cụ thể, cả bản âm thanh và video đều được trình bày.

Nội dung nghe nhìn

Sơ đồ dưới đây cho thấy bố cục của một phân đoạn đa phương tiện ISO BMFF ghép thành 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 trình bày. Một chuỗi các phân khúc này có thể được thêm vào phân khúc Khởi chạy để tạo luồng BMFF ISO hợp nhất và hoàn chỉnh.

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

Các lần nhập RTMP và DASH

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