การส่งเนื้อหาแบบสดบน YouTube ผ่าน HLS

เอกสารนี้อธิบายวิธีใช้โปรโตคอล HTTP Live Streaming (HLS) เพื่อทำสิ่งต่อไปนี้ สตรีมข้อมูลแบบสดบน YouTube จากโปรแกรมเปลี่ยนไฟล์ เอกสารนี้มีไว้สำหรับ ผู้ให้บริการโปรแกรมเปลี่ยนไฟล์ที่ต้องการเพิ่มการรองรับการส่งผ่านข้อมูล HLS ในผลิตภัณฑ์ของตน HLS การส่งผ่านข้อมูลเป็นตัวเลือกที่ดีสำหรับเนื้อหาพรีเมียมที่จำเป็นต้องใช้ทรัพยากรปริมาณมาก มีคุณภาพและมีความละเอียดสูง โดยใช้เวลาในการตอบสนองที่ค่อนข้างสูงขึ้น ข้อมูลสรุป การเปรียบเทียบโปรโตคอลการส่งผ่านข้อมูลแบบต่างๆ ที่ YouTube Live รองรับสตรีมมิงที่หัวข้อการเปรียบเทียบโปรโตคอลการส่งผ่านข้อมูลของสตรีมมิงแบบสดของ YouTube

หากต้องการสตรีมข้อมูลสดโดยใช้ HLS โปรแกรมเปลี่ยนไฟล์ควรส่งชุดสื่อ เพลย์ลิสต์และกลุ่มสื่อไปยังปลายทาง HLS ของ YouTube โดยใช้ HTTP PUT หรือ คำขอ POST รายการ จากมุมมองของโปรแกรมเปลี่ยนไฟล์ อุปกรณ์ปลายทางของ YouTube HLS ดูเหมือนจะเป็นเซิร์ฟเวอร์ HTTP แบบแพสซีฟ

กลุ่มสื่อแต่ละกลุ่มจะแสดงเนื้อหามัลติมีเดียจริงในเวลาสั้นๆ ของสตรีมเป็นเวลา 1-4 วินาที เพลย์ลิสต์สื่อแต่ละรายการ อธิบายวิธีรวมกลุ่มสื่ออีกครั้งตามลำดับสตรีมที่ถูกต้อง

ข้อกำหนดรูปแบบสื่อ

การส่งผ่านข้อมูล HLS ของ YouTube มีข้อกำหนดต่อไปนี้สำหรับวิดีโอและเสียง เนื้อหา:

• ต้องมิกซ์วิดีโอและเสียงในรูปแบบ M2TS
• ตัวแปลงรหัสวิดีโอที่รองรับคือ H.264 และ HEVC
• สนับสนุนอัตราเฟรมสูงสุด 60 FPS
• รองรับเฉพาะ GOP แบบปิดเท่านั้น
• ตัวแปลงรหัสเสียงที่รองรับคือ AAC และรองรับเฉพาะเสียงแทร็กเดียว

ดูข้อกำหนดโดยละเอียดเพิ่มเติมในส่วนกลุ่มสื่อ

HDR

ตัวแปลงรหัส HEVC รองรับวิดีโอ High Dynamic Range (HDR) และมี ข้อกำหนดเพิ่มเติมดังต่อไปนี้

• มาตรฐานสีที่รองรับคือ PQ และ HLG 10 บิตที่มีความสว่างไม่คงที่ กล่าวอย่างเจาะจงคือ
  • รูปแบบโครมาต้องเป็น YUV 4:2:0 10 บิต
  • ฟังก์ชันการโอนต้องเป็น PQ (หรือที่เรียกว่า SMPTE ST 2084) หรือ HLG (หรือที่เรียกว่า ARIB STD-B67)
  • แม่สีต้องเป็นแบบ Rec 2020
  • ค่าสัมประสิทธิ์เมตริกซ์ต้องเป็น Rec ความสว่างไม่คงที่ของปี 2020
