Google sử dụng công nghệ AI để dịch nội dung sang ngôn ngữ bạn ưu tiên. Bản dịch bằng AI có thể có lỗi.

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) để phát trực tuyến dữ liệu 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ợ nhập dữ liệu HLS vào sản phẩm của họ. Việc sử dụng 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. Để xem 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 các giao thức truyền dẫn của tính năng Phát trực tiếp trên YouTube.

Để phát 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 yêu cầu HTTP PUT hoặc POST. Từ góc độ 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 nghe nhìn đại diện cho nội dung đa phương tiện thực tế của một phần ngắn trong luồng phát, kéo dài từ 1 đến 4 giây. Mỗi Danh sách phát nội dung nghe nhìn mô tả cách tập hợ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 tiếp nhận HLS của 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 bản nhạc.

Xem các yêu cầu chi tiết hơn trong phần Phân đoạn 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 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 dải ô giới hạn (hoặc dải ô MPEG) và dải ô đầy đủ (hoặc dải ô 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 trên YouTube để chèn tài nguyên liveStream có các thuộc tính sau:

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

Trong phản hồi của 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, 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ị "mã sự kiện 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 giúp YouTube xác định cả nhà sáng tạo và sự kiện phát trực tiếp.

Bạn có thể tạo một URL HLS từ mã 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 thứ hai của dữ liệu nhập vào 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. Điểm nhập dữ liệu dự phòng phải gửi một giá trị tham số copy= khác với điểm nhập dữ liệu chính để tránh làm hỏng luồng phát.

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

URL thu được bằng một trong hai phương thức 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, nhờ đó hoàn tất tham số file=.

Các quy tắc sau đây á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ữ-số, dấu gạch dưới, dấu gạch chéo lên, dấu gạch nối và dấu chấm; không hỗ trợ các ký tự khác.
Bộ mã hoá không được mã hoá tên tệp thành URL.
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ó chứa một thành phần đường dẫn trong tên tệp của Phân đoạn nội dung nghe nhì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ủ Quy cách phát trực tuyến dựa trên HTTP phiên bản thứ 2.

Thông số kỹ thuật 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 tiếp 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 cho việc nhập HLS, và 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 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á/giải mã duy nhất).
ghép kênh â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 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 Phân đoạn nội dung nghe nhìn nào sẽ xuất hiện và cách sắp xếp các phân đoạn đó theo đúng thứ tự trong luồng được tập 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 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 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 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 chưa xử lý, hãy thêm một vài phân đoạn đã xác nhận vào mỗi Danh sách phát nội dung nghe nhìn. Cách làm 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 đã xác nhận và tối đa 5 phân đoạn chưa 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 Đ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 đoạn nội dung đó lên. Phản hồi 202 cho biết máy chủ đã nhận được phân đoạn trước khi 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 cá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 chín 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ứ tám, thứ chín và thứ mười.
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 trực tiếp. Vì ví dụ này nằm ở 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 Phân đoạn nội dung nghe nhìn trong URL phải có đuôi tệp là .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 trong các lần khởi động lại bộ mã hoá và khởi động lại luồng.
Định dạng
- Phân đoạn nội dung nghe nhìn phải ở định dạng M2TS và phải tự khởi chạy.
- Mỗi đoạn M2TS phải chứa một chương trình MPEG-2 duy nhất.
- Phân đoạn M2TS phải chứa PAT và PMT, đồng thời hai gói Dòng truyền tải đầ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 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à hệ thống chỉ hỗ trợ âm thanh một kênh.
- Bạn nên đặt thời lượng của Phân đoạn nội dung nghe nhìn trong khoảng 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á ở 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 có các Phân đoạn nội dung nghe nhìn nhỏ hơn có thể dẫn đến độ trễ thấp hơn, mặc dù phải trả giá bằng tỷ lệ đệm lại cao hơn và hiệu quả mã hoá thấp hơn. Như đã lưu ý trong phần trước, cá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 các nguyên tắc 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 đề xuất với HEVC để tiết kiệm băng thông, điều này đặ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 kiểu máy 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. Thông tin này sẽ không được dùng để đưa ra quyết định về 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 POST qua HTTP riêng biệt. Điều này áp dụng cho tất cả các hoạt động truyền dẫn HLS.
Phụ đề được nhúng theo tiêu chuẩn 608/708 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 phân đ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.

Để phản hồi yêu cầu DELETE, phản hồi HTTP 200 (OK) cho biết rằng máy chủ YouTube đã nhận 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 phát 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 Phân đ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 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 nê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 bị chậm trễ trong quá trình xử lý phân đoạn đó. Xin lưu ý rằng đâ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 đã cập nhật cho mọi Phân đ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 đã xảy ra một trong các vấn đề sau:

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 (Unauthorized)

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 cần 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 phía máy chủ nội bộ)

Phản hồi HTTP 500 (Lỗi phía 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 thuật toán thời gian đợi luỹ thừa.