+strobe who echoed my concerns with this approach on the thread. This is really something we should leave to the player unless memory pressure signals otherwise. I feel collecting memory unnecessarily is just inefficient use of resources.

Well, of course I realize that people do seek backwards occasionally, that's why I proposed evicting all data older than <playback position> - X seconds, instead of blindly discarding all data up to the GOP containing the current playback position. I suspect (although don't have any hard data on this), that most seeks backwards are within ~30 sec of the current playback position. Yet currently we can be holding much more data in the sourcebuffer. So I was just wondering if we could run some experiments, gather some data on how far back seeking usually happens, and if let's say 90% of seeking happens within 30 sec of the current playback position, wouldn't it be worth it to evict the stale data outside that range and save some memory? I realize this might now seem like much, but on Android phones with 2-4GB of memory it could give us significant savings.

I suspect seek behavior is content dependent, so I'm wary of doing something like that for all of Chrome. I'd be fine with adding metrics to try to quantify seek behavior though.

The fact that only ~6% of all playbacks are near the peak indicates most sites are already doing a good job of managing their own source buffer limits. Which indicates that we'd likely see limited value in proactively collecting data based on some criteria other than memory pressure.