คำถามมักเกิดขึ้น: จะเชื่อมต่อกล้อง ip กับ NVR ได้อย่างไรหากไม่ได้อยู่ในรายการความเข้ากันได้

มีสองตัวเลือก ONVIF และ RTSP

เริ่มจากโปรโตคอล ONVIF (Open Network Video Interface Forum)

ONVIF เป็นโปรโตคอลทั่วไปสำหรับการทำงานร่วมกันของกล้อง IP, NVR, ซอฟต์แวร์ในกรณีที่อุปกรณ์ทั้งหมดมาจากผู้ผลิตที่แตกต่างกัน ONVIF สามารถเปรียบเทียบได้กับ ภาษาอังกฤษเพื่อการสื่อสารระหว่างประเทศของประชาชน

ตรวจสอบให้แน่ใจว่าอุปกรณ์ที่เชื่อมต่อรองรับ ONVIF บนอุปกรณ์บางอย่าง ONVIF อาจถูกปิดใช้งานตามค่าเริ่มต้น
หรือปิดใช้งานการอนุญาต ONVIF ได้ ซึ่งหมายความว่าการเข้าสู่ระบบ / รหัสผ่านจะเป็นค่าเริ่มต้นเสมอ
โดยไม่คำนึงถึงชื่อล็อกอิน/รหัสผ่านสำหรับเว็บ

นอกจากนี้ยังเป็นที่น่าสังเกตว่าอุปกรณ์บางอย่างใช้พอร์ตแยกสำหรับการทำงานภายใต้โปรโตคอล ONVIF

ในบางกรณี รหัสผ่าน ONVIF อาจแตกต่างจากรหัสผ่านสำหรับการเข้าถึงเว็บ

มีอะไรให้บ้างเมื่อเชื่อมต่อผ่าน ONVIF?

การค้นพบอุปกรณ์

การถ่ายโอนข้อมูลวิดีโอ

รับและส่งข้อมูลเสียง

ควบคุม กล้อง PTZ(พีทีซี)

การวิเคราะห์วิดีโอ (เช่น การตรวจจับการเคลื่อนไหว)

ตัวเลือกเหล่านี้ขึ้นอยู่กับความเข้ากันได้ของเวอร์ชันโปรโตคอล ONVIF ในบางกรณี พารามิเตอร์บางตัวไม่พร้อมใช้งานหรือทำงานไม่ถูกต้อง

เค และ ใช้ ONVIF

ในผู้รับจดทะเบียน SNR และ Dahua โปรโตคอล ONVIFอยู่บนแท็บอุปกรณ์ระยะไกล สายผู้ผลิต

เลือกช่องสัญญาณที่จะเชื่อมต่ออุปกรณ์

จากแท็บผู้ผลิต เลือก ออนวิฟ

ระบุ ที่อยู่ IPอุปกรณ์

ร.ฟ.ทพอร์ตยังคงเป็นค่าเริ่มต้น

กล้องใช้ ออนวิฟ พอร์ต 8080
(ตั้งแต่ปี 2560 ในรุ่น ONVIF ใหม่ พอร์ตเปลี่ยนเป็น 80 สำหรับซีรี่ส์ Alpha, Mira)
กล้องออมนี่ ฐานใช้ ออนวิฟ พอร์ต 80ในผู้รับจดทะเบียนระบุว่าเป็นพอร์ต HTTP

ชื่อ

รหัสผ่านตามพารามิเตอร์ของอุปกรณ์

ช่องระยะไกลค่าเริ่มต้นคือ 1 หากอุปกรณ์เป็นแบบหลายช่อง หมายเลขช่องจะถูกระบุ

บัฟเฟอร์ถอดรหัส— การบัฟเฟอร์สตรีมวิดีโอพร้อมค่าเวลา

ประเภทเซิร์ฟเวอร์มีตัวเลือก TCP, UDP Schedule

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

ซึ่งแตกต่างจาก TCP กปปสไม่ได้สร้างการเชื่อมต่อเบื้องต้น แต่เพียงเริ่มส่งข้อมูลแทน UDP ไม่ติดตามข้อมูลที่ได้รับและไม่ทำซ้ำในกรณีที่ข้อมูลสูญหายหรือผิดพลาด

UDP มีความน่าเชื่อถือน้อยกว่า TCP แต่ในทางกลับกัน มันให้การสตรีมที่เร็วขึ้นเนื่องจากไม่มีการส่งซ้ำของแพ็กเก็ตที่สูญหาย

กำหนดการ- การตรวจจับประเภทอัตโนมัติ

นี่คือลักษณะของอุปกรณ์ที่เชื่อมต่อใน Dahua

สถานะสีเขียวหมายความว่า DVR และกล้องเชื่อมต่อสำเร็จ

