commit 4774a9fcb8fab7acd37518f222a479e576d2fdf5
author Yun Zhang <yunz@fb.com> Tue Nov 23 09:11:20 2021
committer WebRTC LUCI CQ <webrtc-scoped@luci-project-accounts.iam.gserviceaccount.com> Tue Nov 30 23:57:40 2021
tree 9f320bba30beae92d89b5d343ff43e3aa99ca04c
parent f0290eb6fdb3ff6b893e67ce26e354f491ede897

Fix rate statistic when time window running out of samples

Current rate statistic tracker has assumption, the tracking window will
always be full after first filled up. This assumption looks not always
true. One example is the input_framerate_ tracker inside
video_stream_sender.cc which is used for setup frame droper and encoder.
Whenever there is a gap in video stream, like mute/unmute,
pacer pause/unpause etc. The fps detected from the rate_statistics
becomes samples_filled_partial_window / full_window_size, which could
be extremely low for a while. This creates a misalignment between the
fps we told encoder/frame dropper, and the real fps we fed into them,
which causes short-term serious overshot and very bad experience on
delay, avsync, congestion etc. This may also depends on how fast
encoder could react to the gap between set fps and real fps, but
libvpx and openh264 at least cannot handle this well.

So propose a fix to update first timestamp after tracker window
drained. This will give more accurate fps estimate similar based on
active window after sample gets drained

Bug: webrtc:13403
Change-Id: I96792c11091fe8bfa63e669f4360a3b3e95593e1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/237720
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35447}