2026-06-02

Solución de fragmentación de H.264 FU-A RTP: por qué su vídeo RTSP está roto (pérdida de paquetes, reensamblaje de NAL)

Repara video RTSP roto debido a la fragmentación H.264 FU-A RTP. Cubre fragmentos faltantes, errores de bits de inicio/final, fallas de reensamblaje de NAL, pérdida de paquetes, MTU y errores de decodificador con comandos de diagnóstico reales.

H.264 sobre RTP se rompe de maneras que parecen errores de decodificador pero que en realidad son problemas de paquetización. La sesión RTSP funciona. DESCRIBE devuelve un SDP válido. La CONFIGURACIÓN se realizó correctamente. PLAY devuelve 200 OK. Los paquetes RTP llegan con el tipo de carga útil correcto asignado a H.264. Aun así, el vídeo muestra daños en bloques, congelaciones, fotogramas negros o errores de decodificador.

Los errores se ven así en sus registros:

[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

Una secuencia FU-A completa para una unidad 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)

El reensamblador ve un fragmento inicial, un fragmento intermedio y luego un fragmento final, pero los bytes de carga útil no se conectan. La unidad NAL reensamblada tiene un espacio.

Síntomas:

Bloquear la corrupción en una banda horizontal del marco.
El decodificador informa "tamaño de unidad NAL no válido"
Corrupción limitada a una unidad de acceso (se elimina en el próximo IDR)

Fallo 2: Falta fragmento de inicio

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]

El reensamblador nunca ve el fragmento final. El límite de la unidad NAL nunca se confirma. El decodificador espera más datos que nunca llegan.

Síntomas:

El vídeo se congela
El decodificador informa "falta una imagen en la unidad de acceso"
La reproducción se detiene hasta que llega la siguiente unidad de acceso completo

Fallo 4: fragmentos desordenados

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=...

modo de paquetización = 1 significa modo no entrelazado (se admite FU-A)
packetization-mode=0 significa modo de unidad NAL única (sin fragmentación, muy limitado)

Paso 2: realizar un seguimiento de los números de secuencia RTP

En su captura, observe los números de secuencia RTP de la pista de video. Los espacios en blanco indican pérdida de paquetes:

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)

Byte 1 (encabezado FU):
  0x85 = S=1, E=0, R=0, Tipo=5 (porción IDR) ← fragmento inicial de IDR
  0x45 = S=0, E=0, R=0, Tipo=5 ← fragmento medio
  0x65 = S=0, E=1, R=0, Tipo=5 ← fragmento final; marcador solo si esta NAL cierra la unidad de acceso

Valores incorrectos a buscar:

S=1 en un paquete que no se inicia → confusión del reensamblador
Marcador establecido antes de E=1 → límite falso de unidad de acceso
E=1 sin marcador puede ser válido si después sigue otra unidad NAL
Cambios de tipo a mitad de secuencia → error del codificador o corrupción de la transmisión

Paso 4: verificar el reensamblaje completo

Para cada unidad NAL:

Encuentra el fragmento inicial (S=1)
Siga números de secuencia consecutivos hasta el fragmento final (E=1)
Contar fragmentos; verificar que no haya espacios en la secuencia
Compare el marcador con el límite de la unidad de acceso; no lo exija en cada fragmento final FU-A
Verifique que todos los fragmentos tengan la misma marca de tiempo y tipo NAL.

Paso 5: comparar modos de transporte

Ejecute la misma transmisión a través de UDP y TCP entrelazados. Si el vídeo está limpio en TCP pero dañado en UDP, el problema es la pérdida de paquetes de red, no problemas del codificador o decodificador.

Paso 6: análisis IDR versus no IDR

Los marcos IDR son más grandes y requieren más fragmentos FU-A por unidad NAL. Más fragmentos = más exposición a la pérdida de paquetes. Si la corrupción aparece principalmente en los cambios de escena o cada pocos segundos (en el intervalo IDR), los fotogramas IDR son la víctima.

Opciones de corrección:

Reduzca el tamaño del fotograma IDR (reduzca la resolución o la tasa de bits para los fotogramas clave)
Aumente el intervalo IDR (menos fotogramas grandes, pero una recuperación más lenta de la pérdida)
Reducir la MTU para FU-A en el codificador (más fragmentos, pero cada uno es más pequeño y es menos probable que active la fragmentación de IP)

