Trang này được dịch bởi Cloud Translation API.

Phân phối nội dung phát trực tiếp trên YouTube qua giao thức HLS

Tài liệu này giải thích cách sử dụng giao thức Phát trực tuyến dựa trên HTTP (HLS) để 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 dành cho các nhà cung cấp bộ mã hoá muốn thêm tính năng hỗ trợ truyền dẫn HLS vào sản phẩm của họ. Việc truyền dẫn HLS là một lựa chọn phù hợp cho nội dung cao cấp đòi hỏi chất lượng cao và độ phân giải cao ở độ trễ tương đối cao hơn. Để biết thông tin so sánh ngắn gọn về các giao thức truyền dẫn mà tính năng Phát trực tiếp trên YouTube hỗ trợ, hãy xem bài viết So sánh giao thức truyền dẫn của tính năng Phát trực tiếp trên YouTube.

Để truyền trực tuyến dữ liệu trực tiếp bằng HLS, bộ mã hoá phải gửi một loạt Danh sách phát nội dung nghe nhìn và Phân đoạn nội dung nghe nhìn đến điểm cuối HLS của YouTube bằng các yêu cầu HTTP PUT hoặc POST. Từ quan điểm của bộ mã hoá, điểm cuối HLS của YouTube có vẻ như là một máy chủ HTTP thụ động.

Mỗi Phân đoạn nội dung đa phương tiện đại diện cho nội dung đa phương tiện thực tế trong một phần ngắn của luồng có thời lượng từ một đến bốn giây. Mỗi Danh sách phát nội dung đa phương tiện mô tả cách kết hợp lại các Phân đoạn nội dung đa phương tiện theo đúng thứ tự phát trực tuyến.

Yêu cầu về định dạng nội dung nghe nhìn

Quy trình truyền dẫn nội dung HLS lên YouTube có các yêu cầu sau đối với nội dung video và âm thanh:

Video và âm thanh phải được kết hợp ở định dạng M2TS.
Các bộ mã hoá và giải mã video được hỗ trợ là H.264 và HEVC.
Hỗ trợ tốc độ khung hình lên đến 60 khung hình/giây.
Chỉ hỗ trợ GOP đóng.
Bộ mã hoá và giải mã âm thanh được hỗ trợ là AAC và chỉ hỗ trợ âm thanh một kênh.

Hãy xem các yêu cầu chi tiết hơn trong phần Phân khúc nội dung nghe nhìn.

HDR

Video có Dải động cao (HDR) được hỗ trợ bằng bộ mã hoá và giải mã HEVC, đồng thời có các yêu cầu bổ sung sau:

Các chuẩn màu được hỗ trợ là PQ 10 bit và HLG với độ chói không đổi. Cụ thể:
- Định dạng màu phải là YUV 4:2:0 10 bit.
- Hàm chuyển phải là PQ (còn gọi là SMPTE ST 2084) hoặc HLG (còn gọi là ARIB STD-B67).
- Dải màu cơ bản phải là Rec. 2020.
- Hệ số của ma trận phải là độ chói không liên tục theo chuẩn Rec. 2020.
Cả giá trị mẫu phạm vi giới hạn (hoặc phạm vi MPEG) và phạm vi đầy đủ (hoặc phạm vi JPEG) đều được hỗ trợ. Điều quan trọng là bạn phải đặt phạm vi theo phạm vi giá trị mẫu mà nội dung sử dụng. Bạn nên sử dụng các giá trị mẫu trong phạm vi giới hạn.

Lấy URL truyền dẫn HLS

Lấy URL truyền dẫn HLS từ API YouTube

Để lấy URL truyền dẫn đầy đủ, bộ mã hoá có thể sử dụng API Phát trực tiếp của YouTube để chèn tài nguyên liveStream với các thuộc tính sau:

"cdn": {
  "ingestionType": "hls",
  "frameRate": "variable",
  "resolution": "variable"
}

Trong phản hồi API, trường cdn.ingestionInfo.ingestionAddress chỉ định URL truyền dẫn chính và trường cdn.ingestionInfo.backupIngestionAddress chỉ định URL truyền dẫn dự phòng. Để biết thêm thông tin chi tiết, hãy xem tài liệu về tài nguyên liveStreams.

Lấy URL truyền dẫn HLS từ YouTube Studio

Trong giao diện web của YouTube Studio, sau khi nhà sáng tạo nhấp vào "Tạo sự kiện phát trực tiếp", YouTube sẽ hiển thị "Mã sự kiện phát trực tiếp" bao gồm các ký tự chữ và số, dấu gạch nối. Khoá bí mật này xác định cả nhà sáng tạo và luồng phát đến YouTube.

Bạn có thể tạo một URL HLS từ khoá phát trực tiếp này như sau:

