2026-06-02

إصلاح تجزئة H.264 FU-A RTP: سبب انقطاع فيديو RTSP (فقد الحزمة، إعادة تجميع NAL)

إصلاح فيديو RTSP المعطوب من تجزئة H.264 FU-A RTP. يغطي الأجزاء المفقودة، وأخطاء بت البداية/النهاية، وفشل إعادة تجميع NAL، وفقدان الحزم، وMTU، وأخطاء وحدة فك التشفير باستخدام أوامر تشخيصية حقيقية.

ينقطع H.264 عبر RTP بطرق تبدو وكأنها أخطاء في وحدة فك التشفير ولكنها في الحقيقة مشكلات في الحزم. تعمل جلسة RTSP. تقوم DESCRIBE بإرجاع SDP صالح. نجح برنامج الإعداد. PLAY يُرجع 200 OK. تصل حزم RTP بنوع الحمولة الصحيح المعين إلى H.264. ومع ذلك، يُظهر الفيديو تلفًا في الحظر، أو تجميدًا، أو إطارات سوداء، أو أخطاء في وحدة فك التشفير.

تبدو الأخطاء كما يلي في سجلاتك:

[h264 @ 0x...] invalid NAL unit size
[h264 @ 0x...] missing picture in access unit
[h264 @ 0x...] non-existing PPS 0 referenced
[h264 @ 0x...] decode_slice_header error
[h264 @ 0x...] no frame!

The fast answer

Why fragmentation exists

The structure of an FU-A packet

Each FU-A RTP packet contains:

Byte 0: FU indicator
  bit 7: F (forbidden_zero_bit) — normally 0
  bits 6-5: NRI (nal_ref_idc) — priority
  bits 4-0: Type = 28 (FU-A)
Byte 1: FU header
  bit 7: S (Start) — 1 for first fragment
  bit 6: E (End) — 1 for last fragment
  bit 5: R (Reserved) — always 0
  bits 4-0: Type — original NAL unit type (1=non-IDR, 5=IDR, 7=SPS, 8=PPS)
Byte 2+: Fragment payload — the actual NAL unit data

تسلسل FU-A كامل لوحدة NAL واحدة:

Packet 1: FU indicator (type=28) | FU header (S=1, E=0, type=5) | payload[0..N]
Packet 2: FU indicator (type=28) | FU header (S=0, E=0, type=5) | payload[N+1..M]
Packet 3: FU indicator (type=28) | FU header (S=0, E=0, type=5) | payload[M+1..P]
Packet 4: FU indicator (type=28) | FU header (S=0, E=1, type=5) | payload[P+1..END]

The RTP marker bit

Failure modes: what breaks and why

Failure 1: Missing middle fragment

Expected:  1000(S)  1001(M)  1002(M)  1003(E|marker)
Received:  1000(S)  1001(M)  [LOST]   1003(E|marker)

يرى جهاز إعادة التجميع جزءًا من البداية، وجزءًا متوسطًا، ثم جزءًا نهائيًا - ولكن لا يتم توصيل بايتات الحمولة. وحدة NAL المُعاد تجميعها بها فجوة.

أعراض:

منع الفساد في شريط أفقي من الإطار
وحدة فك الترميز تُبلغ عن "حجم وحدة NAL غير صالح"
يقتصر الفساد على وحدة وصول واحدة (يتم مسحه عند IDR التالي)

الفشل 2: جزء البداية مفقود

Expected:  1000(S)  1001(M)  1002(E)
Received:  [LOST]   1001(M)  1002(E)

Failure 3: Missing end fragment

Expected:  1000(S)  1001(M)  1002(E|marker)
Received:  1000(S)  1001(M)  [LOST]

لا يرى المُجمع مطلقًا الجزء النهائي. لم يتم تأكيد حدود وحدة NAL أبدًا. ينتظر جهاز فك التشفير المزيد من البيانات التي لا تصل أبدًا.

أعراض:

يتجمد الفيديو
وحدة فك الترميز تبلغ عن "صورة مفقودة في وحدة الوصول"
يتوقف التشغيل حتى وصول وحدة الوصول الكاملة التالية

