تنفيذ WebRTC في خادم وسائط - الممارسة والسياسة

1. الجري إلى المتصفحات في الوقت الحقيقي - لا يوجد حل. أم هناك؟

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

يبدو أنه قد مرت سنوات عديدة وتم إنجاز الكثير من العمل. ما الإنجازات الرائعة في هذا المجال التي يمكن أن نلاحظها بعد 20 عامًا؟ دعنا نزيل غطاء الصندوق (بالطبع ، هذا ليس صندوق Pandora وليس "علبة من الديدان") ونرى ما التقنيات والقدرات الرائعة التي أصبحت متاحة بعد سنوات عديدة من العمل من قبل عشرات الآلاف من مهندسي البرمجيات الموهوبين. مبرمج من عام 1998 ، أرسل أول صوت عبر الشبكة ، طبيب يريد حلًا بسيطًا ورخيصًا وموثوقًا للتطبيب عن بُعد ، ومعلمًا يحتاج إلى إجراء درس عن بُعد - الآن يفتحون هذا الغطاء ، مليئًا بالآمال الساطعة ، وما الذي يرونه؟ في غليان هجومي مليء بالتسويق المذهل ، والرأسمالية الساخرة والمحاولات اليائسة من قبل المتحمسين لتحسين الأشياء ، فإن جميع أنواع برامج الترميز والبروتوكولات والتنسيقات والتطبيقات عائمة.هذا ما يقدمه حساء تكنولوجيا المعلومات "المجتمع" للمستهلك في الوقت الحقيقي. أمسك نفسك برائحة أقل ، حاول ، اختبر ، اشتري. لا يوجد حل بسيط وفعال. على عكس البث ، الذي لا يتطلب وقتًا حقيقيًا: لا يزال هناك لمدة 5 سنوات هناك معيار HLS يعمل على أي متصفحات وأجهزة حيث يمكن لمزود الحلول ببساطة تثبيت أداة HLS على خادمك والنوم بسلام.

هنا RTSP - الكثير من وحدات التحكم والمعدات المهنية تلعبها ، ولكن المتصفحات لا تلعب. إليك RTMP - لا يريد Safari تشغيله على iOS ولا يلعبه جميع أجهزة Android. يحظره Chrome على أنه غير موثوق به. إليك MPEG2-TS - المتصفحات لا تلعبها أيضًا. ملحقات مصدر الوسائط HTML5 (MSE) - جيدة لأجزاء الفيديو التي تتراوح مدتها من 5 إلى 10 ثوانٍ (أي لـ HLS / Dash) ، ولكن للأجزاء القصيرة التي تقل عن ثانية واحدة - ليست ثابتة دائمًا ، تعمل بشكل مختلف في المتصفحات المختلفة ومرة ​​أخرى غير مدعوم على iOS.

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

دعونا نحدد مفهوم "قريب من الوقت الحقيقي". هذا أقل من 5 ثوانٍ تأخير للمراقبة بالفيديو وأقل من ثانية واحدة لعقد مؤتمرات الفيديو. متوسط ​​التأخير لبروتوكول HLS هو 20-30 ثانية. ربما تكون مناسبة إلى حد ما لرياض الأطفال ، ولكن للمراقبة الأمنية بالفيديو وعقد مؤتمرات الفيديو والندوات عبر الإنترنت ، هناك حاجة إلى تقنية أخرى.

