Introducing Generic Interface for staticsources staticstics and forwarding this data to path API

[bjornss-scaleaq]

The diagnostics / metrics output is in transition, with clarified descriptors (inbound/outbound) etc, still used along with older deprecated fields (Received/Sent)

Packet losses / decodingError for static sources is added to MediaMTX Log output, but is NOT similarly available in path API output or METRICS, unlike dynamic sources, which has such support in session API outputs (e.g "/webrtcsessions/list", "/rtspessions/list")

These session statistics (PacketLosses, Jitter etc.) DO NOT appear to be available for staticsources, but if staticsources stats were to be exposed, the INBOUND session statistics could constitute an alternative location for exposing the specific source stats in this proposal , as an alternative to the proposed extension to "/paths/get/" (or "/paths/list") return data.

This request proposes an extension, with new interface whereby inbound staticsource diagnostics from several Client Backends (starting with RTSP) can be forwarded to path API, with specific, potentially different, statistics forwarded by each source Type.

At the moment this is implemented only for RTSP-sources, but the framework can be easily extended to cover specific additional (Packet/Network) stats for other source protocols.
At present, the stats fetching is done, as for other PATH stats via channels, but otherwise directly from the backend, relying on the user not to over-burden the mediaserver with very-rapid API calls.
(Possibly the data could be filtered via extending the "counterdumper" framework already used for logging, enforcing a protective limit on the effective call frequency to backend library functions,, and keeping the backend client threads completely isolated.

The Prometheus metrics API / framework is still to be updated with this new code

Tests are in major way already covered by respective backend Client tests. (No additional low-level client statistics have been exposed, only what was available in backends before is utilized)

The API documentation has not yet been completed, since I do not yet know precisely how and where the principal developer would like this staticsources information to be exposed in API in full generality, for the protocol clients that already provides additional statistics to just Incoming/Outgoing bytes (and hidden for those staticsources protocols that doesn't provide easily-available extra stats).

[bjornss-scaleaq]

I have a few questions I hope can be answered concerning the presentation of RT(C)P packet statistics in the CONTROL API requests /v3/rtspsessions/list and /v3/webrtcsessions/list

1. Are the fields "inboundRTPPackets", "inboundRTPPacketsLost", "inboundRTPPacketsJitter" in use, under any circumstances in this API?
2. If 1. is affirmative. For what sourceTypes are the "inbound*"-type statistics provided (If any)?
3. If 1. is affirmative: What conditions (if any), need to be met for these stats to be active ( incremented)?

If all of these questions above have negative answers, should not these fields be excised from the SERVER SESSION APIs as being redundant?
If NOW being redundant, could not these fields be used to receive the sourceStats in my new proposal above?

[bjornss-scaleaq]

As to the questions above:
I see that the statistics are available for dynamic sources (ie those sources inaugurated by external streaming TO MediaMTX ), but not for static sources (inaugurated by MediaMTX from predefined source URLs).

This extension, @aler9. is therefore to facilitate inbound packet statistics (where available) for the case of staticsources.

[bjornss-scaleaq]

@aler9 I see you have several interesting PR's under evaluation, and I do see that you have already covered this feature for DYNAMIC sources.
I am simply trying to patch a lack of similar stats exposure for static sources.

So far, this is a very small change, only really exposing inbound Packet stats for RTSP(S) staticsources, (despite the introduction of a new interface).
It should hopefully enable a step-wise exposure of additional protocol-specific statistics also for other protocols going forward

I believe this could be a nice feature for a lot of users relying on MediaMTX static sources who would like the ability to also GAUGE the quality of the SOURCE->MEDIASERVER (Inbound) connections, and not only the Mediaserver->Client connections. (Though of course the 2 connection types have a significant correlation in most stats, with the possible exception of Packet Jitter)

I am wondering a bit on what timeframe this PR could be evaluated, and whether the basic design is viable, or would you prefer a different approach altogether?

(From our initial tests we do see a value in having a packet-jitter & loss measure also for the Source->mediaserver connection)