الفشل 4: شظايا خارج الترتيب

Expected:  1000(S)  1001(M)  1002(E)
Received:  1000(S)  1002(E)  1001(M)

Diagnostic workflow

Step 1: Confirm H.264 payload mapping

m=video 0 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1;profile-level-id=4D0029;sprop-parameter-sets=...

packetization-mode=1 يعني الوضع غير المشذر (FU-A مدعوم)
packetization-mode=0 يعني وضع وحدة NAL واحد (بدون تجزئة - محدود للغاية)

الخطوة 2: تتبع أرقام تسلسل RTP

أثناء الالتقاط، انظر إلى أرقام تسلسل RTP لمسار الفيديو. تشير الفجوات إلى فقدان الحزمة:

Seq 1000: FU-A Start, NAL type 5 (IDR)
Seq 1001: FU-A middle
Seq 1003: FU-A End, marker=1   ← gap at 1002

Step 3: Inspect FU-A headers

Byte 0 (FU indicator):
  0x7C = NRI=3, Type=28 (FU-A)

البايت 1 (رأس FU):
  0x85 = S=1، E=0، R=0، النوع=5 (شريحة IDR) ← جزء البداية من IDR
  0x45 = S=0، E=0، R=0، النوع=5 ← الجزء الأوسط
  0x65 = S=0، E=1، R=0، النوع=5 ← جزء النهاية؛ تُضبط العلامة فقط إذا كانت وحدة NAL هذه تنهي وحدة الوصول

قيم خاطئة للبحث عنها:

S=1 على حزمة غير قابلة للتشغيل → ارتباك جهاز إعادة التجميع
ضبط العلامة قبل E=1 → حد زائف لوحدة الوصول
قد يكون E=1 مع علامة غير مضبوطة صحيحًا إذا تبعته وحدة NAL أخرى
تغييرات النوع في منتصف التسلسل → خطأ في برنامج التشفير أو تلف في الدفق

الخطوة 4: التحقق من إعادة التجميع الكاملة

لكل وحدة NAL:

ابحث عن جزء البداية (S=1)
اتبع أرقام التسلسل المتتالية حتى الجزء النهائي (E=1)
عد الشظايا. التحقق من عدم وجود فجوات في التسلسل
قارن العلامة بحد وحدة الوصول؛ لا تشترطها في كل جزء FU-A نهائي
تحقق من أن كافة الأجزاء لها نفس الطابع الزمني ونوع NAL

الخطوة 5: مقارنة أوضاع النقل

قم بتشغيل نفس الدفق عبر UDP وTCP المشذّر. إذا كان الفيديو نظيفًا عبر TCP ولكنه تالف عبر UDP، فإن المشكلة تكمن في فقدان حزمة الشبكة، وليس مشكلات في برنامج التشفير أو وحدة فك التشفير.

الخطوة 6: تحليل IDR مقابل التحليل غير IDR

إطارات IDR أكبر وتتطلب المزيد من أجزاء FU-A لكل وحدة NAL. المزيد من الأجزاء = المزيد من التعرض لفقدان الحزمة. إذا ظهر الفساد في الغالب عند تغيرات المشهد أو كل بضع ثوانٍ (عند الفاصل الزمني لـ IDR)، تكون إطارات IDR هي الضحية.

خيارات الإصلاح:

خفض حجم إطار IDR (تقليل الدقة أو معدل البت للإطارات الرئيسية)
زيادة الفاصل الزمني لـ IDR (إطارات كبيرة أقل، ولكن التعافي من الخسارة أبطأ)
قم بتقليل وحدة الإرسال الكبرى (MTU) لـ FU-A في جهاز التشفير (المزيد من الأجزاء، ولكن كل منها أصغر حجمًا وأقل احتمالاً لتشغيل تجزئة IP)

استراتيجيات التعافي

عند المجمع