สถานะสีแดงหมายถึงมีปัญหาในการเชื่อมต่อ ตัวอย่างเช่น พอร์ตการเชื่อมต่อไม่ถูกต้อง

วิธีที่สองในการเชื่อมต่อคือ ร.ฟ.ท(โปรโตคอลการสตรีมตามเวลาจริง)

ร.ฟ.ทโปรโตคอลการสตรีมแบบเรียลไทม์ที่อธิบายคำสั่งสำหรับควบคุมสตรีมวิดีโอ

ด้วยความช่วยเหลือของคำสั่งเหล่านี้ สตรีมวิดีโอจะออกอากาศจากต้นทางไปยังผู้รับ

เช่น จากกล้อง IP ไปยัง DVR หรือเซิร์ฟเวอร์

มีอะไรให้บ้างเมื่อเชื่อมต่อผ่าน RTSP?

การถ่ายโอนข้อมูลวิดีโอ

รับและส่งข้อมูลเสียง

ข้อได้เปรียบของโปรโตคอลการถ่ายโอนนี้โดยไม่จำเป็นต้องมีความเข้ากันได้ของเวอร์ชัน

ปัจจุบัน RTSP ได้รับการสนับสนุนโดยกล้อง IP และ NVR เกือบทั้งหมด

ข้อบกพร่องโปรโตคอลคือไม่มีสิ่งอื่นใดนอกจากการส่งข้อมูลวิดีโอและเสียง

มาดูตัวอย่างการเชื่อมต่อกล้องกันถึง และ ใช้ RTSP

ร.ฟ.ทอยู่บนแท็บอุปกรณ์ระยะไกล สายผู้ผลิต ในนายทะเบียน SNR และ Dahua จะแสดงเป็นทั่วไป

เลือกช่องสัญญาณที่จะเชื่อมต่ออุปกรณ์

ที่อยู่ URL- ที่นี่เราป้อนสตริงข้อความค้นหาที่กล้องส่งคืน ขั้นพื้นฐาน RTSP สตรีมจาก สูง ปณิธาน.

URL เสริม - ที่นี่ ป้อนสตริงข้อความค้นหาที่กล้องส่งคืน เพิ่มเติม RTSP สตรีมจาก ความละเอียดต่ำ.

ตัวอย่างคำขอ:

rtsp://172.16.31.61/1 สตรีมหลัก

rtsp://172.16.31.61/2 สตรีมเสริม

ทำไมคุณถึงต้องการสตรีมเพิ่มเติม

บนจอภาพเฉพาะที่เชื่อมต่อกับเครื่องบันทึกหลายภาพ เครื่องบันทึกจะใช้เธรดพิเศษเพื่อประหยัดทรัพยากร ตัวอย่างเช่นในภาพขนาดเล็ก 16 หน้าต่างไม่จำเป็นต้องถอดรหัสความละเอียด Full HD เลย D1 ก็เพียงพอแล้ว ถ้าคุณเปิดหน้าต่าง 1/4/8 ในกรณีนี้ สตรีมหลักจะถูกถอดรหัสด้วยความละเอียดสูง

ชื่อตามพารามิเตอร์ของอุปกรณ์

รหัสผ่านตามพารามิเตอร์ของอุปกรณ์

บัฟเฟอร์ถอดรหัสการบัฟเฟอร์สตรีมวิดีโอพร้อมค่าเวลา

ประเภทเซิร์ฟเวอร์- TCP, UDP, กำหนดการ (คล้ายกับโปรโตคอล ONVIF)

บทความนี้ตอบคำถามทั่วไปเช่น:

กล้อง IP เข้ากันได้กับ NVR หรือไม่

แล้วถ้าเข้ากันได้จะเชื่อมยังไง!?

โปรโตคอล RTSP

RTSP (Real Time Streaming Protocol หรือในภาษารัสเซีย โปรโตคอลการสตรีมตามเวลาจริง) เป็นโปรโตคอลแอปพลิเคชันที่อธิบายคำสั่งสำหรับควบคุมสตรีมวิดีโอ ด้วยคำสั่งเหล่านี้ เราสามารถ "สั่ง" กล้องหรือเซิร์ฟเวอร์ เช่น เริ่มแพร่ภาพสตรีมวิดีโอ ตัวอย่างคำขอเริ่มเล่นมีลักษณะดังนี้: PLAY rtsp://192.168.0.200/h264 RTSP/1.0

