هل يدعم المورد WebRTC لمعاينات عن بُعد بزمن استجابة منخفض للغاية؟

لقد شاهدت العديد من المدمجين يخسرون عقودًا لأن معاينتهم عن بُعد تأخرت بمقدار 3-5 ثوانٍ. هذا التأخير يقتل التحكم PTZ¹ ويقتل الصفقات.

نعم، تدعم كاميراتنا بالكامل WebRTC لمعاينات عن بُعد بزمن استجابة منخفض للغاية. يقلل WebRTC من زمن الاستجابة من طرف إلى طرف من 2-5 ثوانٍ المعتادة إلى أقل من 500 مللي ثانية. هذا يعني أنه يمكنك التحكم في كاميرا PTZ عبر شبكة 4G ورؤية الحركة على الفور تقريبًا في أي متصفح حديث.

معاينة عن بعد بزمن استجابة منخفض للغاية WebRTC كاميرا PTZ

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

هل يمكن لـ WebRTC تحقيق زمن استجابة أقل من 500 مللي ثانية للتحكم في PTZ في الوقت الفعلي عبر شبكة 4G²?

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

نعم، يمكن لـ WebRTC تحقيق زمن استجابة أقل من 500 مللي ثانية للتحكم في PTZ في الوقت الفعلي عبر 4G. يستخدم نقل UDP بدلاً من TCP، والذي يتجاوز عملية المصافحة الثقيلة. تزيل البرامج الثابتة لدينا أيضًا إطارات B من خط أنابيب الترميز، لذلك ترسل الكاميرا كل إطار بأقل تأخير.

WebRTC زمن استجابة أقل من 500 مللي ثانية تحكم PTZ شبكة 4G

لماذا تفشل البروتوكولات التقليدية في التحكم في PTZ في الوقت الفعلي

لفهم سبب أهمية WebRTC، تحتاج إلى رؤية أين تفشل البروتوكولات القديمة. RTSP عبر TCP، و HLS، وحتى العديد من حلول P2P تشترك جميعها في مشكلة واحدة: إنها تضيف مخازن مؤقتة. هذه المخازن المؤقتة موجودة لسبب وجيه - فهي تعمل على سلاسة تشغيل الفيديو. لكن التشغيل السلس والتحكم في الوقت الفعلي هما هدفان متعارضان.

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

كيف يحل تطبيق WebRTC الخاص بنا هذه المشكلة

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

على جانب الأجهزة لدينا، اتخذنا ثلاثة خيارات محددة للبرامج الثابتة:

• لا توجد إطارات B في تدفق WebRTC. تتطلب إطارات B من وحدة فك التشفير الانتظار للحصول على إطارات مستقبلية قبل عرض الإطار الحالي. نستخدم H.264 بروفايل أساسي³ لقناة WebRTC، والتي تستخدم فقط إطارات I وإطارات P. هذا وحده يقلل من تأخير فك التشفير بمقدار 100-200 مللي ثانية.
• قناة ترميز مخصصة. يمكن لكاميراتنا تشغيل خطي ترميز في نفس الوقت. أحدهما يعالج تسجيل NVR الخاص بك بجودة كاملة. الآخر هو تدفق خفيف ومنخفض الكمون فقط لـ WebRTC. لا يتنافسان على الموارد.
• تكيف عرض النطاق الترددي GCC. يتضمن WebRTC التحكم في ازدحام Google. عندما ينخفض عرض النطاق الترددي لشبكة 4G - على سبيل المثال، أثناء عاصفة مطيرة في ريف تكساس - تقوم الكاميرا تلقائيًا بخفض الدقة للحفاظ على استمرارية التدفق وتحديثه.

أرقام العالم الحقيقي

متري	RTSP عبر TCP	HLS	WebRTC الخاص بنا
زمن الاستجابة النموذجي	1500 مللي ثانية – 3000 مللي ثانية	4000 مللي ثانية – 10000 مللي ثانية	200 مللي ثانية – 500 مللي ثانية
المخزن المؤقت المطلوب	نعم (1-3 ثوانٍ)	نعم (3-10 ثوانٍ)	لا حاجة لمخزن مؤقت
قابلية استخدام PTZ	فقير	غير قابل للاستخدام	شعور الوقت الحقيقي
تكييف عرض النطاق الترددي لشبكة الجيل الرابع (4G)	يدوي	قائم على القطاعات	تلقائي (GCC)

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