قم بإسقاط وحدات الوصول التالفة بالكامل بدلاً من تغذية بيانات جزئية إلى وحدة فك التشفير
اطلب إطار IDR جديدًا عبر RTCP (إذا كانت الكاميرا مدعومة)
انتظر إطار IDR التالي (سيتم استرداد وحدة فك التشفير تلقائيًا)

عند التشفير

قم بخفض الحد الأقصى لحجم وحدة NAL لتقليل الأجزاء لكل وحدة وصول
استخدم التحديث الداخلي الدوري بدلاً من إطارات IDR الكاملة (إطارات رئيسية أصغر)
قم بتمكين FEC (تصحيح الأخطاء للأمام) إذا كانت حزمة RTP تدعمها

في الشبكة

قم بالتبديل من UDP إلى TCP المشذّر إذا كان فقدان الحزمة أمرًا لا مفر منه
تأكد من أن اكتشاف مسار MTU يعمل (تجنب تجزئة IP)
إعطاء الأولوية لحركة مرور RTP على الروابط المزدحمة

عندما لا يكون FU-A

ليس كل تلف H.264 عبارة عن تجزئة FU-A. يفحص:

SPS/PPS مفقود: أخطاء في وحدة فك الترميز مثل "PPS غير موجودة" - تحقق من مجموعات معلمات SDP
ملف تعريف/مستوى خاطئ: لا يستطيع جهاز فك التشفير التعامل مع تعقيد الدفق
خطأ في برنامج التشفير: ينتج برنامج التشفير بناء جملة وحدة NAL غير صالح
فساد تدفق البتات عند المصدر: برنامج تشفير الكاميرا معطل، وليس الشبكة

إذا وصلت حزم RTP بأرقام تسلسلية مثالية ورؤوس FU-A صحيحة، لكن وحدة فك التشفير ما زالت تفشل، فإن المشكلة تكمن في تدفق بتات H.264 نفسه، وليس في النقل.

خطة إثبات عملية لموضوع «إصلاح تجزئة H.264 FU-A RTP: سبب انقطاع فيديو RTSP (فقد الحزمة، إعادة تجميع NAL)»

الإجابة المباشرة هي أن تشخيص بث كاميرا لا يعتمد على ظهور صورة أو على رمز خطأ منفرد. يجب ربط النتيجة بطلب RTSP وردّه، وباختيار Transport، وبهوية جلسة صالحة، ثم بأرقام تسلسل RTP والطوابع الزمنية وبيانات RTCP عند وصول الوسائط. في موضوع «إصلاح تجزئة H.264 FU-A RTP: سبب انقطاع فيديو RTSP (فقد الحزمة، إعادة تجميع NAL)» ابدأ بأقرب طبقة إلى العرض الظاهر، لكن احتفظ بسجل زمني واحد حتى لا تختلط مشكلة التحكم بمشكلة الشبكة أو برنامج فك الترميز.

أنشئ حالة اختبار صغيرة قبل تغيير إعدادات الكاميرا أو الجدار الناري. دوّن عنوان RTSP بعد إخفاء كلمة المرور، ووقت الاختبار، واسم المسار، ونوع النقل المطلوب، ورد الخادم، وأول لحظة تصل فيها الوسائط. نفّذ محاولة واحدة عبر UDP وأخرى عبر TCP interleaved عندما يسمح الجهاز بذلك. لا تغيّر عنوان المسار وبيانات الاعتماد والنقل في التجربة نفسها، لأن نجاح المحاولة التالية لن يوضح أي متغير أصلح العطل.

طبقة الفحص	الدليل الذي يجب حفظه	سؤال القرار
RTSP	الطلب، الحالة، الرؤوس، CSeq وSession	هل وافق الخادم على العملية نفسها؟
SDP	control وpayload type وclock rate وcodec	هل وصف الخادم المسار الذي سيُستقبل؟
Transport	client_port أو interleaved وقيمة server_port	هل يرسل الطرفان عبر القناة نفسها؟
RTP	SSRC والتسلسل والطابع الزمني وmarker	هل تصل وحدات الوسائط بترتيب يمكن تفسيره؟
RTCP	sender report وCNAME وBYE	هل توجد ساعة وهوية ونهاية جلسة قابلة للتتبع؟
Decoder	SPS/PPS/VPS وpacketization mode	هل البيانات الواصلة قابلة للتهيئة وفك الترميز؟