Estrategias de recuperación

en el reensamblador

Elimine por completo las unidades de acceso dañadas en lugar de enviar datos parciales al decodificador.
Solicite un nuevo fotograma IDR a través de RTCP (si la cámara lo admite)
Espere el siguiente cuadro IDR (el decodificador se recuperará automáticamente)

en el codificador

Reducir el límite de tamaño de la unidad NAL para reducir los fragmentos por unidad de acceso
Utilice intra-actualización periódica en lugar de fotogramas IDR completos (fotogramas clave más pequeños)
Habilite FEC (corrección de errores hacia adelante) si la pila RTP lo admite

en la red

Cambie de UDP a TCP entrelazado si la pérdida de paquetes es inevitable
Asegúrese de que el descubrimiento de MTU de ruta funcione (evite la fragmentación de IP)
Priorice el tráfico RTP en enlaces congestionados

Cuando no es FU-A

No toda la corrupción H.264 es fragmentación FU-A. Controlar:

Falta SPS/PPS: Errores del decodificador como "PPS no existente": verifique los conjuntos de parámetros sprop de SDP
Perfil/nivel incorrecto: El decodificador no puede manejar la complejidad de la transmisión
Error del codificador: El codificador produce una sintaxis de unidad NAL no válida
Corrupción del flujo de bits en la fuente: El codificador de la cámara está roto, no la red

Si los paquetes RTP llegan con números de secuencia perfectos y encabezados FU-A correctos, pero el decodificador aún falla, el problema está en el flujo de bits H.264 en sí, no en el transporte.

Evidencia reproducible para «Solución de fragmentación de H.264 FU-A RTP: por qué su vídeo RTSP está roto (pérdida de paquetes, reensamblaje de NAL)»

La respuesta directa es que una avería de vídeo no se demuestra con una ventana negra ni con un solo código de estado. Un diagnóstico fiable conecta la petición y la respuesta RTSP, el transporte negociado, una sesión válida y después los números de secuencia RTP, las marcas de tiempo y las señales RTCP. Para «Solución de fragmentación de H.264 FU-A RTP: por qué su vídeo RTSP está roto (pérdida de paquetes, reensamblaje de NAL)», empieza por la capa más cercana al síntoma visible, pero conserva una cronología común para no mezclar un fallo de control con uno de red o decodificación.

Antes de cambiar la cámara, el firewall o el VMS, crea una prueba base pequeña. Anota la URL RTSP sin contraseña, la hora, la ruta, el transporte solicitado, la respuesta del servidor y el instante del primer paquete multimedia. Prueba UDP y TCP interleaved por separado cuando el equipo ofrezca ambos. No cambies ruta, credenciales y transporte a la vez; si el segundo intento funciona, necesitas saber qué variable produjo la diferencia.

Capa	Evidencia que se debe guardar	Pregunta de decisión
RTSP	método, estado, cabeceras, CSeq y Session	¿El servidor aceptó exactamente la operación?
SDP	control, payload type, clock rate y codec	¿El servidor describió la pista esperada?
Transport	client_port, server_port o interleaved	¿Ambos extremos usan el mismo canal?
RTP	SSRC, secuencia, timestamp y marker	¿Las unidades llegan en un orden explicable?
RTCP	sender report, CNAME y BYE	¿Se pueden relacionar reloj, identidad y final?
Decoder	SPS/PPS/VPS y packetization mode	¿El payload recibido permite iniciar el decoder?

Separa «no llega multimedia» de «llega multimedia que no se puede decodificar». Si no aparece RTP después de SETUP y PLAY correctos, revisa UDP, NAT, firewall y una respuesta Transport distinta de la oferta. RTP con huecos de secuencia prueba pérdida o reordenación. Una secuencia continua sin imagen desplaza la investigación hacia payload type, clock rate, límites de cuadro y parámetros H.264 o H.265. Esta frontera es más útil que el mensaje general del reproductor.

¿Cómo se redacta una respuesta que pueda citarse?

Usa tres frases: última operación correcta, primera evidencia que falla y siguiente prueba que separa dos causas. Ejemplo: «DESCRIBE, SETUP y PLAY terminan correctamente; no llega RTP a los puertos anunciados por el cliente; repetir por TCP interleaved separará el bloqueo UDP de una ruta multimedia incorrecta». No atribuyas el fallo a la cámara o a la red sin una respuesta o un paquete que marque ese límite.