• ตัวอย่างทั้งแบบจำกัดช่วง (หรือ MPEG-range) และ Full Range (หรือ JPEG-range) ค่าที่รองรับ สิ่งสำคัญคือต้องตั้งค่าช่วงตาม ช่วงค่าตัวอย่างที่เนื้อหาใช้ ค่าตัวอย่างที่จำกัดช่วงคือ แนะนำ

การรับ URL การส่งผ่านข้อมูล HLS

การรับ URL การส่งผ่านข้อมูล HLS จาก YouTube API

หากต้องการรับ URL การส่งผ่านข้อมูลแบบเต็ม โปรแกรมเปลี่ยนไฟล์สามารถใช้สตรีมมิงแบบสดของ YouTube ได้ API เพื่อแทรกสตรีมแบบสด แหล่งข้อมูล ที่มี พร็อพเพอร์ตี้:

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

ในการตอบกลับ API ช่อง cdn.ingestionInfo.ingestionAddress จะระบุ URL การส่งผ่านข้อมูลหลัก และช่อง cdn.ingestionInfo.backupIngestionAddress ระบุ URL การส่งผ่านข้อมูลสำรอง สำหรับรายละเอียดเพิ่มเติม โปรดดูเอกสารสำหรับ แหล่งข้อมูล liveStreams

การรับ URL การส่งผ่านข้อมูล HLS จาก YouTube Creator Studio

ในอินเทอร์เฟซบนเว็บของ YouTube Creator Studio หลังจากที่ครีเอเตอร์คลิก "สร้าง" สตรีม" YouTube จะแสดง "สตรีมคีย์" ที่ประกอบด้วยอักขระที่เป็นตัวอักษรและตัวเลขคละกัน อักขระและขีดกลาง คีย์ลับนี้จะระบุทั้งผู้สร้างและ ไปยัง YouTube

คุณจะสร้าง URL ของ HLS จากสตรีมคีย์นี้ได้ดังนี้

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

... โดยที่ $STREAM_KEY คือสตรีมคีย์ที่แสดงในอินเทอร์เฟซเว็บ ดังตัวอย่างต่อไปนี้ https://a.upload.youtube.com/http_upload_hls?cid=abcd-efgh-ijkl-mnop-qrst&copy=0&file=

คุณสามารถส่งสำเนาที่ 2 ของการส่งผ่านข้อมูลซ้ำซ้อนเพื่อเพิ่มความน่าเชื่อถือ ต่อท้าย URL สำรองนี้:

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

โปรดทราบว่าข้อมูลสำรองมีความแตกต่าง 2 อย่างจาก URL หลัก ได้แก่ ชื่อโฮสต์ทั้งคู่ และพารามิเตอร์ copy= มีการเปลี่ยนแปลง การส่งผ่านข้อมูลสำรองต้องส่ง ค่าพารามิเตอร์ copy= ที่แตกต่างจากการนำเข้าหลักเพื่อหลีกเลี่ยง ทำให้สตรีมเสียหาย

การสร้าง URL การส่งผ่านข้อมูล HLS ให้เสร็จสมบูรณ์

URL ที่ได้รับโดยใช้วิธีใดวิธีการหนึ่งคือเทมเพลตที่ไม่สมบูรณ์ แต่ละด้าน ที่มีพารามิเตอร์การค้นหา file= ที่ว่างเปล่า ในการสร้าง URL สุดท้าย โปรแกรมเปลี่ยนไฟล์ต้อง ให้เติมชื่อไฟล์ของเพลย์ลิสต์สื่อหรือกลุ่มสื่อต่อท้าย URL ซึ่งเป็นการเติมพารามิเตอร์ file= ให้สมบูรณ์

กฎต่อไปนี้ใช้กับค่าของพารามิเตอร์ file=