افصل دائمًا بين «لم تصل وسائط» و«وصلت وسائط غير قابلة للفك». غياب حزم RTP بعد SETUP وPLAY يشير إلى مسار UDP أو NAT أو جدار ناري أو رد Transport غير متطابق. وصول RTP مع فجوات في التسلسل يثبت فقدًا أو إعادة ترتيب. وصول تسلسل متماسك مع فشل الصورة ينقل التحقيق إلى payload type وclock rate وحدود الإطار ومعلمات H.264 أو H.265. هذه الحدود أهم من رسالة اللاعب العامة لأنها تحدد المالك المحتمل للإصلاح.

كيف تُكتب إجابة قابلة للاقتباس؟

اكتب النتيجة في ثلاث جمل: العملية التي نجحت، أول دليل أخفق، والتجربة التالية التي تفصل بين سببين. مثال البنية هو: «نجح DESCRIBE وSETUP وPLAY؛ لم تصل أي حزمة RTP إلى منافذ العميل المعلن عنها؛ إعادة الاختبار عبر TCP interleaved ستفصل بين حجب UDP وخطأ عنوان المسار». لا تقل إن الكاميرا أو الشبكة «معطلة» من دون حزمة أو رد يثبت الحد.

ما الحد الأدنى لإعادة إنتاج المشكلة؟

احتفظ بنسخة من تبادل OPTIONS وDESCRIBE وSETUP وPLAY، ونص SDP، ورد Transport، ومعرّف Session بعد إخفاء الأسرار. بالنسبة للوسائط، سجّل SSRC وأول وآخر رقم تسلسل ومعدل الساعة وعدد الفجوات ومدة الالتقاط. اذكر هل يعمل VLC أو VMS آخر، لكن تعامل مع ذلك كاختبار فرق لا كدليل أن الطرف الآخر صحيح في كل شيء.

متى يجب فحص الخادم بدل العميل؟

افحص الخادم عندما يرفض العملية بحالة واضحة، أو يغيّر عنوان control إلى مسار غير موجود، أو يعيد Transport لا يطابق العرض، أو يبدّل SSRC والساعة من دون انتقال معلن. افحص العميل عندما يكرر nonce قديمًا، أو يرسل Session مفقودة، أو يطلب UDP ثم لا يفتح المنافذ، أو يفسر marker بوصفه نهاية كل NAL. قد يكون العطل بينهما؛ لذلك يجب أن تبقى الحزمة والوقت جزءًا من التقرير.

كيف تُراجع النتيجة قبل التسليم؟

أعد المحاولة من بداية اتصال جديدة، ثم قارن السجلين عند أول اختلاف فقط. تأكد من أن التقرير لا يحتوي كلمة مرور أو رمز Authorization كاملًا. اربط كل استنتاج برقم CSeq أو رقم تسلسل أو طابع زمني. استخدم دليل RTSP المرتبط للخطوات المجاورة، وارجع إلى RTSP Inspector لمسار اختبار بث RTSP وجمع الأدلة محليًا. لا يحتاج هذا التشخيص إلى رفع تدفق الكاميرا إلى خدمة عامة.

من الملاحظة إلى حكم طبقي قابل للمراجعة

في «إصلاح تجزئة H.264 FU-A RTP: سبب انقطاع فيديو RTSP (فقد الحزمة، إعادة تجميع NAL)» اكتب الملاحظة قبل تفسيرها. الملاحظة هي شيء يمكن لشخص آخر العثور عليه في السجل: حالة RTSP مرتبطة بـCSeq، أو قيمة في SDP، أو رد Transport، أو فجوة بين رقمين متتاليين، أو تغير SSRC، أو اختلاف بين RTP timestamp وRTCP sender report. أما عبارات مثل «الخادم بطيء» و«الترميز غير متوافق» فهي فرضيات حتى تحدد الحزمة التي تجعلها أرجح من البدائل.

