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 những nhà cung cấp bộ mã hoá muốn thêm tính năng hỗ trợ truyền trực tiếp HLS vào sản phẩm của họ. Việc truyền trực tiếp HLS là 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. Để xem thông tin so sánh ngắn gọn về các giao thức truyền dẫn mà dịch vụ Phát trực tiếp trên YouTube hỗ trợ, hãy xem bài viết So sánh các giao thức truyền dẫn của dịch vụ Phát trực tiếp trên YouTube.

Để truyền trực tuyến dữ liệu 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ách sử dụng các yêu cầu HTTP PUT hoặc POST. Theo bộ mã hoá, điểm cuối HLS của YouTube có vẻ là một máy chủ HTTP thụ động.

Mỗi Phân đoạn nội dung nghe nhì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ừ 1 đến 4 giây. Mỗi Danh sách phát nội dung nghe nhìn mô tả cách lắp ráp lại các Phân đoạn nội dung nghe nhìn theo đúng thứ tự luồng.

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

Quy trình tải 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.
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.

Xem các yêu cầu chi tiết hơn trong phần Phân khúc truyền thông.

HDR

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

Các chuẩn màu được hỗ trợ là PQ và HLG 10 bit với độ chói không đổi. Cụ thể hơn:
- Định dạng sắc độ phải là YUV 4:2:0 10 bit.
- Hàm truyề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 sơ cấp phải là Rec. 2020.
- Hệ số của ma trận màu phải là độ chói không liên tục Rec. 2020.
Cả giá trị mẫu có dải tương phản hạn hẹp (hoặc dải tương phản MPEG) và dải tương phản đầy đủ (hoặc dải tương phản 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 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ừ YouTube API

Để lấy URL truyền dẫn đầy đủ, bộ mã hoá có thể sử dụng API Phát trực tiếp trên YouTube để chèn tài nguyên liveStream bằng 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ữ liệu HLS từ YouTube Creator Studio

Trong giao diện web của YouTube Creator 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ị "Khoá phát trực tiếp" bao gồm các ký tự chữ và số cũng như dấu gạch ngang. Khoá bí mật này xác định cả nhà sáng tạo và luồng phát với YouTube.

Bạn có thể tạo một URL HLS từ khoá sự kiện 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à Mã sự kiện phát trực tiếp xuất hiện 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 bản sao dự phòng thứ hai của dữ liệu 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=

Xin lưu ý rằng URL dự phòng có 2 điểm khác biệt so với URL chính: cả tên máy chủ lưu trữ và tham số copy= đều đã thay đổi. Quá trình truyền dữ liệu dự phòng phải gửi một giá trị tham số copy= khác với quá trình truyền dữ liệu 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 mẫu 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, do đó hoàn tất tham số file=.

Các quy tắc sau áp dụng cho giá trị của tham 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 có ký tự nào khác được hỗ trợ.
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á có 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ì thành phần đó phải tham chiếu đến cùng một đường dẫn trong mục nhập 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à Đoạn nội dung nghe nhìn do bộ mã hoá gửi phải tuân thủ Quy cách phát trực tuyến dựa trên HTTP phiên bản thứ 2.

Quy cách HLS xác định 2 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ó tốc độ bit khác nhau đến YouTube. Do đó, YouTube chỉ hỗ trợ Danh sách phát nội dung nghe nhìn để nhập HLS và bỏ qua Danh sách phát chính. (Danh sách phát chính cung cấp một tập hợp các luồng biến thể, mỗi luồng mô tả một phiên bản khác của cùng một nội dung.)

Bộ mã hoá phải:

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

Các phần sau đây có những yêu cầu cụ thể hơn đối với Danh sách phát nội dung nghe nhìn và Phân đoạn nội dung nghe nhìn.

Danh sách phát nội dung nghe nhìn

Danh sách phát nội dung nghe nhìn chứa danh sách các Phân đoạn nội dung nghe nhìn có thể được nối để biểu thị một 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 Đoạn nội dung nghe nhìn cần có và cách sắp xếp các đoạn đó đúng cách trong luồng được lắp rá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 nghe nhìn đầu tiên được gửi cho một luồng phát phải bắt đầu ở số thứ tự 0 và số thứ tự phải tăng đơn điệu.
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ó 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 sẽ ở trạng thái chưa hoàn tất 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 công nhận vào mỗi Danh sách phát nội dung nghe nhìn. Cách này giúp giảm khả năng một phân đoạn bị bỏ qua 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 chưa được xác nhận vào 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 một 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) khi tải phân đoạn đó lên. Phản hồi 202 cho biết máy chủ đã nhận được phân đoạn trước khi một danh sách phát xác định phân đoạn đó.
Gửi Danh sách phát nội dung nghe nhìn mới nhất cho mọi Phân đoạn nội dung nghe nhìn để máy chủ có thể nhanh chóng khôi phục 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 để ngăn 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 nghe nhìn đầu tiên, thì Danh sách phát nội dung nghe nhìn tiếp theo có thể liệt kê Phân đoạn nội dung nghe nhìn thứ 8, thứ 9 và thứ 10.
Hệ thống không hỗ trợ thẻ EXT-X-KEY và EXT-X-SESSION-KEY.

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 nghe nhìn được gửi ở giữa luồng video phát trực tiếp. Vì ví dụ này nằm ở giữa một 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 Đ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 của Đoạn nội dung nghe nhìn phải là duy nhất trong 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à phải tự khởi tạo.
- Mỗi đ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 2 gói Transport Stream đầ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.
- Bộ mã hoá và giải mã video được hỗ trợ là H.264 và HEVC.
- Hỗ trợ HDR với HEVC (xem 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.
- Các đoạn nội dung nghe nhìn nên có thời lượng từ 1 đến 4 giây, như đã thảo luận trong phần sau. Các 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á ở 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 mong muốn bạn sử dụng tính năng truyền trực tiếp HLS cho nội dung cao cấp đòi hỏi chất lượng cao và độ phân giải cao. Việc truyền HLS thường có độ trễ cao hơn so với việc truyền RTMP và WebRTC vì việc truyền HLS dựa trên phân đoạn.

Bạn nên sử dụng thời lượng Phân đoạn nội dung nghe nhìn từ 1 đến 4 giây vì việc sử dụng Phân đoạn nội dung nghe nhìn nhỏ hơn có thể làm giảm độ trễ, mặc dù điều này sẽ làm tăng tỷ lệ đệm lại và giảm hiệu quả mã hoá. 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 hướng dẫn về chế độ cài đặt tốc độ bit.

Xin lưu ý rằng HEVC thường mang lại mức nén dữ liệu cao hơn từ 25% đến 50% ở cùng 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 ở mức thấp hơn trong phạm vi được đề xuất với HEVC để tiết kiệm băng thông, đặc biệt hữu ích cho 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. Tham số này sẽ không được dùng cho các quyết định chức năng trong quá trình xử lý luồng.

Phụ đề

Tính năng nhận HLS hỗ trợ 2 lựa chọn để gửi phụ đề:

Gửi phụ đề bằng các yêu cầu HTTP POST riêng biệt. Điều này áp dụng cho tất cả các lần truyền HLS.
Phụ đề chi tiết 608/708 được nhúng hoạt động với các giao thức 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 giao thức 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 Yêu cầu về 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 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 một yêu cầu PUT hoặc POST, phản hồi HTTP 200 (OK) cho biết rằng 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 một yêu cầu XÓA, 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 nghị các ứng dụng không gửi yêu cầu XÓA.

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 Đoạn nội dung nghe nhìn trước khi nhận được một Danh sách phát nội dung nghe nhìn có chứa Đoạn nội dung nghe nhìn đó. Điều này cho biết rằng ứng dụng cần 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 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 phải là vấn đề nếu bộ mã hoá gửi Danh sách phát nội dung nghe nhìn mới cho mọi Đoạn nội dung nghe nhì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 phân tích cú pháp được danh sách phát hoặc danh sách phát chứa các thẻ không được hỗ trợ

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

Phản hồi HTTP 401 (Không được phép) cho biết tham số cid trong URL cơ sở cho điểm cuối HLS của YouTube đã bị hỏng hoặc hết hạn. Ứng dụng khách 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 rằng 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 thuật toán thời gian đợi luỹ thừa.