لذلك ، حتى الآن ، وبشكل أدق حتى صيف عام 2017 ، لم يكن هناك معيار واحد أو بروتوكول واحد لبث الصوت والفيديو إلى أي متصفح على أي جهاز في الوقت الحقيقي. أسباب هذا الموقف ، سننظر في هذه المقالة لاحقًا. هذه ليست ذات طبيعة فنية ، هذه الأسباب. في هذه الأثناء ، دعنا نرى ما حدث في صيف عام 2017 ، وهو على الأقل ، ولكنه لا يزال يوفر تقنية تتيح لنا حل المشكلات المذكورة أعلاه. هذه التكنولوجيا هي WebRTC ، وقد كتب الكثير عنها حول هذا المورد وعلى الشبكة بشكل عام. لم يعد من الممكن تسميته جديدًا تمامًا ، وفي وقت كتابة هذا التقرير ، كان W3C يعتبر WebRTC 1.0 مشروعًا مكتملًا. لن نتحدث هنا عن ماهية WebRTC ؛ إذا لم يكن القارئ على دراية بهذه التقنية ، فإننا نقترح إجراء بحث على المحور أو في google والتعرف ،ما يتم استخدامه وكيف يعمل بعبارات عامة. هنا نقول فقط أن هذه التكنولوجيا تم تطويرها من أجل الاتصال من نظير إلى نظير في المتصفحات ، حيث يمكنك تنفيذ دردشة الفيديو والتطبيقات الصوتية دون أي خادم - يتصل المتصفح مباشرة بالمستعرض. يتم دعم WebRTC من قبل جميع المتصفحات على جميع الأجهزة ، وفي صيف عام 2017 ، أتت إلينا Apple أخيرًا وأضفتها إلى Safari على iOS. كان هذا الحدث هو الذي جعل WebRTC التكنولوجيا الأكثر شمولاً والمقبولة بشكل عام للتدفق في الوقت الفعلي إلى المتصفحات ، منذ غروب RTMP ، الذي بدأ في عام 2015.يتم دعم WebRTC من قبل جميع المتصفحات على جميع الأجهزة ، وفي صيف عام 2017 ، أتت إلينا Apple أخيرًا وأضفتها إلى Safari على iOS. كان هذا الحدث هو الذي جعل WebRTC التكنولوجيا الأكثر شمولاً والمقبولة بشكل عام للتدفق في الوقت الفعلي إلى المتصفحات ، منذ غروب RTMP ، الذي بدأ في عام 2015.يتم دعم WebRTC من قبل جميع المتصفحات على جميع الأجهزة ، وفي صيف عام 2017 ، أتت إلينا Apple أخيرًا وأضفتها إلى Safari على iOS. كان هذا الحدث هو الذي جعل WebRTC التكنولوجيا الأكثر شمولاً والمقبولة بشكل عام للتدفق في الوقت الفعلي إلى المتصفحات ، منذ غروب RTMP ، الذي بدأ في عام 2015.

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

لذا ، تم تشكيل كل شيء في النهاية؟ سيتمكن Akuna Matata ورياض الأطفال من تثبيت خادم الوسائط هذا في مكان ما على الاستضافة أو على AWS ، وإرسال تيار واحد من كل كاميرا هناك ، ومن هناك سيتم توزيعه بالفعل على متصفحات الآباء ، مع تأخير لا يزيد عن ثانية واحدة. بشكل عام - نعم ، الحياة تتحسن. لكن هناك مشاكل. وترتبط هذه المشاكل بحقيقة أن WebRTC ، كما كانت ، بعيدة المنال لمثل هذه المهام ؛ لم يتم تصميمها لهم وليست مناسبة لهم تمامًا. توجد مشكلات ، بالإضافة إلى توافق برنامج الترميز ، بشكل أساسي مع قابلية تطوير خادم الوسائط هذا. أي أنه في نفس الوقت يمكن تقديم 100 من الآباء من كمبيوتر خادم واحد ، و 500 أمر صعب بالفعل. على الرغم من أن الشبكة تسمح. وانظر إلى حمل المعالج على الخادم مع 100 اتصال - فهو قريب بالفعل من 90٪. كيف ذلك؟ بعد كل شيء ، فقط أرسل فيديو صوتي.

باستخدام نفس الدفق ، إذا تم إرساله عبر بروتوكول RTMP إلى مشغل Flash ، فيمكنك بسهولة دعم 2000 اتصال متزامن من خادم واحد. هل WebRTC هو 100 فقط؟
لماذا ا؟ هناك سببان: أولاً ، يعد بروتوكول WebRTC أكثر تكلفة من الناحية الحسابية - هناك ، على سبيل المثال ، يتم تشفير جميع البيانات ، ويستغرق الكثير من وقت المعالج. والسبب الثاني ، الذي سنناقشه بمزيد من التفصيل ، هو التنفيذ غير الفعال للغاية للبروتوكول من قبل منشئه - Google ، والذي يوفر شفرة c ++ المصدر لهذا التطبيق للتكيف في الخوادم والمداخل والتطبيقات الأخرى التي تريد دعم WebRTC: webrtc.org/native-code

