RTSP를 통해 세 대의 카메라에서 비디오를 수신하려고 합니다. 우리는 ffmpeg가 설명하는 것처럼 여러 출력과 함께 ffmpeg를 사용하지만 세 가지 다른 Linux 프로세스를 직접 실행하는 것보다 지연이 더 심합니다. 세 카메라에 대한 녹화 프로세스를 정확한 순간에 시작할 ffmpeg 명령 조합을 찾을 수 있습니까?
현재 우리는 다음 명령을 사용하고 있습니다.
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
대략 2초 정도의 지연을 제공합니다.
또한 녹화하는 동안 모든 프레임의 동기화를 유지하려고 노력하고 있지만 다른 장치에서 가져온 경우 불가능해 보입니다. 동영상 간에 가변적인 지연이 있어야 합니다....
답변1
다양한 소스의 비디오가 시작, 상호 작용 및 동기화 상태를 유지하는 방식(또는 그렇지 않은 방식)에 영향을 미치는 많은 것들이 있습니다.
- 세 대의 카메라에는 없을 가능성이 높습니다.정확히동일한 프레임 속도. 25fps의 시간 기반에서 1/1000의 불평등이라도 40초마다 전체 프레임의 차이를 제공합니다.
- 스트림이 "시작"하려면(즉, 첫 번째 출력 이미지가 표시됨) 디코더는 다음 B-프레임 및 P-프레임을 구축할 수 있는 첫 번째 전체 이미지(I-프레임)를 기다려야 합니다. 이는 스트리밍 카메라의 경우 일반적으로 1~2초 범위인 GOP 길이에 의해 상한됩니다. I-프레임은 각 GOP 경계뿐만 아니라 크게 변경된 이미지 콘텐츠(장면 변경 시 "기회주의적" I-프레임)에서도 예약되는 경우가 가장 많기 때문에 동시에 올 가능성은 거의 없습니다. 이는 다중 입력 사례의 경우 최소 지연이 서로 다른 스트림의 I-프레임 간의 최대 시간 델타임을 의미합니다.기억하세요: h.264 스트림은 설계상 특정 시점부터 해석될 수 없으며 해당 시점 이후의 첫 번째 키프레임(I-프레임)에서만 해석될 수 있습니다.
- 정말로, 당신이 올바른 질문을 하고 있습니까? 입력 단계를 훨씬 일찍 시작하고 키프레임 전용 형식(즉시 시작 가능)으로 디코딩한 다음 다시 인코딩하는 것이 더 나을 수도 있습니다. 이것이 바로 방송산업에서 최소 레이턴시를 구현하는 방법입니다.
처음 두 글머리 기호는 서로 다른 프로세스가 단일 프로세스보다 빠르게 시작되는 것처럼 보이는 이유에 대한 답입니다. 각 프로세스는 세 개 모두가 아니라 단일 키프레임을 기다려야 합니다.