We have seen cases where a track RTP packets timestamps could fall behind live mixer thereshold but still be in the acceptable range. Lowering acceptable range is avoided here to be able to avoid time rebase for the cases where a track only temporarly falls behind and then catches up - we would still like to avoid rebasing in that case so that we don't introduce syncrhonization problems (few missed packets at the cost of preserved sync).
The idea of this change is that if a track is constantly behind for some time - it's better to pull it forward in time and prevent it from being completely lost (at the cost of skewed synchronizaiton)
ec386310c7