2 توافق Native WebRTC API و Media Server من Google

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

دعونا نلقي نظرة على النقاط الرئيسية التي بسببها يمثل استخدام تطبيق WebRTC لخوادم الوسائط مشكلة كبيرة.

2-أ- الكود أكبر بعشر مرات مما يجب أن يكون وغير فعال للغاية

وهذا رقم مثبت. للبدء ، يمكنك تنزيل حوالي 5 غيغابايت من التعليمات البرمجية ، منها 500 ميغابايت فقط ذات صلة بـ WebRTC. ثم تحاول التخلص من التعليمات البرمجية غير الضرورية. بعد كل شيء ، بالنسبة لاحتياجات خادم الوسائط ، لا تحتاج إلى ترميز / فك تشفير ؛ يجب أن يتلقى الخادم المحتوى وإعادة توجيهه إلى الجميع. عندما قمت بإزالة كل ما هو غير ضروري يمكنك (ويمكنك إزالة أقل بكثير مما تريد) ، لا يزال لديك 100 ميغابايت من التعليمات البرمجية. هذا شخصية وحشية. إنها هي أكبر بعشر مرات مما يجب أن تكون.

بالمناسبة ، عند هذه النقطة ، سيقول الكثير - كيف لا حاجة إلى التشفير / فك التشفير؟ ماذا عن تحويل الشفرة من AAC إلى Opus والعكس صحيح؟ ماذا عن تحويل ترميز VP9> H264؟ إذا كنت ستقوم بعمل مثل هذا التحويل على الخادم ، فلا يمكنك سحب 5 اتصالات متزامنة أيضًا. إذا كان ذلك ضروريًا حقًا ، فيجب ألا يتم التحويل عن طريق خادم وسائط ، ولكن عن طريق برنامج آخر.

ولكن دعونا نعود إلى مشكلة الشفرة المنتفخة ونوضحها. ما هو برأيك عمق مكدس الاستدعاءات الوظيفية عند إرسال إطار فيديو مضغوط بالفعل؟ مكالمة واحدة إلى Winsock (على Windows) لوظيفة الإرسال أو الإرسال إلى (WSASend / WSASendTo)؟ لا ، بالطبع ، هناك المزيد من العمل الذي يتعين القيام به. في حالة WebRTC ، تحتاج إلى حزم الإطار عبر بروتوكول RTP وتشفيره ، وهو ما يمنحنا بروتوكول SRTP. من الضروري حفظ الإطار في حالة فقدان الحزمة لإرساله مرة أخرى لاحقًا. كم عدد الكائنات والخيوط التي يجب أن تشارك في هذا الموضوع؟

إليك كيفية تنفيذ WebRTC 61:



كما ترى من لقطة الشاشة هذه ، من اللحظة التي نطعم فيها الإطار المضغوط إلى WebRTC ، حتى اللحظة التي نضعها في قائمة انتظار كائن Paced_Sender ، يكون عمق مكدس الاستدعاء 8 (!) ويتم تضمين 7 كائنات!

ثم يقوم مؤشر ترابط منفصل (مؤشر ترابط) PacedSender بسحب إطارنا من قائمة الانتظار ويرسله بشكل إضافي للمعالجة:



أخيرًا ، وصلنا إلى الخطوة 4 ، حيث يعتمد الإطار المعبأ والمشفّر بالفعل على قائمة الانتظار ليتم إرساله إلى الشبكة ، والتي تعمل في سلسلة رسائل أخرى. عند هذه النقطة ، يكون عمق مكدس الاستدعاءات (على مؤشر ترابط PacedSender) هو 7 ، ويتم تضمين 3 كائنات جديدة أخرى. سوف يستدعي مؤشر الترابط المشغول الإرسال WSASend / WSASendTo النهائي أيضًا بعد 3-4 استدعاءات الوظائف المتداخلة وسيتضمن 3-4 كائنات جديدة أخرى.

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