قسّم القضية إلى نقاط حدود. الحد الأول هو فتح اتصال TCP. الثاني هو قبول OPTIONS أو DESCRIBE. الثالث هو أن يصف SDP مسارًا وعرضًا يمكن للعميل استخدامهما. الرابع هو SETUP مع Transport متوافق. الخامس هو PLAY مع Session صحيحة. السادس هو وصول RTP، ثم سلامة الترتيب والتوقيت، ثم استعداد برنامج فك الترميز. توقف عند أول حد لا يملك دليل نجاح؛ الأدلة اللاحقة لا تصلح لإخفاء غياب دليل سابق.

عند مقارنة تجربتين، ثبّت المصدر والوقت قدر الإمكان. إذا اختبرت UDP مقابل TCP interleaved، استخدم عنوان المسار وبيانات الاعتماد نفسها. إذا اختبرت main stream مقابل sub stream، أبق النقل والعميل ثابتين. إذا قارنت VLC مع VMS، سجّل الطلبات التي يرسلها كل عميل بدل الاكتفاء بأن أحدهما يعرض صورة. الاختلاف في control URL أو Authorization أو Session أو keepalive قد يفسر النتيجة أكثر من اسم البرنامج.

مصفوفة الاستبعاد

ابدأ بفرضيتين فقط. مثال: لا توجد وسائط بسبب حجب UDP، أو لأن الخادم يرسل إلى منافذ مختلفة. يختبر TCP interleaved الفرضية الأولى، بينما مقارنة عرض Transport بردّه واستخراج عناوين IP والمنافذ تختبر الثانية. بالنسبة للصورة المشوهة، قارن فرضية فقد RTP بفرضية تهيئة codec ناقصة: أرقام التسلسل تفصل الأولى، ووجود SPS/PPS/VPS قبل أول إطار يفصل الثانية.

لكل فرضية اكتب دليلًا مؤيدًا ودليلًا يمكن أن ينفيها. إذا لم توجد حزمة يمكن أن تنفي الادعاء، فهو واسع أكثر من اللازم. «الـNAT أسقط UDP» يمكن نفيه بوصول RTP إلى منفذ العميل؛ «لا توجد معلمات H.264» يمكن نفيه برؤية SPS وPPS صالحتين قبل IDR. هذه الصياغة تمنع التقرير من التحول إلى قائمة احتمالات بلا ترتيب.

التعامل مع الزمن من دون استنتاج زائد

RTSP CSeq يرتب معاملات التحكم، وRTP sequence يوضح ترتيب الحزم، وRTP timestamp يوضح زمن أخذ عينات الوسائط، بينما وقت الالتقاط يوضح وصول الحزمة إلى نقطة الرصد. لا تساوِ هذه الساعات. فرق وقت الوصول لا يثبت انجراف timestamp، وقفزة timestamp لا تثبت فقد حزمة من دون تسلسل. عند مزامنة الصوت والفيديو، استخدم RTCP sender reports لربط ساعات RTP بزمن مشترك، ولا تعتمد على تشابه أرقام timestamp بين clock rates مختلفة.

حزمة القبول النهائية

يُغلق التحقيق عندما يمكن تكرار الإصلاح في اتصال جديد وبإعداد واحد موثق. يجب أن يوضح التقرير المدخلات، وآخر خطوة ناجحة، وأول دليل فاشل، والتغيير، ونتيجة إعادة الاختبار، وما لم يُختبر. أرفق مقطعًا صغيرًا من السجل أو إحصاءات الحزم بدل ملف ضخم غير محدد. أخفِ الأسرار، لكن لا تحذف CSeq أو Session المموهة أو SSRC أو النطاق الزمني الذي يجعل النتيجة قابلة للمراجعة.

إذا بقيت المشكلة، استخدم استكشاف أخطاء RTSP لإعادة بناء التسلسل، أو تقارير RTSP Inspector لتسليم الحد الفاشل إلى فريق الكاميرا أو الشبكة أو VMS.