เราต้องการอุปกรณ์, เพื่อรับข้อมูลเกี่ยวกับวิดีโอกล้อง Full HD พร้อม SDI (อินเทอร์เฟซข้อมูลแบบอนุกรม) บนบรรทัดและเข้ารหัสข้อมูลในมาตรฐาน H.265. ข้อมูลที่บีบอัดจะต้องส่งในรูปแบบ DVB-T (การแพร่ภาพวิดีโอดิจิทัลภาคพื้นดิน) หรือมาตรฐาน DVB-S. เอาต์พุตแบบอะนาล็อกของโมดูลที่ออกแบบสามารถรับทั้งสัญญาณ I และ Q, เช่นเดียวกับสัญญาณมอดูเลต.
สารบัญ
Q: SDI Video Encoder ของคุณรองรับอินพุต TSI หรือไม่ / เอาท์พุต?
ก: บอร์ดเข้ารหัสที่มีอยู่ของเราไปยังบอร์ดมอดูเลชั่นจะส่งข้อมูลผ่านพอร์ตเครือข่าย. แทนที่จะเป็นอินเทอร์เฟซ TSI ที่คุณพูดถึง. ซึ่งไม่ส่งผลต่อการใช้เครื่องส่งไปยังเครื่องรับ. นี่คืออินเทอร์เฟซภายในของเครื่องส่งสัญญาณ.
Q: บอร์ดถอดรหัสตัวเข้ารหัสของคุณรองรับหรือไม่ 525 i50 ถึง 1080 P60 ในรูปแบบวิดีโอ?
ก: ขณะนี้บอร์ดเข้ารหัสวิดีโอ SDI ของเรารองรับ HD: 720p @ 23.98Hz/24Hz/25Hz/29.97Hz/30Hz/ 50Hz59.94Hz/60Hz และ 1080p @ 23.98Hz/24Hz/25Hz/29.97Hz/30Hz/50Hz/59.94Hz/60Hz. มันไม่สนับสนุน 525 รูปแบบวิดีโอ i50, โอเคไหม?
Q: SDI COFDM DVB-T H265 SDI Encoder RF ของคุณรองรับกำลังขับ 0~10dBm หรือไม่?
ก: จุดความถี่เอาต์พุตของคุณที่ต้องการตั้งแต่ 400Mhz ถึง 2800Mhz นั้นกว้างมาก.
เป็นเรื่องยากที่จะได้เอาต์พุต 0~10dBm ภายใต้จุดความถี่ที่กว้างเช่นนี้, และการเพิ่ม Power Amplifier บนบอร์ดจะช่วยเพิ่มการใช้พลังงานและความร้อน (คุณยังบอกอีกว่าไม่จำเป็นต้องมีพัดลมเพื่อกระจายความร้อน).
คุณยินดีที่จะเห็นด้วยกับสิ่งที่เรามีอยู่หรือไม่ -3 ถึง -10dBm จากนั้นเพิ่ม PA ของคุณเอง (ขยายอำนาจ)?
Q: มิติของตัวเข้ารหัส COFDM DVB-T H265 SDI ของคุณคือเท่าใด?
คุณมีคำขอมิติพิเศษหรือไม่? ขนาดที่มีอยู่ของเราคือ 70x45 มม.
ก: บอร์ดเข้ารหัสและถอดรหัสวิดีโอที่มีอยู่ของเราสามารถตอบสนองความต้องการของโครงการของคุณได้.
ความกังวลที่ใหญ่ที่สุดของวิศวกรของฉันคือบริษัทของคุณ, ในฐานะสมาชิกของอุตสาหกรรมการออกอากาศและโทรทัศน์มีข้อกำหนดค่อนข้างสูงสำหรับคุณภาพของภาพวิดีโอ.
บอร์ดเข้ารหัสวิดีโอของเราจะทำการบีบอัดแบบสูญเสียข้อมูลเพื่อความหน่วงต่ำ. คุณสามารถนำชุดตัวอย่างที่มีอยู่ไปทดสอบและยืนยันคุณภาพของภาพได้หรือไม่? หากคุณคิดว่าตัวอย่างของเราสามารถตอบสนองความต้องการของบริษัทของคุณได้, เราจะออกแบบและวาดบอร์ดใหม่ตามความต้องการของบริษัทของคุณ.
Q: คุณสามารถให้ข้อมูลเพิ่มเติมเกี่ยวกับ VBR ได้หรือไม่?
โดยการนำวิดีโอไปใช้กับ TX, พารามิเตอร์ VBR จะเปลี่ยนแปลงเมื่อเวลาผ่านไปและไม่ใช่ค่าคงที่. คุณสามารถให้ข้อมูลเพิ่มเติมเกี่ยวกับเรื่องนี้ได้หรือไม่?
ก: VBR คืออัตราบิตการเข้ารหัสวิดีโอที่ตัวส่งสัญญาณ. เนื่องจากภาพวิดีโอเปลี่ยนแปลงแบบไดนามิก, แน่นอนว่า VBR เป็นตัวแปร, แต่จะผันผวนตามอัตราบิตการเข้ารหัสที่กำหนดโดยระบบส่งสัญญาณ: 7.81*0.8=6.248Mbps.
Q: แม้จะมีที่เก็บข้อมูลแฟลชบนตัวรับสัญญาณของฉัน, REC OFF และ No Storage จะแสดงบนหน้าจอ. ทำไมสิ่งนี้ถึงเกิดขึ้น?
คุณกล่าวไว้ในคำอธิบาย: key2: ปุ่มสวิตช์สำหรับการบันทึกวิดีโอ, กดสั้น ๆ เพื่อเปลี่ยนสถานะ. ผู้รับจะตรวจสอบอุปกรณ์จัดเก็บข้อมูลโดยอัตโนมัติ (การ์ด micro SD หรือดิสก์ USB, การ์ด SD ลำดับความสำคัญ) หลังจากเปิดเครื่องและเริ่มบันทึกวิดีโอเมื่อเสียบอุปกรณ์จัดเก็บข้อมูล. เพียงกดปุ่มเพื่อหยุดหรือบันทึกอีกครั้ง.
ก: ระบบรับสัญญาณตรวจไม่พบแฟลชไดรฟ์ USB. แฟลชไดรฟ์ USB จะต้องได้รับการฟอร์แมตเป็นรูปแบบที่ระบบของเราสามารถจดจำได้.
Q: ทั้ง B1 และ B2 เป็นศูนย์. นี่แสดงว่ามี. 0 % อัตราความผิดพลาดในการกัด!!! ช่วงใดของพารามิเตอร์เหล่านี้ที่ยอมรับได้?
ก: การเกิดขึ้นของอัตราข้อผิดพลาดบิตอาจทำให้เกิดปัญหากับภาพวิดีโอ. เมื่ออัตราความผิดพลาดบิตมีน้อยมาก, มันจะไม่ส่งผลกระทบต่อเอฟเฟกต์ภาพวิดีโอ.
Q: ฉันสามารถปรับแต่งเนื้อหาหน้าจอโปรแกรมเมอร์ได้หรือไม่?
ก: เนื้อหาการแสดงผลของแผงการกำหนดค่า (โปรแกรมเมอร์) ไม่เปิดให้ลูกค้าทำการปรับเปลี่ยน.
Q: เหตุใดจึงไม่ตั้งโปรแกรมช่อง S2? ดูเหมือนว่าจูนเนอร์ตัวที่สองไม่ทำงานในขณะนี้.
ก: S2 หมายถึงการรับเสาอากาศ 2, ซึ่งสามารถทำงานได้ตามปกติ. ความถี่และแบนด์วิธเหมือนกัน s1 และ s2.
Q: เหตุใดเวลาแฝงที่ฉันคำนวณจึงมีมาก? มันอยู่รอบๆ 470 นางสาว.
ในคำอธิบายของคุณมา: คุณสมบัติปกติเริ่มต้นของโมดูลตัวรับของเราสามารถจับคู่กับโมดูลตัวส่งสัญญาณ H.265 ของเราได้. เวลาแฝงของวิดีโอ HD จากการป้อนข้อมูลของเครื่องส่งสัญญาณไปยังหน้าจอ HDMI ที่แสดงของเครื่องรับคือประมาณ 200ms ถึง 250ms.
ก: ความล่าช้าที่เราทดสอบคือประมาณ 250ms. คุณทดสอบมันได้อย่างไร? วิธีล่าช้าที่เราทดสอบ, กรุณาตรวจสอบ ลิงค์วีดีโอยูทูป.
Q: เครื่องส่งตัวเข้ารหัส SDI และโมดูลตัวรับตัวถอดรหัสของคุณมีเวลาแฝงเท่าใด?
ฉันจำได้ว่าคุณบอกว่าคุณได้ปรับโปรโตคอลให้เหมาะสมเพื่อให้มีเวลาแฝงที่ดีขึ้น. เนื่องจากฉันไม่ได้ใช้เวลาแฝง H.264 ที่รวดเร็วของคุณ (130 นางสาว) เราควรมีเวลาแฝงเท่าใดในการตั้งค่าของฉัน?
ก: คุณยืนยันว่าคุณต้องการรองรับ H265, แต่ไม่ใช่โหมดเวลาแฝงต่ำ H264. เพื่อให้ได้โหมดเวลาแฝงต่ำ, เครื่องรับจะต้องเปลี่ยนเป็นฮาร์ดแวร์ตัวรับอื่น, และจะต้องเบิร์นเฟิร์มแวร์ที่เกี่ยวข้องก่อนจัดส่ง.
Q: ฉันสามารถใช้เครื่องรับ COFDM ของคุณเพื่อรับช่องทีวี DVB-T ปกติได้หรือไม่?
คุณบอกว่าคุณเปลี่ยนโปรโตคอลวิดีโอเพื่อให้มีเวลาแฝงที่ดีขึ้นใน TX. ฉันสามารถใช้ RX ของคุณเป็น DVB-T เชิงพาณิชย์ได้หรือไม่? จะรับช่อง DVB-T ปกติได้อย่างไร?
ก: หากต้องการใช้เป็นเครื่องรับ DVB-T ปกติจริงๆ, เราต้องอัพเกรดเฟิร์มแวร์อื่น. (ลบการเข้ารหัสบนตัวเข้ารหัสและการถอดรหัสบนตัวถอดรหัส).
Q: ฉันจะใช้ฟังก์ชันเมนู OSD ของคุณบนเครื่องรับ COFDM ได้อย่างไร?
ในคำอธิบายของคุณมา:
โมดูลตัวรับสัญญาณยังมีฟังก์ชันการบันทึก DVR ด้วยการ์ด Micro SD หรือดิสก์ USB. โมดูลตัวรับสัญญาณยังเปิดใช้งานการสตรีมวิดีโอผ่าน USB สำหรับการถอดรหัสอุปกรณ์ Android ระยะไกล เช่น สมาร์ทโฟนหรือ Android PAD. ซึ่งช่วยให้ผู้ดูระยะไกลหลายคนสามารถตรวจสอบวิดีโอเดียวกันได้
พร้อมกัน. โมดูลตัวรับยังรองรับสตริงอักขระที่แสดงบนหน้าจอแสดงผลวิดีโอพร้อมกับวิดีโอพร้อมกันในโหมด OSD.
ก: ดู เอกสารออนไลน์ของ OSD.
Q: ฉันจะเปิดการเข้ารหัส AES ได้อย่างไร? ต้องใส่กุญแจตรงไหน.?
ก: แผงการกำหนดค่าสามารถแก้ไขและเปลี่ยนรหัสผ่านได้.
Q: ระบุคำถามรูปภาพข้อความคันธนู:
ก: ฟังก์ชันเสริมนี้จำเป็นสำหรับผลิตภัณฑ์อื่น (ฟังก์ชั่นพอร์ตเครือข่ายใช้เพื่อเชื่อมต่อกับลิงค์ไร้สายแบบสองทาง). โปรดละเว้นในใบสมัครของคุณ.
Q: การหน่วงเวลาของข้อมูล UART ในการส่งข้อมูลทางเดียวคือเท่าใด?
สำหรับข้อมูล UART จาก TX ถึง RX, คือข้อมูลที่ประมวลผลผ่านกระบวนการเข้ารหัสหรือส่งแบบเรียลไทม์? ฉันต้องการการถ่ายโอนข้อมูลแบบเรียลไทม์.
ก: ข้อมูลและวิดีโอจะถูกส่งพร้อมกันผ่านแพ็คเกจ cofdm ไร้สาย. ดังนั้นความล่าช้าจึงเหมือนกับวิดีโอ.
Q: สำหรับเครื่องส่งสัญญาณ. สามารถเปลี่ยน GI และ FEC และพารามิเตอร์อื่นตามตารางของคุณในคำอธิบายได้?
ก: ใช่.
Q: พลังที่แน่นอน ณ จุดนี้มาจากอะไร 1350 ไปยัง 1450 เมกะเฮิรตซ์? ฉันต้องการข้อมูลนี้เพื่อออกแบบ PA.
เอาต์พุตสูงสุดของย่านความถี่ 1350~1450 อยู่ที่ประมาณ -10±2dBm. ขอแนะนำให้ออกแบบ PA ตามอินพุต -15dBm. เครื่องส่งสัญญาณของเราสามารถปรับลงไปที่ -15dBm.
Q: โปรแกรมเมอร์ของคุณมีหน้าที่รีเซ็ตการคืนค่าจากโรงงานหรือไม่?
หากฉันเปลี่ยนพารามิเตอร์ด้านใดด้านหนึ่ง เช่น ความถี่ GI หรือ FEC หรือแบนด์วิดท์วิดีโอ, ฉันจะรีเซ็ตพารามิเตอร์ทั้งหมดในโหมดรีเซ็ตโรงงานได้อย่างไร? ฉันยังใหม่กับบอร์ดนี้, และฉันต้องเปลี่ยนพารามิเตอร์บางอย่างเพื่อให้บรรลุความปรารถนาของฉัน. แต่ฉันกลัวที่จะเปลี่ยนแปลงข้อมูลเริ่มต้น.
ก: เท็กซัสของเรา / โปรแกรมเมอร์ RX ไม่มีคุณสมบัติการรีเซ็ตเป็นค่าจากโรงงาน.
Q: ตัวเข้ารหัสอินพุตวิดีโอ SDI ของคุณรองรับ 1080i25/1080i30 หรือไม่?
รองรับ 1080i50 และ 1080i60, ไม่รองรับ 1080i25 หรือ 1080i30.
Q: คุณช่วยเสนอไฟล์ทางเทคนิคให้ฉันได้ไหม เพื่อซ่อมแซมส่วนจ่ายไฟของ Vcan1731 SDI บอร์ดเข้ารหัสวิดีโอ?
ก: กรุณาตรวจสอบไฟล์ตามลิงค์ด้านล่าง.
- https://ivcan.com/wp-content/uploads/Vcan1731-Component-Part-Number-Map-1.pdf
- https://ivcan.com/wp-content/uploads/Vcan1731-Component-Part-Number-Map-2.pdf
- https://ivcan.com/wp-content/uploads/vcan1731_A01_power.pdf
แนวคิดในการบำรุงรักษาของเราคือการแยกแยะก่อนว่ามีไฟฟ้าลัดวงจรหรือไม่และไฟฟ้าลัดวงจรอยู่ที่ใด. ตัวอย่างเช่น, ปลดลูกปัดแม่เหล็กหรือตัวต้านทาน 0 โอห์มระหว่างไอซีกำลังกับวงจรถัดไป, แล้วใช้มัลติมิเตอร์วัดว่าเพาเวอร์ไอซีขาดหรือวงจรตามมาเกิดการลัดวงจร. ถ้าเพาเวอร์ไอซีเสีย, เปลี่ยนไอซีเพาเวอร์; ถ้าวงจรถัดไปเกิดการลัดวงจร, คุณต้องตรวจสอบวงจรถัดไป.
Q: บอร์ดเข้ารหัสสามารถรับและส่งต่อข้อมูล UART ผ่านการสื่อสาร UDP ได้หรือไม่ (IP:ท่าเรือ)?
ก: ใช่, การส่งข้อมูล UART ได้รับการสนับสนุนภายใต้ของเรา โปรโตคอลแบบกำหนดเองเริ่มต้น, โดยมีข้อพิจารณาที่สำคัญบางประการ:
1. โปรโตคอลที่กำหนดเอง (เฟิร์มแวร์เริ่มต้น)
เฟิร์มแวร์การจัดส่งเริ่มต้นของเราใช้ โปรโตคอลมัลติเพล็กซ์แบบกำหนดเอง ที่รองรับ UART การส่งผ่านที่โปร่งใส (การส่งผ่านแบบอนุกรม).
- ข้อมูล UART จะถูกมัลติเพล็กซ์พร้อมกับสตรีมเสียง/วิดีโอ.
- ดังนั้น, ฝ่ายรับจะต้องใช้สิ่งที่สอดคล้องกัน ไลบรารี demux โปรโตคอลที่กำหนดเอง เพื่อแยกข้อมูล UART ออกจากสตรีมสื่อ.
- เมื่อใช้ร่วมกับบอร์ดถอดรหัสของเรา, การส่งข้อมูลแบบโปร่งใส UART ทำงานได้อย่างถูกต้องและสามารถส่งต่อ/รับตามที่คาดไว้.
หมายเหตุสำหรับผู้เล่นพีซี
ซอฟต์แวร์เครื่องเล่น PC ในปัจจุบันของเรามีเพียง demux และกระบวนการเท่านั้น:
- ข้อมูลวิดีโอ
- ข้อมูลเสียง
ในปัจจุบัน, มันทำ ไม่ ประมวลผลหรือส่งออกข้อมูลอนุกรม UART.
2. โปรโตคอลมาตรฐาน MPEG-TS
If the encoder board is flashed with the standard MPEG-TS firmware/protocol:
- Only audio and video streams are supported.
- UART/serial data transmission is ไม่รองรับ under MPEG-TS mode.
Please take this into consideration when selecting the firmware/protocol solution.
| Protocol Type | เสียง / วิดีโอ | UART Transparent Transmission |
|---|---|---|
| โปรโตคอลที่กำหนดเอง (ค่าเริ่มต้น) | ได้รับการสนับสนุน | ได้รับการสนับสนุน |
| Standard MPEG-TS | ได้รับการสนับสนุน | Not Supported |
Q: Do you have firmware that supports raw H.264 or RTP instead of MPEG-TS for UDP streaming?
ก: Our UDP firmware does not transmit raw H.264 elementary streams. UDP streaming is supported in two formats depending on firmware version:
- ก custom proprietary format, หรือ
- NS standard MPEG-TS (MPEG Transport Stream) รูป
These correspond to different firmware builds (typically distinguished by a suffix such as “T” or non-“T” versions).
Q: Do you support RTP as a standalone streaming protocol?
ก: เราไม่ได้จัดเตรียม “โหมดการสตรีม RTP แบบดิบ” แยกต่างหาก อย่างไรก็ตาม, RTP ถูกใช้ภายในภายในการสตรีม RTSP แล้ว. ในโหมด RTSP, เสียงและวิดีโอจะถูกส่งผ่านแพ็กเก็ต RTP โดยเป็นส่วนหนึ่งของสแต็ก RTSP/RTP/RTCP. ดังนั้น, RTP ได้รับการสนับสนุนทางอ้อมผ่าน RTSP แทนที่จะเป็นรูปแบบการสตรีม UDP อิสระ.
Q: ระบบสามารถส่งออก H.264 แบบดิบผ่าน UDP ได้หรือไม่?
ก: ไม่. ไม่รองรับการส่งสตรีมเบื้องต้นแบบ Raw H.264 ผ่าน UDP. นี่เป็นเพราะขนาดแพ็คเก็ตและข้อจำกัดของเครือข่าย. I-frame เดียวอาจมีขนาดใหญ่มากและไม่สามารถส่งผ่านแพ็กเก็ต IP เดียวได้อย่างน่าเชื่อถือ.
เพื่อการส่งสัญญาณที่เสถียร, สตรีมวิดีโอจะต้องห่อหุ้มโดยใช้รูปแบบการขนส่ง เช่น:
- MPEG-TS, หรือ
- RTP (ผ่านทาง RTSP)
Q: คีย์เฟรมเป็นยังไงบ้าง (จีโอพี) กำหนดช่วงเวลาแล้ว?
ก: ช่วงคีย์เฟรมถูกควบคุมโดย พารามิเตอร์ GOP ในเว็บอินเตอร์เฟส (หน้าการตั้งค่าวิดีโอ).
- หากตั้งค่า GOP เป็น 0 (โหมดเริ่มต้น/อัตโนมัติ), ระบบจะจัดช่วง I-frame ให้ตรงกับอัตราเฟรมอินพุตโดยอัตโนมัติ.
- ตัวอย่าง: หากอินพุตเป็น 1080p60, จากนั้นช่วง I-frame จะเป็น 60 เฟรม (1 จีโอพีที่สอง).
สิ่งนี้ทำให้มั่นใจได้ถึงพฤติกรรมการเข้ารหัสแบบปรับเปลี่ยนตามคุณลักษณะของแหล่งอินพุต.
Q: เหตุใดจึงไม่สามารถส่ง Raw H.264 โดยตรงผ่าน IP/UDP?
ก: เพราะเฟรม H.264 (โดยเฉพาะไอเฟรม) สามารถมีขนาดใหญ่มากและเกินหน่วยส่งสูงสุดได้ (ผู้ชาย) ของแพ็กเก็ตเครือข่าย. โดยไม่มีการห่อหุ้ม, ไม่สามารถรับประกันการจัดส่งที่เชื่อถือได้. ดังนั้น, วิดีโอจะต้องได้รับการแพ็กเก็ตโดยใช้รูปแบบการสตรีมมาตรฐาน เช่น MPEG-TS หรือ RTP เพื่อการแบ่งส่วนที่เหมาะสม, เวลา, และประกอบกลับเข้าไปใหม่.
Q: เวลาแฝงของระบบของฉันคือทั้งหมด ~ 230 ms. ตัวถอดรหัสและจอแสดงผลใช้เวลาประมาณ ~45 ms, เหลือ ~ 185 ms สำหรับกล้องและตัวเข้ารหัส. ฉันคาดว่ากล้องจะมีส่วน ~60 ms (4 เฟรมที่ 60 เฟรมต่อวินาที), ดังนั้นตัวเข้ารหัสดูเหมือนจะอยู่ที่ ~ 120 ms. มีวิธีลดเวลาแฝงของตัวเข้ารหัสหรือไม่? ฉันเข้าใจว่า MPEG-TS ส่งผลต่อการถอดรหัสเป็นหลัก, ไม่ใช่การเข้ารหัส.
ก: คำแนะนำการแบ่งเวลาแฝงและการเพิ่มประสิทธิภาพ
เพื่อเพิ่มประสิทธิภาพเวลาแฝงของระบบอย่างแม่นยำ, สิ่งสำคัญคือต้องตรวจสอบแต่ละขั้นตอนอย่างแยกจากกันก่อนจะถือว่าเกิดปัญหาคอขวด.
1. ตรวจสอบเวลาแฝงของกล้องก่อน (ขั้นตอนที่สำคัญ)
ก่อนที่จะเพิ่มประสิทธิภาพการเข้ารหัส, คุณควรยืนยันการมีส่วนร่วมของกล้องจริง.
วิธีการวัดเชิงปฏิบัติ:
- เชื่อมต่อเอาต์พุต HDMI ของกล้องเข้ากับจอแสดงผลโดยตรง
- เล็งกล้องไปที่นาฬิกาจับเวลาที่มีความแม่นยำสูงซึ่งแสดงบนหน้าจอ PC ที่แยกต่างหาก
- จับภาพทั้งฉากสดและเอาต์พุต HDMI พร้อมกัน
- เปรียบเทียบการประทับเวลาของเฟรมเพื่อคำนวณเวลาแฝงของกล้องจากต้นทางถึงปลายทาง
หมายเหตุ:
- ใช้นาฬิกาจับเวลาที่มีความแม่นยำสูง (ช่วงเห็บที่น้อยลงช่วยเพิ่มความแม่นยำ)
- การประมวลผล ISP ของกล้องมักมีส่วนสนับสนุนหลัก
- ในประสบการณ์ของเรา:
- 1080โดยทั่วไปแล้วกล้อง p จะแนะนำเวลาแฝงประมาณ 100 ms
- บางรุ่นอาจเกินนี้เนื่องจากไปป์ไลน์ ISP ที่หนักกว่า
2. การกำหนดค่ากล้องมีผลกระทบอย่างมาก
หากเวลาแฝงของกล้องสูง, การเพิ่มประสิทธิภาพควรเริ่มต้นที่นั่น:
- ความละเอียดต่ำกว่า (เช่น, 720p กับ 1080p) → ลดความล่าช้าของ ISP และไปป์ไลน์
- อัตราเฟรมที่สูงขึ้น (เช่น, 60 fps เทียบกับ 30 เฟรมต่อวินาที) → ลดเวลาแฝงในการบัฟเฟอร์เฟรม
- ไปป์ไลน์การประมวลผลภาพที่ง่ายขึ้น → ลดภาระของ ISP
การเปลี่ยนแปลงเหล่านี้มักจะลดเวลาแฝงได้อย่างมีประสิทธิภาพมากกว่าการปรับแต่งตัวเข้ารหัส.
3. เวลาแฝงของตัวเข้ารหัสน่าจะสูงเกินไป
ก 120 โดยทั่วไปความล่าช้าในการเข้ารหัส ms นั้นไม่น่าเป็นไปได้สำหรับตัวเข้ารหัสฮาร์ดแวร์ทั่วไป.
ขึ้นอยู่กับการวัดภายใน:
- ตัวเข้ารหัสฮาร์ดแวร์ + ถอดรหัส + การแพร่เชื้อ + ไปป์ไลน์การแสดงผลผ่านอีเทอร์เน็ตโดยทั่วไปจะส่งผลให้:
- เวลาแฝงจากต้นทางถึงปลายทางทั้งหมด ~80–100 ms
นี่หมายถึง:
- เวลาแฝงของตัวเข้ารหัสเพียงอย่างเดียวนั้นต่ำกว่าอย่างมาก 120 นางสาว
- การเข้ารหัสมักจะไม่ใช่ส่วนสำคัญในระบบที่กำหนดค่าอย่างเหมาะสม
4. วิธีการส่งข้อมูลมีความสำคัญ (โดยเฉพาะระบบไร้สาย)
กรุณาตรวจสอบว่าระบบใช้งานหรือไม่:
- อีเธอร์เน็ตแบบมีสาย
- การส่งสัญญาณแบบไร้สาย
หากใช้แบบไร้สาย:
- แบนด์วิธต่ำ (<20 เมกะบิตต่อวินาที) อาจทำให้เกิดความล่าช้าอย่างมาก
- การส่งสัญญาณ I-frame ขนาดใหญ่อาจทำให้เกิดการบัฟเฟอร์และการรอคิวล่าช้า
- สิ่งนี้สามารถเพิ่มเวลาแฝงตั้งแต่ต้นทางถึงปลายทางได้อย่างเห็นได้ชัด แม้ว่าการเข้ารหัสจะมีประสิทธิภาพก็ตาม
5. การชี้แจงค่าใช้จ่าย MPEG-TS และโปรโตคอล
โดยทั่วไปความเข้าใจของคุณถูกต้อง:
- MPEG-TS ไม่ได้เพิ่มเวลาแฝงในขั้นตอนการเข้ารหัสมากนัก
- โอเวอร์เฮดของโปรโตคอลส่วนใหญ่เกี่ยวข้องกับพฤติกรรมการแพ็กเก็ตและการถอดรหัส, ไม่ได้เข้ารหัสตัวเอง
- การดำเนินการ Mux/demux ถือเป็นการดำเนินการกับหน่วยความจำเป็นหลัก และมีความล่าช้าเล็กน้อยในระบบทั่วไป
6. วิธีการดีบักที่แนะนำ
เพื่อค้นหาแหล่งที่มาของเวลาแฝงอย่างแม่นยำ:
- เพิ่มการประทับเวลาภายในในแต่ละขั้นตอนไปป์ไลน์:
- เวลาจับภาพของกล้อง
- อินพุต/เอาต์พุตตัวเข้ารหัส
- เครือข่ายส่ง/รับ
- เอาต์พุตตัวถอดรหัส
- รีเฟรชจอแสดงผล
- ตรวจสอบให้แน่ใจว่าการบันทึกไม่ซับซ้อนและไม่ส่งผลกระทบต่อประสิทธิภาพการทำงาน
- ตรวจสอบความลึกของบัฟเฟอร์แบบเรียลไทม์เพื่อตรวจจับการสะสมของคิว
สรุปคำตอบของเรา
- ความล่าช้าของ ISP ของกล้องมักเป็นสาเหตุสำคัญที่ซ่อนอยู่ (~100 ms ที่ 1080p เป็นเรื่องปกติ)
- เวลาแฝงของตัวเข้ารหัสมักจะต่ำกว่าที่คิดไว้มาก
- การรับส่งข้อมูลแบบไร้สายและการบัฟเฟอร์สามารถเพิ่มความล่าช้าได้อย่างมาก
- การวัดการประทับเวลาอย่างเป็นระบบเป็นวิธีที่น่าเชื่อถือที่สุดในการระบุปัญหาคอขวดที่แท้จริง
ถามคำถาม
ข้อความของคุณถูกส่งแล้ว