Colección H264 Over RTP

http://blog.sina.com.cn/u/465bdf0b010002t1 (algo anda mal)

H264 Payload Format sobre RTP / RTCP, lo hice hace mucho tiempo, y casi lo olvido, date prisa y revísalo, o te lo devolveré ... no debería ser un profesor, jeje.

RTP Baotou todavía está publicado, parece conveniente:

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| V = 2 | P | X | CC | M | PT | número de secuencia |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| marca de tiempo |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| Identificador de fuente de sincronización (SSRC) |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| identificadores de fuente contribuyente (CSRC) |
| .... |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +

No diré más sobre esto :)

El siguiente es el encabezado H264.

El primero es el tipo de unidad NAL, 8 bytes

+ ---------------------- +
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
+ - + - + - + - + - + - + - + - +
| F | NRI | Tipo |
+ ---------------------- +

F: definido como 0

NRI (nal_ref_idc): 00 no es un marco de referencia utilizado para construir la predicción del marco I.
No 00 se utiliza para mantener la integridad del marco de referencia.

(Qué es, no lo entiendo de todos modos, y no lo necesito. Haré el códec la próxima vez. He visto muchos conceptos y no lo tengo claro, lo siento. )

Tipo (nal_unit_type): como se muestra en la siguiente tabla

Tipo | Tipo de paquete | nombre

Explicar:

H264 sobre RTP se divide básicamente en tres tipos:

1. El paquete de una sola unidad NAL es el tipo NAL real, que puede entenderse como un paquete es una trama de datos H264, que es más en la práctica.

2. Paquete de agregación Un paquete de datos contiene múltiples tramas H264. También se puede subdividir, como se describe a continuación.

3. Unidad de fragmentación Una trama de datos se divide en varios paquetes RTP, lo que también es muy común, especialmente para las tramas clave.

Desglose el paquete de agregación:

El paquete de agregación se puede dividir en cuatro tipos:

Las tramas del paquete STAP-A contienen el mismo tiempo NALU sin DON

Las tramas del paquete STAP-B contienen el mismo tiempo NALU, con DON

Las tramas en el paquete MTAP16 contienen diferentes tiempos NALU, desplazamiento de marca de tiempo = 16

Las tramas en el paquete MTAP24 contienen diferentes tiempos NALU, desplazamiento de marca de tiempo = 24

Los que realmente se utilizan son 1-23. STAP-A (24) y FU-A (28) no han encontrado otros tipos, así que no los estudié, claro, me refiero al cliente. Si desea hacer un remitente, puede solicitarlo usted mismo.

Los datos obtenidos de RTP no tienen un encabezado NAL. El significado del encabezado NAL en los documentos RFC3984 e ITUTH264 parece ser diferente. Fue esta confusión al principio, y fue una pérdida de tiempo. Olvidé los detalles, no me molesto en buscarlo nuevamente, y lo llenaré cuando lo vea la próxima vez. La aplicación real es agregar un encabezado H264 STREAM

h264_stream_head = 0x00, 0x00, 0x00, 0x01 4 bytes

El siguiente es el tipo de unidad NAL, que se refiere al tipo NAL definido por H264. Hay una pequeña diferencia, especialmente cuando se trata de FU, que se discutirá a continuación.

Paquete de unidad NAL única （1-23）

Esto es muy simple, un paquete es una trama de datos. h264_stream_head + NAL_unit_type ... enviado directamente a la decodificación.

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| F | NRI | tipo | |
+ - + - + - + - + - + - + - | |
| Bytes 2..n de una sola unidad NAL |
| |
| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| : ... Acolchado RTP OPCIONAL |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +

STAP-A （24）

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| Encabezado RTP |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| STAP-A NAL HDR | NALU 1 Tamaño | NALU 1 HDR |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| Datos de NALU 1 |
::
+ + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| | NALU 2 Tamaño | NALU 2 HDR |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| Datos de NALU 2 |
::
| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| : ... Acolchado RTP OPCIONAL |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +

