Explicación detallada de los protocolos H264 y H265 de encapsulación del protocolo RTMP

Directorio de artículos

Explicación detallada de los protocolos H264 y H265 de encapsulación del protocolo RTMP

1 RTMP y FLV

Para obtener una introducción detallada a los formatos RTMP y FLV, consulte el siguiente artículo:
https://www.cnblogs.com/ssyfj/p/14684500.html

Como se mencionó anteriormente, cuando RTMP transmite mensajes de audio y video, la carga útil de RTMP adopta el formato de encapsulación FLV. Esta declaración es un poco inexacta. La carga útil de mensajes de audio y video de RTMP no es una encapsulación completa de FLV, sino que solo usa la encapsulación del cuerpo de la etiqueta FLV. Formato, ¿por qué no usar aquí la encapsulación completa del formato flv? Esto se debe a que la información contenida en el encabezado RTMP y la entrega del mensaje en la interacción de flujo push-pull RTMP puede cubrir completamente la información contenida en el campo del encabezado FLV y el campo del encabezado de la etiqueta. . El principio de datos mínimos semanales, solo el formato de cuerpo de la
consultela etiqueta de especificación

Este artículo presenta principalmente la introducción de formato y el análisis de captura de paquetes de mensajes de video RTMP cuando RTMP envía videos H264 y H265.

El protocolo 2 RTMP encapsula el flujo de video H264

Del artículo "Explicación detallada de RTMP de Streaming Media", hemos presentado el proceso de transmisión y transmisión RTMP en detalle, por lo que no lo presentaremos aquí. Aquí solo presentamos el formato de los mensajes de video RTMP. Otros tipos de mensajes e interacción Los procesos se pueden encontrar en este artículo.

Los mensajes de video RTMP son iguales a los mensajes en otros formatos, que consisten en un encabezado de mensaje y un cuerpo de mensaje De acuerdo con el método de transmisión de bloques de mensajes presentado anteriormente, al dividir un mensaje, solo el cuerpo del mensaje se divide en varios fragmentos de datos y el el encabezado del mensaje se fusiona con En el encabezado del fragmento, se compone de encabezado del fragmento + datos del fragmento. Muchos artículos se refieren directamente a él como encabezado RTMP y cuerpo RTMP, que están marcados en wireshark.
El ID de flujo de fragmentos en el encabezado del fragmento se utiliza para distinguir el canal de mensajes. Debido al protocolo RTMP, todas las comunicaciones se realizan a través del mismo TCP, por lo que todos los tipos de canales de comunicación deben distinguirse por el ID de flujo de fragmentos, a fin de determinar la recepción actual El tipo de canal al que pertenece el mensaje recibido lo define el usuario. Adobe recomienda las siguientes clasificaciones:

transmisión obs y transmisión ffmpeg tienen sus propios métodos de definición, que son ligeramente diferentes a este. La fórmula de reanálisis CSID solo puede ser utilizado como El canal de una transmisión, el audio y el video se identifican por el Tipo de mensaje, y la definición del tipo de mensaje se muestra en la siguiente figura:

Aquí se puede ver que el tipo de mensaje del mensaje de video es 9. Cuando el tipo de mensaje es 9, significa que el cuerpo del mensaje son datos de video en el formato de encapsulación del cuerpo de la etiqueta de video (Datos de video). Los datos se muestran en la siguiente figura (video_file_format_spec_v10 flv /f4v especificación):

Tipo de cuadro (frametype): ocupando los 4 bits superiores, definiendo el tipo de cuadro del video
Tipo de codificación (CodecId): ocupa los cuatro bits inferiores, define el formato de codificación de video, H264 es 7, los datos de video adoptan el formato AVCVIDEOPACKET
Datos de video (videoData): Seleccione el formato de encapsulación de datos de video correspondiente según el tipo de codificación, aquí introduce H264, seleccione el formato AVCVIDEOPACKET
formato AVCVIDEOPACKET como se muestra en la figura a continuación:
Tipo de paquete AVC (AVCPacketType): 0 indica el encabezado de secuencia de AVCC. El formato de paquete de video aquí no es nuestro Anexo B común, sino el método AVCC. Cuando H264 usa el paquete AVCC, la decodificación necesita el encabezado de secuencia AVCC, y el cliente debe recibe esto para decodificar Solo se decodificará el paquete de encabezado de secuencia; 1 significa H264 nalu, este paquete es un paquete de datos H264, en comparación con el Anexo B, se elimina el código de inicio nalu 00000001 y se aumenta la longitud nalu de cuatro bytes
Compensación de tiempo de composición: el tiempo de cuadro de composición es barato, generalmente inútil, asigne directamente un valor de 0
Datos de video (Data): De acuerdo al tipo de paquete AVC se encapsula el dato correspondiente, cuando AVCPacketType=0 se encapsula de acuerdo al formato de encabezado de secuencia AVCC, y cuando es 1 se encapsula de acuerdo a nalu.
Mi artículo "Explicación detallada de fmp4 Packing H264" presenta el formato de encapsulación de AVCC H264 en detalle. Cuando RTMP envía datos de video, el cliente puede inicializar el decodificador después de recibir el encabezado de secuencia AVCC y realizar la operación de decodificación de cuadros nalu posteriores. Aquí, para evitar que se pierda el primer paquete de datos. Generalmente, el servidor enviará un paquete de encabezado de secuencia AVC antes de cada marco IDR para garantizar que el cliente pueda continuar decodificando y reproduciendo en casos extremos. Aquí, el encabezado de secuencia AVC y AVCC Nalu se envían desde RTMP Para presentar el formato de empaque en detalle.

