الخلاصة

  • حوّلت RFC 3016 حدود حزمة RTP إلى حدود فشل: يوفر جمع وحدات عدة كلفة الرؤوس، لكنه يجعل فقد حزمة واحدة يمحوها معًا وقد يزيل نقطة البدء اللازمة لتفسير ما بقي.
  • لم يكن رقم التسلسل ولا الطابع الزمني ولا بت العلامة إيصالًا لفك الترميز أو التشغيل؛ وقد تصل وحدة LATM كاملة وتظل غير قابلة للفك إذا ضاع إعداد StreamMuxConfig السابق.

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

كانت البتات اللاحقة موجودة. أما الخريطة التي تشرحها فكانت في إطار سابق لم يصل.

نُشرت RFC 3016 في نوفمبر 2000 لتحدد نقل MPEG-4 Audio وMPEG-4 Visual مباشرة داخل RTP، من دون وظائف التزامن وإدارة التدفقات في MPEG-4 Systems. كان بإمكان H.323 الاعتماد على H.245، بينما يستخدم SIP وRTSP صيغ MIME وSDP. سمح ذلك بالتعامل مع MPEG-4 إلى جانب codecs أخرى عبر أدوات RTP المشتركة.

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

كان الإعداد حالةً يعبر غيابها الزمن

استخدم MPEG-4 Audio صيغة LATM. وُضع audioMuxElement كامل أو جزء منه مباشرة في حمولة RTP، على أن يبدأ أول بايت منه في أول موضع للحمولة. أوصت الوثيقة بعنصر واحد في الحزمة، وسمحت بتجزئته إذا تعذر إبقاء الحجم تحت Path MTU.

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

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

أما الإعداد خارج التدفق فنقل config عبر SDP أو وسيلة أخرى. بذلك تنتقل العهدة إلى مسار الإشارة: يجب أن تصل القيمة الصحيحة، وأن ترتبط بالتدفق الصحيح، وأن تبقى صالحة حين تصل الوسائط.

لا يزيل اختيار المسار الإعداد. إنه يختار حارسه.

في الصورة، جمع الوحدات جمع خسارتها

احتوى MPEG-4 Visual أصلًا على أدوات لمقاومة الأخطاء. لذلك لم تضف RFC 3016 رأس RTP خاصًا بالوسائط، بل وضعت bitstream المرئي مباشرة ومحاذيًا للبايت، من دون حذف عناصره النحوية.

وضعت قواعد لمواضع البداية. يجب أن يبدأ payload بمعلومات الإعداد أو Group_of_VideoObjectPlane، أو أن تأتي بعد رأس أعلى نحويًا مباشرة. وإذا احتوى payload على رؤوس، بدأ بأعلاها. ولم يُسمح بتقسيم رأس بين عدة حزم RTP.

يحمي ذلك موضعًا يستطيع المستقبل أن يبدأ عنده الفهم. تقسيم الرأس يجعل النصفين شرطين متبادلين؛ وقد يضيع أحدهما فتبقى البيانات التالية موجودة من دون مفتاح تفسير.

أوصى النص بوضع video packet واحد في RTP packet واحد وضبط حجمه تحت Path MTU. في مسار كثير الفقد، قد تبقى وحدات أخرى قابلة للفك بواسطة Header Extension Code حتى لو ضاعت الحزمة التي حملت رأس VOP.

لكن الوحدات الصغيرة تجعل رؤوس RTP/IP مكلفة نسبيًا. سمح المعيار بجمع عدة وحدات، وذكر الثمن صراحة: فقد حزمة RTP واحدة يتخلص من جميع video packets داخلها.

كانت الكفاءة توحّد المصائر.

لم يكن عدد الحزم مقياسًا لحجم الضرر

عرض RFC ترتيبًا محظورًا لوحدتي فيديو موزعتين على حزمتين RTP. في ترتيب سليم، فقد الثانية يزيل الوحدة الثانية فقط. في ترتيب آخر، تعبر الوحدة الأولى الحد ويأتي رأس الثانية بعد بقيتها، فيجعل فقد الحزمة الثانية الوحدتين غير صالحتيْن.

عدد الحزم نفسه، وعدد الحزم المفقودة نفسه، لكن موضع الاعتماد مختلف.

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

وحين يعطل coder ميزة video packet، يمكن تقسيم VOP في مواضع بايت عشوائية. قد يناسب ذلك شبكة مضمونة بلا أخطاء، لكن الوثيقة عدّته ضعيف المقاومة في بيئة كثيرة الفقد. سماح الصيغة لا يثبت صحة افتراض المسار.

علامة النهاية لم تكن شهادة تشغيل