2.b 4-5 خيوط مخصصة لكل اتصال

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

2.c مآخذ غير متزامنة تعمل من خلال رسائل windows

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

2.د الاستنتاج

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

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

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

3. لماذا كل شيء حزين جدا

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

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

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

لذلك ، نظرًا لأنه من الممكن تمامًا المضي قدمًا دون تدفق الدفق ، يتم تركه بحق تحت رحمة الأعمال الخاصة. مما يطورها لمصالحهم الخاصة ، وليس في مصلحة المستهلك. كيف لا يخدم مصلحة المستهلك؟ ولكن ماذا عن العرض والطلب؟ ماذا يحتاج المستهلك ، ثم تقدم الأعمال؟ لكنها لا تقدم. جميع المستهلكين يصرخون - Google ، يدعمون صوت AAC في WebRTC ، لكن Google لن تفعل ذلك أبدًا ، على الرغم من أنها تبصق فقط للقيام بذلك. لا تهتم Apple تمامًا ولا تنفذ أي شيء من تقنيات البث التي تشتد الحاجة إليها في أدواتها. لماذا ا؟ نعم ، لأنه ليس دائمًا ما تفعل الشركة ما يحتاجه المستهلك. لا يفعل ذلك عندما يكون محتكرًا ولا يخشى خسارة المستهلك. ثم تنشغل الشركة في تعزيز موقعها. لذا اشترت Google في السنوات الأخيرة مجموعة من مصنعي برامج ترميز الصوت.والآن يدفع صوت Opus ، ويجبر العالم كله على تحويل AAC-> Opus لمطابقة WebRTC ، حيث أن جميع التكنولوجيا تحولت منذ فترة طويلة إلى صوت AAC. يبرر Google هذا بزعم أن AAC هي تقنية مدفوعة ، و Opus مجانية. ولكن في الواقع ، يتم ذلك من أجل ترسيخ تقنيتها كمعيار. كما فعلت آبل ذات مرة مع HLS البائس ، الذي جعلنا نحبه ، أو كما فعلت Adobe مع بروتوكول RTMP غير المسؤول حتى في وقت سابق. لا تزال الأدوات والمتصفحات من الأشياء التي يصعب تطويرها تقنيًا ، من هنا تنشأ الاحتكارات ، من هنا ، كما يقولون ، الأشياء موجودة. ويتم رعاية W3C و IETF من قبل نفس المحتكرين ، لذا فإن عقلية "دعونا نجعل التكنولوجيا الصحيحة تقنيًا وقوية حتى يتمكن الناس من استخدامها وكل شيء على ما يرام" ليست موجودة ولن تكون موجودة أبدًا.ولكن كان يجب أن يكون.

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

4. قليلا عن خوادم الوسائط التي تطبق WebRTC

Wowza ، Flashphoner ، Kurento ، Flussonic ، Red5 Pro ، Unreal Media Server - هذه بعض خوادم الوسائط التي تدعم WebRTC. أنها توفر نشر الفيديو من المتصفحات إلى الخادم وبث الفيديو إلى المتصفحات عبر WebRTC من الخادم.

يتم حل المشكلات الموضحة في هذه المقالة بطرق مختلفة وبدرجات متفاوتة من النجاح في منتجات البرامج هذه. البعض منهم ، على سبيل المثال ، Kurento و Wowza ، يقومون بترميز الصوت والفيديو مباشرة في الخادم ، والبعض الآخر ، على سبيل المثال ، Unreal Media Server ، لا يقومون بتحويل أنفسهم ، ولكن يقدمون برامج أخرى لهذا. تدعم بعض الخوادم ، مثل Wowza و Unreal Media Server ، التدفق على جميع الاتصالات من خلال منفذ TCP و UDP مركزي واحد ، لأن WebRTC نفسها تخصص منفذًا منفصلاً لكل اتصال ، لذلك يجب على الموفر فتح العديد من المنافذ في جدار الحماية ، مما يخلق مشاكل أمنية.

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