هل WebRTC متوافق مع جميع المتصفحات الحديثة (Chrome/Firefox/Safari) بدون تطبيق؟

ما زلت أتلقى مكالمات من المدمجين الذين يعلقون بأنظمة كاميرات قديمة تتطلب Internet Explorer وإضافات ActiveX. يكره المستخدمون النهائيون ذلك. تمنعه أقسام تكنولوجيا المعلومات الخاصة بهم. إنه طريق مسدود.

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

توافق متصفح WebRTC Chrome Firefox Safari لا يوجد تطبيق

مشكلة الإضافة حقيقية

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

تم تصميم WebRTC بواسطة Google خصيصًا للتشغيل داخل المتصفح. أصبح معيارًا لـ W3C. قام كل بائع متصفح رئيسي بتطبيقه. هذه ليست تقنية تجريبية. إنها نفس التقنية التي تشغل Google Meet ومكالمات الفيديو عبر Facebook Messenger و Discord.

تفاصيل خاصة بالمتصفح يجب أن تعرفها

لا تتعامل جميع المتصفحات مع WebRTC بنفس الطريقة. إليك الاختلافات العملية:

• Chrome (سطح المكتب و Android): دعم كامل لـ WebRTC. يعمل فك تشفير H.264 بالأجهزة بشكل جيد. هذا هو المتصفح الأكثر اختبارًا وموثوقية لبث WebRTC. سيستخدم معظم المستخدمين النهائيين لديك Chrome.
• Safari (macOS و iOS): أضافت Apple دعم WebRTC في Safari 11. إنه يعمل، ولكن Safari لديه أحيانًا مشكلات مع تكوينات STUN/TURN محددة. تم اختبار البرامج الثابتة الخاصة بنا مقابل مكدس WebRTC الخاص بـ Safari، ونتعامل مع اختلافات التفاوض على SDP تلقائيًا.
• فايرفوكس: دعم كامل. يستخدم فايرفوكس تنفيذه الخاص لـ WebRTC، وهو يختلف قليلاً عن تنفيذ كروم. خادم الإشارة الخاص بنا يتعامل مع كليهما دون أي إعداد من جانبك.
• إيدج: نظرًا لأن إيدج انتقل إلى محرك كروميوم، فإنه يتصرف تمامًا مثل كروم لأغراض WebRTC.

ماذا عن الهواتف المحمولة؟

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

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

لا يوجد تطبيق يعني نشرًا أسرع

بالنسبة للمكاملين، فإن ميزة “عدم وجود تطبيق” تتجاوز الراحة. هذا يعني:

• لا توجد عملية موافقة لمتجر التطبيقات.
• لا توجد تحديثات للتطبيقات لإدارتها.
• لا توجد مشاكل توافق مع إصدارات أندرويد المختلفة.
• لا توجد مكالمات دعم حول “تعطل التطبيق”.”

أنت تعطي عميلك عنوان URL وكلمة مرور. هذا هو النشر الكامل لجانب المشاهدة.

كيف يتعامل WebRTC مع “UDP Hole Punching” للكاميرات خلف NAT الخاص بمزود الخدمة؟

هذا هو السؤال الذي يفصل بين الأشخاص الذين قاموا بالفعل بنشر كاميرات 4G والأشخاص الذين قرأوا عنها فقط. اجتياز NAT هو أكبر تحدٍ تقني في الوصول عن بُعد إلى كاميرات 4G. لقد رأيته يفسد مشاريع بأكملها.

يستخدم WebRTC نهجًا ثلاثي الطبقات يسمى ICE (إنشاء الاتصال التفاعلي)⁴ للاختراق عبر NAT. يحاول الاتصال المباشر أولاً عبر STUN⁵, ، ثم يعود إلى خادم ترحيل TURN⁶ إذا كان المُزوّد يستخدم NAT متناظرًا. تحتوي كاميراتنا على حزمة ICE/STUN/TURN كاملة مدمجة في البرنامج الثابت، لذا فهي تتعامل مع هذا تلقائيًا.

WebRTC UDP hole punching NAT traversal كاميرا 4G

لماذا يعتبر NAT الخاص بـ 4G أصعب من NAT المنزلي

