🥇WebRTC และการเฝ้าระวังวิดีโอ: เราเอาชนะความล่าช้าของวิดีโอจากกล้องได้อย่างไร

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

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

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

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

เครื่องยนต์ HLS: ข้อดีและข้อเสีย

(c)

เทคโนโลยี HLS (HTTP Live Streaming) ถูกพัฒนาโดย Apple ดังนั้นจึงไม่น่าแปลกใจที่อุปกรณ์ Apple เป็นอุปกรณ์แรกที่รองรับเทคโนโลยีนี้ ปัจจุบัน วิดีโอ HLS รองรับโดยกล่องรับสัญญาณเกือบทุกรุ่นและอุปกรณ์จำนวนมากที่ใช้ระบบปฏิบัติการ Apple Android.

กลไก HLS ใช้ตัวแปลงสัญญาณวิดีโอ H264 ที่รู้จักกันดีร่วมกับสตรีมเสียง AAC หรือ MP3 เพื่อสตรีมข้อมูลวิดีโอ สตรีมข้อมูลเสียงและวิดีโอทั้งหมดถูกบรรจุไว้ในคอนเทนเนอร์การขนส่ง MPEG-TS สำหรับการส่งข้อมูลผ่านโปรโตคอล HTTP ข้อมูลที่อยู่ในสตรีมจะถูกแบ่งออกเป็นส่วนที่อธิบายไว้ในเพลย์ลิสต์ m3u8 จากนั้นแฟรกเมนต์เหล่านี้พร้อมกับเพลย์ลิสต์เท่านั้นที่จะถูกส่งผ่าน HTTP การแบ่งส่วนโดยอัตโนมัติหมายถึงการหน่วงเวลาเป็นวินาที นี่คือคุณลักษณะของคอนเทนเนอร์ MPEG-TS

กลไก HLS ยังรองรับสตรีมแบบหลายบิต Live/VOD

ข้อดีหลักของ HLS:

การสนับสนุนในตัวในเบราว์เซอร์หลักทั้งหมด
ความง่ายในการใช้งาน (เทียบกับ WebRTC)
สะดวกและมีประสิทธิภาพมากในการจัดการออกอากาศทุกประเภทไปยังผู้ชมจำนวนมาก เนื่องจากสามารถอัปโหลดกลุ่มไปยัง CDN ได้เพียงครั้งเดียว

แม้ว่าเครื่องยนต์จะเรียบง่าย แต่ทุกอย่างก็ไม่ได้ราบรื่นอย่างที่คิด ปัญหาหลักคือนักพัฒนาเครื่องเล่นบุคคลที่สามได้ละทิ้งคำแนะนำของ Apple เช่น ในแง่ของรูปแบบเสียงที่รองรับ โดยเฉพาะอย่างยิ่งนักพัฒนาจำนวนมากเริ่มเพิ่มความสามารถในการทำงานกับสตรีมเสียงยอดนิยม: วิดีโอ mpeg2, เสียง mpeg2 ฯลฯ ด้วยเหตุนี้พวกเขาจึงต้องสร้างรูปแบบเพลย์ลิสต์ที่แตกต่างกันสำหรับผู้เล่นที่แตกต่างกัน

แต่ปัญหาที่ใหญ่ที่สุดอย่างหนึ่งของกลไก HLS คือเวลาแฝงที่สูงในการถ่ายโอนข้อมูล

ต้นกำเนิดของ “เบรก”

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

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

หากคุณกำลังดูสำนักงานที่พนักงานเงยหน้าขึ้นจากหน้าจอมอนิเตอร์ชั่วโมงละครั้ง ความล่าช้า 5 วินาทีก็ไม่สำคัญอีกต่อไป แต่ผู้คนเริ่มบ่นว่า เช่น เวลาถ่ายทอดสดการแข่งขันฟุตบอล พวกเขาเขียน GOOOOL ในแชทไปแล้ว แต่นี่ยังไม่มีในวิดีโอ :) เรามีกรณีผู้ใช้จำนวนหนึ่งที่ Ivideon ควรแทนที่ Skype ในทางปฏิบัติ

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

การตัดละเอียด

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

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

