ระดับเนื้อหา: Overview / Implementation considerations
หลักการและการเลือกใช้
RTSP จัดการ session สื่อ ส่วน codec การส่งแพ็กเก็ต การถอดรหัส และ queue มีผลต่อความสดของภาพ Real-time ต้องนิยาม deadline ของงาน ไม่ใช่เรียกวิดีโอที่แสดงต่อเนื่องว่าไร้ความหน่วง
ภาพที่แสดงลื่นอาจเป็นภาพเก่าซึ่งพักไว้ในคิว RTSP เป็นวิธีจัดการการเชื่อมต่อสื่อ ส่วน codec เป็นวิธีเข้ารหัสและถอดภาพ การรับข้อมูลได้ต่อเนื่องจึงไม่บอกอายุภาพ ต้องรู้ว่าภาพถ่ายเมื่อใดและผลพร้อมใช้เมื่อใด Deadline คือเวลาขอบเขตที่งานต้องได้ผล ซึ่งควรกำหนดจากการตัดสินของผู้ใช้ ไม่จากความเร็วเฉลี่ยของตัวประมวลผลเพียงอย่างเดียว
Queue คือคิวพักงาน หากภาพเข้ามาเร็วกว่าที่อ่านได้ อายุข้อมูลจะเพิ่มแม้แต่ละภาพคำนวณเร็ว วิศวกรต้องเลือกระหว่างเก็บครบกับรักษาความสด พร้อมวิธีระบุเฟรมที่ทิ้งและสถานะ stale หรือข้อมูลเก่าเกินใช้ ตรวจความสัมพันธ์เวลา capture receive และ output แยกกัน โดยระบุแหล่งนาฬิกาและการซิงก์ ไม่หักเวลาข้ามเครื่องที่ไม่ตรงกันแล้วสรุปความหน่วงอย่างแน่นอน
เลื่อนแผนภาพซ้าย–ขวาเพื่อดูรายละเอียดครบทุกส่วน
ตัวอย่างในบริบทอุตสาหกรรม
ตัวอย่างเชิงออกแบบ: ตัวอ่านเกจเลือกเฟรมล่าสุดที่มีเวลาถ่ายน่าเชื่อถือ ทิ้งเฟรมเก่าตามนโยบาย และรายงาน stale เมื่อกล้องค้าง แม้ตัวรับยังเชื่อมต่ออยู่
สมมติเครือข่ายช้าแล้วคิวมีภาพเกจเดิมสะสม เมื่อการเชื่อมต่อดีขึ้น ระบบอาจอ่านภาพเก่าได้ต่อเนื่องและดูเหมือนทำงานปกติ ผู้ใช้ควรเห็นอายุข้อมูลและสถานะ ไม่ใช้เวลาประมวลผลใหม่ทำให้ภาพเก่าดูสด หากงานเน้นค่าปัจจุบัน อาจเลือกภาพใหม่สุด แต่ถ้างานต้องเก็บเหตุสั้นครบ ต้องประเมินวิธีบันทึกแยกเพื่อไม่พลาดจากการทิ้งเฟรม
วิศวกรใช้ข้อมูลจำลองควบคุมเวลารับและการขาดภาพเพื่อทดสอบคิวจำกัด ตรวจการล้างข้อมูลเก่าหลัง reconnect และการกลับสู่สถานะพร้อมใช้เมื่อมีภาพใหม่จริง ไม่เพียงพอร์ตเปิด ตรวจว่าเฟรมที่เลือกตรงกับภาพอ้างอิงและเวลาที่ส่งออก หากเวลาถ่ายไม่มีหรือไม่น่าเชื่อถือ ต้องบอกข้อจำกัด ไม่สร้างตัวเลขอายุภาพที่ดูแน่นอนจากเวลารับแทนโดยไม่มีคำอธิบาย
ขั้นตอนศึกษาและทดลอง
- 1 วัดเวลาจาก capture decode inference ถึงปลายทางแยกช่วง
- 2 จำกัด queue และเลือกนโยบาย drop ตามว่าเน้นความสดหรือเก็บครบ
- 3 ทดสอบ jitter packet loss reconnect และการซิงก์นาฬิกา
วิธีประเมินและนิยามผล
รายงาน end-to-end age ของผล p50/p95 สัดส่วนเฟรมตก และ stale events คู่ throughput ระบุความคลาดของนาฬิกาเมื่อจับเวลาข้ามเครื่อง
Throughput คือจำนวนงานที่เสร็จต่อเวลา ต่างจากอายุข้อมูลที่ผู้ใช้ได้รับ p50 กับ p95 เป็นตำแหน่งเปอร์เซ็นไทล์ของค่าที่วัด ไม่ใช่คำรับรองว่าทุกผลทันเวลา ควรรายงานจำนวนตัวอย่าง ระยะวัด และเงื่อนไขงานพร้อมกัน รวมกรณีข้อมูลขาดและการฟื้น ไม่เลือกเฉพาะช่วงที่เครือข่ายดีเพื่อกล่าวว่าระบบตอบทันในทุกสถานการณ์
วิศวกรแยกเวลาถอดภาพ เตรียมข้อมูล อ่าน และส่งผล พร้อมตรวจจำนวนเฟรมเข้า ใช้ และทิ้งให้สอดคล้องกัน ทดสอบ jitter หรือเวลารับแกว่งกับข้อมูลจำลองที่ควบคุมได้ และตรวจความผิดจากนาฬิกา หากผลเก่าแต่ throughput สูงให้แก้คิว ไม่เลือกโมเดลใหม่เพียงอย่างเดียว การใช้ข้อกำหนด RTSP เป็นอ้างอิงเชื่อมต่อไม่ใช่การรับรองความหน่วงหรือคุณภาพผลิตภัณฑ์
ข้อจำกัดและกรณีผิดพลาด
FPS สูงไม่รับรองเฟรมสด GOP ยาวและ buffer อาจเพิ่มความหน่วง นโยบายทิ้งเฟรมอาจพลาดเหตุการณ์สั้น
GOP คือกลุ่มภาพที่การเข้ารหัสอาจอาศัยภาพอื่นเพื่อถอดกลับ การเริ่มรับหรือข้อมูลหายอาจต้องรอส่วนที่จำเป็น ไม่สรุปว่าเปิดการเชื่อมต่อแล้วมีภาพที่ใช้ได้ทันที การตั้งคิวเล็กช่วยจำกัดอายุแต่เพิ่มเฟรมทิ้ง ส่วนคิวใหญ่ช่วยรองรับช่วงช้าแต่เสี่ยงอ่านย้อนหลัง ต้องเลือกและทดสอบตามบทบาท ไม่ใช้คำว่า real-time กลบข้อแลกเปลี่ยนนี้
เวลาที่เชื่อถือไม่ได้ทำให้การประเมินอายุข้อมูลคลุมเครือ ต้องมีสถานะและขอบเขตใช้งานชัดเมื่อกล้องหรือนาฬิกาเปลี่ยน การ reconnect ต้องไม่ส่งค่าค้างเป็นค่าปัจจุบัน และไม่ทำให้เหตุซ้ำโดยไม่มีตัวระบุ ระบบสตรีมเป็นส่วนรับข้อมูล ไม่ยืนยันการรองรับกล้องรุ่นใดหรือเวลาตอบรับรองของผลิตภัณฑ์ในปัจจุบันหากยังไม่มีหลักฐานตรวจเส้นทางจริง
รายการตรวจสอบก่อนนำไปใช้
- แยก capture time กับ receive time หรือไม่
- มี stale timeout หรือไม่
- หลัง reconnect ล้าง queue เดิมหรือไม่