From [1], and based on discussion with chcunningham@, the "max-interbuffer-distance" may grow too large in sequence mode coded frame groups that get large jumps forward due to timestampOffset. While subsequent range merges will have a much more lenient (large) adjacency threshold (which is probably fine for meeting the 'sequence' mode goal of reducing range gaps), if the app switches back to segments mode, that same (large) adjacency threshold would still apply.
This bug tracks consider options to address this, especially if such lenient range merges indeed become a problem for apps using Chrome and mixed sequence+segments mode for the same SourceBuffer, with jumps forward using timestampOffset while in sequence mode.
[1] https://codereview.chromium.org/2035003002/diff/40001/media/filters/frame_processor_unittest.cc
One option I mentioned was to use the current logic while in 'sequence' mode (or even MORE lenient, merge with *all* adjacent ranges, while in 'sequence' mode), and while in 'segments' mode use either the current logic (ignoring any large jumps forward while in sequence mode for calculation of max_interbuffer_distance) or just use something like last_decode_timestamp+2*last_frame_duration. Note that frame durations can vary significantly, so that change to segments mode adjacency risks introducing gaps which may seem spurious or unexpected by apps.
Note that the MSE spec gives us significant lenience w.r.t. buffered range coalescence. Note also that any change to the adjacency logic will need careful inspection to make sure any buffered ranges coherency checks are still correct.
Web authors are encouraged to report any problems they're having with Chrome's 'sequence' mode, and if they're related to existence or lack of buffered range gaps, please report them here.
Comment 1 by bugdroid1@chromium.org
, Jun 16 2016