• โปรแกรมเปลี่ยนไฟล์อาจสร้างชื่อไฟล์เพลย์ลิสต์สื่อหรือส่วนสื่อจาก อักขระที่เป็นตัวอักษรและตัวเลขคละกัน ขีดล่าง เครื่องหมายทับ ขีดกลาง และจุด ไม่รองรับอักขระอื่นๆ
• โปรแกรมเปลี่ยนไฟล์ต้องไม่เข้ารหัส URL สำหรับชื่อไฟล์
• โปรแกรมเปลี่ยนไฟล์อาจมีคอมโพเนนต์เส้นทางแบบสัมพัทธ์หรือเส้นทางสัมบูรณ์ในชื่อไฟล์ แม้ว่าจะไม่จำเป็นก็ตาม หากโปรแกรมเปลี่ยนไฟล์มีคอมโพเนนต์เส้นทาง ภายในชื่อไฟล์ของกลุ่มสื่อ ข้อมูลดังกล่าวจะต้องอ้างอิงเส้นทางเดียวกันใน รายการเพลย์ลิสต์ที่เกี่ยวข้อง

ข้อกำหนดโปรโตคอล HLS

เพลย์ลิสต์สื่อและกลุ่มสื่อที่ส่งโดยโปรแกรมเปลี่ยนไฟล์จะต้องเป็นไปตาม HTTP Live Streaming รุ่น 2 ข้อมูลจำเพาะ

ข้อกำหนด HLS กำหนดเพลย์ลิสต์ไว้ 2 ประเภท ได้แก่ เพลย์ลิสต์สื่อและเพลย์ลิสต์หลัก เพลย์ลิสต์ เนื่องจาก YouTube แปลงสตรีมเนื้อหาเป็นความละเอียดต่างๆ อัตราบิตอื่น โปรแกรมเปลี่ยนไฟล์ไม่จำเป็นต้องส่งเนื้อหาที่มีอัตราบิตที่แตกต่างกันเพื่อ YouTube YouTube จึงรองรับเฉพาะเพลย์ลิสต์สื่อสำหรับการส่งผ่านข้อมูล HLS และเพลย์ลิสต์หลักจะถูกละเว้น (เพลย์ลิสต์หลักจะมีชุดรูปแบบ สตรีม ซึ่งแต่ละสตรีมจะอธิบายเนื้อหาเดียวกันในเวอร์ชันที่แตกต่างกันไป)

โดยโปรแกรมเปลี่ยนไฟล์ต้องมีลักษณะดังนี้

• ส่งสตรีมที่เข้ารหัสแล้วหนึ่งสตรีมที่มีความละเอียดสูงสุดที่คุณต้องการ แสดงต่อผู้ใช้ (ความละเอียดเดียวและตัวแปลงรหัส)
• เสียงและวิดีโอ mux
• ใช้ HTTPS และการเชื่อมต่อแบบถาวรสำหรับคำขอทั้งหมด

ส่วนต่อไปนี้มีข้อกำหนดที่เฉพาะเจาะจงมากขึ้นสำหรับเพลย์ลิสต์สื่อ และกลุ่มสื่อ

เพลย์ลิสต์สื่อ

เพลย์ลิสต์สื่อมีรายการกลุ่มสื่อที่สามารถเชื่อมโยงกับ แสดงถึงสตรีมมัลติมีเดียที่ต่อเนื่องและอ่านได้ เพลย์ลิสต์สื่อจะบอก เซิร์ฟเวอร์ที่คาดว่ากลุ่มสื่อจะคาดหมายและวิธีเรียงลำดับอย่างเหมาะสมใน รวมสตรีมเข้าด้วยกัน

ข้อกำหนด

• ชื่อไฟล์เพลย์ลิสต์สื่อต้องลงท้ายด้วย .m3u8 หรือ .m3u

• เพลย์ลิสต์สื่อรายการแรกที่ส่งสำหรับสตรีมต้องเริ่มต้นที่หมายเลขลำดับ 0 และหมายเลขลำดับต้องเพิ่มขึ้นแบบโมโนโมชัน

• แท็ก EXT-X-MEDIA-SEQUENCE ต้องระบุหมายเลขลำดับของค่า กลุ่มสื่อแรกที่แสดงในเพลย์ลิสต์

