H264 marca de tiempo RTP

Question

Tengo una confusión acerca de la marca de tiempo de paquete RTP h264. Sé que la velocidad de reloj de pared de video es 90KHz, que he definido en el SIP SDP. La velocidad de fotogramas de mi codificador no es exactamente 30 FPS, es variable. Esto varía de 15 fps a 30 fps sobre la marcha. Por lo tanto, no puedo usar cualquier marca de tiempo fijo.

¿Podría alguien decirme la fecha y hora de la siguiente paquete codificado.
Después de 0 milisecond codificada marca de tiempo RTP = 0 (Vamos a la marca de tiempo de partida 0)
Después de 50 milisecond codificado RTP timestamp =?
Después de 40 milisecond codificado RTP timestamp =?
Después de 33 milisecond codificado RTP timestamp =?

¿Cuál es la fórmula cuando la tasa de trama codificada es variable?

Gracias de antemano.

Answer 1

No importa si su codificador codifica vídeo a 10 fps o 30 fps, con la marca de tiempo RTP le dice al receptor cuánto tiempo es la pausa entre los dos marcos. Así se determina que sobre la marcha para cada cuadro. De esa manera usted puede enviar 10 cuadros en un segundo (10 fps), y en otro segundo que puede enviar 30 cuadros (30 fps). Sólo es necesario para establecer la marca de tiempo RTP correctamente. Y si me pregunta, no está seguro de cómo hacer esto ...

Deja que la indicación de la hora de partida sea 0, se agrega la hora del reloj en milésimas de segundo multiplicado por 100 para la última marca de tiempo RTP, o puede utilizar cualquier escala de tiempo que desee. Para hacer el vídeo de 10 fps a 30 fps decodificación del decodificador, añadir 333.000 a RTP marca de tiempo para cada paquete ... pero deja mirada en el ejemplo:

Frame #      RTP Time   Time between frames [ms]
[  1]               0   0
[  2]           50000   50
[  3]           90000   40
[  4]          420000   33  

Así que si establece RTP timestamp como esto (Time in ms * 100000) que hará que la carga decodificador y decodificar el fotograma 1, y luego cargar y marco de decodificación 2, pero va a dormir durante 50 ms (diferencia de tiempo entre los fotogramas 1 y 2) antes de que se dibuja el marco 2, y así sucesivamente ...

Y como se puede ver, el decodificador utiliza RTP marcas de tiempo para saber cuándo mostrar cada uno, y es imposible importa si el vídeo se codifica en 30 o 10 fps.

Además, si el vídeo es de 30 fps, eso no significa que por cada segundo habrá 30 paquetes RTP. A veces puede haber más de 100, por lo que no se puede tener una fórmula que garantiza el cálculo correcto de marca de tiempo RTP.

supongo que esto es lo que necesita ... Espero que me ayudó, no te -1 mí si aún no ha ... =)

Answer 2

no existe una fórmula simple para esto.

En el instante utilizado para el muestreo de la trama antes de la codificación se denomina PTS (timestamp presentación). Está fuera del alcance del codificador, hay que recordar que en su flujo de datos cuando se capturan los fotogramas.

A partir de ahí, usted tiene 2 posibilidades:

1. El codificador H264 no genera trama B, entonces la marca de tiempo RTP debe ser el PTS + desplazamiento aleatorio (el mismo para todas las sesiones de streaming)
2. Si el codificador genera fotogramas B (o B-rebanadas), entonces el orden de decodificación necesita ser modificado, ya fotograma B requiere la siguiente trama a descodificar, por lo que debe ser enviado antes.

En el último caso, el RFC6184 indica que tiene múltiples vías para transmitir las unidades NAL codificados.

La mayor parte del software de transmisión utilizará el modo llamado "no entrelazado", en el cual, debe establecer la marca de tiempo RTP para el PTS + offset, pero enviarlos en el orden de decodificación por lo que la marca de tiempo no va a aumentar de forma monótona. Esto también significa que el cliente tendrá que decodificar en el orden recibido y no cambiar el orden de las tramas en el orden PTS.

No estoy usando el término DTS aquí por una razón, porque no necesita la decodificación marca de tiempo para que esto funcione, sólo el orden.

El último modo descrito en RFC6184 es el llamado orden intercalado donde se puede cambiar el orden de las unidades NAL. En ese caso, hay que aplicar un poco de lógica de aplicación para reordenar las unidades, consulte RFC6184 para más detalles.