marcoscaceres
commented
7 months ago More context based on what @wolenetz wrote in #329:
The assumption that all media is fetched in order of the presentation is incorrect. One important exception I've seen is variation in seeking scenarios: not all apps initiate seek first and then append at the seek target time; some append at the seek target first, and then seek there. Therefore, conserving both the most recently appended bytes as well as the bytes around the playhead are both important to reduce stalls and rebuffering. To promote improved interoperability, I previously documented the rather complicated strategy used by Chromium as the "normal" evictionPolicy in this proposal: https://github.com/wicg/media-source/blob/mse-eviction-policies/mse-eviction-policies-explainer.md#normal. "normal" is probably the wrong word, my apologies. I used it in the context of some new evictionPolicies to support things like infinite-GOP length buffering seek-free playback with reduced I-frame bitrate bursts, for example.
In short, the normative text in this PR currently says the strategy is (actually, implied must) be to preserve uninterrupted forward playback from currentTime, but then in a non-normative note it says the strategy may be implementation-defined instead. This can be confusing. Especially when non-trivial usage of MSE is by players that append to a seek target time before issuing the seek to that time.
It would be great if the spec could describe how the eviction policy works. This would help developers with understanding that they can't rely on one browser's eviction policy matching any other browser... or that it may change depending on what hardware you are on.
We should provide "best practice" guidance based on existing implementation experience (and what not to do to shoot yourself in the foot!).