• เพลย์ลิสต์ของสื่อต้องไม่มีส่วนเด่นเกิน 5 ส่วน ต กลุ่มนั้นค้างชำระหากเซิร์ฟเวอร์ไม่ได้รับหรือรับทราบ เมื่อได้รับพัสดุ

  นอกจากกลุ่มที่โดดเด่นแล้ว ให้รวมกลุ่ม ที่ได้รับการยอมรับ ในเพลย์ลิสต์สื่อแต่ละรายการ วิธีนี้ช่วยลดโอกาสที่จะ ส่วนนี้จะถูกข้ามหากเพลย์ลิสต์ของสื่อหายไปจากฝั่งเซิร์ฟเวอร์ สำหรับ ตัวอย่างเช่น คุณสามารถรวมกลุ่มที่รับทราบแล้วได้สูงสุด 2 กลุ่ม และไม่เกิน 5 กลุ่ม ส่วนที่โดดเด่นในเพลย์ลิสต์สื่อแต่ละรายการ

  โปรดทราบว่าเซิร์ฟเวอร์รับทราบการรับกลุ่มสื่อโดยการส่งคืน คำตอบ 200 (OK) หรือ 202 (Accepted) ในการอัปโหลดของกลุ่มนั้น ต การตอบสนอง 202 ระบุว่าเซิร์ฟเวอร์ได้รับกลุ่มก่อน ที่ระบุส่วนนั้นอยู่

• ส่งเพลย์ลิสต์สื่อที่อัปเดตแล้วสำหรับกลุ่มสื่อทุกกลุ่ม เพื่อให้ เซิร์ฟเวอร์สามารถกู้คืนได้อย่างรวดเร็วหากเพลย์ลิสต์ของสื่อหายไป

• เมื่อเซิร์ฟเวอร์รับทราบการรับกลุ่มสื่อ คุณสามารถเพิ่ม ค่าแท็ก EXT-X-MEDIA-SEQUENCE เพื่อป้องกันไม่ให้เพลย์ลิสต์ของสื่อกลายเป็น ยาวเกินไป ตัวอย่างเช่น หากเซิร์ฟเวอร์รับทราบการรับ ส่วนสื่อ 9 กลุ่มแรก เพลย์ลิสต์สื่อถัดไปอาจแสดง กลุ่มสื่อที่ 9 และ 10

• ไม่รองรับแท็ก EXT-X-KEY และ EXT-X-SESSION-KEY

ตัวอย่าง

รายการต่อไปนี้แสดงตัวอย่างของไฟล์ที่โปรแกรมเปลี่ยนไฟล์ควรจะมี ส่ง:

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
...

ตัวอย่างต่อไปนี้แสดงเพลย์ลิสต์สื่อที่ส่งในระหว่างวิดีโอสด สตรีม เนื่องจากตัวอย่างนี้มาจากช่วงกลางของสตรีม แท็ก EXT-X-MEDIA-SEQUENCE มีค่าที่ไม่ใช่ 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

กลุ่มสื่อ

รายการต่อไปนี้จะระบุข้อกำหนดสำหรับกลุ่มสื่อ

• ชื่อไฟล์
  • ชื่อไฟล์ของกลุ่มสื่อใน URL ต้องมีชื่อไฟล์ .ts นามสกุล และต้องตรงกับชื่อไฟล์ในเพลย์ลิสต์
  • ชื่อไฟล์ของกลุ่มสื่อต้องไม่ซ้ำกันในการรีบูตโปรแกรมเปลี่ยนไฟล์และ สตรีมจะรีสตาร์ท
• รูปแบบ
  • กลุ่มสื่อต้องอยู่ในรูปแบบ M2TS และควรเริ่มต้นด้วยตัวเอง
  • กลุ่ม M2TS แต่ละกลุ่มต้องมีโปรแกรม MPEG-2 ไฟล์เดียว
  • กลุ่ม M2TS ต้องมี PAT และ PMT และ 2 รายการแรก แพ็กเก็ตสตรีมการรับส่งข้อมูลในกลุ่มควรเป็น PAT และ PMT