¿Qué hace reproducible el caso?

Guarda OPTIONS, DESCRIBE, SETUP y PLAY, el SDP, la respuesta Transport y el identificador Session saneado. Para RTP registra SSRC, primer y último número de secuencia, clock rate, huecos y duración. Indica si VLC u otro VMS funciona, pero úsalo como comparación controlada, no como prueba de que el cliente exitoso interpreta todas las reglas de forma correcta.

¿Cuándo se investiga el servidor y cuándo el cliente?

Mira el servidor si rechaza un método, entrega un control URL inexistente, responde con un transporte incompatible o cambia SSRC o reloj sin transición. Mira el cliente si reutiliza un nonce caducado, pierde Session, solicita UDP sin abrir los puertos o interpreta cada final NAL como final de access unit. Si el límite está entre ambos, conserva paquete y hora en cada afirmación.

¿Cómo se revisa el informe?

Repite desde una conexión nueva y compara las dos cronologías solo hasta la primera diferencia. Elimina contraseñas y valores Authorization completos. Relaciona cada conclusión con CSeq, secuencia o timestamp. Continúa con la guía RTSP relacionada y usa RTSP Inspector para probar un stream RTSP y recoger evidencia de forma local, sin subir el vídeo de la cámara a un servicio público.

Respuesta directa y límite de aceptación

La respuesta breve a «Solución de fragmentación de H.264 FU-A RTP: por qué su vídeo RTSP está roto (pérdida de paquetes, reensamblaje de NAL)» es: Repara video RTSP roto debido a la fragmentación H.264 FU-A RTP. Cubre fragmentos faltantes, errores de bits de inicio/final, fallas de reensamblaje de NAL, pérdida de paquetes, MTU y errores de decodificador con comandos de diagnóstico reales. Trate esa frase como un resultado que debe comprobarse, no como una promesa para cualquier entrada, dispositivo, proyecto o entorno. Un resultado completo registra estado inicial, acción exacta, salida visible y condición que demuestra que la tarea terminó en RTSP Inspector.

Procedimiento basado en evidencia

Empiece con un caso pequeño y repetible antes de cambiar un proyecto completo. Anote versión de la aplicación, sistema operativo, identidad de entrada o dispositivo, ajustes relevantes y resultado esperado. Ejecute una acción deliberada, conserve la primera transición inesperada y compárela con un caso conocido cuando exista. Cambiar varios controles a la vez oculta qué condición creó o corrigió el problema.