Esta estructura debe ser muy clara Primero, la longitud de 16 bits, puede obtener una trama, h264_stream_head + NALU 1 HDR ... envíelo para decodificar. Cuente el siguiente cuadro. Tenga en cuenta que no está necesariamente alineado con 32 bits.

Cabe señalar que este tamaño NALU no incluye los 2 bytes en sí.

FU-A （28）

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| Indicador FU | Cabecera FU | |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |
| |
| Carga útil FU |
| |
| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| : ... Acolchado RTP OPCIONAL |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +

Indicador FU

+ ---------------------- +
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
+ - + - + - + - + - + - + - + - +
| F | NRI | Tipo |
+ ---------------------- +

Encabezado FU

+ ---------------------- +
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
+ - + - + - + - + - + - + - + - +
| S | E | R | Tipo |
+ ---------------------- +

S: 1 significa el paquete de inicio de una trama

E: 1 significa el paquete final de una trama, que es consistente con el bit marcador RTP

R: 0 debe

Cabe señalar aquí que el tipo de unidad NAL debe ensamblar los primeros cuatro bytes del indicador FU + los últimos cuatro bytes del encabezado FU por sí mismo. Es decir, el campo de tipo está en el encabezado FU

nal_unit_type = (fu_indicator & 0xe0) | (fu_header y 0x1f)

Cuando se reciben las tramas, agregue H264_streaming_head + nal_unit_type .... para decodificar

Algunos de ellos no se pueden recordar, todos se eliminan del código y debe escribirlos la próxima vez que los vea. Es muy agotador escribir, después de salir del trabajo, 88

Materiales de referencia:

1. RFC3984 - Formato de carga útil RTP para video H.264

Cálculo de la frecuencia de muestreo de audio y la marca de tiempo

Para ffmpeg, el intervalo de marca de tiempo es: presentation_time = frame_size / sample_rate;

frame_size: el número de bytes correspondientes a cada marco de datos

sample_rate: frecuencia de muestreo, que se refiere al número de veces que se muestrea la amplitud de la onda de sonido por segundo cuando se digitaliza la forma de onda de sonido analógica

presentation_time: intervalo de tiempo, es decir, el tiempo que se reproduce el marco de datos, en s, si usa milisegundos como unidad, multiplique por 1000

Presentation_time = frame_size * 1000 / sample_rate;

Por ejemplo: el número de bytes correspondientes a cada cuadro de datos AAC es 1024, si sample_rate == 32K, el intervalo de tiempo correspondiente es 1024 * 1000/32000 = 32ms

El número de bytes correspondientes a cada cuadro de datos mp3 es 1152, si smple_rate == 8k, el intervalo de tiempo correspondiente es 1152 * 1000/8000 = 144ms

Método de sellado de tiempo de audio y video

http://blog.csdn.net/wfqxx/article/details/5497138

1. Marca de tiempo del video

pts = inc ++ * (1000 / fps); donde inc es un estado estático, el valor inicial es 0 y la marca de tiempo inc se incrementa en 1.

En ffmpeg, el código en

pkt.pts = m_nVideoTimeStamp ++ * (m_VCtx-> time_base.num * 1000 / m_VCtx-> time_base.den);

2. Marca de tiempo de audio

pts = inc ++ * (frame_size * 1000 / sample_rate)

El código en ffmpeg es

pkt.pts = m_nAudioTimeStamp ++ * (m_ACtx-> frame_size * 1000 / m_ACtx-> sample_rate);

La frecuencia de muestreo se refiere al número de veces que se muestrean las muestras de amplitud de la onda de sonido por segundo cuando se digitaliza la forma de onda de sonido analógica.

. El rango de frecuencia de la audición humana normal es de aproximadamente 20 Hz ~ 20 kHz. Según la teoría de muestreo de Nyquist, para garantizar que el sonido no se distorsione, la frecuencia de muestreo debe ser de alrededor de 40 kHz. Las frecuencias de muestreo de audio más utilizadas son 8 kHz, 11,025 kHz, 22,05 kHz, 16 kHz, 37,8 kHz, 44,1 kHz, 48 kHz, etc. Si se utiliza una frecuencia de muestreo más alta, también se puede lograr la calidad de sonido de un DVD.

