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

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

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

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

ข้อกำหนดเกี่ยวกับรูปแบบสื่อ

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

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

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

HDR

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

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

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

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

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

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

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

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

**ข้อควรระวัง:** วิธีรับ URL การส่งผ่านข้อมูล HLS นี้เป็นฟีเจอร์เบต้าและอาจ มีการเปลี่ยนแปลงในอนาคต

ในอินเทอร์เฟซเว็บของ 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=

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

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

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

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

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

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

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

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

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

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

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

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

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

ข้อกำหนด

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

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

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

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

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

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

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

• เมื่อเซิร์ฟเวอร์ยืนยันการรับกลุ่มเนื้อหาของสื่อแล้ว คุณสามารถเพิ่มค่าแท็ก EXT-X-MEDIA-SEQUENCE เพื่อไม่ให้เพลย์ลิสต์สื่อยาวเกินไป ตัวอย่างเช่น หากเซิร์ฟเวอร์ยืนยันการรับกลุ่มเนื้อหาของสื่อ 9 กลุ่มแรกแล้ว เพลย์ลิสต์สื่อถัดไปอาจแสดงกลุ่มเนื้อหาของสื่อกลุ่มที่ 8, 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)
  • รองรับอัตราเฟรมสูงสุด 60fps
  • รองรับเฉพาะ GOP แบบปิด
  • ตัวแปลงรหัสเสียงที่รองรับคือ AAC และรองรับเฉพาะเสียงแบบแทร็กเดียว
  • เราขอแนะนำให้กลุ่มเนื้อหาของสื่อมีระยะเวลาตั้งแต่ 1-4 วินาทีตามที่อธิบายไว้ในส่วนต่อไปนี้ กลุ่มเนื้อหาของสื่อต้องมีระยะเวลาไม่เกิน 5 วินาที
  • กลุ่มเนื้อหาของสื่อต้องเข้ารหัสในเลเยอร์ TLS/SSL ด้วย HTTPS เท่านั้น ระบบไม่รองรับกลไกการเข้ารหัสอื่นๆ

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

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

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

บิตเรต

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

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

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

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

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

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

คำบรรยายแทนเสียง

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

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

รหัสการตอบกลับ HTTP

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

200 (OK)

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

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

202 (Accepted)

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

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

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

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

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

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

405 (ไม่อนุญาตให้ใช้วิธีนี้)

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

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

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