https://a.upload.youtube.com/http_upload_hls?cid=$STREAM_KEY&copy=0&file=

... trong đó $STREAM_KEY là Khoá phát trực tuyến hiển thị trong giao diện web. Ví dụ: https://a.upload.youtube.com/http_upload_hls?cid=abcd-efgh-ijkl-mnop-qrst&copy=0&file=

Để tăng độ tin cậy, bạn có thể truyền một bản sao thứ hai dư thừa của quá trình truyền dẫn đến URL dự phòng này:

https://b.upload.youtube.com/http_upload_hls?cid=$STREAM_KEY&copy=1&file=

Lưu ý rằng URL sao lưu có hai điểm khác biệt so với URL chính: cả tên máy chủ và tham số copy= đều đã thay đổi. Quá trình truyền dẫn dự phòng phải gửi giá trị tham số copy= khác với quá trình truyền dẫn chính để tránh làm hỏng luồng.

Hoàn tất URL truyền dẫn HLS

URL thu được bằng một trong hai phương thức này là các mẫu chưa hoàn chỉnh; mỗi URL kết thúc bằng một tham số truy vấn file= trống. Để tạo URL cuối cùng, bộ mã hoá phải thêm tên tệp của Danh sách phát nội dung nghe nhìn hoặc Phân đoạn nội dung nghe nhìn vào cuối URL, nhờ đó hoàn tất tham số file=.

Các quy tắc sau áp dụng cho giá trị của thông số file=:

Bộ mã hoá có thể tạo tên tệp Danh sách phát nội dung nghe nhìn hoặc Phân đoạn nội dung nghe nhìn từ các ký tự chữ và số, dấu gạch dưới, dấu gạch chéo lên, dấu gạch ngang và dấu chấm; không hỗ trợ ký tự nào khác.
Bộ mã hoá không được mã hoá URL tên tệp.
Bộ mã hoá có thể bao gồm các thành phần đường dẫn tương đối hoặc tuyệt đối trong tên tệp, mặc dù điều này không bắt buộc. Nếu bộ mã hoá bao gồm một thành phần đường dẫn trong tên Tệp phân đoạn nội dung đa phương tiện, thì bộ mã hoá đó phải tham chiếu đến cùng một đường dẫn trong mục danh sách phát tương ứng.

Yêu cầu về giao thức HLS

Danh sách phát nội dung nghe nhìn và Phân đoạn nội dung nghe nhìn do bộ mã hoá gửi phải tuân thủ Thông số kỹ thuật phiên bản 2 của giao thức Phát trực tuyến dựa trên HTTP.

Quy cách HLS xác định hai loại danh sách phát: Danh sách phát nội dung nghe nhìn và Danh sách phát chính. Vì YouTube chuyển mã nội dung phát trực tuyến sang nhiều độ phân giải và tốc độ bit, nên bộ mã hoá không cần gửi nội dung có nhiều tốc độ bit đến YouTube. Do đó, YouTube chỉ hỗ trợ Danh sách phát nội dung nghe nhìn để nhập nội dung HLS, còn Danh sách phát chính sẽ bị bỏ qua. (Danh sách phát chính cung cấp một tập hợp Luồng biến thể, mỗi luồng mô tả một phiên bản khác nhau của cùng một nội dung.)

Bộ mã hoá phải:

gửi đúng một luồng đã mã hoá có độ phân giải cao nhất mà bạn muốn phân phát cho người dùng (một độ phân giải và bộ mã hoá và giải mã).
kết hợp âm thanh và video.
sử dụng HTTPS và kết nối ổn định cho tất cả các yêu cầu.

Các phần sau đây chứa các yêu cầu cụ thể hơn đối với Danh sách phát nội dung đa phương tiện và Phân đoạn nội dung đa phương tiện.

Danh sách phát nội dung đa phương tiện

Danh sách phát nội dung đa phương tiện chứa danh sách các Phân đoạn nội dung đa phương tiện có thể được nối với nhau để biểu thị luồng nội dung đa phương tiện liên tục, có thể giải mã. Danh sách phát nội dung nghe nhìn cho máy chủ biết những Phân đoạn nội dung nghe nhìn cần chờ và cách sắp xếp các phân đoạn đó đúng cách trong luồng được kết hợp lại.

Yêu cầu

Tên tệp Danh sách phát nội dung nghe nhìn phải kết thúc bằng .m3u8 hoặc .m3u.
Danh sách phát nội dung đa phương tiện đầu tiên được gửi cho một luồng phải bắt đầu ở số thứ tự 0 và số thứ tự phải tăng dần.
Thẻ EXT-X-MEDIA-SEQUENCE phải xác định số thứ tự của Phân đoạn nội dung nghe nhìn đầu tiên được liệt kê trong danh sách phát.
Danh sách phát nội dung nghe nhìn không được chứa quá 5 phân đoạn chưa được tiếp nhận. Một phân đoạn được coi là chưa xử lý nếu máy chủ chưa nhận được hoặc chưa xác nhận đã nhận được phân đoạn đó.