นั่นคือ RTSP เป็นเพียงชุดคำสั่งสำหรับควบคุมสตรีมวิดีโอ มาทำการทดลองกันเถอะ ในการทำเช่นนี้ เราจำเป็นต้องมีกล้อง IP ที่รองรับโปรโตคอล RTSP และที่อยู่ RTSP ที่อยู่นี้มีลักษณะดังนี้ rtsp:// /mpeg. ดูได้จากคู่มือกล้องหรือในคำอธิบาย API เพื่อความสะดวก เราจะแสดงรายการที่อยู่ RTSP ของกล้องยอดนิยมจำนวนหนึ่งในตาราง หลังจากที่เราทราบที่อยู่ RTSP ของกล้องแล้ว เราจะเปิดโปรแกรมเล่นมาตรฐานที่รองรับ RTSP สามารถเป็นหนึ่งในโปรแกรมต่อไปนี้: Windows Media Player, QuickTime, Media ผู้เล่นคลาสสิก.VLC เครื่องเล่นสื่อ, เรียลเพลเยอร์ , เอ็มเพลเยอร์ เราเลือกควิกไทม์ เปิดเมนู "ไฟล์ > เปิด URL" และป้อนที่อยู่ RTSP ของเรา หลังจากนั้น QuickTime จะเชื่อมต่อกับกล้องและเล่น "วิดีโอสด" อุปกรณ์บันทึกที่ทำงานในระบบเฝ้าระวังวิดีโอ IP รับวิดีโอจากกล้องไม่ว่าจะใช้โปรโตคอล HTTP นั่นคือวิธีเดียวกับที่เราดาวน์โหลดภาพ JPEG จากเว็บไซต์หรือสตรีมผ่าน RTSP นั่นคือวิธีเดียวกับที่เราได้รับโดยใช้มาตรฐาน ผู้เล่นในตัวอย่างสุดท้าย ในการตั้งค่าของกล้อง IP ตัวเลือกการถ่ายโอนข้อมูลแบบสตรีมมิ่งสามารถอ้างอิงเป็น RTSP over TCP, RTSP over UDP หรือเรียกง่ายๆ ว่า RTP ดังนั้น RTSP จึงเป็นชุดคำสั่งสำหรับควบคุมโฟลว์ แต่ตัวย่ออื่น ๆ หมายถึงอะไร: TCP, UDP, RTP TCP, UDP และ RTP เป็นกลไกการขนส่ง (โปรโตคอล) ที่ส่งวิดีโอจริงๆ

โปรโตคอล TCP

สมมติว่าเราเลือกวิธี RSTP ผ่าน TCP และต้องการเริ่มส่งสตรีมวิดีโอ จะเกิดอะไรขึ้นในระดับกลไกการขนส่ง? ก่อนหน้านี้ ด้วยความช่วยเหลือของหลายคำสั่ง การเชื่อมต่อจะถูกสร้างขึ้นระหว่างผู้ส่งและผู้รับ หลังจากนั้น การถ่ายโอนข้อมูลวิดีโอจะเริ่มขึ้น ในขณะเดียวกัน กลไก TCP

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

UDP เป็นอีกทางเลือกหนึ่งในการขนส่ง โปรโตคอล TCP. ซึ่งแตกต่างจาก TCP ตรง UDP ไม่ได้สร้างการเชื่อมต่อล่วงหน้า แต่เพียงแค่เริ่มส่งข้อมูลแทน UDP ไม่ทำให้แน่ใจว่าได้รับข้อมูลแล้วและไม่ทำซ้ำหากชิ้นส่วนขาดหายไปหรือได้รับโดยมีข้อผิดพลาด UDP น้อยลง

เชื่อถือได้มากกว่า TCP แต่ในทางกลับกัน มันให้การสตรีมที่เร็วกว่าเนื่องจากไม่มีกลไกสำหรับการส่งแพ็กเก็ตที่สูญหายซ้ำ ความแตกต่างระหว่างโปรโตคอล TCP และ UTP สามารถแสดงได้จากตัวอย่างต่อไปนี้ เพื่อนสองคนพบกัน ตัวเลือก TCP:

อีวาน: สวัสดี! เรามาคุยกันดีไหม” (สร้างการเชื่อมต่อแล้ว)
ไซมอน: "สวัสดี! เถอะ!" (สร้างการเชื่อมต่อแล้ว)
อีวาน: “เมื่อวานฉันอยู่ในร้าน คุณเข้าใจไหม?" (การถ่ายโอนข้อมูล)
ไซมอน: "ใช่!" (คอนเฟิร์ม)
อีวาน: “พวกเขากำลังขนอุปกรณ์ใหม่ คุณเข้าใจไหม?" (การถ่ายโอนข้อมูล)
เซมยอน: "ไม่" (ยืนยัน)
อีวาน: “พวกเขากำลังขนอุปกรณ์ใหม่ คุณเข้าใจไหม?" (ส่งสัญญาณซ้ำ)
ไซมอน: "ใช่!" (คอนเฟิร์ม)
อีวาน: “พรุ่งนี้ฉันจะไปที่นั่นอีกครั้ง คุณเข้าใจไหม?" (การถ่ายโอนข้อมูล)
ไซมอน: "ใช่!" (คอนเฟิร์ม)
ตัวแปร UDP
อีวาน: สวัสดี! ฉันไปที่ร้านเมื่อวานนี้” (การส่งข้อมูล)
อีวาน: “พวกเขากำลังขนถ่ายอุปกรณ์ใหม่” (การส่งข้อมูล)
อีวาน: “พรุ่งนี้ฉันจะไปที่นั่นอีกครั้ง” (การส่งข้อมูล)
อีวาน: "ฉันขอราคาคุณได้" (การส่งข้อมูล)
อีวาน: "พวกเขาสัญญาว่าจะได้รับส่วนลดสำหรับปริมาณที่ดี" (การส่งข้อมูล)
อีวาน: "ถ้าคุณต้องการโทรหา - เราจะไปด้วยกัน" (การส่งข้อมูล)
เซมยอน: "ใช่ ฉันจะโทรหา" (การส่งข้อมูล)

