obs-ffmpeg: Add a stats dock for SRT with graphs

[pkviet]

Description

This adds:

• a proc handler for srt stats.
• an srt stats dock, including a live updated graph of the most important statistics.
  This depends on a companion obs-deps PR adding qtcharts to qt deps : deps.qt: Add qtcharts obs-deps#192 .
  The current PR will stay in draft state until the obs-deps PR is merged (if it is).

Motivation and Context

I had many exchanges with broadcast engineers during the 2023 SRT Plugfest.
One thing missing from obs srt output are stats to monitor the network condition.
In particular, given the peculiarities of SRT (which relies on udp rather than tcp like rtmp), it is important to
be able to monitor:

• resent packets,
• dropped packets,
• RTT,
• latency.

I received also the suggestion to use live updated graph which allows to follow the
trends over time and are more informative than instantaneous stats.

The charts code could be easily ported to the current stats dock.
@derrod suggested that a chart of dropped frames could be useful for rtmp too.

How Has This Been Tested?

Tested on windows against YouTube SRT ingests and a variety of other SRT capable servers.

Types of changes

• New feature (non-breaking change which adds functionality)

Checklist:

• My code has been run through clang-format.
• I have read the contributing document.
• My code is not on the master branch.
• The code has been tested.
• All commit messages are properly formatted and commits squashed where appropriate.
• I have included updates to all appropriate documentation.

[Warchamp7]

Is this something that should live in OBS at all? Can this information not be tracked/monitored with external applications or utilities?

[pkviet]

Is this something that should live in OBS at all? Can this information not be tracked/monitored with external applications or utilities?

1. I wouldn't formulate the question like that. There are a lot of features of obs that are optional but probe very convenient.
   Should it be included in obs ? Phrased like that, no.
   Is it convenient to SRT users ? Definitely.
   SRT users will live better with it than without. This improves their network monitoring.
2. As to the second question, for instance YouTube doesn't provide any of these stats. Your mileage may vary depending on the ingest service.
   These stats are provided by libsrt on the sender side. Libsrt doesn't send stats from the receiver.
   Even if the receiver has a dashboard or tool giving useful stats, it's still interesting to cross-check the info with that on the sender side.

[gxalpha]

How difficult do you think it would be to provide API's for plugins to implement such windows? Looking at the code it seems that’s basically what it does already, albeit internally via proc handlers.
(And also, having the main obs-ffmpeg plugin link against Qt is going to be very controversial, I’d argue that if this should become part of OBS itself it should be a UI feature instead, at which point you’d need the same API's a plugin would use).

[pkviet]

How difficult do you think it would be to provide API's for plugins to implement such windows? Looking at the code it seems that’s basically what it does already, albeit internally via proc handlers. (And also, having the main obs-ffmpeg plugin link against Qt is going to be very controversial, I’d argue that if this should become part of OBS itself it should be a UI feature instead, at which point you’d need the same API's a plugin would use).

it's probably not too difficult to make an API for that.
Is it worth it though since I only foresee such a usage for the stats dock ? But I lack imagination tbh.

I could certainly split the code into its own plugin indeed; i hadn't thought about it.
I did consider splitting srt / rist / mpegts in its own plugin since obs-ffmpeg has turned into a behemoth, including audio and video encoders, media source, recording output, ffmpeg output ...

[derrod]

I wonder if it would be reasonable to have some sort of generic metrics API in libobs that plugins could report various stats to, e.g. things like drops/RTT, RAM usage, frame rate (for async sources). Then the UI could register a callback or poll to receive metrics updates and can be then present such data in arbitrary forms, such as a graph.

[RytoEX]

The questions from @Warchamp7, @gxalpha, and @derrod are exactly in line with concerns I had previously raised.

Personally, I am not fond of the idea of adding more Qt components for the core distribution. I do see how this could help with debugging SRT streams, but I do not presently see the benefits for the larger subsets of our users. I think that it would be better to have the stream session data/metrics able to be extracted via appropriate APIs for any given stream session and read/parsed/interpreted/graphed/charted by external tools rather than us implementing charts in the OBS interface itself.

[derrod]

I do not presently see the benefits for the larger subsets of our users.

For SRT maybe not, but for general performance? Absolutely.

I think that it would be better to have the stream session data/metrics able to be extracted via appropriate APIs for any given stream session and read/parsed/interpreted/graphed/charted by external tools rather than us implementing charts in the OBS interface itself.

I'm definitely in favour of adding Qt Charts based stats displays to the stats dock, as it's currently not really possible to determine OBS performance/network stability over time. Relegating that to third-party tools would be pretty silly.

[norihiro]

I think this is an unnecessary and unrelated modification.

[mufunyo]

It seems a bit silly to abbreviate "RTT", when "Retransmitted (pkts/sec)" is more characters than "Round Trip Time" would be.

[basisbit]

It seems this PR is not progressing because of the added qt component. Is there any chance to get this PR through without the chart? I am referring to this part from @pkviet 's screenshot:

This already would be a huge improvement, and imho this is very much needed improvement to resolve the "but stats show no dropped frames and no encoding lag" when using SRT in OBS when in fact there is for example 30% packet loss and tons of retransmits. Currently the streamer doesn't see that they chose a way too high bitrate for the used internet connection, except when watching the stream and seeing random fragments instead of the intended video stream.