คำตอบสั้น ๆ: Enhanced RTMP ขยายรูปแบบข้อความ RTMP/FLV เพื่อให้ผู้ส่งและผู้รับที่เข้ากันได้ส่งสัญญาณเกี่ยวกับโคเดกรุ่นใหม่ เช่น HEVC หรือ AV1 ได้ ทั้งผู้ส่งและผู้รับยังคงต้องรองรับโคเดกตรงกัน ส่วน RTMPS คือรูปแบบการขนส่งที่ป้องกันด้วย TLS ตรวจสอบข้อกำหนด ingest ล่าสุดของ YouTube ก่อนสร้างอีเวนต์
เริ่มจากข้อกำหนดเอาต์พุตของ YouTube
| ชั้นงาน | คำถามที่ต้องตอบ | สิ่งที่ไม่ควรสรุปเอง |
|---|---|---|
| Enhanced RTMP | ผู้ส่งและเส้นทาง ingest ของ YouTube รองรับการส่งสัญญาณโคเดกแบบขยายที่ต้องใช้หรือไม่ | ผู้รับ RTMP ทุกตัวรับ HEVC หรือ AV1 ได้ |
| โคเดกวิดีโอ | ปลายทางยอมรับโคเดก โปรไฟล์ ความละเอียด อัตราเฟรม และการควบคุมอัตราบิตค่าใดในขณะนี้ | การเลือกโคเดกคือการเข้ารหัสลับ |
| RTMPS | YouTube ให้ URL ingest ที่ปลอดภัยใดสำหรับสตรีมนี้ | RTMP Server อื่นที่ไม่เกี่ยวข้องรับ rtmps:// ได้ |
| การเล่นของผู้ชม | หลังรับ ingest แล้ว YouTube รายงานสถานะการประมวลผลและ rendition อย่างไร | โคเดกสำหรับส่งเข้าระบบคือ rendition สุดท้ายที่ผู้ชมได้รับ |
ก่อนสร้างเอาต์พุต
สร้างหรือตั้งเวลาสตรีมสดของ YouTube แล้วคัดลอก URL เซิร์ฟเวอร์และสตรีมคีย์ปัจจุบันไปใส่เฉพาะในการกำหนดค่าปลายทาง เลือกโปรไฟล์แหล่งสัญญาณที่ปลายทางระบุไว้ หน้าการตั้งค่าเอนโค้ดเดอร์ของ YouTube คือแหล่งอ้างอิงสำหรับคำแนะนำล่าสุดเรื่องโคเดก ความละเอียด บิตเรต และโปรโตคอล อย่านำโปรไฟล์มาใช้ซ้ำเพียงเพราะเคยใช้ได้กับอีเวนต์ก่อนหน้า
สร้างเอาต์พุต YouTube
สร้าง Restream ด้วยการผูกแหล่งสัญญาณที่เลือกไว้ พร้อม URL/คีย์ปลายทางของ YouTube นี่คือเวิร์กโฟลว์เอาต์พุต ดังนั้นการตั้งค่าปลายทางของ YouTube เป็นตัวกำกับการส่งต่อนั้น สำหรับส่วนควบคุมพื้นฐาน โปรดดู การรีสตรีม และ การแปลงรหัสวิดีโอสด
เลือกโปรไฟล์จากงานผลิตจริง
ไล่ย้อนจากค่าการรับ ingest ที่ YouTube เผยแพร่ในปัจจุบัน ยืนยันว่าแหล่งสัญญาณมีโคเดกที่ต้องใช้แล้ว หรือเอาต์พุตจำเป็นต้องใช้โปรไฟล์ transcode ที่รองรับ ตรวจสอบโคเดกเสียง จังหวะ keyframe และการควบคุมอัตราบิตเทียบกับคำแนะนำของปลายทางด้วย Enhanced RTMP ส่งข้อมูลความสามารถของโคเดก จึงควรใช้การซ้อมเพื่อประเมินเอาต์พุตจริง
ตัวเลือกเอาต์พุตที่เป็นรูปธรรม
สำหรับอีเวนต์ที่ยอมรับได้ 1080p30 H.264/AAC เป็นตัวเลือกที่เน้นความเข้ากันได้และใช้งานได้จริง ใช้ HEVC กับ Enhanced RTMP เมื่อ endpoint ปัจจุบันของ YouTube และแหล่งสัญญาณ/เอาต์พุตจริงรองรับเส้นทางนั้น ไม่ว่ากรณีใด ให้ตรวจโปรไฟล์วิดีโอ จังหวะ GOP/keyframe เสียง และ endpoint ที่กำหนดก่อนซ้อม
ซ้อมเส้นทางของผู้ชม
- เริ่มการทดสอบแบบส่วนตัวด้วยรูปแบบแหล่งสัญญาณเดียวกับที่จะใช้จริง
- ยืนยันว่า Callaba มองเห็นอินพุต และเอาต์พุตที่กำหนดค่าไว้เชื่อมต่อได้
- ตรวจสถานะสตรีมที่รับเข้าและคำเตือนใน YouTube Live Control Room
- เปิดเส้นทางพรีวิว/ผู้ชม แล้วตรวจภาพและเสียงของรายการ
- หยุดและเริ่มแหล่งสัญญาณใหม่หนึ่งครั้ง จากนั้นบันทึกขั้นตอนการกู้คืนที่สังเกตได้
วิเคราะห์ปัญหาตามขอบเขต
หากแหล่งสัญญาณปกติแต่ YouTube ไม่แสดง ingest ให้ตรวจ URL/คีย์เซิร์ฟเวอร์ที่คัดลอกมาและโปรโตคอลเอาต์พุตอีกครั้ง หาก YouTube รับสตรีมแต่ปฏิเสธวิดีโอ ให้เปรียบเทียบโคเดก/โปรไฟล์และการตั้งค่าเอนโค้ดเดอร์อื่นกับข้อกำหนดปัจจุบัน หาก ingest ปกติแต่มุมมองผู้ชมล่าช้าหรือใช้ไม่ได้ ให้ตรวจสถานะอีเวนต์และเส้นทางการเล่นของ YouTube แทนการเปลี่ยนแหล่ง RTMP โดยไม่มีข้อมูล
เอกสารอ้างอิงและขั้นตอนถัดไป
ใช้ การตั้งค่าเอนโค้ดเดอร์สำหรับไลฟ์ของ YouTube และ ข้อกำหนด Veovera Enhanced RTMP v2 เป็นเอกสารอ้างอิงในการกำหนดค่า สำหรับแหล่งสัญญาณที่เผยแพร่เข้า Callaba ก่อน ให้ใช้ RTMP Server แล้วจึงกำหนดค่าเอาต์พุต YouTube แยกต่างหาก