في Visual، يشير marker إلى آخر حزمة RTP في VOP أو الحزمة الوحيدة. وإذا احتوت الحزمة عدة VOPs وُضع أيضًا، وأشار timestamp إلى أقدمها فيما جاءت أزمنة البقية من رؤوسها.

يعرف depacketizer أن حدًا قد انتهى. لكنه لا يعرف أن المستقبل رأى النتيجة. قد تضيع الحزمة ذات العلامة، أو تصل بعد فقد جزء سابق، أو تُجمع وحدة يرفضها decoder، أو ينتج decoder صورة لا يعرضها التطبيق.

في RTP العام، يساعد sequence number على كشف الفقد وإعادة الترتيب. يمثل timestamp لحظة أخذ العينة ويدعم المزامنة؛ أما العرض الفعلي فيحدث لاحقًا. ويحدد payload format معنى marker. لا يمثل أي منها عبارة «شاهدها المستخدم».

القدرة ليست الإعداد

سجلت RFC 3016 النوعين video/MP4V-ES وaudio/MP4A-LATM وربطتهما بـSDP. في Visual، يصف profile-level-id مجموعة أدوات يستطيع codec دعمها. أما config فيصف إعداد bitstream المقابل، ونصت الوثيقة على ألا يُستعمل بوصفه إعلان قدرة.

قد يملك المستقبل الأدوات العامة من دون حالة التدفق الحالية. وقد يعلن طرفان Profile/Level متطابقًا ويختلفان في الإعداد الفعلي. يصف SDP النية والبنية، ولا يراقب الطريق أو يفك الوسائط.

تبدأ FEC بعد اختيار محتوى الرهان

سمحت RFC 3016 باستخدام Generic FEC من RFC 2733 والبيانات الصوتية الزائدة من RFC 2198. لكن عند بدء FEC، يكون packetizer قد حدد ما داخل كل source packet.

وهذا يفصل هذه المقالة عن مقال RFC 2733 المنشور. ذاك يناقش parity وشروط الاسترداد وكلفة العرض والزمن. أما هنا فالسؤال أسبق: كم وحدةً نحوية وإعدادًا جُعلت موضوع فقد أو معادلة حماية واحدة؟

ويقدم RFC 2429 مقارنة أخرى؛ فقد أضاف H.263+ payload header ونسخ أحيانًا معلومات picture header حتى يبقى الفك ممكنًا إذا ضاع الأصل. اعتمد RFC 3016 بدلًا من ذلك على أدوات MPEG-4 Visual الداخلية. وحد RTP الغلاف، ولم يوحد عقد الاسترداد.

كشف RFC 6416 أن الاسم لا يحدد النسخة الثنائية

أبطل RFC 6416 سلفه في 2011 لتصحيح عدم التطابق مع 3GPP PSS في MPEG-4 Audio. كانت نسخة LATM التي ألزم بها غير متوافقة ثنائيًا مع النسخة المشار إليها في RFC 3016، كما عُدلت StreamMuxConfig وإشارات SBR وParametric Stereo وrate والقنوات والطبقات القابلة للتوسع.

استخدمت بعض التطبيقات المسماة «RFC 3016» LATM أحدث، فكانت أقرب إلى RFC 6416 لأنها لم تتبع المرجع القديم حرفيًا. لم يكن رقم RFC بصمة للبِتات على السلك.

وبقيت المقايضة المرئية في الوثيقة الجديدة: الفصل يزيد عزل الخسارة، والجمع يوفر الرؤوس لكنه يوسّع ما يسقط معًا.

لا يصغر التشفير وحدة الفشل

أحالت RFC 3016 إلى أمن RTP، وسمحت بتشفير الوسائط بعد ضغطها. كما أن الحمولة المحدودة بالصوت والفيديو لا تنقل applets من MPEG-J أو scripts الممكنة في MPEG-4 Systems الكامل.

تحمي السرية والنزاهة وأصالة المصدر البتات ومن أرسلها. لكنها لا تغيّر Path MTU، ولا تعيد إعدادًا مفقودًا، ولا تفصل وحدات جُمعت داخل حزمة واحدة. قد تكون الحزمة صحيحة وأصيلة، ومع ذلك تكون رهانًا أكبر مما ينبغي.

القيمة التاريخية هنا هي إبقاء العهدة مرئية. لم يفرض RFC حجمًا واحدًا لكل الشبكات، لأن bitrate والفقد وMTU وأدوات codec تختلف. لكنه أوضح أن موضع الرأس وتكرار الإعداد والتجميع ليست تفاصيل محايدة.

قد تصل الحزمة كاملة. وقد تكون الخريطة التي تمنحها معناها قد ضاعت قبلها.

المصادر