UI: Add graphs for Stats dock

[pkviet]

Description

This adds in the Stats dock a graph plotting bitrate over time as well as dropped frames.
This allows better monitoring of network issues.

Dynamic bitrate was triggered in the next screenshot, and after the congestion ended, one can see clearly the bitrate increasing.

In the next screenshot, one can see dropped frames (when dynamic bitrate is disabled).

The graph can be zoomed in and zoomed out with the mouse.
There's a tooltip explaining it.

The time span for the horizontal time axis can be adjusted.

NOTE: the last commit should be dropped eventually. Since the PR requires QCharts, that commit pulls binaries from a a companion obs-deps PR [1] generated from CI in my obs-deps fork.
[1] obsproject/obs-deps#192

Motivation and Context

Allow better monitoring of the stream.
On default the graph displays the last minute of data but this can be expanded to 4 hrs. This allows an analysis of network conditions on both short medium and long time scales.

How Has This Been Tested?

See screenshots.
I simulated network issues using 'clumsy', allowing to test both dynamic bitrate & frame dropping.

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.

[alinsavix]

This is pretty cool, and probably damned useful.

It would be great, I think, if we also had a graph for render & encoder overload. I've definitely run into cases where it'd be really useful to see when overload happened, rather than just noticing at the very end of a stream and going "wonder when that happened, and if it was all at once or gradually"...

[pkviet]

Update
Added a show / hide button.

I plan to move the graphs to a separate tab in the Stats dock.

@alinsavix 👋 hi it's been a while !
i can add the frames missed due to rendering lag / skipped frames due to encoding lag.
But I need to check what would be the useful format:

• percentage,
• raw number,
• raw number per second
  This impacts whether all the data can be displayed in the same graph.
  I'll probably go with the last format.

[alinsavix]

@alinsavix 👋 hi it's been a while!

I do indeed still exist! More or less. Slightly. (also, hi!)

I need to check what would be the useful format:

• percentage,
• raw number,
• raw number per second
  This impacts whether all the data can be displayed in the same graph.
  I'll probably go with the last format.

Definitely the last format, because that makes it super easy to see if something is happening and when it's happening. A percentage graph might could work; just having the raw number is probably the worst of the choices since once you get more than a few hundred of something, it might be hard to tell if the graph is rising or not at any particular moment (since the scale of the change for "add 1 to 5000 existing drops" is near nothing. Raw count per second makes it easy to see at a glance when there was a problem (because the graph makes a spike at the moment it happens, and then returns to zero if there are no more problems, or stays level if the problem continues but doesn't get better/worse), and makes it really easy to tell at a glance what the scale of the problem is.

One thing that might be worth thinking about is how to summarize the data when there are more datapoints on the X axis than there are pixels -- e.g. if you're showing rate-per-second, and showing an hour of data, you'd need 3600 horizontal pixels to show one pixel per second, which is... not reasonable. So do you summarize it by picking the worst value per second in a given time range? The average value? Total value? Most graphing libraries will do that kind of summarization for you, but you still have to tell them what kind to do. I don't have a specific suggestion here, but it might be worth at least a couple of seconds of thought. (or make it selectable, but that might be a bit... excessive, for this use)

[pkviet]

Ok i'll go with raw per sec.
As to the case of large number of datapoints higher than the pixel number, there's no way in qt to customize that. Qtcharts makes its own sauce to adjust what's displayed.

[alinsavix]

Qtcharts makes its own sauce to adjust what's displayed.

This is a slight surprising, but I guess the reality is that most people probably wouldn't understand the choices when making it configurable, even if it was. Which is frustrating, given just how badly a graph can hide important things when it's not done properly. Ah well, I'll still totally take it!

[WizardCM]

Suggested change

	Basic.Stats.Graphs.Show.Hide="Show / Hide Graphs."
	Basic.Stats.Graphs.Show.Hide="Toggle Graphs"

[derrod]

Perhaps rather than hiding/unhiding the graphs they could just be a separate dock entirely?

[pkviet]

Perhaps rather than hiding/unhiding the graphs they could just be a separate dock entirely?

I can certainly do that.
I'm waiting for more instructions from @Warchamp7 and @GeorgesStavracas and ui/ix discussions. Mockups are planned by George.
Warchamp suggested tabs. Also he wanted output specific stats (ex SRT) in these tabs. And the possibility to expand to other outputs (whip? MoQ? Rist ?)
I'm planning to implement these suggestions.