มาสรุปข้อดีข้อเสียของเทคโนโลยี HLS กันโดยย่อ

ข้อดีของ HLS:

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

ข้อเสีย:

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

ข้อเสียของ HLS มีมากกว่าข้อได้เปรียบสำหรับเรา และบังคับให้เรามองหาตัวเลือกอื่น

WebRTC คืออะไร

(c)

แพลตฟอร์ม WebRTC ได้รับการพัฒนาโดย Google ในปี 2011 เพื่อส่งข้อมูลวิดีโอและเสียงแบบสตรีมระหว่างเบราว์เซอร์และแอปพลิเคชันมือถือโดยมีเวลาแฝงน้อยที่สุด ด้วยเหตุนี้จึงใช้โปรโตคอล UDP มาตรฐานและอัลกอริธึมควบคุมการไหลพิเศษ ปัจจุบันเป็นโครงการโอเพ่นซอร์สที่ได้รับการดูแลและพัฒนาโดย Google

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

นักพัฒนาเบราว์เซอร์ยอดนิยมทุกตัวต่างชื่นชมความสะดวกสบายและความสามารถที่ครอบคลุมของเทคโนโลยีนี้ ปัจจุบัน Mozilla Firefox, Opera, Google Chrome (และเบราว์เซอร์ที่ใช้ Chromium ทั้งหมด) รวมถึงแอปพลิเคชันบนมือถือที่รองรับ WebRTC ก็มีให้บริการแล้ว Android และ iOS

สำหรับข้อดีที่ไม่ต้องสงสัยทั้งหมด WebRTC มีข้อเสียที่สำคัญหลายประการ

ความยากลำบากในการเลือก

เทคโนโลยี WebRTC มีความซับซ้อนมากขึ้นในแง่ของการโต้ตอบเครือข่ายเนื่องจากเป็นเรื่องเกี่ยวกับ P2P เป็นการยากที่จะแก้ไขจุดบกพร่อง ทดสอบ และสามารถทำงานได้อย่างคาดเดาไม่ได้ ในเวลาเดียวกัน เราจำเป็นต้องเอาชนะ NAT และไฟร์วอลล์ เราต้องรับประกันการทำงานในเครือข่ายที่บล็อก UDP

การใช้งาน WebRTC ของ Google นั้นใช้งานได้ยากมาก มีทั้งบริษัทที่ให้บริการประกอบ SDK นอกจากนี้ การใช้งานของ Google ยังเป็นเรื่องยากมากที่จะผสานรวมกับระบบของเราโดยไม่ต้องเข้ารหัสวิดีโอทั้งหมดอีกครั้ง

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

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

เราได้ทำอะไร

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

เพื่อให้ WebRTC ทำงานได้อย่างถูกต้อง ก่อนอื่น จำเป็นต้องดำเนินการอัปเกรดเทคโนโลยีของสแต็กสำหรับการทำงานกับวิดีโอบนเว็บ นั่นคือสิ่งที่เราทำ

อันดับแรก เราใช้เซิร์ฟเวอร์โปรโตคอลการส่งสัญญาณ WebRTC บน Websocket และยังปรับใช้เซิร์ฟเวอร์เพียร์ WebRTC ในระบบคลาวด์โดยอิงตาม webrtc.org SDK หน้าที่ของมันคือการกระจายสตรีมวิดีโอไปยังไคลเอนต์ WebRTC ในรูปแบบ H.264 + Opus/G.711 โดยไม่ต้องแปลงรหัสวิดีโอ

เราเลือก Websocket เป็นโปรโตคอลการส่งสัญญาณเนื่องจากมีการรองรับคุณภาพสูงในเว็บเบราว์เซอร์ยอดนิยมทั้งหมดอยู่แล้ว ด้วยเหตุนี้ คุณจึงสามารถลดไม่เพียงแต่ค่าใช้จ่ายในการพัฒนาเท่านั้น แต่ยังหลีกเลี่ยงการเสียเวลาและทรัพยากรไปกับการจับมือ TCP และ TLS ซ้ำๆ เมื่อเทียบกับ AJAX

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