คุณยังสามารถเห็นความแตกต่างในโปรโตคอลได้โดยทำการทดลองต่อไปนี้ ลองตั้งค่ากล้องเป็น RTSP ผ่านโหมด TCP แล้วโบกมือที่หน้าเลนส์ คุณจะเห็นการหน่วงเวลาบนหน้าจอมอนิเตอร์ ตอนนี้รันการทดสอบเดียวกันใน RTSP ผ่านโหมด UDP ความล่าช้าจะน้อยลง มีหลายปัจจัยที่ส่งผลต่อเวลาหน่วง: รูปแบบการบีบอัด พลังของคอมพิวเตอร์ โปรโตคอลการส่ง และคุณลักษณะของซอฟต์แวร์ที่เกี่ยวข้องกับการถอดรหัสวิดีโอ

RTP (Real-time Transport Protocol) หรือโปรโตคอลการขนส่งตามเวลาจริงในภาษารัสเซีย โปรโตคอลนี้ได้รับการออกแบบมาโดยเฉพาะเพื่อส่งทราฟฟิกตามเวลาจริง ช่วยให้คุณตรวจสอบการซิงโครไนซ์ข้อมูลที่ส่ง ปรับลำดับการส่งแพ็คเก็ต ดังนั้นจึงเหมาะสำหรับการส่งข้อมูลวิดีโอและเสียง โดยทั่วไป ควรใช้ RTP หรือ UDP เพื่อส่งวิดีโอสตรีม การทำงานผ่าน TCP นั้นสมเหตุสมผลก็ต่อเมื่อเราต้องทำงานกับเครือข่ายที่มีปัญหา เนื่องจากโปรโตคอล TCP จะสามารถแก้ไขข้อผิดพลาดและความล้มเหลวที่เกิดขึ้นระหว่างการถ่ายโอนข้อมูลได้

RTSP (โปรโตคอลการสตรีมแบบเรียลไทม์)เป็นโปรโตคอลการสตรีมตามเวลาจริงที่มีชุดของ คำสั่งพื้นฐานเพื่อควบคุมสตรีมวิดีโอ

การเชื่อมต่อแหล่ง RTSP และกล้อง IP ในการประชุมทางวิดีโอ

โปรโตคอล RTSP ช่วยให้ผู้ใช้ TrueConf สามารถเชื่อมต่อกับกล้องวิดีโอ IP และแหล่งเนื้อหาสื่ออื่น ๆ ที่ออกอากาศโดยใช้โปรโตคอลนี้เพื่อตรวจสอบวัตถุระยะไกล นอกจากนี้ ผู้ใช้สามารถเชื่อมต่อกับกล้องดังกล่าวเพื่อเผยแพร่ภาพระหว่างการประชุมทางวิดีโอ

ด้วยการรองรับโปรโตคอล RTSP ผู้ใช้เซิร์ฟเวอร์ TrueConf ไม่เพียงแต่สามารถเชื่อมต่อกับกล้อง IP เท่านั้น แต่ยังถ่ายทอดการประชุมทางวิดีโอไปยังเครื่องเล่น RTSP และเซิร์ฟเวอร์มีเดียได้อีกด้วย อ่านเพิ่มเติมเกี่ยวกับการออกอากาศ RTSP

ประโยชน์ของการใช้กล้อง IP กับโซลูชันซอฟต์แวร์ TrueConf

