Save cameras simultaneously

Hello,

I’m working with 4 IP cameras connected to a PC in a vehicle to record the route, the provider of the cameras send me the following pipeline to record the stream of the camera:

gst-launch-1.0 udpsrc port=53260 !image/jpeg, framerate=30/1! jpegparse ! jpegdec ! jpegenc! avimux ! filesink location=C:/Temp/output.avi

To record 4 cameras i use an “&” between commands but what it do is record the 2nd camera after I stop the first one and currently for the other cameras. There is a function that make the 4 pipelines works simultaneously?

Thanks for any support

You should be able to do something like this:

gst-launch-1.0 \
\
udpsrc port=53260 ! image/jpeg, framerate=30/1 ! jpegparse ! jpegdec ! jpegenc ! avimux ! filesink location=C:/Temp/output1.avi async=false \
\
udpsrc port=53261 ! image/jpeg, framerate=30/1 ! jpegparse ! jpegdec ! jpegenc ! avimux ! filesink location=C:/Temp/output2.avi async=false
\
udpsrc port=53262 ! image/jpeg, framerate=30/1 ! jpegparse ! jpegdec ! jpegenc ! avimux ! filesink location=C:/Temp/output3.avi async=false
\
udpsrc port=53263 ! image/jpeg, framerate=30/1 ! jpegparse ! jpegdec ! jpegenc ! avimux ! filesink location=C:/Temp/output4.avi async=false

There are a couple of things that are a bit suboptimal here:

  • why decode the jpeg and re-encode it again? That should not be required, jpegparse ! avimux should work too hopefully
  • AVI is not a good container format, no one should be creating new files with that in 2023. I would recommend Matroska (matroskamux) instead.
  • you could even save all cameras into the same file with matroskamux name=mux ! filesink ... and then jpegparse ! queue ! mux.video_%u on all branches.
  • are you sure it’s sending ‘raw’ jpeg and not an RTP-encapsulated stream? (does udpsrc ! rtpjitterbuffer latency=50 ! rtpjpegdepay ! ... work too?)[quote=“Tomas, post:1, topic:187, full:true”]

Also, gst-launch-1.0 is a debugging/testing tool and not meant for production use. You probably want to write an application in whatever language for this instead. That way you would also have more control over everything, including when which streams are started/stopped and if they’re in one or more pipelines.