عند نشر كاميرا على شبكة منزلية، يستخدم جهاز التوجيه عادةً NAT من نوع “المخروط الكامل” أو “المخروط المقيد”. هذه الأنواع من NAT سهلة نسبيًا للاختراق. يمكن لخادم STUN بسيط اكتشاف عنوان IP العام والمنفذ، ويعمل الاتصال.

تختلف شركات الاتصالات 4G. معظم شركات الاتصالات - T-Mobile و Verizon و AT&T وما يعادلها في أوروبا والشرق الأوسط - تستخدم NAT متناظر⁷. في NAT المتناظر، يقوم المُزوّد بتعيين منفذ خارجي مختلف لكل اتصال جديد. هذا يعني أن خدعة STUN لا تعمل. المنفذ الذي يكتشفه STUN ليس هو نفس المنفذ الذي سيتم استخدامه لتدفق الفيديو الفعلي.

هذا هو السبب في فشل العديد من كاميرات 4G الرخيصة في الميدان. إنها تعمل بشكل جيد على المكتب (متصلة بشبكة Wi-Fi المكتبية) ولكنها تفشل عندما تضع فيها شريحة SIM حقيقية وتنشرها على برج خلوي.

اجتياز NAT ثلاثي الطبقات الخاص بنا

يقوم البرنامج الثابت الخاص بنا بتنفيذ إطار عمل ICE الكامل. إليك كيفية عمله عمليًا:

الطبقة	الطريقة	متى يتم استخدامه	معدل النجاح على 4G
الطبقة 1	اتصال مباشر من نظير إلى نظير (مرشح المضيف)	كلا الجانبين على نفس الشبكة	نادر في عمليات نشر 4G
الطبقة 2	STUN (انعكاسي للخادم)	NAT غير متناظر	~30% من شركات الاتصالات 4G
الطبقة 3	TURN (ترحيل)	NAT متناظر	100% — يعمل دائمًا

تحاول الكاميرا الطبقة 1 أولاً. إذا فشلت (وهو ما يحدث عادةً)، فإنها تحاول الطبقة 2. إذا فشلت هذه أيضًا (وهو أمر شائع في شبكات 4G)، فإنها تعود إلى الطبقة 3. يعمل خادم TURN كـ "مرحّل" — ترسل الكاميرا الفيديو إلى خادم TURN، ويقوم المشاهد بسحب الفيديو من خادم TURN. يضيف هذا قدرًا صغيرًا من التأخير (عادةً 50-100 مللي ثانية)، ولكنه يضمن عمل الاتصال.

خيارات خادم TURN

لديك خياران لخادم TURN:

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

بالنسبة لحالة استخدام David — نشر كاميرات PTZ التي تعمل بالطاقة الشمسية في مزارع تكساس النائية — فإن مرحّل TURN ليس اختياريًا. إنه ضروري. تستخدم شركات الاتصالات التي تخدم المناطق الريفية دائمًا تقريبًا NAT المتماثل. بدون TURN، لن تتصل الكاميرا ببساطة.

الأمان أثناء الترحيل

أحد المخاوف التي أسمعها من المديرين التنفيذيين للتكنولوجيا هو: “إذا كان الفيديو يمر عبر خادم مرحّل، فهل لا يزال آمنًا؟” الإجابة هي نعم. يقوم WebRTC بتشفير جميع الوسائط باستخدام SRTP (بروتوكول النقل الآمن في الوقت الفعلي)⁸ وجميع الإشارات باستخدام DTLS (بروتوكول أمان طبقة النقل Datagram). يقوم خادم TURN بترحيل الحزم المشفرة. لا يمكنه رؤية محتوى الفيديو أو تسجيله. هذا التشفير إلزامي في معيار WebRTC — لا يمكن إيقافه.

هل سيقوم بث WebRTC تلقائيًا بضبط جودته بناءً على سرعة الإنترنت المحلية لدي؟

لقد كنت في مكالمات حيث يعرض أحد المدمجين عرضًا توضيحيًا مباشرًا لعميله، ويتجمد البث في منتصف العرض التقديمي. كانت شبكة Wi-Fi الخاصة بمكتب العميل مزدحمة. استمرت الكاميرا في إرسال بث بسرعة 4 ميجابت في الثانية إلى اتصال لم يكن بإمكانه التعامل سوى مع 1 ميجابت في الثانية. كانت النتيجة شاشة مجمدة ومدمج محرج.

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

