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

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

لماذا يصبح الوصول إلى الفيديو صعبًا

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

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

ومع ذلك، تتبع البنية التحتية للمراقبة تاريخًا تقنيًا مختلفًا. قد توفر الكاميرات، ومسجلات الفيديو الشبكية، وأنظمة إدارة الفيديو، وأجهزة المراقبة المحمولة، والطائرات بدون طيار، ومنصات المراقبة الخاصة بالقطاع دفقات من خلال GB/T28181، أو RTSP، أو RTP، أو RTMP، أو HLS، أو SIP، أو واجهات أخرى. قد تستخدم أيضًا برامج ترميز فيديو تم اختيارها أساسًا لكفاءة التخزين وليس لتشغيل المتصفح.

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

منتج ذو صلة: وحدة تحكم إرسال Becke

أين يخلق H.265 فجوة التوافق

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

المشكلة هي أن دعم تشغيل H.265 غير متوفر بشكل ثابت عبر بيئات WebRTC والمتصفحات النموذجية. لذلك قد توفر منصة المراقبة دفق H.265 صحيحًا تمامًا لا يمكن استهلاكه مباشرة بواسطة تطبيق WebRTC المستخدم في موقع الإرسال.

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

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

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

بنية بوابة تحويل ترميز عملية

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

يمكن تقسيم سير العمل النموذجي إلى خمس مراحل:

1. تطلب منصة الإرسال كاميرا معينة، أو طائرة بدون طيار، أو جهاز مراقبة محمول، أو مورد فيديو تابع لجهة خارجية.

2. تحصل البوابة على الدفق المصدر من خلال بروتوكول المراقبة أو البث المتاح.

3. تتحقق خدمة الوسائط من برنامج الترميز الوارد، والدقة، ومعدل الإطارات، ومعدل البت، وتنسيق الدفق.

4. إذا لزم الأمر، يتم تحويل الفيديو أو إعادة تجميعها إلى تنسيق مناسب لبيئة WebRTC.

5. يتم تسليم الوسائط المحولة إلى وحدة تحكم الإرسال القائمة على المتصفح للمشاهدة في الوقت الفعلي.

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

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

التعاون البروتوكولي عبر أنظمة الفيديو

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

تشمل الواجهات الشائعة في بيئات القيادة والمراقبة GB/T28181، وRTSP، وRTP، وRTMP، وFLV، وHLS، وSIP، وWebRTC. أغراضها ليست متطابقة. بعضها يستخدم للوصول إلى أجهزة المراقبة والتحكم بها، وبعضها لنقل الوسائط في الوقت الفعلي، وبعضها لتوزيع البث، والبعض الآخر للإشارات الخاصة بالجلسات أو اتصالات المتصفح.

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

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

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

سير عمل النشر للمشاريع الحقيقية

يجب أن يبدأ مشروع تكامل ناجح ببيئة الفيديو الحالية بدلاً من واجهة WebRTC وحدها. المهمة الأولى هي تحديد الموارد التي يجب عرضها وكيفية عرض هذه الموارد حاليًا.

رسم خرائط مصادر الفيديو الحالية

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

فصل الإشارات عن الوسائط

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

التوحيد فقط عند الضرورة

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

استخدام سحب الدفق عند الطلب

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

الحفاظ على سير عمل المشغل بسيطًا

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

الموثوقية وجودة الوسائط مهمة

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

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

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

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

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

ملاحظات ختامية

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

يُعد H.265 مصدرًا شائعًا بشكل خاص لعدم التوافق. بدلاً من إعادة تصميم وحدة تحكم الإرسال أو استبدال معدات المراقبة الحالية، يمكن لبوابة تحويل ترميز الوسائط استقبال الدفق الأصلي، وتحويل H.265 إلى H.264 عند الحاجة، وتكييف الدقة ومعدل الإطارات ومعدل البت، وتسليم النتيجة عبر مسار متوافق مع WebRTC.

عندما تدعم البوابة نفسها أيضًا واجهات مثل GB/T28181، وRTSP، وRTP، وRTMP، وFLV، وHLS، وSIP، وWebRTC، تصبح طبقة تشغيل بيني عملية لبنية اتصالات متقاربة أوسع. والنتيجة هي سير عمل إرسال حيث يمكن للمشغلين الوصول إلى موارد فيديو غير متجانسة من خلال واجهة واحدة بينما يبقى تحويل برنامج الترميز وتكيف البروتوكول في الخلفية.

الأسئلة الشائعة

هل يجب تحويل كل دفق مراقبة بشكل دائم قبل أن يطلبه المشغل؟

عادةً لا. في التركيبات الكبيرة، غالبًا ما تكون المعالجة عند الطلب أكثر كفاءة. يمكن لخدمة الوسائط بدء سحب الدفق وتكييفه عندما يفتح المشغل المورد المقابل، ثم تحرير سعة المعالجة عندما لا يكون الدفق مطلوبًا بعد الآن.

هل يمكن تسليم نفس دفق الكاميرا إلى عدة مشغلي إرسال؟

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

كيف يجب إدارة أذونات الوصول إلى الفيديو؟

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

ماذا يحدث عندما يصبح مصدر الفيديو الأصلي غير متاح مؤقتًا؟

يجب أن يتلقى تطبيق الإرسال حالة واضحة للانقطاع أو إعادة الاتصال بدلاً من عرض صورة مجمدة إلى أجل غير مسمى. يمكن للنهاية الخلفية محاولة إعادة الاتصال وفقًا لسياسات إعادة المحاولة المحددة واستعادة الدفق تلقائيًا بعد عودة المصدر المنبع.