• ด้วยการติดตั้งกล้อง IP ในสำนักงานหรือเวิร์กช็อปอุตสาหกรรมและเชื่อมต่อกับกล้องในเวลาใดก็ได้ที่สะดวก คุณสามารถตรวจสอบกระบวนการผลิตของบริษัทของคุณได้
• คุณสามารถดำเนินการตรวจสอบวัตถุระยะไกลได้ตลอด 24 ชั่วโมง ตัวอย่างเช่น หากคุณกำลังไปเที่ยวพักผ่อนและไม่ต้องการออกจากอพาร์ทเมนต์ของคุณโดยไม่มีใครดูแล เพียงติดตั้งกล้อง IP หนึ่งตัวขึ้นไปที่นั่น ด้วยการโทรหาหนึ่งในกล้องเหล่านี้จากพีซีของคุณโดยติดตั้งแอปพลิเคชันไคลเอ็นต์ TrueConf คุณสามารถเชื่อมต่อกับอพาร์ทเมนต์ของคุณได้ตลอดเวลาและดูว่าเกิดอะไรขึ้นที่นั่นแบบเรียลไทม์
• แอปพลิเคชันไคลเอนต์ TrueConf สำหรับ Windows, Linux และ macOS ช่วยให้ผู้ใช้ทุกคนมีความสามารถในการบันทึกการประชุมทางวิดีโอ ซึ่งคุณสามารถบันทึกเหตุการณ์ใด ๆ ในระหว่างการเฝ้าระวังวิดีโอและรับเอกสารหลักฐานจากเหตุการณ์เหล่านั้นได้

จากข้อมูลบางส่วนจนถึงปัจจุบันทั่วโลกได้ติดตั้ง หลายร้อยล้านกล้อง IP สำหรับการเฝ้าระวังวิดีโอ อย่างไรก็ตาม ความล่าช้าในการเล่นวิดีโอนั้นยังห่างไกลจากทั้งหมด ตามกฎแล้วการเฝ้าระวังวิดีโอจะเกิดขึ้นแบบ "คงที่" - สตรีมจะถูกบันทึกในที่เก็บข้อมูลและสามารถวิเคราะห์การเคลื่อนไหวได้ สำหรับการเฝ้าระวังด้วยวิดีโอ โซลูชันซอฟต์แวร์และฮาร์ดแวร์จำนวนมากได้รับการพัฒนาซึ่งทำงานได้ดี

ในบทความนี้ เราจะพิจารณาแอปพลิเคชันที่แตกต่างกันเล็กน้อย กล้องไอพีกล่าวคือใช้ในการออกอากาศทางออนไลน์หากจำเป็น ความล่าช้าในการสื่อสารต่ำ

ก่อนอื่น เรามาทำความเข้าใจเกี่ยวกับความเข้าใจผิดที่อาจเกิดขึ้นเกี่ยวกับคำศัพท์เกี่ยวกับเว็บแคมและกล้อง IP

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

กล้องไอพีเป็นอุปกรณ์แบบสแตนด์อโลนที่มีการ์ดเครือข่ายและตัวประมวลผลของตัวเองเพื่อบีบอัดวิดีโอที่ถ่ายและส่งไปยังเครือข่าย ดังนั้น กล้อง IP จึงเป็นมินิคอมพิวเตอร์แบบสแตนด์อโลนที่เชื่อมต่อกับเครือข่ายอย่างสมบูรณ์และไม่จำเป็นต้องเชื่อมต่อกับอุปกรณ์อื่น และสามารถแพร่ภาพไปยังเครือข่ายได้โดยตรง

เวลาแฝงต่ำ(เวลาแฝงต่ำ) เป็นข้อกำหนดที่ค่อนข้างหายากสำหรับกล้อง IP และการออกอากาศออนไลน์ ความต้องการในการทำงานโดยมีเวลาแฝงต่ำจะปรากฏขึ้น ตัวอย่างเช่น หากแหล่งที่มาของสตรีมวิดีโอโต้ตอบกับผู้ชมของสตรีมนี้อย่างแข็งขัน

ส่วนใหญ่แล้ว เวลาแฝงที่ต่ำเป็นสิ่งจำเป็นในกรณีการใช้งานเกม ตัวอย่าง ได้แก่ การประมูลวิดีโอสด คาสิโนวิดีโอดีลเลอร์สด รายการทีวีแบบโต้ตอบสดกับโฮสต์ รีโมทควอดคอปเตอร์ ฯลฯ

ตัวแทนจำหน่ายคาสิโนออนไลน์สดในที่ทำงาน

ตามกฎแล้วกล้อง RTSP IP ทั่วไปจะกดวิดีโอเข้าไป H.264ตัวแปลงสัญญาณและสามารถทำงานในสองโหมดของการขนส่งข้อมูล: บรรณนิทัศน์และ แบบไม่สอดแทรก.

โหมด บรรณนิทัศน์เป็นที่นิยมและสะดวกที่สุดเพราะ ในโหมดนี้ ข้อมูลวิดีโอจะถูกส่งผ่านโปรโตคอล TCP ภายใน การเชื่อมต่อเครือข่ายไปที่กล้อง ในการเผยแพร่จากกล้อง IP ไปยังอินเตอร์ลีฟ คุณเพียงแค่ต้องเปิด/ส่งต่อพอร์ต RTSP หนึ่งพอร์ตของกล้อง (เช่น 554) ไปยังภายนอก ผู้เล่นจะต้องเชื่อมต่อกับกล้องผ่าน TCP และรับสตรีมที่อยู่ในการเชื่อมต่อนี้เท่านั้น

