RTCP improvements

[gavv]

Follow-up for #14 and #675.

• Refine packet counter calculation. On receiver, derive it from packet_count in SR, and handle 32-bit wraps. On sender, derive it from ext_first_sn and ext_last_sn, and also handle 32-bit wraps. (add rtcp::PacketCounter)
• Add fract_loss calculation - loss ratio since last report. (add rtcp::LossEstimator)
• Use receive timestamp (RTS) as report time when processing RTCP report.
• Support multiple sources on sender (for cases like RaptorQ).
• Implement rtcp::IntervalComputer (computes packet generation interval according to algorithm from RFC 3550) and use in rtcp::Communicator instead of hard-coded 200ms report interval.
• Add sliding window to rtcp::RttEstimator. Compute moving minimum RTT, and average clock_shift based on it. Adjust communicator RTT tests to ensure that sliding window improves RTT & clock offset estimation precision.
• Implement RTCP BYE exchange. Handle exit by signal and ask pipeline to generate BYE. Processing of BYE is already implemented.
• Fix RTCP multicast support. If receiver RTCP endpoint is bound to multicast address, it should use Report_ToAddress instead of Report_Back mode.
• Always collect metrics for all receivers in FeedbackMonitor. If single-receiver mode is enabled, additionally create latency tuner, otherwise just collect metrics. Needed for Metrics API #681.
• Implement local SSRC change in FeedbackMonitor when latency goes out of bounds (to initiate session restart on remote side).
• Schedule pipeline refresh() according to nearest deadline returned from RTCP.
• Handle system clock jumps in pipeline (since it breaks RTCP).

[gavv]

Results of first 3 tests - good wifi, bad wifi, and ethernet: https://github.com/roc-streaming/qa/tree/326e7ef46c4e9ec1c98f5af66345432732fc9983/reports/20241230_gh674_clock_offset

I think we need to try more aggressive smoothing of clock offset, which is especially notable on the second tests where RTT jitter was high.

However, even in that test, clock offset jitter was below 1ms, and 95-percentile of clock offset jitter was 60 microseconds, which I think is already cool!

---

Note: all these tests were done without SCHED_RR (no root) and when input & output are files.

I plan to do tests with SCHED_RR separately to see what effect does it have. (BTW we probably want SCHED_RR in both netio and sndio threads, not just netio).

PulseAudio & ALSA are to be handled separately as well (I guess not in this issue).

---

My next step will be to pass clock offset to e2e latency, enable latency tuning based on e2e, and build test bench to measure actual latency using signal-estimator. These experiments are going to be quite time consuming, so before I start:

1. Do we want to try any other modifications of the algorithm?
2. Do we want to include additional statistics in measurements and reports?

@baranovmv Let me know if you have suggestions.

[baranovmv]

Thank you for so thorough evaluation

It might be more representative to compute RTT and Clock offset statistics on data which wasn't smoothed by median

    RttOffsetPair p;
    p.rtt = rtt;
    p.offset = clock_offset;
    rtt_stats_.add(p);
    RttOffsetPair min = rtt_stats_.mov_min();
    
    //    metrics_.clock_offset = clock_offset;
    //    metrics_.rtt = rtt;
    metrics_.clock_offset = min.offset;
    metrics_.rtt = min.rtt;

To be continued...

[gavv]

It might be more representative to compute RTT and Clock offset statistics on data which wasn't smoothed by median

Indeed, though probably only rtt? Because our goal is to minimize jitter of clock offset after smoothing, not before.