الخلاصة

  • فصلت RFC 3984 بين وحدات H.264 التي تحمل الصورة وبين مجموعات معاملات التسلسل والصورة التي تمنح تلك الوحدات معناها داخل جهاز فك الترميز.
  • عند التحديث كان لا بد من ترتيب الإشارة والوسائط: وصول القاعدة متأخرة، أو استبدال معرّفها قبل انتهاء الحزم القديمة، قد يجعل تدفقاً سليماً يعتمد على حالة خاطئة.

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

عالجت RFC 3984، الصادرة في فبراير 2005، نقل فيديو H.264 داخل RTP. وتبين صفحة الحالة وسجل التصويبات وتاريخ Datatracker أنها استبدلت لاحقاً بـ RFC 6184. لا تكمن أهميتها التاريخية فقط في تجزئة وحدات NAL وتجميعها، بل في اعتبار الإعداد الذي يفسر الوسائط حالة مستقلة عن الوسائط نفسها.

يضع H.264 المعلومات المشتركة بين شرائح كثيرة في مجموعات معاملات. تصف مجموعة معاملات التسلسل، SPS، خصائص تسلسل الفيديو المشفر. وتصف مجموعة معاملات الصورة، PPS، خصائص مستخدمة داخل الصور، مثل بعض أوضاع الترميز وخريطة مجموعات الشرائح. لا يكرر رأس كل شريحة تلك المعلومات؛ بل يشير إلى المجموعات بواسطة معرّفات.

المعرّف إذن عنوان وليس المحتوى. يجب أن تكون النسخة الصحيحة من SPS وPPS متاحة قبل وصول وحدة NAL التابعة إليها في ترتيب فك الترميز. قد تكون الحزمة في موعدها بحسب ساعة RTP، لكنها مبكرة بحسب ساعة حالة جهاز الاستقبال. وقد يكون المعرّف صحيحاً شكلاً بعد أن تغيرت دلالته فعلاً.

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

قدمت RFC 3984 ثلاثة مبادئ لنقل مجموعات المعاملات. في المبدأ A تصل بصورة موثوقة خارج النطاق قبل جلسة RTP. وفي B تصل التحديثات بصورة موثوقة خارج النطاق أثناء الجلسة. أما C فيرسلها داخل تدفق RTP نفسه. فضلت وثيقة 2005 النقل الموثوق خارج النطاق في A وB. واحتاج النقل داخل النطاق إلى وسائل مثل التكرار أو إعادة الإرسال أو التصحيح الأمامي، لأن فقدان مجموعة واحدة قد يؤثر في عدد كبير من وحدات NAL التالية.

كان sprop-parameter-sets يحمل مجموعات أولية مشفرة بصيغة base64 ضمن وصف الوسيط. واشترطت RFC 3984 أن تسبق هذه المجموعات، في ترتيب فك الترميز، الوحدات التي تشير إليها. كما حذرت من اعتبار هذا المعامل إعلاناً عن قدرات المستقبل. إنه يصف الحالة المقترحة للتدفق، ولا يثبت كل تكوين يستطيع المستقبل فكّه.

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

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

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

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

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

كما حذرت RFC 3984 من مزج تحديثات المبدأ B خارج النطاق مع تحديثات المبدأ C داخله من دون مزامنة كافية. قد يدخل مستقبل متأخراً ومعه الحالة الأولية من SDP لكنه لم يشهد تحديثاً مر سابقاً داخل التدفق. وقد يفقد مستقبل آخر حزمة التحديث ويبقى على الحالة القديمة بينما تصل كل حزم الصورة اللاحقة.

عدلت RFC 6184 هذا الاختيار التاريخي. وتوضح صفحة حالتها وتصويباتها وسجل Datatracker أنها تسمح بالنقل داخل النطاق وخارجه من دون تفضيل عام، وتضيف تفاوضاً مثل in-band-parameter-sets. فلا يصح تحويل تفضيل 2005 إلى قاعدة أبدية. القاعدة الباقية هي وضوح المسار وتنسيق التحديث مع الوسائط التابعة.

وتقدم RFC 7798، مع حالتها وتصويباتها وتاريخ Datatracker، مقارنة من نقل HEVC عبر RTP. عودة مجموعات المعاملات هناك دليل على استمرار فئة المشكلة، لا على انتشار موحد أو سلوك واحد لكل الأجهزة.

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

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

تكشف RFC 3984 درساً أوسع: البيانات والقواعد التي تجعلها مفهومة قد تستخدمان قناتين وضمانين وساعتين مختلفتين. الإقرار الذي يأتي بعد الوسائط لا يستطيع إعادة كتابة لحظة فك مضت. الاستمرارية تبدأ حين تصبح جاهزية الإعداد آلة حالة مستقلة، لها إصدار ومالك وحد قطع واضح.

المصادر