It is now possible to define forward destinations for each path configuration. For each destination, the server will create a client that will forward the stream to the intended destination. Supported protocols are RTSP, RTMP, SRT. API and metrics have also been improved to allow monitoring the new forwarding system.
---------
Co-authored-by: aler9 <46489434+aler9@users.noreply.github.com>
Path names are used as part of paths in several components: in the
recorder, in the playback server and in every HTTP-based component
(WebRTC, HLS, API). Special characters that allow to escape from the
intended directory are now forbidden in order to prevent directory
traversal attacks.
this allows to use MPEG-TS tracks with other protocols and with the recording system.
---------
Co-authored-by: aler9 <46489434+aler9@users.noreply.github.com>
Unix socket are stream-based connections, while RTP requires
packet-based connections. While packet-based Unix sockets exist
(unixgram), no client supports them. Consequently we are forced to
deprecate unix+rtp.
When the publisher or source of a stream is offline, the server can be
configured to fill gaps in the stream with a video that is played on
repeat until a publisher comes back online. This allows readers to stay
connected regardless of the state of the stream. The offline video and
any future online stream are concatenated without decoding or
re-encoding packets, using the original codec.
In Golang, slices can be set to nil, while in most other languages they
cannot. This causes compatibility issues, especially because the
OpenAPI definition of the API does not allow slices to be nil. This
prevents slices from being set to nil through JSON/YAML, and
also sets default slices to an empty list instead of nil.
when a new configuration is pushed with either API or hot reloading,
the server now checks whether existing paths belong to a new
configuration. If they do, these paths are deleted.
The API crashed when
- '%path%' is not present in 'recordPath'
- 'all_others' is in 'paths'
- there's at least one recording segment
A recording segment without path is parsed as a segment with an empty
path. This path is then passed to FindPathConf(), that returns an error
in case of empty or invalid paths. This error is not checked for
performance reasons, leading to the crash.
This PR prevents empty or invalid paths from reaching FindPathConf().
Response times of the /list endpoint were slow because the duration of
each segment was computed from scratch by summing the duration of each
of its parts.
This is improved by storing the duration of the overall segment in the
header and using that, if available.