2.1 RTMP envía encabezado de secuencia AVC

RTMP envía el encabezado de secuencia AVC, su método de paquete de datos de video (establece el paquete como una matriz buf), el primer byte es buf[0]=0x17=0B00010111, su tipo de cuadro es un cuadro clave, por lo que los cuatro bits superiores son 1 y el tipo de codificación es H264, por lo que los cuatro bits inferiores son 7, sus datos de video adoptan el formato AVCVIDEOPACKET y AVCPacketType es el encabezado de secuencia AVC, por lo que buf[1]=0, buf[2,3,4]={0,0, 0}, en este momento el formato de datos es AVCDecoderConfigurationRecord (es decir, encabezado de secuencia AVC), y el formato del encabezado de secuencia AVC es el siguiente: el número de versión se fija en 1, por lo que buf[5]=1, y

el los siguientes tres bytes indican la especificación de codificación, la compatibilidad de codificación y el nivel de codificación, de SPS Se puede obtener, por lo que buf[6]=SPS[1], buf[7=SPS[2], buf[8]=SPS[3] , lengthSizeMinusOne indica cuántos bytes se usan para representar el tamaño de nalu, generalmente el valor predeterminado es 3. Su valor +1 significa que nalu necesita usar 4 bytes para representar la longitud, buf[9]= 0xFC|0x3=0xFF, el siguiente byte representa la cantidad de SPS, H264 generalmente solo tiene un SPS, por lo que buf[10]=E0 |01=E1, seguido del tamaño de SPS y los datos de SPS, el tamaño de SPS representa 2 bytes, buf[11,12,13,14 ]=tamaño SPS (modo big-endian), seguido de datos SPS directamente, preste atención aquí Para eliminar los datos después del código de inicio, suponiendo que el SPS es 24 después de eliminar el código de inicio, entonces buf[11-12]=0x0018 , buf[13-26]= SPS data, el siguiente byte es el número de PPS, generalmente 1, buf[27]=1, seguido de PPS Size y PPS Data, suponiendo que PPS Size=4, luego buf[28- 29]=0x04, buf[30-33]=Datos PPS, hasta ahora el comienzo de la transmisión RTMP El encabezado de la secuencia AVC del marco se ensambla, y este marco se puede enviar repetidamente con el marco IDR cada vez

2.2 RTMP envía datos de cuadros de video AVCC'

El artículo anterior presentó cómo RTMP envía cuadros de secuencia AVC ¿Cómo se envía el cuadro de video real? La transmisión del cuadro de video real es muy simple, si es un cuadro I, buf[0]=0x17, lo que significa un cuadro clave, codificación H264; el tipo AVCPacketType del cuadro de video es AVC Nalu, entonces buf[1]=1 ,buf[2,3,4 ]={0,0,0}, en este momento, el formato de datos es el método de encapsulación AVCC Nalu, es decir, tamaño nalu de 4 bytes + datos nalu (elimine el código de inicio), por lo que buf[5-8]=tamaño nalu, buf[9-n]=datos nalu, hasta ahora se combina la carga RTMP del cuadro I; el cuadro P y el cuadro I son diferentes en el primer byte, el cuadro P no es un cuadro clave , por lo que frametype=2, buf[0]=0x27 , los otros métodos de combinación son los mismos y no se presentarán aquí.

El protocolo 3 RTMP encapsula la transmisión de video H265

El protocolo RTMP no presenta especificaciones relacionadas con H265. El estándar de extensión HEVC de CDN Alliance se puede usar para definir VideoTagHeader de HEVC como 12. Consulte la siguiente figura para obtener más detalles:

Cuando la codificación HEVC, CodecID = 12, la encapsulación de datos de video adopta la encapsulación HEVC y adopta el formato de encapsulación HVCC, similar a AVCC, no tiene código de inicio, los primeros cuatro bytes indican el tamaño de nalu, y su decodificación de cliente debe recibirse primero Para el encabezado de secuencia de HEVC, el formato del encabezado de secuencia es el siguiente:

el valor de los campos relevantes definidos en el formato puede analizarse directamente desde el marco de secuencia SPS de HEVC y combinarse en el encabezado de secuencia de HEVC de acuerdo con este formato , su buf[0]=0x1C, lo que significa fotograma clave, el formato de codificación es HEVC, buf[1]=0 significa fotograma de secuencia HEVC, buf[2-4]=0x000000, buf[5]=1, la codificación posterior la asignación de información se basa en el análisis del H265 SPS. La asignación de valor es suficiente, donde numOfArrays indica el número de matrices posteriores, generalmente 0x03, lo que indica que contiene VPS/SPS/PPS, y el método de encapsulación de la última matriz se muestra a continuación. (detallado en "ISO-14496-15 formato de archivo AVC"):

// The CodecPrivate syntax shall follow the
// syntax of HEVCDecoderConfigurationRecord
// defined in ISO/IEC 14496-15.
//
// The number zero (0) shall be written to
// the configurationVersion variable until
// official finalization of 14496-15, 3rd ed.
//
// After its finalization, this field and the
// following CodecPrivate structure shall
// follow the definition of the
// HEVCDecoderConfigurationRecord in 14496-15.

unsigned int(8)  configurationVersion;
unsigned int(2)  general_profile_space;
unsigned int(1)  general_tier_flag;
unsigned int(5)  general_profile_idc;
unsigned int(32) general_profile_compatibility_flags;
unsigned int(48) general_constraint_indicator_flags;
unsigned int(8)  general_level_idc;
bit(4) reserved = ‘1111’b;
unsigned int(12) min_spatial_segmentation_idc;
bit(6) reserved = ‘111111’b;
unsigned int(2)  parallelismType;
bit(6) reserved = ‘111111’b;
unsigned int(2)  chromaFormat;
bit(5) reserved = ‘11111’b;
unsigned int(3)  bitDepthLumaMinus8;
bit(5) reserved = ‘11111’b;
unsigned int(3)  bitDepthChromaMinus8;
bit(16) avgFrameRate;
bit(2)  constantFrameRate;
bit(3)  numTemporalLayers;
bit(1)  temporalIdNested;
unsigned int(2) lengthSizeMinusOne;
unsigned int(8) numOfArrays;
for (j=0; j < numOfArrays; j++) {
  bit(1) array_completeness;
  unsigned int(1)  reserved = 0;
  unsigned int(6)  NAL_unit_type;
  unsigned int(16) numNalus;
  for (i=0; i< numNalus; i++) {
    unsigned int(16) nalUnitLength;
    bit(8*nalUnitLength) nalUnit;
  }
}

La explicación detallada es la siguiente:

pedacitos	describir	Observación
1	matriz_completa	Predeterminado 0
1	reservado	Predeterminado 0
6	tipo_unidad_NAL	tipo de marco
dieciséis	numNalus	El número de cuadros de este tipo es generalmente 1, si es mayor que 1, ingrese el ciclo a continuación
dieciséis	nalUnitLength	2 bytes indican la longitud de la trama adicional (VPS/SPS/PPS)
norte	datos NALU	Datos de trama adicionales (VPS/SPS/PPS)

Generalmente, numOfArrays=3, la primera matriz son datos relacionados con VPS, la segunda matriz es SPS y la tercera matriz es PPS

La encapsulación del cuadro de video Hevc es similar a la de H264. Cuando es un cuadro I, buf[0]=0x1C, lo que indica un cuadro clave, codificación H265, el tipo de cuadro de video es HEVCNalu, entonces buf[1]=1, buf[2,3, 4]={0,0,0}, en este momento, el formato de datos es el método de encapsulación HEVC Nalu, es decir, tamaño nalu de 4 bytes + datos nalu (elimine el código de inicio y necesite elimine el byte de transferencia), por lo que buf[5 -8]=nalu size,buf[9-n]=nalu data, hasta ahora se ensambla la carga RTMP del cuadro I; el cuadro P es diferente del cuadro I en el primer byte, y el cuadro P no es un cuadro clave, por lo que frametype=2, buf[0]=0x2C, otras combinaciones son iguales, no hay introducción aquí