โหมดการทำงานที่สองของกล้องคือ แบบไม่สอดแทรก. ในกรณีนี้ การเชื่อมต่อจะถูกสร้างขึ้นโดยใช้โปรโตคอล RTSP/TCPและทราฟฟิกแยกกันอยู่แล้วตามโปรโตคอล ร.ฟ.ท./ปชปนอกช่อง TCP ที่สร้างขึ้น

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

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

ดังนั้น เพื่อที่จะถ่ายวิดีโอจากกล้องโดยมีความหน่วงน้อยที่สุด คุณจำเป็นต้องใช้ ไม่แทรกโหมดและรับทราฟฟิกวิดีโอผ่าน UDP

เบราว์เซอร์ไม่รองรับสแต็กโปรโตคอล RTSP/UDP โดยตรง แต่รองรับสแต็กโปรโตคอลเทคโนโลยีแบบฝัง WebRTC.

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

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

เซิร์ฟเวอร์รับสตรีมจากกล้อง IP ไปยังตัวมันเอง ร.ฟ.ท./ปชปและมอบให้กับเบราว์เซอร์ที่เชื่อมต่อผ่าน WebRTC

เทคโนโลยี WebRTC ทำงานตามโปรโตคอล กปปสและทำให้มีความหน่วงต่ำในทิศทาง เซิร์ฟเวอร์ > เบราว์เซอร์. กล้อง IP ยังทำงานบนโปรโตคอล ร.ฟ.ท./ปชปและให้ความหน่วงต่ำในทิศทาง กล้อง > เซิร์ฟเวอร์.

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

ในทางกลับกัน เมื่อใช้เซิร์ฟเวอร์ จะเปิดใช้งานขาการสื่อสารสองขา:
1) ระหว่างผู้ชมและเซิร์ฟเวอร์
2) ระหว่างเซิร์ฟเวอร์และกล้อง
โทโพโลยีดังกล่าวมี "คุณลักษณะ" หรือ "ข้อผิดพลาด" หลายประการ เราแสดงรายการไว้ด้านล่าง

ข้อผิดพลาด #1 - ตัวแปลงสัญญาณ

ตัวแปลงสัญญาณที่ใช้อาจเป็นอุปสรรคต่อเวลาแฝงต่ำและทำให้ประสิทธิภาพของระบบโดยรวมลดลง

ตัวอย่างเช่น หากกล้องส่งสตรีมวิดีโอ 720p ใน H.264 และเบราว์เซอร์ Chrome เชื่อมต่อกับ สมาร์ทโฟนแอนดรอยด์โดยรองรับเฉพาะ VP8 เท่านั้น

เมื่อเปิดใช้การแปลงรหัส จะต้องสร้างเซสชันการแปลงรหัสสำหรับกล้อง IP ที่เชื่อมต่อแต่ละตัว ซึ่งจะถอดรหัส H.264และเข้ารหัสใน VP8. ในกรณีนี้ เซิร์ฟเวอร์ที่มีโปรเซสเซอร์ดูอัลแบบ 16 คอร์จะสามารถให้บริการกล้อง IP ได้ 10-15 ตัวเท่านั้น โดยมีการคำนวณกล้องประมาณ 1 ตัวต่อคอร์จริง

ดังนั้น หากความจุของเซิร์ฟเวอร์ไม่อนุญาตให้แปลงรหัสตามจำนวนกล้องที่วางแผนไว้ จึงควรหลีกเลี่ยงการแปลงรหัส ตัวอย่างเช่น ให้บริการเฉพาะเบราว์เซอร์ที่รองรับ H.264 และเสนอส่วนที่เหลือให้ใช้แบบเนทีฟ แอพมือถือสำหรับ iOS หรือ Android ที่รองรับตัวแปลงสัญญาณ H.264

คุณสามารถใช้ตัวเลือกเพื่อข้ามการแปลงรหัสในเบราว์เซอร์มือถือ ฮ.ล. แต่การสตรีม HTTP ไม่ได้มีเวลาแฝงต่ำและไม่สามารถใช้สำหรับการสตรีมแบบโต้ตอบได้ในขณะนี้

ข้อผิดพลาด #2 - บิตเรตของกล้องและการสูญเสีย

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

เพื่อกำจัดการสูญเสีย คุณต้องแน่ใจว่าสตรีมวิดีโอที่สร้างโดยกล้องมีอัตราบิตที่เหมาะกับแบนด์วิดท์ที่จัดสรรระหว่างกล้องและเซิร์ฟเวอร์

