我正在嘗試透過 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 秒也會產生完整幀的差異
- 為了使流程「開始」（即出現第一個輸出影像），解碼器需要等待第一個完整影像（I 幀），在其上可以建立後續的 B 幀和 P 幀。這是 GOP 長度的上限，對於串流攝影機來說，該長度通常在 1-2 秒範圍內。由於 I 幀通常不僅安排在每個 GOP 邊界處，而且還安排在顯著變化的圖像內容上（場景變化時的「機會主義」I 幀），因此它們同時出現的可能性很小。這意味著，對於多輸入情況，最小延遲是不同流中的 I 幀之間的最大時間增量。請記住：h.264 流在設計上不能從任何給定時間點開始解釋，而只能從該時間點之後的第一個關鍵幀（I 幀）開始解釋
- 您確定您問的是正確的問題嗎？也許更早開始輸入階段，解碼為僅關鍵幀格式（這可以讓您立即啟動），然後重新編碼會更好？這就是廣播業如何實現最小延遲的。
前兩個要點回答了為什麼不同的進程似乎比單一進程啟動得更快：每個進程都必須等待一個關鍵幀，而不是所有三個關鍵幀。