A recent bugfix[1] introduced having to reconfigure the encoder in
response to restrictions updating for the sake of not getting stuck at
the wrong resolution in some cases.
But the newly added ReconfigureEncoder() calls happened too early/often,
and the initial frame dropper got confused thinking resolution changes
were not in response to adaptation (restrictions) when they in fact were.
The CL wrongly disabled the "reset initial frame dropper" logic, when
the correct solution to this problem should have been to delay the
ReconfigurationEncoder() call to the next frame (using
`pending_encoder_reconfiguration_ = true`).
With this delay the initial frame dropper is not confused and we can
restore the old "reset" logic, fixing the regression.
[1] https://webrtc-review.googlesource.com/c/src/+/360200
Bug: b/364252657
Change-Id: I6b93f4cc44eb12b1bbbda0d8d1e9906c29b615a2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/361740
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42961}
d4c5843bae