Ngoài các phân đoạn nổi bật, hãy thêm một vài phân đoạn được xác nhận vào mỗi Danh sách phát nội dung nghe nhìn. Phương pháp này giúp giảm khả năng bỏ qua một phân đoạn nếu Danh sách phát nội dung nghe nhìn bị mất ở phía máy chủ. Ví dụ: bạn có thể thêm tối đa 2 phân đoạn được xác nhận và tối đa 5 phân đoạn nổi bật trong mỗi Danh sách phát nội dung nghe nhìn.

Xin lưu ý rằng máy chủ xác nhận đã nhận được Phân đoạn nội dung nghe nhìn bằng cách trả về phản hồi 200 (OK) hoặc 202 (Accepted) về việc tải phân đoạn đó lên. Phản hồi 202 cho biết máy chủ đã nhận được phân khúc trước khi danh sách phát xác định phân khúc đó.
Gửi Danh sách phát nội dung nghe nhìn đã cập nhật cho mọi Phân đoạn nội dung nghe nhìn để máy chủ có thể khôi phục nhanh chóng nếu Danh sách phát nội dung nghe nhìn bị mất.
Khi máy chủ xác nhận đã nhận được Phân đoạn nội dung nghe nhìn, bạn có thể tăng giá trị thẻ EXT-X-MEDIA-SEQUENCE để tránh Danh sách phát nội dung nghe nhìn trở nên quá dài. Ví dụ: nếu máy chủ đã xác nhận đã nhận được 9 Phân đoạn nội dung đa phương tiện đầu tiên, thì Danh sách phát nội dung đa phương tiện tiếp theo có thể liệt kê Phân đoạn nội dung đa phương tiện thứ 8, thứ 9 và thứ 10.
Thẻ EXT-X-KEY và EXT-X-SESSION-KEY không được hỗ trợ.

Ví dụ

Danh sách sau đây cho thấy ví dụ về các tệp mà bộ mã hoá dự kiến sẽ gửi:

Media Playlist file with seqnum #0
Media Segment file #0
Media Playlist file with seqnum #0-#1
Media Segment file #1
Media Playlist file with seqnum #0-#2
Media Segment file #2
Media Playlist file with seqnum #1-#3
Media Segment file #3
...

Ví dụ sau đây cho thấy một Danh sách phát nội dung đa phương tiện được gửi giữa một sự kiện phát trực tiếp. Vì ví dụ này là từ giữa luồng, nên thẻ EXT-X-MEDIA-SEQUENCE có giá trị khác 0.

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:4
#EXT-X-MEDIA-SEQUENCE:2680

#EXTINF:3.975,
fileSequence2680.ts
#EXTINF:3.941,
fileSequence2681.ts
#EXTINF:3.975,
fileSequence2682.ts

Phân đoạn nội dung nghe nhìn

Danh sách sau đây xác định các yêu cầu đối với Phân đoạn nội dung nghe nhìn:

Tên tệp
- Tên tệp của Phân đoạn nội dung nghe nhìn trong URL phải có đuôi tệp .ts và phải khớp với tên tệp trong danh sách phát.
- Tên tệp Phân đoạn nội dung nghe nhìn phải là duy nhất trên các lần khởi động lại bộ mã hoá và khởi động lại luồng.
Định dạng
- Các phân đoạn nội dung nghe nhìn phải ở định dạng M2TS và tự khởi chạy.
- Mỗi Phân đoạn M2TS phải chứa một Chương trình MPEG-2.
- Phân đoạn M2TS phải chứa PAT và PMT, đồng thời hai gói Truyền dẫn luồng đầu tiên trong một Phân đoạn phải là PAT và PMT.
Nội dung
- Video và âm thanh phải được kết hợp.
- Các bộ mã hoá và giải mã video được hỗ trợ là H.264 và HEVC.
- Hỗ trợ HDR với HEVC (xem các yêu cầu đối với nội dung HDR).
- Hỗ trợ tốc độ khung hình lên đến 60 khung hình/giây.
- Chỉ hỗ trợ GOP đóng.
- Bộ mã hoá và giải mã âm thanh được hỗ trợ là AAC và chỉ hỗ trợ âm thanh một kênh.
- Bạn nên đặt thời lượng của Đoạn nội dung nghe nhìn từ 1 đến 4 giây, như đã thảo luận trong phần sau. Phân đoạn nội dung nghe nhìn không được có thời lượng dài hơn 5 giây.
- Các phân đoạn nội dung nghe nhìn chỉ được mã hoá trong lớp TLS/SSL bằng HTTPS. Các cơ chế mã hoá khác không được hỗ trợ.

