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 Truyền trực tuyến qua HTTP (HLS) để phát trực tiếp 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 dẫn HLS vào sản phẩm. HLS việc nhập dữ liệu là lựa chọn hay cho nội dung trả phí có yêu cầu cao có chất lượng và độ phân giải cao với độ trễ tương đối cao hơn. Tóm tắt so sánh các giao thức truyền dẫn khác nhau được dùng để phát trực tiếp trên YouTube Hỗ trợ phát trực tiếp, hãy xem bài viết So sánh giao thức truyền dẫn phát trực tiếp trên YouTube.

Để phát trực tiếp dữ liệu trực tiếp bằng giao thức HLS, bộ mã hoá cần gửi một loạt nội dung nghe nhìn Danh sách phát và Phân đoạn nội dung đa phương tiện tới điểm cuối HLS của YouTube bằng cách sử dụng HTTP PUT hoặc POST yêu cầu. 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 phương tiện truyền thông đạ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 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 phương tiện theo đúng thứ tự luồng.

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

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

Video và âm thanh phải được trộn ở đị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 (Nhóm hình ảnh) đó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 yêu cầu chi tiết hơn về 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 tiêu chuẩn màu được hỗ trợ là PQ và HLG 10 bit với độ chói không liên tục. Cụ thể hơn:
- Định dạng sắc độ phải là YUV 4:2:0 10-bit.
- Chức năng truyền phải là PQ (còn được gọi là SMPTE ST 2084) hoặc HLG (còn được 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 phải là Rec. Độ chói không liên tục 2020.
Cả mẫu phạm vi giới hạn (hoặc phạm vi MPEG) và mẫu toàn dải (hoặc phạm vi JPEG) giá trị được hỗ trợ. Điều quan trọng là phạm vi được đặt theo phạm vi giá trị mẫu mà nội dung sử dụng. Các giá trị mẫu trong phạm vi giới hạn là được đề xuất.

Lấy URL truyền dẫn HLS

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

Để có được URL truyền dẫn đầy đủ, bộ mã hoá có thể sử dụng tính năng Phát trực tiếp trên YouTube API để chèn sự kiện phát trực tiếp bằng các thuộc tính sau thuộc tính:

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

Trong phản hồi của API, trường cdn.ingestionInfo.ingestionAddress sẽ 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ẫn HLS từ YouTube Creator Studio

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

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 hiển thị trên 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ự phòng của quy trình truyền dẫn 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 bản sao lưu có hai khác biệt so với URL chính: cả hai tên máy chủ và tham số copy= đã thay đổi. Quá trình truyền dẫn dự phòng phải gửi một giá trị thông số copy= khác với giá trị 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 qua một trong hai phương thức này là mẫu chưa hoàn chỉnh; mỗi kết thúc có tham số truy vấn file= trống. Để tạo URL cuối cùng, bộ mã hoá phải nối 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 thành 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ừ 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ợ 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 bao giờ là 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 phương tiện, nó phải tham chiếu cùng một đường dẫn trong mục nhập danh sách phát tương ứng.

Yêu cầu đối với 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ủ Phát trực tuyến HTTP phiên bản thứ 2 Thông số kỹ thuật.

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 Danh sách phát. Vì YouTube chuyển mã nội dung phát trực tuyến thành các độ phân giải khác nhau và thì bộ mã hoá không cần gửi nội dung có cá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 để truyền dẫn 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 nhóm các Biến thể Luồng, 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 đến người dùng (độ phân giải đơn và bộ mã hoá và giải mã).
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ả yêu cầu.

Các phần sau có các 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 Phân đoạn nội dung nghe nhìn có thể nối với thể hiện một luồng đa phương tiện liên tục và có thể giải mã. Danh sách phát nội dung nghe nhìn cho biết máy chủ cần phân đoạn phương tiện truyền thông và cách sắp xếp chúng đúng cách trong tập hợp lại luồng.

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ả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 phương tiệ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 xử lý. Đáp phân đoạn chưa thanh toán nếu máy chủ không nhận được hoặc đã xác nhận của bạn.

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

Lưu ý rằng máy chủ xác nhận đã nhận được Phân đoạn phương tiện bằng cách trả về một Phản hồi 200 (OK) hoặc 202 (Accepted) khi tải đoạn đó lên. Đáp Phản hồi 202 cho biết rằng 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 cập nhật cho mọi phân khúc 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 việc nhận Phân đoạn nội dung nghe nhìn, bạn có thể tăng EXT-X-MEDIA-SEQUENCE giá trị thẻ để ngăn chặn Danh sách phát nội dung nghe nhìn quá dài. Ví dụ: nếu máy chủ đã xác nhận đã nhận được 9 Phân đoạn phương tiện đầu tiên, Danh sách phát phương tiện tiếp theo có thể liệt kê Phân đoạn phương tiện thứ chín và thứ mười.
Các thẻ EXT-X-KEY và EXT-X-SESSION-KEY không được hỗ trợ.

Ví dụ

Danh sách sau đây trình bà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 một video trực tiếp luồng. Vì ví dụ này xảy ra từ 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 cho Phân đoạn nội dung nghe nhìn:

Tên tệp
- Tên tệp Phân đoạn phương tiện trong URL phải có tên 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 phương tiện phải là duy nhất qua các lần khởi động lại bộ mã hoá và luồng sẽ khởi động lại.
Đị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 tạo.
- 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 một PAT và một PMT, đồng thời là hai phân đoạn đầu tiên Các gói Luồng truyền tải trong Phân đoạn phải là PAT và PMT.
Nội dung
- Video và âm thanh phải được trộn.
- 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 về HDR).
- Hỗ trợ tốc độ khung hình lên đến 60 khung hình/giây.
- Chỉ hỗ trợ GOP (Nhóm hình ảnh) đóng.
- Bộ mã hoá và giải mã âm thanh được hỗ trợ là AAC và chỉ âm thanh có một bản nhạc được hỗ trợ.
- Phân đoạn nội dung nghe nhìn nên có thời lượng từ 1 đến 4 giây, như được thảo luận trong phần sau. Phân đoạn phương tiện không được có thời lượng dài hơn 5 giây.
- Phân đoạn phương tiện chỉ được mã hoá trong lớp TLS/SSL với 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 rằng bạn sẽ dùng chế độ truyền dẫn HLS cho những nội dung cao cấp có yêu cầu có chất lượng và độ phân giải cao. Quá trình truyền dẫn bằng HLS thường có độ trễ cao hơn giao thức RTMP và truyền dẫn qua WebRTC vì quá trình truyền dẫ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 là từ 1 đến 4 giây vì có Phân đoạn nội dung đa phương tiện nhỏ hơn có thể dẫn đến độ trễ thấp hơn, mặc dù có chi phí cao hơn tỷ lệ đệm lại và hiệu quả 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 hơn 5 giây.

