هناك شيء ينتهي بي شرحه في كثير من الأحيان نسبيًا يتعلق بجميع الطرق المختلفة التي يمكنك من خلالها بث الفيديو المغلف في بروتوكول النقل في الوقت الحقيقي ، أو RTP ، وما زلت تدعي أنه متوافق مع المعايير.
بعض الخلفيات: يتم استخدام RTP بشكل أساسي لدفق فيديو H.264 أو MPEG-4. RTP هو بروتوكول نظام يوفر آليات لمزامنة التدفقات المختلفة للعرض التقديمي - على سبيل المثال الصوت والفيديو. على هذا النحو ، فإنه يؤدي بعض الوظائف نفسها مثل نقل MPEG-2 أو دفق البرنامج.
RTP - التي يمكنك أن تقرأ عنها بتفصيل كبير في RFC 3550 - لا تعتمد على الترميز. هذا يعني أنه من الممكن حمل عدد كبير من أنواع الترميز داخل RTP ؛ لكل بروتوكول ، تحدد IETF ملف تعريف RTP الذي يحدد أي تفاصيل خاصة ببرنامج الترميز لتعيين البيانات من برنامج الترميز إلى حزم RTP. يتم تعريف ملفات التعريف لـ H.264 و MPEG-4 والفيديو والصوت وغير ذلك الكثير. حتى VC-1 - النموذج "القياسي" لـ Windows Media Video - له ملف تعريف RTP .
في رأيي ، المعايير فوضى في هذا المجال. يجب أن يكون من الممكن تلبية جميع المتطلبات المختلفة لدفق الفيديو بطريقة واحدة أو طريقتين على الأكثر للبث. لكن في النهاية هيئات المعايير هي لجان: كل شخص يضع لونًا جميلًا ، والنتيجة تظهر باللون الرمادي.
في الواقع ، كان وضع المعايير الأصلي حول فيديو MPEG-4 مرتبكًا للغاية لدرجة أن مجموعة من الشركات الكبيرة شكلت تحالف وسائط البث عبر الإنترنت ، أو ISMA. يتمثل دور ISMA في الأساس في الخوض في جميع الخيارات المختلفة المقدمة في المعايير وإنشاء معيار تعريف - حاليًا ISMA 2.0 - يربط عددًا من وثائق المعايير الأخرى معًا ويخبرك بكيفية بناء نظام عمل يتفاعل مع الأنظمة الأخرى .
على أي حال ، هناك عدد من الطرق السائدة لإرسال فيديو MPEG-4 أو H.264 باستخدام RTP ، وكلها تتبع بعض المعايير ذات الصلة. إذا كنت تكتب وحدة فك ترميز ، فستحتاج عادةً إلى معالجتها جميعًا ، لذا إليك نظرة عامة سريعة.
تسليم البث المتعدد: RTP عبر UDP
في بيئة يوجد فيها مصدر واحد لدفق الفيديو والعديد من المشاهدين ، من الأفضل أن ينقل كل إطار من الفيديو والصوت الشبكة مرة واحدة فقط. هذه هي الطريقة التي يعمل بها التسليم المتعدد. في شبكة متعددة البث ، يجب على كل عارض استرداد ملف SDP من خلال آلية غير محددة ، والتي تكون عادةً HTTP. بمجرد استرداد ملف SDP ، يوفر معلومات كافية للمشاهد للعثور على تدفقات البث المتعدد على الشبكة وبدء التشغيل.
في سيناريو التسليم المتعدد ، يتم إرسال كل دفق فردي على زوج من منافذ UDP المختلفة - أحدهما للبيانات والثاني لبروتوكول التحكم RTP ذي الصلة أو RTCP. هذا يعني أنه بالنسبة لبرنامج فيديو يتكون من دفق فيديو واثنين من دفق الصوت ، سترى في الواقع الحزم يتم تسليمها إلى ستة منافذ UDP:
- يتم تسليم بيانات الفيديو عبر RTP
- منفذ RTCP ذي الصلة لدفق الفيديو
- يتم تسليم بيانات الصوت الأساسية عبر RTP
- منفذ RTCP ذي الصلة لدفق الصوت الأساسي
- يتم تسليم بيانات الصوت الثانوية عبر RTP
- منفذ RTCP ذي الصلة لدفق الصوت الثانوي
يمكن استخدام الطوابع الزمنية في رؤوس RTP لمزامنة عرض التدفقات المختلفة.
كملاحظة جانبية ، يعتبر RTCP أثريًا تقريبًا لمعظم التطبيقات. تم تحديده في RFC 3550 مع RTP. إذا كنت تقوم بتنفيذ وحدة فك ترميز ، فستحتاج إلى الاستماع على منافذ RTCP ، ولكن يمكنك تقريبًا تجاهل أي بيانات يتم إرسالها إليك. الاستثناءات هي تقرير المرسل ، الذي ستحتاجه لمطابقة الطوابع الزمنية بين التدفقات و BYE ، والتي سترسلها بعض المصادر لأنها تقوم بتفكيك الدفق.
يعمل توصيل الفيديو متعدد البث بشكل أفضل مع المحتوى المباشر. نظرًا لأن كل عارض يشاهد البث نفسه ، فلا يمكن للمشاهدين الفرديين إيقاف البث مؤقتًا أو البحث عنه أو إرجاعه أو تقديمه بسرعة.
تسليم أحادي الإرسال: RTP عبر UDP
من الممكن أيضًا إرسال فيديو أحادي الإرسال عبر UDP ، مع وجود نسخة واحدة من الفيديو تعبر الشبكة لكل عميل. يمكن استخدام التسليم الأحادي لكل من المحتوى المباشر والمخزن. في حالة المحتوى المخزن ، يمكن استخدام أوامر تحكم إضافية للإيقاف المؤقت والسعي والدخول في أوضاع التقديم السريع والإرجاع.
عادة في هذه الحالة ، يقوم اللاعب أولاً بإنشاء اتصال تحكم بخادم باستخدام بروتوكول البث المباشر في الوقت الحقيقي ، أو RTSP . من الناحية النظرية ، يمكن استخدام RTSP عبر إما UDP أو TCP ، ولكن من الناحية العملية يتم استخدامه دائمًا عبر TCP.
يبدأ المشغل عادةً بعنوان rtsp: // URL ، وهذا يتسبب في توصيله عبر TCP بخادم RTSP. بعد بعض التنقلات بين المشغل وخادم RTSP ، حيث يرسل الخادم للعميل ملف SDP يصف الدفق ، يبدأ الخادم في إرسال الفيديو إلى العميل عبر UDP. كما هو الحال مع حالة تسليم البث المتعدد ، يتم استخدام زوج من منافذ UDP لكل من التدفقات الأولية.
بالنسبة إلى التدفقات التي يمكن البحث عنها ، بمجرد تشغيل الفيديو ، يتمتع المشغل بتحكم إضافي باستخدام RTSP: يمكن أن يتسبب في إيقاف التشغيل مؤقتًا ، أو السعي إلى موضع مختلف ، أو الدخول في وضع التقديم أو الترجيع السريع.
وضع RTSP معشق: RTP و RTSP عبر TCP
أنا لست من محبي دفق الفيديو عبر TCP. في حالة فقدان حزمة في الشبكة ، يكون من الأسوأ عادةً انتظار إعادة الإرسال (وهو ما يحدث مع التسليم المضمون لـ TCP) بدلاً من السماح لخلل الفيديو الناتج بالمرور إلى المستخدم (وهذا ما يحدث مع UDP).
ومع ذلك ، هناك عدد قليل من تكوينات الشبكات المختلفة التي قد تمنع فيديو UDP ؛ على وجه الخصوص ، لقد تفاعلت جدران الحماية تاريخيًا بشكل سيئ مع وضعي تسليم UDP الملخصين أعلاه.
لذا فإن RTSP RFC ، في القسم 10.12 ، تحدد بإيجاز طريقة تشذير حزم RTP و RTCP على اتصال TCP الحالي المستخدم في RTSP. تُعطى كل حزمة RTP و RTCP بادئة من أربعة بايت ويتم إسقاطها في تدفق TCP. والنتيجة هي أن المشغل يتصل بخادم RTSP ، وتتدفق جميع الاتصالات عبر اتصال TCP واحد بين الاثنين.
الوضع النفقي لـ HTTP: RTP و RTSP عبر HTTP عبر TCP
قد تعتقد أن وضع RTSP Interleaved ، الذي تم تصميمه لنقل الفيديو عبر جدران الحماية ، سيكون هو النهاية ، ولكن اتضح أن العديد من جدران الحماية لم يتم تكوينها للسماح بالاتصالات بمنفذ TCP 554 ، المنفذ المعروف لخادم RTSP.
لذلك ابتكرت Apple طريقة لتعيين اتصال RTSP Interleaved بالكامل أعلى HTTP ، مما يعني أن الفيديو يتدفق في نهاية المطاف عبر منفذ TCP 80. على حد علمي ، فإن وضع HTTP Tunneled هذا غير موحد في أي RFC رسمي ، ولكنه مطبق على نطاق واسع لدرجة أنه أصبح معيارًا واقعيًا.
