[MSE] Fix GC with media_time past the last appended buffer timestamp

media/filters/source_buffer_stream.h

Index: media/filters/source_buffer_stream.h
diff --git a/media/filters/source_buffer_stream.h b/media/filters/source_buffer_stream.h
index deec40970ba53217343f32302db684e628dff651..3c727d7239154707cd692592674d982555071aa2 100644
--- a/media/filters/source_buffer_stream.h
+++ b/media/filters/source_buffer_stream.h
@@ -406,7 +406,8 @@ class MEDIA_EXPORT SourceBufferStream {
 
   // The timestamp of the last buffer appended to the media segment, set to
   // kNoDecodeTimestamp() if the beginning of the segment.
-  DecodeTimestamp last_appended_buffer_timestamp_;
+  DecodeTimestamp last_appended_buffer_timestamp_ = kNoDecodeTimestamp();

[wolenetz, 2015/12/02 23:32:50]

Note that this is a DTS, not a PTS (pre-existing problem: see crbugs with
label:MSEptsdtsCleanup for this known issue). media_time is correctly PTS.
Buffered ranges and last_appendeded incorrectly are based on DTS.

Perhaps adjust the CL description to not mention PTS, so that it doesn't confuse
readers.

Note that DTS usually is < PTS, so the clamping CL follow-up is motivated not
just for Chromium pipeline allowing audio clock to go slightly past end of
buffered video, it's also motivated for clamping a slightly higher PTS into the
(incorrectly DTS-based-currently) buffered ranges for sane GC in out-of-order
decode streams like AVC.

+  base::TimeDelta last_appended_buffer_duration_ = kNoTimestamp();
   bool last_appended_buffer_is_keyframe_ = false;
 
   // The decode timestamp on the last buffer returned by the most recent