Al decodificar audio AAC con una frecuencia de muestreo de 44,1 kHz, el tiempo de decodificación de un cuadro debe controlarse dentro de los 23,22 milisegundos.

conocimiento de fondo:

(Un marco original de AAC contiene 1024 muestras y datos relacionados en un período de tiempo)

análisis:

1 CAA

Tiempo de reproducción de cuadros de audio = el número de muestras de muestreo correspondientes a un cuadro AAC / frecuencia de muestreo (unidad: s)

1024 muestras por fotograma. La frecuencia de muestreo es 44100 KHz, 44100 muestras por segundo, por lo que de acuerdo con la fórmula, el tiempo de reproducción del cuadro de audio = el número de muestras de muestra correspondientes a un cuadro AAC / frecuencia de muestreo

El tiempo de reproducción actual de un cuadro de AAC es = 1024 * 1000000/44100 = 22.32ms (la unidad es ms)

2 MP3

Cada cuadro de mp3 tiene 1152 bytes, luego:

frame_duration = 1152 * 1000000 / sample_rate

Por ejemplo: cuando sample_rate = 44100HZ, la duración calculada es 26.122ms, por lo que el tiempo de reproducción de mp3 que se escucha con frecuencia por cuadro se fija en 26ms.

El principio de sincronización de audio y video (reproducción)

Cada cuadro de audio o video tiene una duración: duración: la
frecuencia de muestreo se refiere al número de veces que se muestrea la amplitud de la onda de sonido por segundo cuando se digitaliza la forma de onda de sonido analógica.
. El rango de frecuencia de la audición humana normal es de aproximadamente 20 Hz ~ 20 kHz. Según la teoría de muestreo de Nyquist, para garantizar que el sonido no se distorsione, la frecuencia de muestreo debe ser de alrededor de 40 kHz. Las frecuencias de muestreo de audio más utilizadas son 8 kHz,

11.025kHz, 22.05kHz, 16kHz, 37.8kHz, 44.1kHz, 48kHz, etc. Si se usa una frecuencia de muestreo más alta, también se puede lograr la calidad
de sonido del DVD . Al decodificar audio AAC con una frecuencia de muestreo de 44.1kHz, la El tiempo de un fotograma debe ser Control dentro de 23,22 milisegundos.
Conocimientos previos:
(Un cuadro original AAC contiene 1024 muestras y datos relacionados en un período de tiempo)
Análisis:
1)
El tiempo de reproducción del cuadro de audio AAC = el número de muestras de muestra correspondientes a un cuadro AAC / frecuencia de muestreo (unidad: s )
un cuadro 1024 muestras. La frecuencia de muestreo es 44100 KHz, 44100 muestras por segundo, por lo que de acuerdo con la fórmula, el tiempo de reproducción del cuadro de audio = el número de muestras de muestra correspondientes a un cuadro AAC / frecuencia de muestreo El tiempo de reproducción
actual de un cuadro AAC es = 1024 * 1000000/44100 = 22.32ms (Unidad: ms)
2)
Cada cuadro de MP3 mp3 tiene 1152 bytes, luego:
frame_duration = 1152 * 1000000 / sample_rate
Por ejemplo: cuando sample_rate = 44100HZ, la duración calculada es 26.122ms. Esta es la frecuencia mp3 escuchado cada El origen del tiempo de reproducción del fotograma se fija en 26 ms.
3)
El tiempo de reproducción del vídeo H264 está relacionado con la velocidad de fotogramas frame_duration = 1000 / fps
Por ejemplo: fps = 25,00, el valor calculado suele ser 40 ms, que es lo que la industria dice que es 40 ms un fotograma de datos de vídeo.

