WebRTC ومراقبة الفيديو: كيف هزمنا تأخير الفيديو من الكاميرات

صورة

منذ الأيام الأولى من العمل على نظام المراقبة بالفيديو على السحابة ، واجهنا مشكلة والتي بدونها كان من الممكن وضع حد ل Ivideon - لقد كانت إفرست لدينا ، وتسلقها استغرق الكثير من الطاقة ، ولكن الآن وصلنا أخيرًا إلى فأس جليدي في تاج العبور عبر النظام الأساسي.

لا ينبغي أن يعتمد نظام إرسال الصوت والفيديو عبر الإنترنت على الأجهزة وعملاء الويب والمعايير التي يدعمونها ، كما يجب أن يعمل بشكل صحيح مع مترجمي عنوان الشبكة والجدران النارية. يريد مستخدم المراقبة بالفيديو السحابي الوصول إلى الخدمة ، حتى لو كان يستخدم الكاميرات التمثيلية ، ويفضل مشاهدة بث الفيديو المباشر على الجهاز الأكثر حداثة.

من المهم جدًا أن يرغب المستخدم في مشاهدة الفيديو بأقل تأخير. إن الطريقة الوحيدة لعرض مقاطع الفيديو ذات زمن الاستجابة المنخفض في المستعرض هي استخدام WebRTC (اتصالات في الوقت الفعلي عبر الإنترنت). WebRTC هي مجموعة من التقنيات لنقل الفيديو والصوت من نظير إلى نظير في المتصفحات ، وهي مصممة أصلاً لنقل وتشغيل دفق الفيديو مع زمن انتقال منخفض. لهذا ، من بين أمور أخرى ، يتم استخدام بروتوكول UDP.

قبل إخبارك بالمحرك الجديد الذي يمنحه المستخدم ، سنذكرك لماذا ولماذا ندعم تقنيات HLS ولما قررنا المضي فيه.

محرك HLS: إيجابيات وسلبيات


صورة
( ج )

تم تطوير تقنية HLS (HTTP Live Streaming) من قِبل Apple ، لذلك ليس من المستغرب أن يظهر دعمها لأول مرة على أجهزة هذه العلامة التجارية المعينة. حتى الآن ، يمكن لجميع أجهزة فك تشفير التليفزيون والعديد من الأجهزة التي تعمل على نظام التشغيل أندرويد أيضًا تشغيل لقطات بتنسيق HLS.

يستخدم محرك 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 ثوانٍ. لكن بدأ الأشخاص يشكون ، على سبيل المثال ، عند بث مباراة كرة قدم ، تمت كتابة GOOOOOOL بالفعل في الدردشة ، لكن هذا ليس على الفيديو :). لدينا بالفعل عدد من الحالات المخصصة التي يجب أن يحل فيها Ivideon محل skype.

هل من الممكن هزيمة التأخير في HLS؟ تبدو الإجابة على هذا السؤال بمثابة خطاب لأحد المقاتلين ذوي الخبرة في الفئران في محاضرة قبل اضطرابات المبتدئين: "لا يمكن إبادة الفئران ، ولكن يمكن تقليل أعدادها إلى حد معقول". لذلك مع تأخير في HLS ، لن تنجح إزالته إلى الصفر ، ولكن هناك حلول في السوق يمكنها تقليل التأخير بشكل كبير.

قطع الضحلة


عيب آخر للمحرك هو استخدام ملفات صغيرة الحجم لنقل البيانات. يبدو أن هذا أمر سيء؟

أي شخص حاول نسخ عدد كبير من الملفات الصغيرة من وسيطة إلى أخرى ، ربما لاحظ أن سرعة كتابة هذه المجموعة أقل بكثير من ملف واحد كبير من نفس الحجم. نعم ، وكثافة الوصول إلى القرص الصلب تزداد بشكل كبير ، مما يؤثر سلبًا بشكل عام على أداء الكمبيوتر بأكمله. لذلك ، يساهم نقل بيانات الفيديو في شكل أجزاء صغيرة مدتها 10 ثوانٍ أيضًا في زيادة تأخير المحرك.