ข้อผิดพลาด #3 - บิตเรตของผู้ดูและการสูญเสีย

ผู้ดูการออกอากาศแต่ละคนที่เชื่อมต่อกับเซิร์ฟเวอร์ก็มีบางอย่างเช่นกัน ปริมาณงานในการดาวน์โหลด

หากกล้อง IP ส่งสตรีมที่เกินความสามารถของช่องผู้ชม (เช่น กล้องจะส่ง 1 เมกะบิตต่อวินาทีและผู้ดูสามารถยอมรับได้เท่านั้น 500 กิโลบิตต่อวินาที) จากนั้นจะมีการสูญเสียจำนวนมากในช่องนี้ และเป็นผลให้วิดีโอสลักเสลาหรือสิ่งประดิษฐ์ที่แข็งแกร่ง

ในกรณีนี้ มีสามตัวเลือก:

1. แปลงรหัสสตรีมวิดีโอทีละรายการสำหรับผู้ดูแต่ละคนตามบิตเรตที่กำหนด
2. Transcode สตรีมไม่ได้สำหรับแต่ละรายการที่เชื่อมต่อ แต่สำหรับกลุ่มผู้ชมกลุ่มหนึ่ง
3. เตรียมการสตรีมจากกล้องล่วงหน้าด้วยความละเอียดและอัตราบิตที่หลากหลาย

ตัวเลือกแรกการแปลงรหัสสำหรับแต่ละวิวเวอร์ไม่เหมาะสมเนื่องจากจะใช้ทรัพยากร CPU หมดแล้วกับผู้ชมที่เชื่อมต่อ 10-15 ตัว แม้ว่าควรสังเกตว่าตัวเลือกนี้ให้ความยืดหยุ่นสูงสุดกับโหลด CPU สูงสุด เหล่านั้น. ซึ่งเหมาะอย่างยิ่ง ตัวอย่างเช่น หากคุณกำลังสตรีมไปยังผู้คนที่กระจายตามพื้นที่ทางภูมิศาสตร์เพียง 10 คน แต่ละคนจะได้รับบิตเรตไดนามิก และแต่ละคนต้องการการหน่วงเวลาขั้นต่ำ

ตัวเลือกที่สองคือการลดภาระบน CPU ของเซิร์ฟเวอร์โดยใช้กลุ่มการแปลงรหัส เซิร์ฟเวอร์สร้างหลายกลุ่มตามบิตเรต ตัวอย่างเช่น สองกลุ่ม:

• 200 กิโลบิตต่อวินาที
• 1 เมกะบิตต่อวินาที

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

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

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

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

ตารางแสดงให้เห็นว่าเราสามารถเปลี่ยนภาระการแปลงรหัสไปยังกล้องหรือถ่ายโอนการแปลงรหัสไปยังเซิร์ฟเวอร์ ตัวเลือก 2 และ 3 ดูเหมือนจะเหมาะสมที่สุด

ทดสอบ RTSP เป็น WebRTC

ถึงเวลาทำการทดสอบเพื่อเปิดเผยภาพที่แท้จริงของสิ่งที่เกิดขึ้น ลองใช้กล้อง IP จริงและทดสอบเพื่อวัดเวลาแฝงในการออกอากาศ

ลองนำกล้อง IP โบราณมาทดสอบดู ดีลิงค์ DCS-2103ด้วยการสนับสนุน ร.ฟ.ทและตัวแปลงสัญญาณ H.264 และ G.711.

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

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

เราไปที่เว็บอินเตอร์เฟสของกล้องและตั้งค่าตัวแปลงสัญญาณและความละเอียดสำหรับการทดสอบ:

ต่อไปเราไปที่ การตั้งค่าเครือข่ายและค้นหาที่อยู่ RTSP ของกล้อง ในกรณีนี้ ที่อยู่ RTSP live1.sdp, เช่น. กล้องได้ที่ rtsp://192.168.1.37/live1.sdp

สามารถตรวจสอบการเข้าถึงกล้องได้อย่างง่ายดาย เครื่องเล่น VLC. สื่อ - เปิดสตรีมเครือข่าย

เราตรวจสอบให้แน่ใจว่ากล้องใช้งานได้และให้วิดีโอผ่าน RTSP

เราจะใช้ Web Call Server 5 เป็นเซิร์ฟเวอร์ในการทดสอบ นี่คือเซิร์ฟเวอร์สตรีมมิ่งพร้อมการสนับสนุน RTSP และ WebRTCโปรโตคอล มันจะเชื่อมต่อกับกล้อง IP โดย ร.ฟ.ทและนำสตรีมวิดีโอ เผยแพร่สตรีมเพิ่มเติมโดย WebRTC.

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

