Prevent incorrect start time from being used during new range creation.

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 1cd9cfa3f67c2050b9c092e4f78d0ef5399f5e87..b706fb18cbbe70482a1a2d2b169672a0f76d7105 100644
--- a/media/filters/source_buffer_stream_unittest.cc
+++ b/media/filters/source_buffer_stream_unittest.cc
@@ -3511,6 +3511,33 @@ TEST_F(SourceBufferStreamTest, Remove_GOPBeingAppended) {
   CheckExpectedBuffers("240K 270 300");
 }
 
+TEST_F(SourceBufferStreamTest, Remove_WholeGOPBeingAppended) {

[wolenetz, 2014/06/11 01:53:54]

I tried this test without the SBS.cc change applied and no repro resulted
(though the test failed). Does another remove need to be included to trigger the
issue?

[acolwell GONE FROM CHROMIUM, 2014/06/11 16:47:51]

I'm just fixing the range creating problem here. This avoids the crash in the
bug, but like my other comment stated I believe there is still another
underlying issue.

+  Seek(0);
+  NewSegmentAppend("0K 30 60 90");
+  CheckExpectedRangesByTimestamp("{ [0,120) }");
+
+  // Remove the keyframe of the current GOP being appended.
+  RemoveInMs(0, 30, 120);
+  CheckExpectedRangesByTimestamp("{ }");
+
+  // Continue appending the current GOP.
+  AppendBuffers("210 240");
+
+  CheckExpectedRangesByTimestamp("{ }");
+
+  // Append the beginning of the next GOP.
+  AppendBuffers("270K 300");
+
+  // Verify that the new range is started at the
+  // beginning of the next GOP.
+  CheckExpectedRangesByTimestamp("{ [270,330) }");
+
+  // Verify the buffers in the ranges.
+  CheckNoNextBuffer();
+  SeekToTimestamp(base::TimeDelta::FromMilliseconds(270));
+  CheckExpectedBuffers("270K 300");
+}
+
 TEST_F(SourceBufferStreamTest,
        Remove_PreviousAppendDestroyedAndOverwriteExistingRange) {
   SeekToTimestamp(base::TimeDelta::FromMilliseconds(90));