Estoy intentando recibir vídeos de tres cámaras vía rtsp. Usamos ffmpeg con múltiples salidas como explica ffmpeg, pero el retraso es peor que si ejecutamos directamente tres procesos de Linux diferentes, ¿es posible encontrar alguna combinación de comandos de ffmpeg para iniciar en el momento exacto el proceso de grabación para las tres cámaras?
Actualmente, estamos usando este comando:
ffmpeg -rtsp_transport tcp -i rtsp://admin:[email protected]:554 -rtsp_transport tcp -i rtsp://admin:[email protected]:554 -rtsp_transport tcp -i rtsp://admin:[email protected]:554 -map 0 -vcodec copy video1.mp4 -map 1 -vcodec copy video2.mp4 -map 2 -vcodec copy video3.mp4 -y
Proporciona un retraso de 2 segundos más o menos.
Además, estamos intentando mantener sincronizados todos los fotogramas mientras grabamos, pero parece imposible si vienen de diferentes dispositivos, debería haber un retraso variable entre vídeos....
Respuesta1
Hay MUCHAS cosas que influyen en cómo el vídeo de diferentes fuentes comienza, interactúa y permanece sincronizado (o no):
- Es muy probable que tres cámaras no tenganexactamentela misma velocidad de fotogramas. Incluso una desigualdad de 1/1000 en las bases de tiempo a 25 fps te dará una diferencia de un fotograma completo cada 40 segundos.
- Para que la transmisión "comience" (es decir, que aparezca la primera imagen de salida), el decodificador debe esperar la primera imagen completa (cuadro I), sobre la cual se pueden construir los siguientes cuadros B y P. Esto está limitado por la duración del Partido Republicano, que normalmente está en el rango de 1 a 2 segundos para las cámaras de transmisión. Dado que los I-frames normalmente no sólo se programan en cada frontera del Partido Republicano, sino también en contenidos de imagen significativamente modificados (I-frames "oportunistas" en el cambio de escena), es muy poco probable que se produzcan al mismo tiempo. Esto implica que, para un caso de múltiples entradas, el retraso mínimo es el delta de tiempo máximo entre fotogramas I en los diferentes flujos.Recuerde: Por diseño, una transmisión h.264 no puede interpretarse desde un momento dado en adelante, sino solo desde el primer fotograma clave (fotograma I) siguiente a ese momento.
- ¿Estás seguro de que estás haciendo la pregunta correcta? ¿Quizás sería mejor comenzar la etapa de entrada mucho antes, decodificar a un formato de solo fotogramas clave (lo que le brinda un inicio inmediato) y luego volver a codificar? Así es como se logra la latencia mínima en la industria de la transmisión.
Los dos primeros puntos responden por qué diferentes procesos parecen iniciarse más rápido que un solo proceso: cada uno tiene que esperar por un único fotograma clave, no por los tres.