بينما يحاول أول من تبنوا مؤتمرات الفيديو الجديدة الخاصة بنا (حتى 100 شخص!) في مشاريعهم ، نواصل الحديث عن أشياء مثيرة للاهتمام من عالم نقل الصوت والفيديو باستخدام متصفح. سنتحدث أيضًا عن مؤتمرات الفيديو ، ولكن لاحقًا - عندما تتراكم كتلة حرجة من المستخدمين ويتم جمع إحصاءات مثيرة للاهتمام. والآن قمت بترجمة قصة د. أليكس حول مكان البروتوكولات المختلفة عند إرسال الفيديو مع الكمون المنخفض. القصة هي في الأساس رد على مقال آخر ، ويشير المؤلف ، إلى جانب القصة ، إلى الأخطاء وعدم الدقة التي ارتكبها زملاؤه في ورشة العمل.
بيانات الشبكة: التنبيه بشكل منفصل ، والفيديو بشكل منفصل
في الأنظمة الحديثة ، إذا رأيت فيديو في متصفح ، فمن المرجح أن تتم معالجة دفق الفيديو والتنبيه بواسطة خوادم مختلفة. إذا كان كل شيء واضحًا في الفيديو ، فإن "خادم التنبيه" يوفر شيئين: "الاكتشاف" و "المصافحة". الأول ، "الاكتشاف" ، هو اختيار طريقة نقل البيانات: عناوين IP ، خادم وسيط (إذا لزم الأمر). "المصافحة" - حول التفاوض بين المشاركين في نقل الفيديو والصوت: برامج الترميز ، الدقة ، معدل الإطار ، الجودة. ومن المثير للاهتمام أنه في الفلاش القديم ، لم يتم فصل الإشارات ونقل الوسائط كما هو الحال في VoxIP أو WebRTC وتم توفيرها بواسطة بروتوكول واحد: RTMP.
الفرق بين بروتوكول التشوير ونقل التشوير
يحدد بروتوكول التشوير اللغة التي سيوافق بها المتصفح والمشاركون الآخرون في إرسال الفيديو على الاكتشاف والمصافحة. يمكن أن يكون SIP لاكتشافه في VoIP أو WebRTC ، وهو مع عرض / إجابة للمصافحة. منذ وقت طويل ، استخدم فلاش
RTMP / AMF . وإذا لزم الأمر ، بالنسبة إلى WebRTC ، لا يمكنك استخدام SIP ، ولكن JSEP غير عادية.
بروتوكول نقل الإشارات من المكدس نفسه ، ولكن أقل: هذه هي الطريقة التي سيتم بها إرسال حزم بروتوكول التشوير فعليًا. تقليديا ، بالنسبة لـ Flash + SIP أو TCP أو UDP تم استخدامه ، ولكن الآن في حزمة WebRTC + SIP ، يتم العثور على WebSockets بشكل متزايد. يشغل بروتوكول النقل WebSockets مكانة TCP في المستعرضات حيث لا يمكنك استخدام مآخذ TCP و UDP "الخالصة".
يتم وصف مجموعة إشارات كاملة بشكل شائع الآن بعبارات مثل "SIP في أعلى مآخذ الويب" أو "JSEP في أعلى مآخذ الويب" أو "SIP القديمة في أعلى TCP / UDP" أو "جزء من RTMP" القديم.
الانجيلية المبرمج: ترميز الوسائط
ترتبط معظم بروتوكولات دفق الفيديو بواحد أو أكثر من برامج الترميز. تتم معالجة الفيديو المستلم من الكاميرا إطارًا بإطار. ويتم حل مشكلات الشبكة ، مثل النطاق الترددي المنخفض أو فقدان الحزمة أو التأخير بينها ، من خلال إعدادات برنامج الترميز لكل إطار. للتعرف على مشكلات الشبكة في الوقت المناسب ، نستخدم آليات بروتوكول النقل (RTP / RTCP) وآليات تقدير النطاق الترددي (REMB ، Transport-CC ، TIMBR). كانت إحدى المشاكل الأساسية في فيديو Flash هي أن RTMP لا يمكنها القيام بأي منهما أيضًا ، لذلك توقف الفيديو ببساطة عن التشغيل عند انخفاض عرض النطاق الترددي للقناة.
أنجليكانية أخرى: بروتوكول تدفق الوسائط
يحدد كيفية تقسيم دفق الفيديو إلى حزم صغيرة يتم إرسالها عبر الشبكة بواسطة بروتوكول النقل. بشكل عام ، لا يزال بروتوكول الدفق يوفر آليات للتعامل مع مشاكل الشبكة: فقدان الحزمة والتأخير. العازلة الارتعاش ، إعادة الإرسال (RTC) ، التكرار (RED) وتصحيح الخطأ الأمامي (FEC).
بروتوكول نقل الوسائط
بعد تقسيم الفيديو المستلم من الكاميرا إلى حزم صغيرة ، يجب إرسالها عبر الشبكة. بروتوكول النقل المستخدم لهذا مشابه لبروتوكول الإشارة ، ولكن بما أن "الحمولة" مختلفة تمامًا ، فإن بعض البروتوكولات أفضل من غيرها. على سبيل المثال ، يوفر بروتوكول TCP إمكانية وصول الحزمة ، ولكنه لا يضيف قيمة إلى المكدس ، لأن الآليات المماثلة (RTX / RED / FEC) موجودة بالفعل في بروتوكول الدفق. لكن التأخيرات في إعادة الإرسال إلى TCP هي خلل واضح ليس لدى UDP. ولكن هناك ممارسة لحظر UDP على أنه "بروتوكول للسيول."
تم تحديد اختيار البروتوكول ومنافذ الشبكة مسبقًا من خلال "الترميز الثابت" ، ولكننا نستخدم الآن بروتوكولات مثل ICE في WebRTC ، والتي تسمح لك بالاتفاق على المنافذ والنقل في كل اتصال محدد. في المستقبل القريب ، من الممكن استخدام بروتوكول QUIC (متوافق مع الإصدارات السابقة مع UDP) ، والذي تمت مناقشته بنشاط من قبل IETF وله مزايا على TCP و UDP في السرعة والموثوقية. أخيرًا ، يمكننا ذكر بروتوكولات دفق الوسائط مثل MPEG-DASH و HLS ، والتي تستخدم HTTP كوسيلة نقل وستستفيد من إدخال HTTP / 2.0.
أمان نقل الوسائط
تقوم بعض المحركات بحماية البيانات أثناء الإرسال عبر الشبكة: إما دفق الوسائط نفسه ، أو حزم طبقة النقل. تتضمن العملية نقل مفاتيح التشفير ذاتها ، والتي يتم استخدام بروتوكولات منفصلة لها: SDES في VoIP و DTLS في WebRTC. هذا الأخير له ميزة ، لأنه بالإضافة إلى البيانات ، فإنه يحمي أيضًا نقل مفاتيح التشفير.
ما يزعجني في كل هذا
يضع بعض المطورين ، مثل مؤلفي
هذه المقالة ، بروتوكولات WebSocket و QUIC البحتة على نفس مستوى WebRTC أو Flash أو HLS. بالنسبة لي ، تبدو مثل هذه المجموعة غريبة ، لأن البروتوكولات الثلاثة الأخيرة هي قصة حول تدفق الوسائط. يحدث التشفير والحزم قبل استخدام WebSocket أو QUIC. استخدام WebRTC المرجعي من Google (libwebrtc / chrome) و ORTC من Microsoft يستخدمان QUIC كبروتوكول النقل.
من المثير للدهشة أيضًا عدم ذكر HTTP / 2.0 كمحسن للبروتوكولات المستندة إلى HTTP مثل HLS و MPEG-DASH. و CMAF المذكور ليس أكثر من تنسيق ملف لـ HLS و MPEG-DASH ، ولكنه ليس بديلاً على الإطلاق.
وأخيرًا ، يعد SRT مجرد بروتوكول نقل. بالطبع ، يضيف عددًا من الرقائق مقارنةً بالرقائق القائمة على ملفات HLS و MPEG-DASH ، ولكن كل هذه الرقائق موجودة بالفعل على مستوى مكدس مختلف ويتم تنفيذها في RTMP أو WebRTC. يشارك SRT أيضًا ترميز دفق الوسائط والإحصاءات ، والتي لا تسمح لبرنامج الترميز بإبقاء هذه المعلومات قريبة قدر الإمكان من بعضها البعض. قد يؤثر مثل هذا القرار سلبًا على القدرة على تكييف الفيديو المنقول مع عرض النطاق الترددي المتغير للشبكة.
تقوم البروتوكولات القائمة على الملفات ، مثل HLS ، بترميز تدفقات متعددة وتحديد البروتوكولات اللازمة للتكيف مع عرض القناة. يسمح لك WebRTC بتكييف ترميز كل إطار في الوقت الفعلي: فهو أسرع بكثير من تحديد دفق آخر في HLS ، والذي يتطلب عد حتى 10 ثوانٍ من البيانات المرسلة بالفعل.