لم تعد مشاريع النقل الذكية مقتصرة على أنظمة المراقبة التقليدية. في إدارة الطرق السريعة، ومراكز التحكم في حركة المرور، وشبكات الطرق الحضرية، وتشغيل الأنفاق، والاستجابة للطوارئ، والإشراف على النقل، أصبحت موارد الفيديو مرتبطة بشكل متزايد مع تحليلات الذكاء الاصطناعي، واتصالات التوزيع، واستشعار إنترنت الأشياء، ومنصات البيانات الضخمة، وأنظمة القيادة المعتمدة على الويب.
هذا يخلق تحدياً عملياً: عادةً ما يتم توفير الأنظمة الفرعية المختلفة من قبل موردين مختلفين، ومبنية ببروتوكولات مختلفة، ويتم نشرها في مراحل مختلفة. قد يشمل المشروع الواحد منصات مراقبة الفيديو، وأنظمة التحليل الذكية، ومنصات اتصالات التوزيع، ومنصات إنترنت الأشياء، ومراكز البيانات، وأنظمة التصور على الشاشات الكبيرة. لجعل هذه الأنظمة تعمل معاً، يصبح تقارب الفيديو جزءًا رئيسيًا من الحل الشامل.
من المراقبة المستقلة إلى عمليات النقل المتكاملة
في مشاريع مراقبة حركة المرور السابقة، كانت أنظمة الفيديو تُستخدم أساساً للمعاينة المباشرة والتسجيل وإعادة التشغيل. تلتقط الكاميرا الصورة، ويخزن المنصة الدفق، ويعيد المشغلون مشاهدة الفيديو عند الحاجة. لا يزال هذا النموذج مهماً، لكن أنظمة النقل الحديثة تتطلب أكثر من ذلك بكثير.
اليوم، قد يُستخدم الفيديو بواسطة أنظمة الذكاء الاصطناعي لاكتشاف الأحداث، ومراكز القيادة للتوزيع في حالات الطوارئ، ومنصات الاتصال للتنسيق البصري، ولوحات معلومات الويب للعرض على الشاشات الكبيرة، ومنصات البيانات لتحليل حركة المرور. قد يحتاج دفق الكاميرا نفسه إلى خدمة أنظمة أعمال متعددة في نفس الوقت.
هذا يعني أن قيمة الفيديو لم تعد فقط في الكاميرا أو منصة التخزين. تظهر القيمة الحقيقية عندما يمكن للفيديو أن يتدفق بين الأنظمة، ويتطابق مع محطات العرض المختلفة، ويدعم العمليات عبر المنصات. بدون تقارب الفيديو، قد ترى كل منصة مواردها الخاصة فقط، ويصبح مشروع النقل الذكي بأكمله مجزأً.
لماذا تظهر مشاكل التوافق أثناء تسليم المشروع
تواجه العديد من مشاريع النقل الذكية عدم توافق فيديو عبر الأنظمة أثناء التنفيذ. المشكلة ليست ببساطة أن جهازاً ما به عطل أو أن منصة ما مصممة بشكل سيء. غالباً ما تأتي من الاختلافات في بنية النظام، وبروتوكولات الفيديو، وتنسيقات الترميز، وقدرة الدقة، وأداء فك التشفير للمحطة الطرفية.
على سبيل المثال، قامت العديد من مشاريع الطرق السريعة بنشر كاميرات بدقة 4K للحصول على صور أوضح للطريق، وتفاصيل لوحات الترخيص، ومشاهد الأنفاق، وظروف التقاطعات، ومناظر المراقبة لمسافات طويلة. في نفس الوقت، لتوفير عرض النطاق الترددي للإرسال ومساحة التخزين، تستخدم العديد من الأنظمة ترميز الفيديو H.265. هذا أمر معقول من منظور تخزين المراقبة والمراقبة عالية الوضوح.
ومع ذلك، لا تزال العديد من أجهزة العرض، ومحطات التوزيع، ومنصات الاتصال، وعملاء الويب، وأنظمة الاتصال المدمجة تدعم بشكل محدود فيديو H.265 أو 4K. حتى عندما يمكن لمنصة ما نظرياً دعم تنسيق فيديو معين، قد لا يقوم عميل المحطة الطرفية الفعلي بفك تشفيره بسلاسة. قد تكون النتيجة فشل سحب الدفق، أو تأخر المعاينة، أو تجمد الصورة، أو الشاشة السوداء، أو عدم القدرة على عرض الفيديو في نظام القيادة.
المشكلة الأساسية: عدم تطابق الترميز والدقة والبروتوكول
في المشاريع الفعلية، تأتي مشاكل تقارب الفيديو عادة من ثلاث طبقات. الطبقة الأولى هي عدم تطابق الترميز، مثل الحاجة إلى تحويل فيديو H.265 إلى H.264 لمزيد من التوافق مع المنصات والمحطات الطرفية. الطبقة الثانية هي عدم تطابق الدقة، مثل الحاجة إلى تحويل فيديو 4K إلى 1080P لشاشات التوزيع، أو واجهات الويب، أو محطات فيديو SIP. الطبقة الثالثة هي عدم تطابق البروتوكول، مثل الحاجة إلى إخراج فيديو GB28181 كـ SIP، أو WebRTC، أو FLV، أو RTMP، أو HLS، أو تنسيقات أخرى.
هذه المشاكل مترابطة بشكل وثيق. قد تكون المنصة قادرة على سحب دفق GB28181 ولكنها لا تدعم ترميز H.265 الأصلي. قد تدعم صفحة الأوامر المعتمدة على المتصفح WebRTC ولكنها لا تستطيع تشغيل H.265 مباشرة. قد تحتاج منصة توزيع SIP إلى فيديو في جلسة وسائط SIP قياسية ولكن المصدر الأصلي يأتي من منصة فيديو معيارية وطنية. بدون التحويل، يكون مورد الفيديو موجوداً، ولكن لا يمكن استخدامه بفعالية.
لذلك، لا يقتصر تقارب الفيديو على ربط المنصات فقط. بل يتطلب أيضاً تحويلاً برمجياً للفيديو، وتحويل الدفق، وضبط الدقة، والتحكم في معدل الإطارات، وتحسين معدل البت، وتكييف البروتوكول.
لماذا غالباً لا يكون التحويل البرمجي عبر البرامج كافياً
بالنسبة لعدد قليل من التدفقات منخفضة الدقة، قد يكون التحويل البرمجي عبر البرامج مقبولاً. يمكن لبعض المنصات تحويل عدة قنوات من H.265 إلى H.264 باستخدام موارد وحدة المعالجة المركزية، خاصة عندما لا تكون الدقة عالية ويكون معدل الإطارات معتدلاً. ومع ذلك، غالباً ما تتضمن مشاريع النقل الذكية فيديو عالي الدقة ومتعدد القنوات.
عندما يكون فيديو الإدخال بدقة 4K، يزداد عبء العمل بشكل حاد. فك التشفير في الوقت الفعلي، وتحويل التنسيق، وإعادة الترميز، وتدفق الإخراج تتطلب موارد حوسبة قوية. قد تكافح منصة برمجية عامة لمعالجة العديد من تدفقات 4K بشكل مستمر، خاصة عندما تكون هناك حاجة إلى تنسيقات إخراج متعددة في نفس الوقت.
هذا هو السبب في استخدام التحويل البرمجي بمساعدة الأجهزة غالباً في تقارب فيديو النقل الذكي. يمكن لخادم تحويل برمجي مخصص مزود بوحدة معالجة رسومات أو قدرة تسريع الفيديو معالجة قنوات متعددة بشكل أكثر كفاءة. في تصميم مرجعي عملي، يمكن التخطيط لمثل هذا النظام لأحمال عمل مثل تحويل 16 قناة من فيديو 1080P، أو 8 قنوات من تحويل 4K بمعدل 30 إطارًا في الثانية، أو 4 قنوات من تحويل 4K بمعدل 60 إطارًا في الثانية، حسب التكوين وإعدادات الترميز ومتطلبات الإخراج.
| التحدي | السبب النموذجي | طريقة المعالجة الموصى بها |
|---|---|---|
| شاشة سوداء أو فشل في المعاينة | لا يستطيع العميل أو المنصة فك تشفير تدفقات H.265 أو 4K | تحويل H.265 إلى H.264 وتقليل دقة 4K إلى 1080P عند الحاجة |
| سحب التدفق بطيء أو غير مستقر | تطلب أنظمة متعددة الفيديو من مصادر مختلفة | استخدام طبقة مركزية للوصول إلى الفيديو وتوزيعه |
| لا يمكن لصفحة توزيع الويب تشغيل الفيديو | لا يدعم تشغيل المتصفح تنسيق التدفق الأصلي | إخراج FLV، WebRTC، HLS، أو تنسيقات أخرى صديقة للويب |
| لا يمكن لنظام توزيع SIP استخدام فيديو الكاميرا | لا يتطابق فيديو GB28181 مباشرة مع سير عمل وسائط SIP | تحويل تدفقات GB28181 إلى وسائط قياسية متوافقة مع SIP |
| لا يمكن للمنصة العليا استقبال فيديو متوافق | يوجد تتالي GB28181 لكن الترميز أو معدل البت غير مناسب | ضبط الترميز والدقة ومعدل الإطارات ومعدل البت قبل إعادة التوجيه |
طبقة تحويل برمجي مادية للموارد المرئية المعقدة
يمكن وضع طبقة تحويل فيديو مخصصة بين المنصات المصدر وتطبيقات الأعمال. على جانب الإدخال، يمكنها استقبال الفيديو من منصات GB28181، والكاميرات، ومسجلات NVR، وأنظمة إدارة الفيديو، وتدفقات RTSP، وتدفقات RTMP الدافعة، أو مصادر فيديو أخرى. على جانب الإخراج، يمكنها توفير تدفقات مناسبة للمنصات العليا، وأنظمة التوزيع، وتطبيقات الويب، وأنظمة التصور على الشاشات الكبيرة.
ميزة هذه البنية هي أن مصدر الفيديو الأصلي لا يحتاج إلى التغيير. يمكن للكاميرات والمنصات وأنظمة التخزين الحالية الاستمرار في العمل بطريقتها الأصلية. تتولى طبقة التحويل البرمجي أعمال التوافق، بما في ذلك تحويل الترميز، وضبط الدقة، وتقليل معدل الإطارات، والتحكم في معدل البت، وتحويل البروتوكول.
بالنسبة لتسليم المشروع، هذا مهم لأن أنظمة النقل غالباً ما تتضمن أصولاً موجودة مسبقاً. تم نشر العديد من الكاميرات والمنصات بالفعل. سيكون استبدالها مكلفاً ومعطلاً. تساعد طبقة تقارب الفيديو في حماية الاستثمار الحالي مع جعل الفيديو قابلاً للاستخدام من قبل تطبيقات النقل الذكية الجديدة.
التتالي وفق GB28181 للتواصل الشبكي للمنصات متعددة المستويات
يُستخدم GB28181 على نطاق واسع في التواصل الشبكي لمراقبة الفيديو. في مشاريع النقل، قد تحتاج منصات الفيديو ذات المستوى الأدنى إلى إرسال موارد فيديو محددة إلى منصات القيادة ذات المستوى الأعلى، أو أنظمة الإشراف على مستوى المدينة، أو منصات النقل الإقليمية، أو أنظمة الطرف الثالث المعيارية الوطنية.
في هذا السيناريو، يمكن لطبقة التحويل البرمجي دعم التواصل الشبكي للمستوى الأعلى والأدنى وفق GB28181. يمكنها سحب الفيديو من منصات GB28181 الرئيسية وإعادة توجيه التدفقات المعالجة إلى منصة GB28181 أخرى. خلال هذه العملية، يمكن للنظام ضبط ترميز الفيديو والدقة ومعدل الإطارات ومعدل البت وفقاً لمتطلبات المنصة المستقبلة.
هذا يحل مشكلة مهمة: اتصال GB28181 وحده لا يضمن الاستخدام السلس للفيديو. إذا استلمت المنصة العليا تدفقاً لا يمكنها فك تشفيره أو عرضه أو معالجته بكفاءة، فإن الاتصال لا يكون ناجحاً حقاً. يجب أن يضمن تصميم تقارب الفيديو المناسب حصول المنصة المستقبلة على الفيديو بتنسيق يمكنها استخدامه فعلياً.
ربط فيديو المراقبة بأنظمة توزيع SIP
العديد من أنظمة القيادة في النقل الذكي مبنية حول اتصالات الدمج القائمة على SIP. قد تدعم هذه المنصات التوزيع الصوتي، ومكالمات الفيديو، والاتصال الداخلي، والمؤتمرات، والاتصالات في حالات الطوارئ، والتنسيق القيادي. ومع ذلك، فإن سير عمل الوسائط الخاص بها يختلف عن منصة مراقبة GB28181 التقليدية.
عندما يحتاج مشروع طريق سريع إلى إحضار فيديو كاميرا GB28181 إلى نظام توزيع SIP، قد لا يكون الوصول المباشر كافياً. قد يحتاج الفيديو إلى التحويل إلى جلسة وسائط قياسية متوافقة مع SIP. في نفس الوقت، قد يحتاج H.265 إلى التحويل إلى H.264، وقد يحتاج فيديو 4K إلى التحويل إلى 1080P بحيث يمكن لمحطات التوزيع، وهواتف الفيديو، وعملاء القيادة، أو أنظمة الشاشات الكبيرة عرض الفيديو بسلاسة.
هذه القدرة مفيدة للقيادة المرئية. على سبيل المثال، عندما يعالج مشغل حادثاً على طريق سريع، قد يحتاج النظام إلى عرض كاميرات قريبة داخل منصة التوزيع، وبدء الاتصال الصوتي مع موظفين ميدانيين، ومشاركة المعلومات المرئية مع مستخدمي القيادة. من خلال تحويل الفيديو المعياري الوطني إلى موارد فيديو متوافقة مع SIP، يمكن للمراقبة والاتصال العمل معاً في نفس سير العمل التشغيلي.
جعل الفيديو متاحاً لشاشات القيادة المعتمدة على الويب
تستخدم العديد من أنظمة التوزيع الحديثة واجهات تعتمد على الويب. غالباً ما تُبنى لوحات معلومات القيادة، وأنظمة التصور على الشاشات الكبيرة، ولوحات عمليات النقل، وصفحات إدارة الطوارئ بتقنيات الويب. هذا يسهل النشر لأنه يمكن للمستخدمين الوصول إلى النظام من خلال المتصفحات أو عملاء الويب.
ومع ذلك، فإن تشغيل الفيديو في المتصفح له قيود. يُستخدم WebRTC على نطاق واسع للاتصال المرئي منخفض الكمون على الويب، لكن WebRTC نفسه لا يدعم H.265 مباشرة في العديد من بيئات النشر الشائعة. إذا كان فيديو المصدر هو H.265، فقد لا تتمكن واجهة توزيع الويب من تشغيله مباشرة.
يمكن لطبقة التحويل البرمجي للفيديو إخراج تنسيقات صديقة للويب مثل FLV، أو WebRTC، أو HLS، أو طرق دفق أخرى مدعومة. هذا يسمح بعرض نفس مصدر المراقبة في لوحة تحكم ويب بعد التحويل. لمشاريع النقل، هذا مفيد بشكل خاص عندما تحتاج المنصة إلى عرض فيديو الكاميرا، وأحداث حركة المرور، ونتائج تحليلات الذكاء الاصطناعي، وعناصر التحكم في التوزيع على نفس صفحة الويب.
تكييف البروتوكول لأنظمة الأعمال المختلفة
يجب ألا يعتمد حل تقارب فيديو النقل الذكي على بروتوكول واحد فقط. قد تتطلب الأنظمة المختلفة طرق وصول مختلفة. GB/T28181 مهم للتواصل الشبكي القياسي للفيديو الوطني. SIP مفيد لتوزيع الاتصال والاتصال الداخلي المرئي. RTSP شائع للوصول إلى الكاميرا والتدفق المحلي. يمكن استخدام RTMP للدفع وسحب التدفق. غالباً ما يُستخدم FLV عبر HTTP أو WebSocket في عرض الويب. HLS مفيد للتوافق الواسع. RTP و WebRTC قيمان لتطبيقات الوسائط في الوقت الفعلي.
لهذا السبب، يجب أن تدعم طبقة التقارب العملية بروتوكولات إدخال وإخراج متعددة. لا ينبغي لها فقط تحويل ترميز الفيديو، ولكن أيضاً تحويل الوسائط إلى التنسيق المطلوب من قبل كل منصة أعمال. هذا يسمح لنفس مصدر الفيديو بخدمة سيناريوهات المراقبة، والتوزيع، وتحليلات الذكاء الاصطناعي، والعرض على الشاشات الكبيرة، والوصول عبر الهاتف المحمول، وتطبيقات الويب.
في بعض المشاريع، قد تحتاج طبقة التحويل البرمجي أيضاً إلى قدرات اتصال بسيطة، مثل تسجيل SIP مدمج أو تفاعل يشبه البرنامج الطرفي اللين، بحيث يمكنها المشاركة في سير عمل الاتصال بدلاً من إعادة توجيه التدفقات فقط. يعتمد الشرط الدقيق على ما إذا كان المشروع يركز على المراقبة، أو التوزيع، أو الاستجابة للطوارئ، أو التعاون متعدد الأنظمة.
تقليل تعقيد التكامل أثناء التسليم
أحد أسباب جاذبية تقارب الفيديو القائم على الأجهزة هو بساطة النشر. مقارنة بالتحويل البرمجي المخصص عبر البرامج أو تطوير بطاقة GPU، يمكن لجهاز تحويل برمجي متكامل أن يقلل من ضبط مستوى التعليمات البرمجية وتكييف مستوى برنامج التشغيل. كما تجعل واجهة الإدارة الرسومية التكوين أسهل لمهندسي المشاريع.
هذا لا يعني أن التخطيط غير ضروري. لا يزال فريق المشروع بحاجة إلى تأكيد مصادر الإدخال، وبروتوكولات الإخراج، وكمية التدفق، وأهداف الدقة، ومتطلبات الترميز، وحدود معدل البت، ومتطلبات معدل الإطارات، والمسارات الشبكية، وتوافق المنصة المستقبلة. ومع ذلك، يمكن لواجهة إدارة متكاملة أن تقلل من عبء التطوير منخفض المستوى وتجعل النظام أسهل في التسليم.
بالنسبة لمتكاملي الأنظمة، يمكن أن تكون هذه ميزة كبيرة. غالباً ما يكون لمشاريع النقل الذكية جداول زمنية ضيقة والعديد من البائعين المشاركين. يساعد تقليل التطوير المخصص في تقصير دورات التصحيح ويقلل من خطر وصول الفيديو غير المستقر أثناء اختبار القبول.
البنية الموصى بها لمشاريع الطرق السريعة الذكية
في مشروع طريق سريع ذكي، قد يتم نشر الكاميرات على طول الطرق، والأنفاق، ومحطات الرسوم، ومناطق الخدمة، والجسور، والتقاطعات، ونقاط التحكم في حركة المرور. قد تكون هذه الكاميرات متصلة بالفعل بمنصة فيديو موجودة. قد يكون لدى مركز القيادة أيضاً منصة اتصالات توزيع منفصلة، ونظام عرض على شاشة كبيرة، ومنصة تحليلات ذكاء اصطناعي، ولوحة تحكم لإدارة حركة المرور تعتمد على الويب.
البنية الموصى بها هي إضافة طبقة تقارب وتحويل برمجي للفيديو بين منصة الفيديو الحالية وأنظمة الأعمال العليا. تسحب هذه الطبقة أو تستقبل موارد الفيديو المحددة، وتحولها وفقاً لمتطلبات العمل، ثم توزعها على المنصة المقابلة. يمكن تتالي تدفقات GB28181 إلى الأعلى، ويمكن إرسال فيديو متوافق مع SIP إلى أنظمة التوزيع، ويمكن توفير تدفقات WebRTC أو FLV إلى لوحات تحكم الويب.
تتجنب هذه البنية الطبقية التكامل المباشر من نقطة إلى نقطة بين كل نظام. بدلاً من مطالبة كل منصة بفهم كل كاميرا وبرنامج ترميز وبروتوكول، تصبح طبقة التقارب نقطة التكيف المركزية. هذا يحسن قابلية الصيانة ويسهل التوسع في المستقبل.
الفوائد التشغيلية لمراكز قيادة حركة المرور
عندما يتم تصميم تقارب الفيديو بشكل صحيح، يكتسب المشغلون تجربة مشاهدة وتوزيع أكثر اتساقاً. يمكن أن يظهر مصدر فيديو من نظام مراقبة الطرق السريعة في لوحة تحكم القيادة، أو وحدة تحكم توزيع SIP، أو شاشة ويب كبيرة، أو منصة GB28181 ذات المستوى الأعلى بعد التحويل. لم يعد المشغلون بحاجة إلى التبديل بين الأنظمة المعزولة فقط لمشاهدة نفس مشهد الطريق.
يمكن لمركز القيادة أيضاً الاستجابة بشكل أسرع أثناء حوادث المرور. عند حدوث ازدحام، أو حوادث، أو مخاطر على الطريق، أو حالات طوارئ في الأنفاق، أو أحداث غير طبيعية، يمكن توصيل الفيديو إلى المنصة التي تحتاج إليه أكثر. يمكن لفريق التوزيع الجمع بين الفيديو المباشر، والاتصال الصوتي، وبيانات الأحداث، وتنبيهات الذكاء الاصطناعي، ومعلومات حركة المرور في سير عمل واحد.
بالنسبة للإدارات الإدارية، لا تكمن القيمة في التوافق التقني فقط. بل تعمل أيضاً على تحسين كفاءة النظام، وحماية الاستثمار الحالي، وتقليل البناء المكرر، ودعم توسع المنصة في المستقبل.
نقاط التخطيط الرئيسية قبل النشر
قبل نشر حل تقارب الفيديو، يجب على فريق المشروع سرد جميع الأنظمة المصدر وأنظمة الاستقبال. يشمل ذلك منصات الكاميرا، ومنصات GB28181، وخوادم تحليلات الذكاء الاصطناعي، ومنصات توزيع SIP، ولوحات تحكم الويب، وعملاء الأجهزة المحمولة، وأنظمة التسجيل، وأنظمة القيادة التابعة لجهات خارجية.
الخطوة التالية هي تحديد قواعد تحويل التدفق. قد يحتاج بعض الفيديو فقط إلى تحويل البروتوكول. قد يحتاج البعض إلى تحويل H.265 إلى H.264. قد يحتاج البعض إلى تحويل 4K إلى 1080P. قد يحتاج البعض إلى تقليل معدل البت لمطابقة سعة الشبكة. قد يحتاج البعض إلى ضبط معدل الإطارات لعرض الويب أو معالجة الذكاء الاصطناعي.
أخيراً، يجب أن يشمل الاختبار حمل التدفق الحقيقي. لا يكفي عرض قناة واحدة لمشاريع النقل. يجب على المهندسين اختبار التزامن متعدد القنوات، وحمل تحويل 4K، واستقرار تتالي GB28181، وتوافق فيديو SIP، وتشغيل WebRTC، وكمون الشبكة، والتشغيل طويل الأجل قبل القبول النهائي.
الأسئلة الشائعة
لماذا تفشل كاميرات المرور بدقة 4K أحياناً في أنظمة التوزيع؟
العديد من أنظمة التوزيع والمحطات الطرفية غير مصممة لفك تشفير تدفقات 4K عالية الدقة مباشرة، خاصة عندما يستخدم الفيديو H.265. يمكن أن يؤدي تحويل الفيديو إلى دقة وترميز أكثر توافقاً إلى حل هذه المشكلة.
هل تحويل البروتوكول هو نفس التحويل البرمجي للفيديو؟
لا. يغير تحويل البروتوكول كيفية تسليم التدفق، مثل من GB28181 إلى WebRTC. يغير التحويل البرمجي للفيديو الترميز أو الدقة أو معدل الإطارات أو معدل البت. تحتاج العديد من المشاريع إلى كليهما.
هل يمكن لمنصة GB28181 إرسال فيديو إلى منصة GB28181 أخرى بدون تحويل برمجي؟
يمكن ذلك في بعض الحالات، ولكن إذا كانت المنصة المستقبلة لا تستطيع التعامل مع الترميز أو الدقة أو معدل الإطارات أو معدل البت الأصلي، فلا يزال التحويل البرمجي مطلوباً من أجل مشاهدة مستقرة.
لماذا يعتبر WebRTC صعباً مع فيديو H.265؟
لا تدعم العديد من بيئات WebRTC القائمة على المتصفح تشغيل H.265 مباشرة. غالباً ما يكون تحويل تدفق المصدر إلى تنسيق مدعوم على نطاق أوسع ضرورياً للوحات تحكم الويب.
ما الذي يجب اختباره قبل قبول المشروع؟
تشمل الاختبارات الهامة الوصول متعدد القنوات، والتحويل من H.265 إلى H.264، والتحويل من 4K إلى 1080P، وتتالي GB28181، وإخراج فيديو SIP، وتشغيل الويب، واستقرار المدة الطويلة، واستخدام عرض النطاق الترددي للشبكة.
هل تحل طبقة تقارب الفيديو محل منصة المراقبة الأصلية؟
لا. تعمل عادةً بين منصات الفيديو الحالية وتطبيقات الأعمال. يمكن أن تظل منصة المراقبة الأصلية قيد الاستخدام، بينما تقوم طبقة التقارب بتكييف الفيديو للتوزيع، وعرض الويب، وتحليلات الذكاء الاصطناعي، والمشاركة رفيعة المستوى.