• เนื้อหา
  • ต้องผสมสัญญาณวิดีโอและเสียง
  • ตัวแปลงรหัสวิดีโอที่รองรับคือ H.264 และ HEVC
  • รองรับ HDR ที่มี HEVC (ดูข้อกำหนดของ HDR)
  • สนับสนุนอัตราเฟรมสูงสุด 60 FPS
  • รองรับเฉพาะ GOP แบบปิดเท่านั้น
  • ตัวแปลงรหัสเสียงที่รองรับคือ AAC และเสียงแทร็กเดียวคือ ที่รองรับ
  • กลุ่มสื่อได้รับการแนะนําให้มีระยะเวลาระหว่าง 1-4 วินาที ดังที่กล่าวไว้ในส่วนต่อไป กลุ่มสื่อต้องไม่ มีความยาวมากกว่า 5 วินาที
  • กลุ่มสื่อต้องเข้ารหัสในเลเยอร์ TLS/SSL ด้วย HTTPS เท่านั้น ไม่รองรับกลไกการเข้ารหัสอื่นๆ

ระยะเวลาของกลุ่มสื่อ

เราคาดว่าจะใช้การส่งผ่านข้อมูล HLS สำหรับเนื้อหาพรีเมียมที่จำเป็นต้องใช้ คุณภาพสูงและมีคุณภาพ การส่งผ่านข้อมูล HLS มักมีเวลาในการตอบสนองสูงกว่า RTMP- และการส่งผ่านข้อมูลแบบ WebRTC เนื่องจากการส่งผ่านข้อมูล HLS เป็นแบบอิงตามกลุ่ม

เราแนะนำความยาวของกลุ่มสื่อไว้ที่ 1-4 วินาที เพราะ กลุ่มสื่อขนาดเล็ก อาจส่งผลให้เวลาในการตอบสนองลดลง แม้ว่าจะมีค่าใช้จ่าย อัตราการบัฟเฟอร์ซ้ำและประสิทธิภาพการเข้ารหัสที่ลดลง ดังที่ได้กล่าวไว้ในส่วนก่อนหน้านี้ กลุ่มสื่อต้องมีความยาวไม่เกิน 5 วินาที

บิตเรต

ความช่วยเหลือของ YouTube กลาง ให้หลักเกณฑ์สำหรับการตั้งค่าอัตราบิต

โปรดทราบว่าโดยทั่วไป HEVC จะให้การบีบอัดข้อมูลมากขึ้น 25% ถึง 50% ที่อัตราเท่าเดิม คุณภาพวิดีโอเมื่อเทียบกับ H.264 ดังนั้น ค่าอัตราบิตในส่วนล่างของ ช่วงที่แนะนำสามารถใช้ร่วมกับ HEVC เพื่อประหยัดแบนด์วิดท์ โดยเฉพาะ มีประโยชน์กับเนื้อหา 4K

ข้อกำหนดอื่นๆ

• โปรแกรมเปลี่ยนไฟล์ควรตั้งค่าส่วนหัว User-Agent ในคำขอ HTTP โดยใช้ ไวยากรณ์ต่อไปนี้ ซึ่งมีชื่อผู้ผลิต ชื่อรุ่น และ เวอร์ชัน:

  User-Agent: <manufacturer> / <model> / <version>
  

คำบรรยาย

การส่งผ่านข้อมูล HLS รองรับการส่งคำบรรยายแทนเสียง 2 แบบดังนี้

• ส่งคำบรรยายโดยใช้คำขอ HTTP POST แยกต่างหาก วิธีนี้เหมาะสำหรับทุกคน การส่งผ่านข้อมูล HLS
• คำบรรยายแทนเสียง 608/708 แบบฝังสามารถทำงานร่วมกับการนำเข้า HLS ที่ใช้ H264 ตัวแปลงสัญญาณวิดีโอ แต่ไม่ใช้กับการส่งผ่านข้อมูลที่ใช้ตัวแปลงรหัสวิดีโอ HEVC สำหรับข้อมูลเพิ่มเติม โปรดดูรายละเอียดที่หัวข้อข้อกำหนดเกี่ยวกับคำบรรยายสด ในศูนย์ช่วยเหลือของ YouTube

