0

I am trying to receive videos from three cameras via rtsp. We use ffmpeg with multiple outputs how ffmpeg explains, but the delay is worse than we run directly three different linux processes, is it possible to find some ffmpeg command combination to start in the exact moment the recording process for the three cameras.

Currently, we are using this command:

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

It provides a 2 seconds delay more or less.

Also, We are trying to keep synchronized all the frames while we are recording, but it seems impossible if they come from different devices, it should have a variable delay among videos....

1 Answer 1

1

There is a LOT of things, that influence how the video from different sources start, interact and stay in sync (or not):

  • Three cameras are very likely to not have exactly the same frame rate. Even a 1/1000 inequality in the time bases at 25fps will give you a difference of a complete frame every 40 seconds
  • For the stream to "start" (i.e. the first output image to appear) the decoder needs to wait for the first full image (I-frame), on which the following B-frames and P-frames can be built. This is upper-bounded by the GOP length, which is typically in the 1-2 second range for streaming cameras. Since I-frames are most often not only scheduled at each GOP border, but also on significantly changed image content ("oportunistic" I-frames on scene change), it is very unlikely, that they come at the same time. This implies, that for a multi-input case, the minimum delay is the maximum time delta between I-frames in the different streams. Remember: A h.264 stream can by design not be interpreted from any given point in time on, but only from the first keyframe (I-frame) following that point in time
  • Are you sure, you are asking the right question? Maybe it would be better to start the input stage much earlier, decode to a keyframe-only format (which gives you immediate startup), then reencode? This is, how minimum latency ist done in the broadcast industry.

The first two bullets answer, why different processes seem to start up faster than a single process: Each one has to wait for a single keyframe, not for all three.

0

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .