Resumen

  • RFC 10034 define el formato RTP del atlas V3C y la semántica SDP que reúne las líneas de atlas, ocupación, geometría y atributos. El grupo declara una relación; no certifica entrega, coherencia ni reconstrucción.
  • La autoridad para cerrar una sesión debe basarse en una cadena: versión de señalización, conjunto de parámetros, fuente autorizada, fragmentos completos, orden de decodificación, alineación entre flujos, resultado del decodificador y prueba útil en la aplicación.

Un receptor acepta una oferta con cuatro líneas de medios. La primera trae ocupación, la segunda geometría, la tercera color y la cuarta el atlas. Las cuatro muestran tráfico. La sesión SDP conserva a=group:V3C 1 2 3 4. El atlas acaba una unidad de acceso y su último paquete activa el marcador RTP.

La aplicación no puede formar la mano de la persona capturada.

No faltaba una línea de la oferta. Faltaba el segundo fragmento de una unidad NAL de geometría. Los paquetes posteriores habían mantenido viva la métrica de recepción y los otros tres flujos eran correctos dentro de su propio alcance. El sistema confundió cuatro verdades locales con una verdad compuesta.

El RFC 10034, publicado en agosto de 2026 en la vía de estándares del IETF, permite describir esta frontera con precisión. Define cómo transportar por RTP los subflujos de atlas de Visual Volumetric Video-Based Coding. Para los componentes de vídeo remite a los formatos RTP de cada códec. Además crea parámetros y una agrupación SDP para reconocer qué líneas pertenecen a una representación V3C.

El resultado no es un tubo único. Es un contrato de coordinación entre piezas que conservan sus fallos.

La reconstrucción depende de funciones distintas

V3C convierte información tridimensional en imágenes bidimensionales y datos de atlas. La ocupación señala qué píxeles intervienen. La geometría describe posiciones. Los atributos pueden aportar color, reflectancia, normales o material. El atlas contiene parches e información que permite proyectar las regiones de las imágenes de vuelta al espacio.

La ficha pública de ISO/IEC 23090-5:2026 identifica la edición de la norma V3C y V-PCC utilizada por RFC 10034. El RFC expone los elementos necesarios para comprender el transporte sin fingir que todo el estándar ISO es una sola carga RTP.

El atlas usa application/v3c con reloj de 90 kHz. Ocupación, geometría y atributos pueden usar H.264, H.265, H.266 u otro códec admitido con su propia especificación RTP. Por tanto, una representación puede cruzar distintos packetizadores, colas y superficies de seguridad.

La unidad económica y visual es la escena. La unidad operativa que observa RTP es el flujo. Gobernar el servicio exige no hacerlas equivalentes.

El grupo señala qué comparar

RFC 10034 registra la semántica:

a=group:V3C 1 2 3 4

Los tokens son valores mid. El marco general viene del RFC 5888. La nueva semántica dice que esas líneas forman una representación V3C. No afirma que se hayan abierto, autenticado o recibido.

Las mismas líneas pueden incluirse en un grupo BUNDLE y compartir transporte. Compartir el cinco-tuplas no elimina los tipos de componente ni sus referencias. Cada paquete sigue necesitando asociación con el mid, el conjunto de parámetros, el atlas y la fuente correctos.

El registro de medios de IANA para application/v3c exige sprop-v3c-parameter-set y limita el tipo al encuadre RTP. Los registros SDP de IANA reservan los vocabularios de atributos y grupos. Una inscripción resuelve nombres compartidos; no aporta una lista de productos conformes ni una medida de adopción.

El grupo es, en realidad, una orden de investigación: estas son las líneas cuyos estados deben cuadrar antes de afirmar que existe una escena.

El estado de parámetros puede romper un conjunto válido

sprop-v3c-parameter-set contiene los bytes del conjunto de parámetros codificados en base64. Ese estado describe recursos y perfiles que el receptor necesita para reconstruir. RFC 10034 considera útil anunciarlo fuera de banda porque descubrir durante el flujo que faltan capacidades puede dejar un comportamiento indefinido.

Otros parámetros identifican tipo de unidad, ID del conjunto, atlas, atributo, partición y mapa. Un encabezado compacto puede reemplazarlos. La norma prohíbe enviar a la vez el encabezado y los campos equivalentes para evitar dos autoridades contradictorias.

También puede anunciarse fuera de banda información de atlas, atlas común y SEI. Se aplica hasta que una unidad del mismo tipo dentro del flujo la sustituye. Ese reemplazo cambia el significado de paquetes posteriores. Si no se conserva una revisión de sesión, un receptor puede mezclar estado antiguo con componentes nuevos.

a=v3cfmtp funciona en el nivel de sesión o de medio. Cuando chocan, prevalece el nivel de sesión. La prioridad resuelve la interpretación normativa, pero no demuestra que un proxy de señalización, el remitente y el receptor almacenan la misma versión.

La respuesta puede escoger menos de lo ofrecido

Según el modelo de RFC 3264, el ofertante propone formatos y el receptor responde. RFC 10034 permite aceptar los componentes sugeridos o seleccionar un subconjunto poniendo a cero el puerto de las líneas no deseadas. Incluso prevé que el receptor conozca solo parcialmente V3C.

La autonomía es intencional. La conclusión operacional no viene incluida. Un modo sin color puede seguir siendo útil; uno sin geometría difícilmente producirá el mismo objeto; una inspección puede depender de un atributo que una demostración visual considera prescindible. La aplicación debe publicar su matriz de subconjuntos válidos.

En SDP declarativo, los valores de perfil y nivel describen las propiedades del bitstream y no las capacidades del receptor. Quien no pueda cumplirlos debe rechazar o no participar. Tanto en negociación como en declaración, el control llega hasta la selección. No llega hasta el resultado de ejecución.

El marcador no es un commit distribuido

El RFC 3550 define RTP, incluidos secuencia, tiempo, SSRC y marcador interpretado por el formato. En V3C, el marcador identifica el último paquete de la unidad de acceso transportada en ese flujo. No sabe si el componente vecino ha recibido su última pieza.

El atlas admite una unidad NAL por paquete, varias unidades agregadas o una unidad fragmentada. La agregación reduce sobrecarga y debe respetar el MTU local. Los fragmentos de una NAL se envían consecutivamente, sin anidar otra fragmentación.

Perder un fragmento suele obligar a descartar los fragmentos siguientes de esa NAL, salvo que el decodificador tolere explícitamente la incompletitud. Por eso “siguen llegando paquetes” no es evidencia de unidad completa.

Cuando sprop-max-don-diff es cero o falta, transmisión y decodificación conservan el mismo orden. Si es mayor, aparecen DON y el receptor debe ordenar las unidades antes de entregarlas. La despacketización necesita además considerar flujos dependientes y un posible retraso deliberado para sincronizarlos. RFC 7798 ofrece un antecedente NAL para HEVC, pero RFC 10034 añade la dependencia entre componentes heterogéneos.

La autenticidad debe tener la misma sesión como sujeto

RFC 10034 deja la elección de seguridad a la aplicación. RFC 7202 explica por qué ningún formato RTP puede imponer una solución única para todas las topologías. RFC 7201 enumera opciones, y SRTP aporta mecanismos de confidencialidad, autenticación y defensa frente a repetición.

La norma V3C pide cautela con todos los subflujos: RTP, SDP y RTCP tienen que ser auténticos respecto de lo que quiso el remitente. No basta con proteger el atlas y dejar la geometría fuera de la misma autorización.

Pero un conjunto de cuatro autenticaciones también puede ser incoherente. Dos flujos podrían pertenecer a revisiones diferentes o a tiempos incompatibles. La criptografía protege una afirmación sobre bytes y fuente; no ejecuta la reconstrucción ni certifica el uso final.

Degradar un componente es una decisión semántica

Para unicast, RFC 10034 obliga a vigilar la pérdida y usar control de congestión. Emisor y receptor pueden reducir tasa, abandonar o aplicar el circuit breaker de RTP. También pueden bajar la calidad o suprimir subflujos menos importantes considerando la experiencia global.

El protocolo no sabe qué significa “menos importante”. Quitar color puede preservar una silueta y destruir una clasificación. Reducir geometría puede ser una degradación visual o invalidar la escena. Cada acción de congestión debe cambiar el estado de producto y lanzar una nueva prueba útil.

Un libro mayor debe cruzar todas las capas

Por revisión de sesión, conviene conservar hashes de oferta y respuesta, miembros V3C y BUNDLE, conjunto de parámetros, tipos de componentes, códecs, atlas y fuentes autorizadas. En ejecución, añadir SSRC, transporte, tiempos, pérdida, jitter, fragmentos, reordenamiento DON y fronteras de unidad.

La cadena continúa con entrada al decodificador, errores, identidad del frame reconstruido, prueba visual o analítica, modo degradado, acción de congestión y cierre. Las palabras “aceptado”, “recibido”, “despacketizado”, “decodificado” y “útil” no deben compartir una sola casilla.

La primacía del código en ejecución de Heng Lu ubica la prueba en ese camino. La idea de una especificación inicial mínima con decisiones locales impide convertir el estándar en mando sobre cada receptor. Y la diferencia entre control formal y control práctico explica por qué el creador de la sesión no gobierna copias, buffers y resultados ajenos.

RFC 10034 no promete una escena. Hace más valioso el hecho de poder demostrar cuál se reconstruyó.