Thời lượng phân đoạn nội dung nghe nhìn

Chúng tôi dự kiến sẽ sử dụng tính năng truyền dẫn HLS cho nội dung cao cấp yêu cầu chất lượng và độ phân giải cao. Quá trình truyền dẫn HLS thường có độ trễ cao hơn so với quá trình truyền dẫn dựa trên RTMP và WebRTC vì quá trình truyền dẫn HLS dựa trên phân đoạn.

Bạn nên đặt thời lượng Phân đoạn nội dung nghe nhìn từ 1 đến 4 giây vì việc có Phân đoạn nội dung nghe nhìn nhỏ hơn có thể làm giảm độ trễ, mặc dù phải trả giá bằng tốc độ lưu vào bộ đệm cao hơn và hiệu suất mã hoá thấp hơn. Như đã lưu ý trong phần trước, Phân đoạn nội dung nghe nhìn không được dài quá 5 giây.

Tốc độ bit

Trung tâm trợ giúp của YouTube cung cấp nguyên tắc về cách cài đặt tốc độ bit.

Xin lưu ý rằng HEVC thường nén dữ liệu nhiều hơn từ 25% đến 50% ở cùng một chất lượng video so với H.264. Do đó, bạn có thể sử dụng các giá trị tốc độ bit ở cuối phạm vi đề xuất với HEVC để tiết kiệm băng thông, điều này đặc biệt hữu ích đối với nội dung 4K.

Yêu cầu khác

Bộ mã hoá phải đặt tiêu đề User-Agent trong yêu cầu HTTP bằng cú pháp sau, bao gồm tên nhà sản xuất, tên mẫu và phiên bản:
```
User-Agent: <manufacturer> / <model> / <version>
```
Lưu ý: Thông tin này sẽ chỉ được dùng cho mục đích gỡ lỗi. Phương thức này sẽ không được dùng cho các quyết định chức năng trong việc xử lý luồng.

Phụ đề

Tính năng truyền dẫn HLS hỗ trợ hai cách gửi phụ đề:

Gửi phụ đề bằng các yêu cầu POST HTTP riêng. Điều này áp dụng cho tất cả các lần truyền dẫn HLS.
Phụ đề 608/708 nhúng hoạt động với các tệp truyền dẫn HLS sử dụng bộ mã hoá và giải mã video H264 nhưng không hoạt động với các tệp truyền dẫn sử dụng bộ mã hoá và giải mã video HEVC. Để biết thêm thông tin chi tiết, hãy xem Các yêu cầu đối với phụ đề trực tiếp trong Trung tâm trợ giúp của YouTube.

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 Đoạn nội dung nghe nhìn và Danh sách phát nội dung nghe nhìn được phân phối bằng HLS.

200 (OK)

Để phản hồi yêu cầu PUT hoặc POST, 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 đó.

Để phản hồi yêu cầu XOÁ, phản hồi HTTP 200 (OK) cho biết rằng máy chủ YouTube đã nhận được và bỏ qua yêu cầu đó. Máy chủ YouTube không yêu cầu ứng dụng xoá bất kỳ tài nguyên nào trong luồng và bỏ qua các yêu cầu xoá. Vì lý do hiệu suất, YouTube khuyên bạn không nên gửi yêu cầu XOÁ.

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

Phản hồi HTTP 202 (Đã chấp nhận) cho biết máy chủ YouTube đã nhận được Phân đoạn nội dung nghe nhìn trước khi nhận được Danh sách phát nội dung nghe nhìn chứa Phân đoạn nội dung nghe nhìn đó. Điều này cho ứng dụng biết rằng ứng dụng phải gửi Danh sách phát nội dung nghe nhìn chứa Phân đoạn nội dung nghe nhìn đó càng sớm càng tốt để tránh bị chậm trễ trong quá trình xử lý phân đoạn đó. Xin lưu ý rằng điều này sẽ không gây ra vấn đề nếu bộ mã hoá gửi Danh sách phát nội dung đa phương tiện đã cập nhật cho mỗi Phân đoạn nội dung đa phương tiện.

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
Không thể phân tích cú pháp Danh sách phát hoặc Danh sách phát chứa thẻ không được hỗ trợ

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

Phản hồi HTTP 401 (Không được uỷ quyền) cho biết tham số cid trong URL cơ sở của điểm cuối HLS của YouTube đã bị hỏng hoặc hết hạn. Ứng dụng phải cập nhật tham số cid để tiếp tục.

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 rằng yêu cầu đó không phải là yêu cầu POST, PUT hoặc DELETE.

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 thời gian đợi luỹ thừa.