When a stream with always-available turned on switches from offline to
online, or from a publisher to another, the reader mutex was not
acquired during writing of codec parameters. This is now fixed.
sessions are now tracked through cookies or query parameters.
This provides the ability to inspect sessions through logs, metrics and
API, allows more precise tracking of outbound bytes, decreases load on
external HTTP authentication URLs since they are now called once per
session and not once per request.
The new outboundRtpPacketsReportedLost property allows to track RTP
packets that have been reported lost by readers. Furthermore, stats now
have a "inbound" or "outbound" prefix to improve readability.
when alwaysAvailableFile points to a file with a H265 or H264 track,
server is started, an online stream is published and then closed, video
was getting corrupted since the online video was overriding the
parameters of the offline video.
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.
this allows to apply features that were previously implemented for
single codecs (like RTP packet resizing), to any codec, and simplifies
future development.
When the absolute timestamp of incoming frames was not available, it
was filled with the current timestamp, which is influenced by latency
over time.
This mechanism is replaced by an algorithm that detects when latency is
the lowest, stores the current timestamp and uses it as reference
throughout the rest of the stream.
in API (/paths/list, /paths/get) and metrics (paths_bytes_sent), the
amount of sent bytes was increased even in case of writes to the
recorder and HLS muxer, which are not generating network traffic. This
fixes the issue.
Stream errors include both errors from decoding RTP packets into
frames, and errors from encoding frames into RTP packets. "processing
errors" is more fit.
Discarded frames, decode errors and lost packets were logged
individually, then there was a mechanism that prevented more than 1 log
entry per second from being printed, resulting in inaccurate reports.
Now discarded frames, decode errors and lost packets are accurately
counted, and their count is printed once every second.
