Ingesting multiple UDP/MPEG-TS streams

[baronlib]

Question

I'm currently using MediaMTX to stream multiple camera feeds via WebRTC. The camera feeds come in via MPEG-TS packets over a TCP connection, and I convert them to RTSP via FFMpeg, so they can be fed into MediaMTX with each camera ID mapped to a unique path.

I notice that MediaMTX supports ingesting MPEG-TS packets directly, however I couldn't find a way to map each MPEG-TS stream to a unique path based on the output URL in FFMpeg. It seems that the output paths have to be hardcoded up-front in the YML file.

Is there a way to support dynamic paths when ingesting MPEG-TS into MediaMTX, like with RTSP stream paths?

so that each input camera stream would output to a unique path from FFMpeg, with {cameraId} in the path.

e.g.
ffmpeg -re -f lavfi -i testsrc=size=1280x720:rate=30 \ -pix_fmt yuv420p -c:v libx264 -preset ultrafast -b:v 600k \ -f mpegts udp://238.0.0.1:1234/{cameraId}?pkt_size=1316

I feel that ingesting MPEG-TS directly, rather than through RTSP, would be more efficient for my case.

Thanks for a great product!

[aler9]

Hello,

Is there a way to support dynamic paths when ingesting MPEG-TS into MediaMTX, like with RTSP stream paths?

Unfortunately no, that's because raw MPEG-TS streams are stateless streams that don't contain a path name, they just contain the list of tracks, their codecs (PMT table) and the stream (PES data packets). Everything is sent repeatedly regardless of the number of readers.

On the contrary, RTSP sessions are stateful, they are addressed to a specific server, they transmit the path name, credentials and other parameters and then they wait for the green light from the server before starting streaming.

Another thing: keep in mind that MPEG-TS streams are slightly slower than RTSP / WebRTC streams - this is because MPEG-TS PES data packets, which are used to send frames, have a maximum size of 65536 bytes, and when a frame is larger than that, their size is set to zero. In order to receive a packet, you have to know its size, and if the size is not specified, the only way to correctly receive a packet is to wait for the first packet of the next frame, which usually contains a "start" flag. This causes a delay equal to at least 1 frame. This limitation is not present into RTSP.