لخص بإيجاز جميع إيجابيات وسلبيات تقنية HLS.

مزايا HLS:

  1. القدرة على العمل مع أي جهاز. يمكنك مشاهدة مقاطع الفيديو على أي جهاز حديث ، سواء كان الهاتف الذكي أو الكمبيوتر اللوحي أو الكمبيوتر المحمول أو الكمبيوتر المكتبي. الشيء الرئيسي هو أن متصفح الويب محدث ومتوافق مع HTML5 و Media Source Extensions.
  2. جودة صورة رائعة. تتيح لك وظيفة نقل البيانات التكيفية المستخدمة تغيير جودة تسلسل الفيديو المنقول ديناميكيًا وفقًا لعرض النطاق الترددي لاتصال الإنترنت ، بينما تسعى الخوارزمية إلى الحفاظ على الجودة القصوى.
  3. ليست هناك حاجة لتكوين معقد لمعدات المستخدم.

العيوب:

  1. دعم محدود للعمل مع المحرك على بعض الأجهزة.
  2. تأخيرات عالية في نقل الصور.
  3. زيادة قوية في النفقات العامة وتعقيد التحسين بسبب استخدام الملفات الصغيرة. نظرًا لطبيعة الحاوية ، لا يمكننا أبدًا تأخير أقل من حجم القطعة.

تفوقت عيوب HLS على مزاياها بالنسبة لنا وأجبرتنا على البحث عن خيارات بديلة.

ما هو WebRTC؟


صورة
( ج )

تم تطوير WebRTC بواسطة Google في عام 2011 لدفق الفيديو والصوت بين المتصفحات وتطبيقات الهاتف المحمول بأقل قدر من الكمون. لهذا ، يتم استخدام بروتوكول UDP القياسي وخوارزميات التحكم في التدفق الخاصة. واليوم هو مشروع مفتوح المصدر ، وهو مدعوم بنشاط من Google وهو في طور التطوير.

WebRTC هي مجموعة من التقنيات لنقل الفيديو والصوت من نظير إلى نظير. وهذا هو ، على سبيل المثال ، يمكن لمتصفحات المستخدم التي تستخدم WebRTC نقل البيانات إلى بعضها البعض مباشرة ، دون استخدام خوادم بعيدة لتخزين ومعالجة البيانات. تتم معالجة جميع المعلومات أيضًا عن طريق المتصفحات وتطبيقات الأجهزة المحمولة للمستخدمين النهائيين.

تم تقدير الراحة والقدرات الكبيرة لهذه التكنولوجيا من قبل مطوري جميع المتصفحات الشعبية. يتم تطبيق دعم WebRTC اليوم في موزيلا فايرفوكس وأوبرا وجوجل كروم (وجميع المتصفحات القائمة على Chromium) ، وكذلك في تطبيقات الأجهزة المحمولة لنظامي التشغيل 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 ، لأنه يحتوي فقط على التحكم الصحيح في التدفق ، وهناك كل المخططات المعروفة لتصحيح الخطأ الأمامي (FEC) ، ويتم تنفيذ آلية إعادة إرسال الحزمة لجميع المتصفحات بشكل صحيح. من المهم أيضًا تطوير SDK webrtc.org بواسطة Google.

ما هي نتيجة تطبيق 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 ، لم يعد هناك من الناحية العملية. وفي محاولة لتحديد ما إذا كان متصفح المستخدم يدعمه أم لا ، نفقد قرابة الثواني من الوقت الثمين.

فيما يلي ملخص موجز للتغييرات التي تنتظرك في نظام المراقبة بالفيديو السحابي والحساب الشخصي الخاص بنا. ترقبوا وابقوا معنا!

Source: https://habr.com/ru/post/ar449326/


All Articles