[core] Shared moving average calc for RCV and SND buffers

[maxsharabayko]

Both Receiver and Sender buffers share the same logic of the moving average calculation of the buffer state (packets, bytes, timespan).
This PR moves this logic into a separate class, which is used as aggregation by both buffers.

Didn't use inheritance to avoid virtual tables.

Fixes #1272

[maxsharabayko]

Integer-based calculation of the moving average does not work well.
The image below shows different averaging methods on the receiver buffer timespan. 1 Mbps streaming rate was used to collect samples.
Due to the loss of precision the current SRT averaging method is underestimating the actual value.

Legend

• Instant Values - Instant values of the receiver buffer timespan
• MAvg elapsed/1s (int) - the current SRT moving average calculation
• MAvg elapsed/1s (float) - same as above, but using floats instead of ints
• MAvg 1/8 (float) - moving average with 1/8 for new value and 7/8 for old value.

[ethouris]

Is assumption, that now > 1000 will always be true, safe?

[maxsharabayko]

It is unlikely to be true. Most of the time elapsed_ms is below 1s.

[ethouris]

I mean, a situation that now would ship a value less than 1000. Then when you subtract 0 from it you'll get the same value, and already less than 1000. If not, then the "too long time ago" situation would be handled together with "didn't initialize before".

[maxsharabayko]

now would ship a value less than 1000

now is the current time. How can it ship a value of less than 1000?
Or do you mean now - m_tsLastSamplingTime?

[ethouris]

No, I meant now exactly - so that the result of the value compared against 1000 would be less than 1000. I personally think that even if you have a steady clock that starts from 0 at the moment when the system starts, no system in the world is capable of running the application in less than 1s after bootup.

[ethouris]

Consider ^

[maxsharabayko]

Saving scripts and data used for analysis.
python-analyse.zip