Clamp currentTime to buffered ranges for MSE GC

Clamp currentTime to buffered ranges for MSE GC

BUG=563292

[servolk, 2015-12-02 03:38:59]

Description was changed from

==========
Clamp currentTime to buffered ranges for MSE GC

BUG=563292
==========

to

==========
Clamp currentTime to buffered ranges for MSE GC

BUG=563292
==========

[servolk, 2015-12-02 03:38:59]

servolk@chromium.org changed reviewers:
+ wolenetz@chromium.org

[wolenetz, 2015-12-02 23:11:00]

There's much to motivate doing this instead in SourceBufferStream:

https://codereview.chromium.org/1491813002/diff/20001/third_party/WebKit/Sour...
File third_party/WebKit/Source/modules/mediasource/SourceBuffer.cpp (right):

https://codereview.chromium.org/1491813002/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/modules/mediasource/SourceBuffer.cpp:589: // but
media::Pipeline uses audio stream as the main time source. When audio
nit: (when there is an audio stream)

https://codereview.chromium.org/1491813002/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/modules/mediasource/SourceBuffer.cpp:597: double
nearest = bufferedRanges->nearest(currentTime, currentTime);
Two strongly related comments:
1) This fix-up is specific to the Chromium (desktop) pipeline. Other content
embedders (Opera, etc) may have no need for this overhead here. ISTM this
clamping would be more appropriately done within Chromium SourceBufferStream.
2) TimeRanges::nearest(...,...) could return the *next* buffered range's start
time, rather than the previous buffered range's end time (which would introduce
issues due to potentially removing the currently playing video GOP, which could
be just a partial GOP so far). Specifically, the Chromium clamping scenario (to
workaround a currentTime that has slightly gone past the end of the
currently-playing video buffered range) needs to only be done to the end of the
currently playing buffered range, and be done iff a) no seek is in progress in
the demuxer, and b) no change to the end of the currently playing video buffered
range has occurred (such as an intervening explicit remove() operation).

IMHO, #2 further motivates #1. #1's also more easily testable at the
SourceBufferStream layer in a unit test, which is nice :)

[wolenetz, 2015-12-03 17:26:28]

I believe this CL is now obsolete due to the logic being merged into
https://codereview.chromium.org/1491513002/.

[servolk, 2015-12-03 18:59:56]

On 2015/12/03 17:26:28, wolenetz wrote:
> I believe this CL is now obsolete due to the logic being merged into
> https://codereview.chromium.org/1491513002/.

Correct. Closing.