และเพื่อที่จะใช้เทคโนโลยีการส่งสัญญาณอย่างอิสระ เราจำเป็นต้องพัฒนาเซิร์ฟเวอร์การส่งสัญญาณของเราเองด้วยการรองรับโปรโตคอลเว็บหลายตัว (Websocet, WebRTC) และด้วยความสามารถในการจัดการเซสชันและการแจ้งเตือนแบบเรียลไทม์ การจัดการวิดีโอ และอื่นๆ อีกมากมายอย่างปลอดภัย

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

ในไคลเอนต์มือถือ เราได้ติดตั้งโปรแกรมเล่นโดยใช้ webrtc.org SDK เนื่องจากมีเพียงโปรแกรมควบคุมการไหลที่ถูกต้องเท่านั้น มีรูปแบบ Forward Error Correction (FEC) ที่รู้จักทั้งหมด และใช้กลไกในการส่งแพ็กเก็ตอีกครั้งสำหรับเบราว์เซอร์ทั้งหมดอย่างถูกต้อง สิ่งสำคัญคือ Google จะพัฒนา SDK ของ webrtc.org อย่างจริงจัง

ผลลัพธ์ของการนำ WebRTC ไปใช้คืออะไร?

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

หลังจากแนะนำการสนับสนุน WebRTC ในบริการคลาวด์ของ Ivideon แล้ว เราสามารถพูดได้อย่างมั่นใจว่าลูกค้าของเราสามารถรับชมวิดีโอถ่ายทอดสดได้อย่างเต็มรูปแบบแล้ว ตอนนี้ความล่าช้าในการออกอากาศลำดับวิดีโอไม่เกินหนึ่งวินาที! สำหรับการเปรียบเทียบ กลไก HLS ก่อนหน้านี้ให้การส่งวิดีโอโดยมีความล่าช้า 5-7 วินาที ความแตกต่างของความเร็วในการสาธิตวิดีโอมีความสำคัญมากและผู้ใช้จะสังเกตเห็นได้ทันทีหลังจากเริ่มทำงานกับบริการวิดีโอของเรา

ตามที่เราคาดไว้ การใช้งานเครื่องเล่นใหม่ได้ปรับปรุงการตอบสนองของ PTZ และการสื่อสารด้วยเสียงด้วยกล้อง

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

คุณสมบัติของการใช้งาน WebRTC ในบริการ Ivideon

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

นี่เป็นเหตุผลว่าทำไมเรายังไม่ได้กำหนดให้โปรแกรมเล่น WebRTC เป็นค่าเริ่มต้นสำหรับผู้ใช้ทุกคน

ในตอนนี้ เราขอแนะนำให้ใช้ WebRTC ในเบราว์เซอร์ Google Chrome เท่านั้น Firefox และ Safari เวอร์ชันล่าสุดรองรับเทคโนโลยีนี้เช่นกัน แต่น่าเสียดายที่เทคโนโลยีนี้ยังไม่เสถียร

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

และในการสรุปเรื่องราวเกี่ยวกับฟีเจอร์การใช้งาน WebRTC ในบริการของเรา เราจะพูดถึงประเด็นที่ละเอียดอ่อนอีกสองประเด็น

ประการแรกเทคโนโลยีมุ่งเน้นไปที่การถ่ายทอดสดวิดีโอแบบเรียลไทม์ ดังนั้น หากช่องของคุณมีแบนด์วิธไม่เพียงพอที่จะส่งวิดีโอ คุณจะสังเกตเห็นว่าเฟรมลดลง (ด้วย HLS คุณจะสังเกตเห็นว่าวิดีโอซีดจางและมีเวลาแฝงเพิ่มขึ้น แต่จะไม่มีเฟรมตก) แต่วิดีโอจะยังคงออกอากาศแบบเรียลไทม์ เวลา.

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

การเปลี่ยนแปลงอื่น ๆ ในการบริการ

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

ต่อไปนี้เป็นภาพรวมโดยย่อของการเปลี่ยนแปลงที่รอคุณอยู่ในระบบ Surveillance วิดีโอบนคลาวด์และบัญชีส่วนบุคคลของเรา อยู่กับเราและติดตามข่าวสาร!

ที่มา: will.com