rtsp_interleaved_mode=เท็จ
ค่าติดตั้งนี้ถูกเพิ่มในคอนฟิก flashphoner.properties และต้องรีสตาร์ทเซิร์ฟเวอร์:

บริการ webcallserver รีสตาร์ท
ดังนั้นเราจึงมีเซิร์ฟเวอร์ที่ทำงานตามรูปแบบ non-interleaved รับแพ็กเก็ตจากกล้อง IP ผ่าน UDP แล้วกระจายผ่าน WebRTC (UDP)

เซิร์ฟเวอร์ทดสอบตั้งอยู่บนเซิร์ฟเวอร์ VPS ที่ตั้งอยู่ในศูนย์ข้อมูลแฟรงค์เฟิร์ต มี 2 คอร์และ RAM 2 กิกะไบต์

กล้องอยู่ในเครือข่ายท้องถิ่นที่ 192.168.1.37

ดังนั้นสิ่งแรกที่เราต้องทำคือส่งต่อพอร์ต 554 ไปที่ 192.168.1.37 สำหรับขาเข้า ทีซีพี/อาร์ทีเอสพีเพื่อให้เซิร์ฟเวอร์สามารถเชื่อมต่อกับกล้อง IP ของเราได้ ในการดำเนินการนี้ ให้เพิ่มกฎเพียงข้อเดียวในการตั้งค่าเราเตอร์:

กฎบอกให้เราเตอร์เปลี่ยนเส้นทางการรับส่งข้อมูลขาเข้าทั้งหมดบนพอร์ต 554 ไปยัง 37 - ที่อยู่ IP

หากคุณมี NAT ที่เป็นมิตรและคุณทราบที่อยู่ IP ภายนอก คุณสามารถเริ่มการทดสอบกับเซิร์ฟเวอร์ได้

โปรแกรมเล่นตัวอย่างมาตรฐานในเบราว์เซอร์ Google Chromeดูเหมือนว่า:

ในการเริ่มเล่นสตรีม RTSP คุณเพียงแค่ป้อนที่อยู่ในฟิลด์ ลำธาร.
ในกรณีนี้ ที่อยู่สตรีม: rtsp://ip-cam/live1.sdp
ที่นี่ กล้องไอพีนี่คือที่อยู่ IP ภายนอกของกล้องของคุณ เซิร์ฟเวอร์จะพยายามสร้างการเชื่อมต่อกับที่อยู่นี้

การทดสอบเวลาแฝง VLC กับ WebRTC

หลังจากที่เรากำหนดค่ากล้อง IP และทดสอบแล้ว วี.แอล.ซีตั้งค่าเซิร์ฟเวอร์และทดสอบ ร.ฟ.ทไหลผ่านเซิร์ฟเวอร์ด้วยการจัดจำหน่ายโดย WebRTCในที่สุดเราก็สามารถเปรียบเทียบความล่าช้าได้

ในการทำเช่นนี้เราจะใช้ตัวจับเวลาที่จะแสดงเศษเสี้ยววินาทีบนหน้าจอมอนิเตอร์ เปิดตัวจับเวลาและเล่นสตรีมวิดีโอพร้อมกัน VLC ในเครื่องและบน เบราว์เซอร์ไฟร์ฟอกซ์ผ่านเซิร์ฟเวอร์ระยะไกล

ปิงไปยังเซิร์ฟเวอร์ 100ms.
ปิงในเครื่อง 1 มิลลิวินาที.

การทดสอบตัวจับเวลาครั้งแรกมีลักษณะดังนี้:
บนพื้นหลังสีดำคือตัวจับเวลาดั้งเดิม ซึ่งแสดงการหน่วงเวลาเป็นศูนย์ ซ้าย วี.แอล.ซี, ด้านขวา ไฟร์ฟอกซ์รับ WebRTCสตรีมจากเซิร์ฟเวอร์ระยะไกล

	ศูนย์	วี.แอล.ซี	ไฟร์ฟอกซ์, WCS
เวลา	50.559	49.791	50.238
ms แฝง	0	768	321

ในการทดสอบนี้ เราเห็นความล่าช้า วี.แอล.ซีสองเท่าของความล่าช้า Firefox + เว็บคอลเซิร์ฟเวอร์แม้ว่าวิดีโอใน VLC จะเล่นบนเครือข่ายท้องถิ่นและวิดีโอที่แสดงใน Firefox จะส่งผ่านเซิร์ฟเวอร์ในศูนย์ข้อมูลในเยอรมนีและส่งคืน ความคลาดเคลื่อนนี้อาจเกิดจากข้อเท็จจริงที่ว่า VLC ทำงานบน TCP (โหมดแทรกสลับ) และมีบัฟเฟอร์เพิ่มเติมสำหรับการเล่นวิดีโอที่ราบรื่น

เราถ่ายภาพเล็กน้อยเพื่อจับค่าการหน่วงเวลา