bluenviron / mediamtx

Ready-to-use SRT / WebRTC / RTSP / RTMP / LL-HLS media server and media proxy that allows to read, publish, proxy, record and playback video and audio streams.
MIT License
12.48k stars 1.55k forks source link

Support for reading RTP/UDP source stream #1515

Open RouquinBlanc opened 1 year ago

RouquinBlanc commented 1 year ago

Describe the feature

Quite similarly to the #1490 PR, sometimes all we get from a source is an RTP stream, not an RTSP server.

Provided that we know enough about the source, would that be very different from what the RTSP source does once the stream is playing?

For H264 for example, this can be solved by either:

It would allow to plug such stream directly from an RTP source instead of having first to expose it somehow as an RTSP source, hence improving the overall latency when working with live streams.

aler9 commented 1 year ago

Hello, this may be an enhancement, just one thing, this won't improve latency since RTSP and RTP-over-UDP streams use the same exact mechanism for streaming, the only difference is that with RTP-over-UDP readers have to know the SDP in advance, while with RTSP the SDP is sent automatically.

nonibytes commented 7 months ago

This is a great feature to add.

robclarkoi commented 1 week ago

So, we have an RTP UDP multicast source, and it serves .sdp files from a built in web server. We're currently ingesting this into mediamtx with the following source config:

...
  CAMERA1:
    runOnInit: ffmpeg -protocol_whitelist "file,http,https,tcp,tls,rtp,udp" -i http://camera_system_host:8088/camera1.sdp -c copy -f rtsp rtsp://localhost:$RTSP_PORT/$MTX_PATH
    runOnInitRestart: yes
...

Is that the workaround you mentioned to use in the meantime @RouquinBlanc ? Is there a different way to pass the sdp file to the RTP-over-UDP reader more directly?

Example sdp file contents in case that makes any difference:

v=0
c=IN IP4 239.255.80.12
m=video 50120 RTP/AVP 96 
a=rtpmap:96 H264/90000
RouquinBlanc commented 6 days ago

@robclarkoi this is the same kind, yes. You have a source emitting directly RTP toward an address, and in order to plug it with mediamtx, you need an intermediate piece of software (ffmpeg, gstreamer, ...) to make the bridge.

While @aler9 is correct on the fact that it does not impact latency for the handling inside mediamtx, it adds an extra layer of software which would not be necessary otherwise, adding delay, resources and complication with external dependencies

aler9 commented 6 days ago

@RouquinBlanc yes but I think we'll add this feature in the future due to popular demand anyway.