Tốc độ bit

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

Lưu ý rằng HEVC thường có hiệu suất nén dữ liệu cao hơn 25% đến 50% ở cùng thời điểm so với H.264. Như vậy, giá trị tốc độ bit ở phía dưới của phạm vi đề xuất có thể dùng với HEVC để tiết kiệm băng thông, đặ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ách sử dụ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. Không dùng cho các quyết định chức năng trong quá trình xử lý luồng.

Phụ đề

Phương thức truyền dẫn bằng HLS hỗ trợ hai cách gửi phụ đề:

Gửi phụ đề bằng các yêu cầu POST qua HTTP riêng biệt. Cách này phù hợp với tất cả Truyền dẫn HLS.
Phụ đề nhúng 608/708 hoạt động với quy trình truyền dẫn HLS bằng công nghệ H264 nhưng không dùng bộ mã hoá và giải mã video đối với các tệp truyền dẫn có dùng bộ mã hoá và giải mã video HEVC. Để biết thêm chi tiết, hãy xem Các 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 các mã phản hồi mà YouTube trả về phản hồi cho 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 tác vụ 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 được và bỏ qua yêu cầu. Máy chủ YouTube không yêu cầu ứng dụng DELETE bất kỳ tài nguyên nào trong luồng và ứng dụng sẽ bỏ qua XÓA yêu cầu. Vì lý do hiệu suất, YouTube đề xuất khách hàng không gửi DELETE.

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 lỗi 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 khúc nội dung nghe nhìn đó. Thao tác này cho ứng dụng khách biết rằng cần gửi Danh sách phát nội dung đa phương tiện chứa Phân đoạn phương tiện đó sớm nhất có thể để ngăn sự chậm trễ trong quá trình xử lý phân khúc. Lưu ý rằng đây không phải là vấn đề nếu bộ mã hoá gửi nội dung đã cập nhật Danh sách phát nội dung nghe nhìn 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ệ) chỉ ra một trong các sự cố sau xảy ra:

URL không đúng định dạng
Danh sách phát không được phân tích cú pháp hoặc chứa thẻ không được hỗ trợ

401 (Trái phép)

Phản hồi HTTP 401 (Trái phép) cho biết rằng tham số cid trong URL cơ sở cho điểm cuối HLS của YouTube bị lỗi hoặc hết hạn. Khách hàng phải cập nhật thông số cid để tiếp tục.

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

Phản hồi HTTP 405 (Phương pháp không được phép) cho biết 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 có hàm mũ thời gian đợi.