La sincronización teórica de audio y video (reproducción) es así:
se obtiene la duración de cada cuadro de datos, y el audio y el video se entrelazan en el contenedor: un eje de
tiempo: eje de tiempo: 0 22.32 40 44.62 66.96 80 89.16 111.48 120 . ...............
Audio: 0 22.32 44.62 66.96 89.16 111.48 ......
Video: 0 40 80120 ..... ........
Eso es decir, se agrega la duración del video y se agrega la duración del audio para comparar, se escribe el que sea menor.

Pero la situación real (jugando) no es cierta

1: resuelve un problema primero

¿Por qué no reproduce audio y video? Lo anterior reproducirá un cuadro de audio a 22,32 ms y reproducirá un cuadro de video a 40 ms.

Porque este 22,32 ms o 40 ms no es exacto, o es diferente del tiempo de transmisión de la tarjeta de sonido . Aquí necesita saber cuánto tiempo tarda la tarjeta de sonido en reproducir un fotograma o un audio buf.

2: La tarjeta de sonido reproduce un punto de muestreo a la vez en lugar de un cuadro. El sonido se puede escuchar cuando se pierde un punto de muestreo, pero el video no.

3: modo de sincronización de audio y video: 1 ---- modo de devolución de llamada

Suponga que la tarjeta de sonido tiene dos búferes, los cuales almacenan el pcm de sonido que se reproducirá, y han estado reproduciendo buf "B". Primero determine algunos puntos

(1) El tamaño del buf es fijo, por lo que el tiempo para reproducir un buf es fijo, asumiendo 30 ms;

(2) Cuando se reproduce buf "B", buf se agota y luego se vuelve a reproducir buf "A" para garantizar que el pcm de audio sea siempre continuo

(3) Cuando se reproduce un buf, significa que el sistema (tarjeta de sonido) ha pasado de 30ms. En este momento , es posible que el tiempo real haya pasado de 40ms (no importa aquí), y aquí tienes un tiempo de 30 ms a través de la devolución de llamada;

(4) Luego use los 30ms de video correspondientes al audio, el tiempo en este momento es exacto:

Línea de tiempo: 0 30 60 90120 ......
Audio: 0 22.32 44.62 66.96 89.16 111.48 ......
Video: 0 40 80120 ......

(5) Hay una pregunta aquí: cómo calcular los 10ms entre 30ms y 40ms en el video, esto no es una preocupación, porque los ojos humanos no pueden verlo en 10ms.

Es decir, cuando se recupera el audio una vez en 30 ms, se puede reproducir el segundo cuadro de video, como se muestra en la figura anterior.

La primera devolución de llamada (30 ms) --- transmisión de video (40 ms),

La primera devolución de llamada (60 ms) --- transmisión de video (80 ms),

La primera devolución de llamada (90 ms) --- sin video,

El primer video de devolución de llamada (120 ms) -transmisión (120 ms).

4: modo de sincronización de audio y video: 1 ---- modo de bloqueo

Todavía mira la imagen de arriba

(1) buf "B" se está reproduciendo todo el tiempo, el buf externo pasado en buf "A" envía los datos a buf "A" y luego no regresa inmediatamente, espere hasta que se reproduzca buf "B" y luego regrese,

En este momento, el tiempo entre el bloqueo entrante y saliente es un búfer, como los 30 ms anteriores.

(2) Entonces buf "A" ha estado sonando, el buf externo pasado en buf "B" le da los datos a buf "B" y luego no regresa inmediatamente, espere hasta que se reproduzca buf "A" y luego regrese,

En este momento, el tiempo entre el bloqueo entrante y saliente es un búfer, como los 30 ms anteriores.

(3) Realice un bucle con el (1) (2) anterior y obtenga el mismo tiempo de 30 ms que el método de devolución de llamada. Lo siguiente es el mismo que el método de devolución de llamada, consulte el método de devolución de llamada (4) (5).

Publicado de http://blog.csdn.net/zhuweigangzwg/article/details/25815851

H264 Over RTP, tasa de muestreo de audio y cálculo de marca de tiempo

Colección H264 Over RTP

Cálculo de la frecuencia de muestreo de audio y la marca de tiempo

Método de sellado de tiempo de audio y video

El principio de sincronización de audio y video (reproducción)

Supongo que te gusta