โค้ดตอบกลับ HTTP

ส่วนต่อไปนี้จะอธิบายโค้ดตอบกลับที่ YouTube แสดงผล การตอบสนองต่อกลุ่มสื่อและเพลย์ลิสต์สื่อที่แสดงโดยใช้ HLS

200 (ปกติ)

ในการตอบสนองต่อคำขอ PUT หรือ POST นั้น การตอบสนอง HTTP 200 (OK) จะระบุ เซิร์ฟเวอร์ YouTube ได้รับการดำเนินการตามที่คาดไว้ และจัดการการทำงาน สำเร็จ

ในการตอบสนองต่อคำขอ DELETE การตอบกลับ HTTP 200 (OK) ระบุว่า เซิร์ฟเวอร์ YouTube ได้รับและไม่สนใจคำขอ เซิร์ฟเวอร์ของ YouTube ไม่จำเป็นต้องให้ไคลเอ็นต์ลบทรัพยากรใดๆ ในสตรีม และจะไม่ประมวลผลทรัพยากรใดๆ ลบคำขอ เพื่อประสิทธิภาพในการทำงาน YouTube แนะนำลูกค้า อย่าส่ง DELETE

202 (Accepted)

การตอบกลับ HTTP 202 (ยอมรับ) ระบุว่าเซิร์ฟเวอร์ของ YouTube ได้รับ กลุ่มสื่อก่อนที่จะได้รับเพลย์ลิสต์สื่อที่มีกลุ่มสื่อนั้น ซึ่งเป็นการแจ้งให้ลูกค้าทราบว่าควรส่งเพลย์ลิสต์สื่อที่มี กลุ่มสื่อดังกล่าวโดยเร็วที่สุดเพื่อไม่ให้การประมวลผลล่าช้า กลุ่ม โปรดทราบว่าปัญหานี้จะไม่เกิดขึ้นหากโปรแกรมเปลี่ยนไฟล์ส่งการอัปเดต เพลย์ลิสต์สื่อสําหรับกลุ่มสื่อทุกกลุ่ม

400 (คำขอไม่ถูกต้อง)

การตอบกลับ HTTP 400 (คำขอไม่ถูกต้อง) ระบุถึงปัญหาข้อใดข้อหนึ่งต่อไปนี้ เกิดขึ้น:

• URL มีรูปแบบไม่ถูกต้อง
• ไม่สามารถแยกวิเคราะห์เพลย์ลิสต์หรือมีแท็กที่ไม่รองรับ

401 (ไม่ได้รับอนุญาต)

การตอบกลับ HTTP 401 (ไม่ได้รับอนุญาต) บ่งชี้ว่าพารามิเตอร์ cid ใน URL ฐานสำหรับปลายทาง HLS ของ YouTube เสียหายหรือหมดอายุแล้ว ลูกค้า ควรอัปเดตพารามิเตอร์ cid เพื่อดำเนินการต่อ

405 (ไม่อนุญาตเมธอดนี้)

การตอบกลับ HTTP 405 (ไม่อนุญาตเมธอด) บ่งชี้ว่าคำขอ ไม่ใช่คำขอ POST, PUT หรือ DELETE

500 (ข้อผิดพลาดภายในเซิร์ฟเวอร์)

การตอบกลับ HTTP 500 (ข้อผิดพลาดภายในเซิร์ฟเวอร์) บ่งชี้ว่าเซิร์ฟเวอร์ถูก ไม่สามารถดำเนินการตามคำขอได้ สำหรับข้อผิดพลาดนี้ เราขอแนะนำให้คุณลอง คำขอที่มี Exponential Backoff