คำตอบสั้น ๆ: การเร่งด้วยฮาร์ดแวร์อาจเปลี่ยนทรัพยากรประมวลผลที่ใช้สำหรับเส้นทาง encode หรือ decode ที่รองรับได้ ความเข้ากันได้ของโคเดกกับปลายทางและการส่งสัญญาณ Enhanced RTMP ยังคงเป็นสิ่งที่ต้องตรวจแยกกัน เริ่มจากข้อกำหนดเอาต์พุต ทดสอบหนึ่งโปรไฟล์ภายใต้โหลดที่เป็นตัวแทนการใช้งานจริง แล้วจึงตัดสินว่าความจุในการประมวลผลเพียงพอหรือไม่
ใช้การเร่งสำหรับงานประมวลผลที่วัดได้
| ชั้นงาน | การตัดสินใจ | การตรวจรับ |
|---|---|---|
| อินพุต | แหล่งสัญญาณถอดรหัสหรือส่งผ่านได้ในเวิร์กโฟลว์ที่เลือกหรือไม่ | ภาพอินพุตคงที่ การแมปเสียง และข้อมูลสถานะจากแหล่งสัญญาณ |
| การแปลง | ส่งผ่าน รีมักซ์ หรือสร้าง rendition ใหม่ด้วยโคเดก/ความละเอียด/บิตเรตใหม่ | โคเดก โปรไฟล์ ขนาด อัตราเฟรม และ GOP ของเอาต์พุตที่ระบุตรงกับข้อกำหนดของผู้รับ |
| การเร่ง | โปรไฟล์ที่เลือกใช้ได้บนทรัพยากรประมวลผลที่เลือกหรือไม่ | การทำงานต่อเนื่องแสดงเฮดรูมที่ใช้งานได้ และไม่มีการถดถอยของสื่อที่รับ |
| การขนส่ง | เอาต์พุตต้องใช้ endpoint และการขนส่งใด | ปลายทางเชื่อมต่อด้วย URL และข้อมูลรับรองที่กำหนด |
| Enhanced RTMP | คู่ผู้ส่ง/ผู้รับนี้รองรับการส่งสัญญาณโคเดกที่ต้องใช้หรือไม่ | ผู้รับยอมรับสื่อจริง อย่าตัดสินจากการเชื่อมต่อเพียงอย่างเดียว |
แยกสี่กระบวนการที่มักถูกเรียกรวมว่า transcoding
การส่งผ่านคงสื่อที่เข้ารหัสไว้โดยไม่เปลี่ยนแปลง การรีมักซ์เปลี่ยนคอนเทนเนอร์หรือแพ็กเกจจิงโดยไม่จำเป็นต้องเข้ารหัสสตรีมใหม่เสมอไป Transcoding ถอดรหัสและเข้ารหัสตัวแทนใหม่ การเร่งด้วยฮาร์ดแวร์เป็นรายละเอียดการนำไปใช้ของเส้นทางประมวลผลที่รองรับ ไม่ใช่รูปแบบสื่อชนิดที่สี่ ระบุชื่อกระบวนการที่ต้องใช้ก่อนกำหนดขนาดโครงสร้างพื้นฐาน
สิ่งที่การเร่งสื่อเปลี่ยนแปลงจริง
การเร่งอาจให้ทรัพยากรที่เหมาะสมสำหรับงานวิดีโอบางประเภท แต่ความหนาแน่นการใช้งานจริงขึ้นอยู่กับโคเดก/โปรไฟล์ ความละเอียด อัตราเฟรม ความซับซ้อนของอินพุต งานอื่น และชุดแพลตฟอร์ม/ไดรเวอร์ AWS อธิบาย VT1 ว่าเป็นตระกูลอินสแตนซ์ Amazon EC2 สำหรับเวิร์กโหลดการแปลงรหัสวิดีโอ ให้ใช้เป็นบริบทด้านโครงสร้างพื้นฐาน แล้วทดสอบแหล่งสัญญาณ เอาต์พุต และการติดตั้ง Callaba ที่เลือก การควบคุมการเร่งด้วยฮาร์ดแวร์อยู่ใน Live Video Transcoding แต่โปรไฟล์ยังต้องผ่านการรันที่เป็นตัวแทนการใช้งานจริงก่อนจึงจะยอมรับสำหรับการใช้งานจริง
Enhanced RTMP คือข้อตกลงการทำงานร่วมกัน
ข้อกำหนดของ Veovera เพิ่มการส่งสัญญาณ RTMP/FLV สำหรับโคเดกรุ่นใหม่ รวมถึง HEVC และ AV1 การขนส่งยังคงเป็น RTMP หรือ RTMPS ได้ตามปลายทาง RTMPS ปกป้องการเชื่อมต่อด้วย TLS ขณะที่ Enhanced RTMP เพิ่มการส่งสัญญาณโคเดก ตรวจสอบความสามารถทั้งสองกับ endpoint ปลายทาง เอกสารเอนโค้ดเดอร์ฉบับปัจจุบันของ YouTube และรายละเอียด ingest ที่ปลายทางกำหนด คือแหล่งอ้างอิงการตั้งค่าสำหรับเส้นทางไปยัง YouTube
บันทึกผลการตรวจรับ
จดโคเดก โปรไฟล์ จังหวะ GOP/keyframe เสียง และ endpoint ที่ปลายทางต้องการ แล้วรัน rendition ที่เลือกภายใต้โหลดที่เป็นตัวแทนการใช้งานจริง เก็บผลเอาต์พุตที่ผู้รับได้รับไว้กับโปรไฟล์ เพื่อให้ผู้ปฏิบัติงานคนถัดไปทำซ้ำเส้นทางที่ใช้งานได้
สร้างหนึ่งโปรไฟล์โดยไล่ย้อนจากปลายทาง
- บันทึกข้อกำหนดปัจจุบันของปลายทางสำหรับการขนส่ง โคเดก เสียง ความละเอียด อัตราเฟรม บิตเรต และ keyframe
- ตรวจแหล่งสัญญาณ ส่งผ่านเฉพาะเมื่อข้อกำหนดสื่อทั้งหมดตรงกันอยู่แล้ว
- หากต้องแปลง ให้เลือกโปรไฟล์เอาต์พุตที่ตรงกับข้อกำหนดปลายทาง และตรวจว่าเส้นทางการเร่งที่เลือกใช้งานได้หรือไม่
- รันสื่อรายการที่เป็นตัวแทนการใช้งานจริงนานพอเพื่อสังเกตพฤติกรรมการประมวลผล เสียง/วิดีโอที่รับ และการกู้คืน
- เก็บโปรไฟล์ที่พิสูจน์แล้วว่าใช้งานได้ พร้อมหลักฐานที่ใช้ยอมรับโปรไฟล์นั้น
แก้ปัญหาโดยสังเกตแต่ละขอบเขต
หากอินพุตปกติแต่เอาต์พุตไม่เริ่ม ให้ตรวจ URL ปลายทาง ข้อมูลรับรอง การเปิดใช้งานเอาต์พุต หรือโปรไฟล์ที่เข้ากันไม่ได้ก่อน เอาต์พุตที่เชื่อมต่อแล้วแต่ภาพดำต้องตรวจโคเดก/โปรไฟล์และผู้รับ การเพิ่ม latency หรือเปลี่ยนการเร่งไม่ใช่สิ่งทดแทนการตรวจข้อกำหนดเอาต์พุต เมื่อคุณภาพการเคลื่อนไหวลดลง ให้เปรียบเทียบ rendition ที่รับกับแหล่งสัญญาณ และทบทวนการควบคุมอัตราบิต จังหวะ และเฮดรูมการประมวลผลต่อเนื่อง
Callaba อยู่ส่วนใดของเวิร์กโฟลว์
Live Video Transcoding คือส่วนควบคุมของ Callaba สำหรับการตั้งค่าโคเดก โปรไฟล์ บิตเรต อัตราเฟรม ขนาด GOP แทร็ก แชนเนล การเร่งด้วยฮาร์ดแวร์ และโอเวอร์เลย์ ใช้ เอกสาร Restream API เมื่อโปรไฟล์ที่กำหนดเองทำงานได้แล้ว สำหรับการตั้งค่า Enhanced RTMP เฉพาะ YouTube ให้ทำตาม เวิร์กโฟลว์ YouTube ส่วนการเข้าถึงอินพุต ให้ใช้ RTMP Server เพื่อกำหนดค่าด้าน ingest
