Add MPEG-TS passthrough support to recorder

[zach-grant-skydio]

The idea here is that MediaMTX does not support recording incoming MPEG-TS streams, but since MPEG-TS doesn't need any transcoding/demuxing/etc to be written to disk we can just keep an eye out for when an incoming RTSP stream is already MPEG-TS and write it directly to disk. This is simple and preserves the internal structure, such as elementary stream ID's, PMT organization, and timestamps.

This requires the incoming stream to be MPEG-TS and the recording format to be set to mpegts, it does not add support for writing an MPEG-TS stream to fmp4 as that would require demuxing, parsing, and re-containerization of any streams that can be put into an MP4 format.

Actions taken:

• Detect MPEG-TS format in RTSP streams
• Implement passthrough mode to write MPEG-TS packets directly to disk
• Initialize necessary writers and buffers for passthrough
• Handle segment creation and rotation

[zach-grant-skydio]

@aler9 I think this is in a stable state now, tests are passing locally and I've had internal reviews.

Let me know if you agree with this approach to add the functionality, we know of at least 2 of our customers that were attempting to use MediaMTX in this manner and were being blocked.

[ingalls]

@aler9 Thanks a ton as always for getting 1.13.0 out, your work is incredible! Just adding us as a voice who has tested the PR and would benefit greatly from it getting merged in.

[aler9]

Hello, the problem of this feature is that it creates a shortcut that allows to bypass the server architecture, in which every stream is first converted into a universal format, and then made available to any kind of reader. This PR goes to the benefit of the minority of users that want to read a MPEG-TS stream and store it on disk in MPEG-TS format, leaving out everyone else.
I'd rather improve the existing architecture in order to preserve as many MPEG-TS attributes as possible.

[zach-grant-skydio]

@aler9 I do see where you are coming from, so I spent some time looking at what it would take to get incoming MPEG-TS streams to be a first-class citizen of MediaMTX and unless I am not understanding things well it looks like the current architecture won't play nicely with that.

The core issue is that when an MPEG-TS stream arrives as RTP payload type 33, it then needs to be demuxed and the tracks within it then distributed into MediaMTX. This doesn't work well at the FormatProcessor level because it is already too deep within the server and would have to then be re-routed back in as essentially new streams. I couldn't find a clean why to approach that without it getting pretty messy.

So looking at the proposed recording here, I am not sure I see where this wouldn't be a strictly positive improvement to the functionality of MediaMTX, since it doesn't take away from any existing functionality and just adds a bit more for pure MPEG-TS streams. Another consideration I have is that we are dealing with STANAG 4609 conformant streams in my case and other utilities typically do not do well when attempting to containerize into MPEG-TS, this includes tools like GStreamer's mpegtsmux element*. I would be worried that we a demux->redistribute tracks->remux approach was taken without spinning up custom components to do the work there is a good change the resulting files and streams would no longer be STANAG conformant out of the other side. This was one reason I was inclined to go with a direct write to disk approach.

This isn't a show stopper if this approach is really not wanted though, just let me know and I will close this PR. One alternative we have used is just using a GStreamer pipeline in the exec section of the config. But this is slightly less feature-rich than having MediaMTX do it directly, as you lose things like segmenting the video automatically.