Punto de control 1: Solución de fragmentación de H.264 FU-A RTP: por qué su vídeo RTSP está roto (pérdida de p

Compruebe «Solución de fragmentación de H.264 FU-A RTP: por qué su vídeo RTSP está roto (pérdida de paquetes, reensamblaje de NAL)» con la entrada representativa más pequeña. Mantenga iguales los ajustes no relacionados, repita la misma acción y revise el resultado después de reabrir o reconectar. Una captura aislada es más débil que un registro con entrada, ajuste, acción, salida y hora.

Punto de control 2: Repara video RTSP roto debido a la fragmentación H.264 FU-A RTP. Cubre fragmentos faltante

Si «Repara video RTSP roto debido a la fragmentación H.264 FU-A RTP. Cubre fragmentos faltantes, errores de bits de inicio/final, fallas de reensamblaje d» es ambiguo, compare un caso bueno y otro fallido bajo condiciones equivalentes. Marque la primera diferencia significativa en vez de enumerar todos los síntomas posteriores. Ese límite suele producir una consulta más clara y un experimento más seguro.

Punto de control 3: The fast answer

Compruebe «The fast answer» con la entrada representativa más pequeña. Mantenga iguales los ajustes no relacionados, repita la misma acción y revise el resultado después de reabrir o reconectar. Una captura aislada es más débil que un registro con entrada, ajuste, acción, salida y hora.

Punto de control 4: Why fragmentation exists

Si «Why fragmentation exists» es ambiguo, compare un caso bueno y otro fallido bajo condiciones equivalentes. Marque la primera diferencia significativa en vez de enumerar todos los síntomas posteriores. Ese límite suele producir una consulta más clara y un experimento más seguro.

Punto de control 5: The structure of an FU-A packet

Compruebe «The structure of an FU-A packet» con la entrada representativa más pequeña. Mantenga iguales los ajustes no relacionados, repita la misma acción y revise el resultado después de reabrir o reconectar. Una captura aislada es más débil que un registro con entrada, ajuste, acción, salida y hora.

Punto de control 6: The RTP marker bit

Si «The RTP marker bit» es ambiguo, compare un caso bueno y otro fallido bajo condiciones equivalentes. Marque la primera diferencia significativa en vez de enumerar todos los síntomas posteriores. Ese límite suele producir una consulta más clara y un experimento más seguro.

Punto de control 7: Failure modes: what breaks and why

Compruebe «Failure modes: what breaks and why» con la entrada representativa más pequeña. Mantenga iguales los ajustes no relacionados, repita la misma acción y revise el resultado después de reabrir o reconectar. Una captura aislada es más débil que un registro con entrada, ajuste, acción, salida y hora.

Punto de control 8: Failure 1: Missing middle fragment

Si «Failure 1: Missing middle fragment» es ambiguo, compare un caso bueno y otro fallido bajo condiciones equivalentes. Marque la primera diferencia significativa en vez de enumerar todos los síntomas posteriores. Ese límite suele producir una consulta más clara y un experimento más seguro.

Punto de control 9: Fallo 2: Falta fragmento de inicio

Compruebe «Fallo 2: Falta fragmento de inicio» con la entrada representativa más pequeña. Mantenga iguales los ajustes no relacionados, repita la misma acción y revise el resultado después de reabrir o reconectar. Una captura aislada es más débil que un registro con entrada, ajuste, acción, salida y hora.

Punto de control 10: Failure 3: Missing end fragment

Si «Failure 3: Missing end fragment» es ambiguo, compare un caso bueno y otro fallido bajo condiciones equivalentes. Marque la primera diferencia significativa en vez de enumerar todos los síntomas posteriores. Ese límite suele producir una consulta más clara y un experimento más seguro.

Matriz de aceptación

Punto	Evidencia que conservar	Condición de aprobado
Solución de fragmentación de H.264 FU-A RTP: por qué su vídeo RTSP está roto (pérdida de paquetes, reensamblaje de NAL)	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Repara video RTSP roto debido a la fragmentación H.264 FU-A RTP. Cubre fragmentos faltantes, errores de bits de inicio/f	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
The fast answer	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Why fragmentation exists	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
The structure of an FU-A packet	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
The RTP marker bit	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado

Aislamiento, recuperación y entrega

Deténgase en el primer límite que falla. Conserve fuente, proyecto, sesión o captura, duplíquelo antes de una edición destructiva y cambie una variable por experimento. Repetir un flujo amplio después de varios cambios puede dar otro resultado sin explicar la causa.

Separe ausencia de evidencia de evidencia de ausencia. Una vista vacía puede indicar entrada, alcance, filtro, permiso, dispositivo, intervalo o estado equivocado. Verifique adquisición o importación antes de interpretar el decoder, editor, informe o exportación.

Antes de entregar, reabra el artefacto y revise inicio, punto de decisión y final. Registre versión, plataforma, configuración, expectativa, observación y reproducción mínima. Elimine o redacte datos sensibles y confirme que el destinatario está autorizado.

Preguntas y respuestas

¿Cuál es la forma fiable más rápida de empezar?

Use el caso representativo más pequeño, escriba el resultado esperado y cambie una variable. Confirme el recorrido básico antes de añadir filtros, efectos, ediciones, automatización o una fuente mayor.

¿Qué evidencia debe guardarse?

Conserve identidad de entrada, versión, plataforma, ajustes, acción exacta, primera transición inesperada y salida final. Cierre y reabra cualquier proyecto, sesión, informe o exportación antes de considerarlo duradero.

¿Cuándo debe repetirse el procedimiento?

Repítalo después de cambios relevantes en aplicación, sistema, driver, firmware, modelo, fuente o flujo. Preserve el caso aceptado anterior como referencia sin modificar.

¿Cuándo está listo para entregar?

Cuando otra persona autorizada identifica la entrada, repite la acción, obtiene el mismo resultado, entiende los límites restantes y abre el artefacto sin depender de estado local no documentado.

Guías relacionadas

Estas páginas en el mismo idioma cubren etapas contiguas sin cambiar el propietario canónico del tema: