El RTP header estándar es seguido por 2 octetos de payload header que extienden el número de secuencia RTP, y por 6 octetos de paylaod header para cada línea (o línea parcial) de video incluida. Luego siguen una o más líneas, o líneas parciales, de datos de video. Este formato hace que el payload header de 32 bits esté alineado en un caso común, donde una línea de escaneo (o fragmento) de video es incluida en cada paquete RTP.
Por ejemplo, si se encapsulan dos líneas de video, el formato de payload será de esta manera:
RTP Payload Format con dos líneas de video (parciales)
14.8.3.1.RTP Header
Los campos del RTP header fijo tiene su significado habitual, con los siguientes agregados:
Payload Type (PT): 7 bits – Es un campo de tipo de payload colocado en
forma dinámica que define al payload como “video sin comprimir”.
Timestamp: 32 bits – Para el escaneo de video progresivo, el timestamp
denota el instante de muestreo del frame al cual pertenece el paquete RTP. Los paquetes no deben incluir datos de múltiples frames, y todos los paquetes pertenecientes al mismo frame deben tener el mismo timestamp.
Se deberá usar un timestamp con reloj de 90 KHz, y si el instante de muestreo no corresponde con un valor entero del reloj (como puede ocurrir en el caso de interleaving) el valor deberá truncarse al siguiente entero más bajo, sin ambigüedad.
Marker bit (M): 1 bit – Si se transmite el video escaneado en modo
progresivo, el Marker bit denota el fin de un frame de video. Este bit deberá ser establecido en 1 para el último paquete del frame de video y 0 para otros paquetes.
Sequence Number: 16 bits – Ese incrementan los 16 bits del campo
estándar de RTP en 16 bits más en el payload header para evitar que los números de secuencia no sufran un roll-over.
14.8.3.2.Payload Header
A continuación se detallan los campos del payload header:
Extended Sequence Number: 16 bits – Son los bits de alto orden del campo
de números de secuencia extendido de 32 bits, con el orden de bytes que llegan desde la red.
Length: 16 bits – Es el número de octetos de datos incluidos por la presente
línea escaneada, con el orden de bytes que llegan desde la red.
Line Number: 15 bits – Es el número de línea escaneada de los datos
encapsulados, ordenados por bytes con el orden que llegan desde la red. Los paquetes RTP sucesivos pueden contener parte de la misma línea escaneada (con el número de secuencia RTP incrementado, pero con el mismo timestamp) en el caso que sea necesario fragmentar una línea.
Offset: 15 bits – Es el offset del primer píxel de los datos del payload
dentro de la línea escaneada. En el presente caso que se transporta datos de vidoe con formato YCbCr, este valor es el offset del píxel de la muestra de luminancia. El valor se brinda con el orden de bytes que llegan desde la red. El offset tiene un valor de cero si la primera muestra en el payload corresponde al comienzo de la línea, y luego se incrementa por uno para cada píxel.
Field Identification (F):1 bit – Identifica el campo al que pertenece la línea
escaneada, para el escaneo entrelazado. En el caso del presente trabajo, como usamos escaneo progresivo, F siempre está establecido en 0.
Continuation ( C ): 1 bit – Determina si un header adicinal de una línea
escaneada sigue al actual header de la línea escaneada en el paquete RTP. Se establece en 1 si sigue un header adicional, implicando así que el paquete RTP está transportando datos para más de una línea escaneada. En le caso contrario, se establece en 0. En un único paquete se pueden llegar a incluir diferentes líneas escaneadas, hasta llegar al límite del MTU del camino de red. La única manera de determinar la cantidad de líneas escaneadas incluidas por paquetes es analizando el payload header.
14.8.3.3.Datos del Payload
Dependiendo del formato de video, cada paquete RTP puede incluir ya sea una sola línea de escaneo completa, un solo fragmento de una línea de escaneo, o una o más líneas de escaneo completas y fragmentos de líneas de escaneo. La longitud de cada línea de escaneo o fragmento de línea de escaneo debe ser un múltiplo entero del tamaño en octetos del pgroup. Las líneas de escaneo deberán fragmentarse para que el paquete RTP resultante sea de tamaño menor o igual al MTU de la red.
Es posible que la longitud de la línea de escaneo no sea divisible por el número de píxeles en un pgroup, y así el dato de píxel final de una línea de escaneo no se alinea ni con un octeto ni con el límite del pgroup. Sin embargo el payload debe contener unnúmero entero de de pgroups; el emisor debe llenar los bits restantes del final del pgroup con 0 y el receptor deberá ignorar los datos así completados.
En el caso de vido con formato YCbCr, el empaquetado de las muestras dentro del payload depende del submuestreo de color usado. Para el formato de video YCbCr 4:2:2, los componentes Cb y Cr están horizontalmente submuestreados por un factor de 2 (cada muestra Cb y Cr corresponde a dos componentes Y). Las muestras son empaquetadas en el orden Cb0-Y0-Cr0-Y1, tanto para el escaneo de líneas entrelazado como progresivo. Para el caso como el presente de muestras con 8 bits (luego de haber sufrido un downsampling desde los 10 bits iniciales) el pgroup se forma con dos pixels adyacentes (4 octetos).