منذ الأيام الأولى من العمل على نظام المراقبة بالفيديو السحابي ، واجهنا مشكلة ، دون حل كان من الممكن وضع حد لـ Ivideon - لقد كان تسلق جبل إيفرست لدينا هو الذي استغرق الكثير من القوة ، لكننا الآن توقفنا أخيرًا فأس جليدي في الجزء العلوي من rebus عبر النظام الأساسي.
يجب ألا يعتمد نظام نقل الصوت والفيديو عبر الإنترنت على المعدات وعملاء الويب والمعايير التي يدعمونها ، كما يجب أن يعمل بشكل صحيح في وجود مترجمي عناوين الشبكة والجدران النارية. يريد مستخدم المراقبة بالفيديو السحابي الوصول إلى الخدمة ، حتى لو كان يستخدم الكاميرات التناظرية ، ويفضل مشاهدة بث فيديو مباشر على أحدث جهاز.
من المهم جدًا أن يرغب المستخدم في مشاهدة الفيديو بأقل تأخير. إلى حد كبير ، الطريقة الوحيدة لإظهار الفيديو بزمن انتقال منخفض في المستعرض هي استخدام WebRTC (اتصالات الويب في الوقت الفعلي). WebRTC عبارة عن مجموعة من التقنيات لنقل الفيديو والصوت من نظير إلى نظير في المتصفحات ، وهي مصممة في الأصل لنقل وتشغيل دفق فيديو بزمن انتقال منخفض. لهذا ، من بين أمور أخرى ، يتم استخدام بروتوكول UDP.
قبل إخبارك بما يقدمه المحرك الجديد للمستخدم ، سنذكرك لماذا ولماذا ندعم تقنيات HLS ، ولماذا قررنا المضي قدمًا.
محرك HLS: إيجابيات وسلبيات
()
طُوّرت تقنية HLS (البث المباشر عبر HTTP) من قِبل شركة آبل، لذا ليس من المستغرب أنها كانت مدعومة في البداية على أجهزة آبل. واليوم، يدعم فيديو HLS جميع أجهزة الاستقبال الرقمية تقريبًا والعديد من الأجهزة التي تعمل بنظام التشغيل. 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 محل سكايب عمليًا.
هل من الممكن التغلب على الكمون في HLS؟ تبدو الإجابة على هذا السؤال وكأنها خطاب من قبل إبادة الفئران ذوي الخبرة في محاضرة للمبتدئين في إبادة الفئران: "لا يمكن إبادة الفئران ، ولكن يمكن تقليل عدد سكانها إلى الحد الأدنى المعقول". لذلك مع التأخير في HLS ، لن يعمل على إزالته إلى الصفر ، ولكن هناك حلول في السوق يمكن أن تقلل التأخير بشكل كبير.
قطع ناعم
عيب آخر للمحرك هو استخدام الملفات الصغيرة لنقل البيانات. يبدو أن هذا سيء؟
يجب أن يكون أي شخص حاول نسخ عدد كبير من الملفات الصغيرة من وسيط إلى آخر قد لاحظ أن سرعة الكتابة لمثل هذه المجموعة أقل بكثير من ملف كبير من نفس الحجم. نعم ، وتزداد كثافة الوصول إلى القرص الصلب بشكل كبير ، مما يؤثر بشكل عام سلبًا على أداء الكمبيوتر بالكامل. لذلك ، فإن نقل بيانات الفيديو في شكل أجزاء صغيرة مدتها 10 ثوان يساهم أيضًا في زيادة تأخير المحرك.
دعونا نلخص بإيجاز جميع إيجابيات وسلبيات تقنية HLS.
مزايا HLS:
- القدرة على العمل مع أي جهاز. يمكنك مشاهدة مقاطع الفيديو على أي جهاز حديث ، سواء كان هاتفًا ذكيًا أو جهازًا لوحيًا أو كمبيوتر محمولاً أو كمبيوتر مكتبيًا. الشيء الرئيسي هو أن متصفح الويب محدث ومتوافق مع HTML5 و Media Source Extensions.
- جودة صورة ممتازة. تتيح لك وظيفة نقل البيانات التكيفية المستخدمة تغيير جودة تسلسل الفيديو المرسل ديناميكيًا اعتمادًا على عرض النطاق الترددي لاتصال الإنترنت ، بينما تسعى الخوارزمية جاهدة للحفاظ على الجودة عالية قدر الإمكان.
- ليست هناك حاجة لإعداد معدات المستخدم المعقدة.
العيوب:
- دعم محدود للعمل مع المحرك على بعض الأجهزة.
- الكمون العالي في نقل الصور.
- زيادة كبيرة في النفقات العامة وتعقيد التحسين بسبب استخدام الملفات الصغيرة. نظرًا لطبيعة الحاوية ، لن نتمكن أبدًا من الحصول على تأخير أقل من حجم المقطع.
تفوقت عيوب HLS على مزاياها وأجبرتنا على البحث عن بدائل.
ما هو WebRTC
()
تم تطوير منصة WebRTC بواسطة Google في عام 2011 لنقل بيانات تدفق الفيديو والصوت بين المتصفحات وتطبيقات الهاتف المحمول بأقل تأخير. لهذا الغرض ، يتم استخدام بروتوكول UDP القياسي وخوارزميات التحكم في التدفق الخاصة. اليوم هو مشروع مفتوح المصدر ، مدعومًا بنشاط Google وتطويره.
WebRTC عبارة عن مجموعة من التقنيات لنقل الفيديو والصوت من نظير إلى نظير. أي ، على سبيل المثال ، يمكن لمتصفحات المستخدمين التي تستخدم WebRTC نقل البيانات مباشرة إلى بعضها البعض ، دون استخدام خوادم بعيدة لتخزين البيانات ومعالجتها. تتم أيضًا معالجة جميع المعلومات بواسطة متصفحات المستخدمين وتطبيقات الهاتف المحمول.
لقد حظيت سهولة استخدام هذه التقنية وإمكانياتها الواسعة بتقدير مطوري جميع المتصفحات الشائعة. يتوفر دعم WebRTC حاليًا في متصفحات Mozilla Firefox وOpera وGoogle Chrome (وجميع المتصفحات المبنية على Chromium)، بالإضافة إلى تطبيقات الجوال التي تعمل بنظام التشغيل Android و دائرة الرقابة الداخلية.
مع كل مزاياه التي لا يمكن إنكارها ، فإن 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) المعروفة ، وينفذ بشكل صحيح آلية إعادة إرسال الحزم لجميع المتصفحات . من المهم أيضًا أن يتم تطوير webrtc.org SDK بشكل نشط بواسطة Google.
ما هي نتيجة تطبيق WebRTC؟
لمشاهدة الفيديو المباشر من الكاميرات ، أضفنا مشغلًا محسنًا جديدًا يعتمد على WebRTC إلى حسابك الشخصي. يوفر تحميل فيديو عالي السرعة ويزيل تمامًا مشكلة تراكم الكمون مع زيادة وقت المشاهدة.
بعد تنفيذ دعم WebRTC في خدمة Ivideon السحابية ، يمكننا القول بثقة تامة أنه يمكن لعملائنا الآن مشاهدة فيديو مباشر كامل. الآن التأخير في بث تسلسل الفيديو لا يتجاوز ثانية واحدة! للمقارنة ، قدم محرك HLS السابق توصيل فيديو بتأخير من 5 إلى 7 ثوانٍ. الاختلاف في سرعة عرض الفيديو مهم للغاية ، وسوف يلاحظه المستخدم فور بدء العمل مع خدمة الفيديو الخاصة بنا.
كما توقعنا ، أتاح تطبيق المشغل الجديد زيادة استجابة PTZ والتواصل الصوتي مع الكاميرا.
هناك نقطة دقيقة واحدة فقط نريد أن نلفت الانتباه إليها. لا يزال مشغل WebRTC الجديد يعمل في وضع الاختبار. ولهذا السبب لا نقوم بتمكينه لجميع عملائنا بشكل افتراضي. ولكن يمكنك تنشيطه بنفسك عن طريق تمكين العنصر المقابل في إعدادات الكاميرا (للقيام بذلك ، انتقل إلى ).
ميزات تطبيق WebRTC في خدمة Ivideon
لا تزال WebRTC تقنية تجريبية في الوقت الحالي. لم يتم تنفيذ دعمه بشكل صحيح حتى الآن في جميع المتصفحات وأجهزة المستخدم ، وليس في جميع الكاميرات.
هذا هو بالضبط ما يفسر حقيقة أننا لم نجعل مشغل WebRTC هو الافتراضي الرئيسي لجميع المستخدمين.
في الوقت الحالي ، نوصي باستخدام WebRTC في متصفحات Google Chrome فقط. تدعم أحدث إصدارات Firefox و Safari أيضًا هذه التقنية ، لكنها للأسف ليست مستقرة بعد.
لم ننفذ دعم WebRTC للمتصفحات على الأجهزة المحمولة حتى الآن. الآن ، إذا قمت بتسجيل الدخول من جهاز محمول وقمت بتنشيط WebRTC ، فلن يعمل هذا الوضع. ومع ذلك ، WebRTC متاح في تطبيقات الجوال الخاصة بنا لـ и .
واستكمالًا للقصة حول ميزات تطبيق WebRTC في خدمتنا ، نلاحظ نقطتين أخريين أكثر دقة.
أولاً ، تركز التقنية على بث الفيديو المباشر في الوقت الفعلي. لذلك ، إذا كان عرض النطاق الترددي الخاص بك غير كافٍ لنقل تسلسل الفيديو ، فستلاحظ حدوث انخفاض في الإطارات (مع HLS ستلاحظ تلاشي الفيديو وزيادة زمن الوصول ، بينما لن يتم إسقاط أي إطارات) ، ولكن سيظل الفيديو يبث بشكل حقيقي وقت.
ثانيًا ، نظرًا لأن التكنولوجيا مصممة للعمل مع الفيديو المباشر في الوقت الفعلي ، فإننا لا نستخدمها للعمل مع بيانات الفيديو المؤرشفة.
تغييرات الخدمة الأخرى
في الوقت الحالي ، لم يعد Flash يشارك في آلية الاختيار التلقائي للمحرك. لا يزال بإمكانك استخدام هذا المشغل ، ولكن لهذا تحتاج إلى تحديده يدويًا في إعدادات الحساب أو الكاميرا. هذا ليس تقديرًا للموضة ، فقط وفقًا لإحصائيات خدمتنا ، لا يوجد عمليًا أي مستخدمين يعملون مع Flash. ومحاولة تحديد ما إذا كان متصفح المستخدم يدعمه ، فإننا نفقد حوالي ثانيتين من الوقت الثمين.
فيما يلي ملخص موجز للتغييرات التي تنتظرك في نظام المراقبة بالفيديو القائم على السحابة والحساب الشخصي. ابق معنا وتابع الأخبار!
المصدر: www.habr.com
