الخلاصة

  • اقترحت RFC 2448 إيصال معلومات الأولوية العالية (HP) بموثوقية أكبر، مع إبقاء فيديو الأولوية المنخفضة (LP) على مساره المعتاد.
  • لا يثبت استلام HP وصول LP أو تطابق المسارين أو نجاح فك الترميز أو ظهور الصورة في الوقت المناسب.

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

لهذا نقلت RFC 2448 الحكم إلى المرمّز أو التطبيق. يقسم المرسل التدفق إلى مقاطع عالية الأولوية HP يراها حيوية، ومقاطع منخفضة الأولوية LP تضم الباقي. ويمكنه إرسال HP عبر نقل موثوق قبل بدء LP، أو حملها في حزم RTP منفصلة، أو إرسال نسخ إضافية بجانب التدفق الأصلي غير المقسّم، أو بث معلومات HP القابلة لإعادة الاستخدام مرة واحدة خارج النطاق ليحتفظ بها المستقبل في مخبأ. لم تمنح الشبكة الأولوية؛ بل أنشأ النظام مسارات موثوقية مختلفة.

كان التصنيف هو موضع القرار الحاسم. تقول الوثيقة إن تحديد HP يتطلب معرفة نحو المرمّز وقواعده الدلالية، ولا توجد طريقة عامة تصلح لكل تدفق مرمّز. ويظهر مثال MPEG-2 كلفة الاختيار: كانت HP التي تقتصر على الرؤوس أقل من 2% من بيانات الفيديو عادةً. وقد تصل النسبة إلى نحو 40% عند إضافة معاملات DC، بما يتيح فيديو قابلاً للاستخدام إلى حد ما من HP وحدها، لكن مع كمية أكبر بكثير يجب تسليمها بموثوقية. هذه أرقام المثال الوارد في RFC وليست قياسات عامة للفيديو.

إرسال HP أولاً يقلل تعرضها للفقد، لكنه يضيف انتظاراً عند بدء التشغيل. ويمكن لحزم RTP المنفصلة الخاصة بها استخدام نوع حمولة مختلف مع مشاركة صيغة الطوابع الزمنية ومساحة SSRC مع التدفق الرئيسي. تساعد هذه المعرفات على التنسيق، لكنها لا تجعل ضمان التسليم واحداً للمسارين. ويمكن للمرسل أيضاً إبقاء HP في التدفق الأصلي واستخدام النسخ المنفصلة عند وقوع فقد فقط. وفي حالة المعلومات المعاد استخدامها والمُرسلة خارج النطاق، قد لا تكون الطوابع الزمنية ذات معنى؛ ويمكن لإطار مفتاحي، وعلامة الحزمة إن وُجدت، أن يساعدا على ربطها بتدفق LP.

لذلك ينبغي للمستقبل التحقق مما هو أبعد من انتهاء النقل الموثوق: هل تنتمي HP إلى نسخة المرمّز الحالية وإلى الموضع الصحيح في LP؟ هل وصلت بيانات LP اللازمة؟ هل أنتج المفكك صورة قبل مهلة العرض؟ وهل عُرضت فعلاً؟ لا يجيب استلام HP كاملاً وحده عن أي من هذه الأسئلة.

نُشرت RFC 2448 في نوفمبر 1998 بوصفها وثيقة معلوماتية، لا معياراً للإنترنت. وذكرت براءات ذات صلة بـ AT&T/Lucent، ونصت على أن IESG وIETF لا يتخذان موقفاً من صلاحيتها أو نطاقها أو توافر ترخيص لها. يصف النص تقنية، لكنه لا يثبت تبنيها أو نشرها اليوم أو توافقها التشغيلي أو منفعتها للمشاهدين. وتكمن دلالتها التاريخية في نطاق أضيق: الموثوقية الانتقائية تحول مشكلة النقل إلى سياسة للمرمّز، وكل مسار إضافي ينشئ شرط ربط يجب رصده لا افتراضه.

المصادر

RFC 2448؛ سجل RFC 2448؛ سجل IETF Datatracker؛ تصويبات RFC 2448؛ RFC 2250، حمولة RTP لـ MPEG؛ RFC 3550، بروتوكول RTP؛ RFC 2198، بيانات صوتية مكررة؛ RFC 2733، تصحيح أخطاء RTP؛ RFC 5109، FEC عام لـ RTP؛ RFC 4588، إعادة إرسال RTP؛ RFC 1191، اكتشاف MTU للمسار؛ RFC 1889، مواصفة RTP الأسبق؛ Heng Lu، أولوية الشيفرة العاملة؛ Heng Lu، المواصفة والتبني الطوعي.