Fix crash caused by removing the gap at the beginning of a media segment.

media/filters/source_buffer_stream_unittest.cc

Index: media/filters/source_buffer_stream_unittest.cc
diff --git a/media/filters/source_buffer_stream_unittest.cc b/media/filters/source_buffer_stream_unittest.cc
index b706fb18cbbe70482a1a2d2b169672a0f76d7105..b250952f6ac4b6fba54d82e6eecc9b31c943b1e0 100644
--- a/media/filters/source_buffer_stream_unittest.cc
+++ b/media/filters/source_buffer_stream_unittest.cc
@@ -3562,6 +3562,35 @@ TEST_F(SourceBufferStreamTest,
   CheckExpectedBuffers("90K 121 151");
 }
 
+TEST_F(SourceBufferStreamTest, Remove_GapAtBeginningOfMediaSegment) {
+  Seek(0);
+
+  // Append a media segment that has a gap at the beginning of it.
+  NewSegmentAppend(base::TimeDelta::FromMilliseconds(0),
+                   "30K 60 90 120K 150");
+  CheckExpectedRangesByTimestamp("{ [0,180) }");
+
+  // Remove the gap that doesn't contain any buffers.
+  RemoveInMs(0, 10, 180);
+  CheckExpectedRangesByTimestamp("{ [10,180) }");
+
+  // Verify we still get the first buffer still since only part of
+  // the gap was removed.
+  // TODO(acolwell/wolenetz): Consider not returning a buffer at this
+  // point since the current seek position has been explicitly
+  // removed but didn't happen to remove any buffers.

[wolenetz, 2014/06/12 00:00:16]

Is the only source of gaps at beginning of a range due to demuxed multitrack
appends where some other track actually has a keyframe buffer at the (same)
beginning of the range. (If so, this test only simulates this for one track, but
that's fine at this scope.) If not, I'm confused.

IIUC, I agree: it seems that an explicit seek to a still-buffered-after-remove
time should be necessary to not stall on reading from the track, which differs
from the behavior expected in this change.

[acolwell GONE FROM CHROMIUM, 2014/06/12 01:19:27]

Yes. This simulates the sitation where the first audio frame is at 0 and the
first video frame is at 30 in a muxed stream.
Yes. It seems to me if you are "seeked to time 0", but haven't handed out any
buffers yet and then time 0 gets removed, the seek should stall and no buffers
should be handed out after the remove. I'm defering this change in behavior to a
different CL because I'm pretty sure it will have effects elsewhere and I didn't
want to muddy the purpose of this CL.

[wolenetz, 2014/06/12 19:20:49]

nit: please file and reference crbug

[acolwell GONE FROM CHROMIUM, 2014/06/12 20:17:58]

Done.

+  CheckExpectedBuffers("30K");
+
+  // Remove a range that includes the first GOP.
+  RemoveInMs(0, 60, 180);
+
+  // Verify that no buffer is returned because the current buffer
+  // position has been removed.
+  CheckNoNextBuffer();
+
+  CheckExpectedRangesByTimestamp("{ [120,180) }");
+}
+
 TEST_F(SourceBufferStreamTest, Text_Append_SingleRange) {
   SetTextStream();
   NewSegmentAppend("0K 500K 1000K");