WebRTC تعديل جودة معدل البت التكيفي سرعة الإنترنت

كيف يعمل GCC باللغة الإنجليزية البسيطة

GCC هو اختصار لـ Google Congestion Control. إنه مدمج في بروتوكول WebRTC. إليك ما يفعله بعبارات بسيطة:

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

تستجيب الكاميرا عن طريق القيام بواحد أو أكثر مما يلي:

• خفض الدقة (على سبيل المثال، من 1080p إلى 720p أو حتى 480p).
• تقليل معدل الإطارات (على سبيل المثال، من 25 إطارًا في الثانية إلى 15 إطارًا في الثانية).
• زيادة الضغط (جودة أقل لكل إطار).

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

كلا الجانبين مهمان

تعمل معدلات البت التكيفية في WebRTC على طرفي الاتصال:

• جانب الكاميرا (تحميل): اتصال 4G من الكاميرا إلى الإنترنت. هذا غالبًا ما يكون عنق الزجاجة. يمكن أن تتراوح سرعات التحميل عبر 4G من 1 ميجابت في الثانية إلى 20 ميجابت في الثانية اعتمادًا على قوة الإشارة، ووقت اليوم، وازدحام الناقل.
• جانب المشاهد (تنزيل): اتصال الإنترنت للشخص الذي يشاهد. يمكن أن يكون هذا شبكة Wi-Fi مكتبية، أو نطاق عريض منزلي، أو حتى هاتف 4G آخر.

يراقب GCC المسار بأكمله. إذا كان أحد الجانبين بطيئًا، تتكيف الجودة. هذا شيء لا يمكن لـ RTSP القيام به. مع RTSP، تقوم بتعيين معدل بت ثابت. إذا لم تتمكن الشبكة من التعامل معه، ينقطع البث.

إرشادات عملية لعرض النطاق الترددي

بناءً على اختباراتنا عبر عشرات عمليات نشر 4G، إليك نطاقات عرض النطاق الترددي التي يمكنك توقعها:

حالة الشبكة	تحميل متاح	دقة WebRTC	معدل الإطارات	تجربة المشاهد
4G قوي (LTE)	10-20 ميجابت في الثانية	1080p	25 إطارًا في الثانية	ممتاز — تفاصيل كاملة
4G عادي	3-8 ميجابت في الثانية	720p	20 إطارًا في الثانية	جيد - واضح وسلس
4G ضعيف	1-2 ميجابت في الثانية	480p	15 إطارًا في الثانية	قابل للاستخدام - لا يزال PTZ يعمل
إشارة ضعيفة جدًا	أقل من 1 ميجابت في الثانية	360p	10 إطارات في الثانية	أساسي - تفاصيل منخفضة ولكن مباشر

النقطة الأساسية هي: البث لا يتوقف أبدًا. يتدهور بلطف. لدى عميلك دائمًا عرض مباشر، حتى في الظروف السيئة.

حدود المشاهدين المتزامنين

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

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

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

الخاتمة

WebRTC هو أفضل بروتوكول للتحكم في PTZ في الوقت الفعلي عبر 4G. تدعمه كاميراتنا على مستوى البرنامج الثابت مع اجتياز NAT كامل، ومعدل بت تكيفي، وتوافق المتصفح، وتشفير من طرف إلى طرف - جاهز للنشر التالي الخاص بك.

---

1. نظرة عامة على تقنية كاميرات التحريك والإمالة والتقريب ومتطلبات التحكم الخاصة بها. ︎↩︎ 2. خلفية عن شبكات الهاتف المحمول 4G وخصائصها ذات الصلة بالبث. ︎↩︎ 3. نظرة عامة تقنية على ملفات H.264، مع تسليط الضوء على ملف التعريف الأساسي للكمون المنخفض. ︎↩︎ 4. نظرة عامة على إطار عمل ICE لاجتياز NAT. ︎↩︎ 5. شرح بروتوكول STUN لاجتياز NAT. ︎↩︎ 6. شرح بروتوكول TURN كحل بديل لـ NAT المتماثل. ︎↩︎ 7. وصف NAT المتماثل ولماذا يعقد اتصالات P2P على شبكات 4G. ︎↩︎ 8. بروتوكول التشفير القياسي لتدفقات الوسائط WebRTC. ︎↩︎