Don't rebase timestamps for positive start times.

media/filters/ffmpeg_demuxer.cc

Index: media/filters/ffmpeg_demuxer.cc
diff --git a/media/filters/ffmpeg_demuxer.cc b/media/filters/ffmpeg_demuxer.cc
index 9df765e8f161c4051c804c81fea7be5e090a357c..24e9357f9b566f58ccbf625de7bc281724a77b12 100644
--- a/media/filters/ffmpeg_demuxer.cc
+++ b/media/filters/ffmpeg_demuxer.cc
@@ -305,6 +305,12 @@ void FFmpegDemuxerStream::EnqueuePacket(ScopedAVPacket packet) {
       start_time = base::TimeDelta();
     }
 
+    // Don't rebase timestamps for positive start times, the HTML Media Spec
+    // details this in section "4.8.10.6 Offsets into the media resource." We
+    // will still need to rebase timestamps before seeking with FFmpeg though.
+    if (start_time > base::TimeDelta())
+      start_time = base::TimeDelta();
+
     buffer->set_timestamp(stream_timestamp - start_time);
 
     // If enabled, mark audio packets with negative timestamps for post-decode
@@ -588,7 +594,16 @@ void FFmpegDemuxer::Seek(base::TimeDelta time, const PipelineStatusCB& cb) {
   // we know we're going to drop it on the floor.
 
   // FFmpeg requires seeks to be adjusted according to the lowest starting time.
-  const base::TimeDelta seek_time = time + start_time_;
+  // Since EnqueuePacket() rebased negative timestamps by the start time, we
+  // must correct the shift here.
+  //
+  // Additionally, to workaround limitations in how we expose seekable ranges to
+  // blink, we also want to special case seeks to zero; they're unambiguously

[acolwell GONE FROM CHROMIUM, 2014/09/11 18:34:42]

nit: Please file a bug to track the seekable range work and reference it here.

[DaleCurtis, 2014/09/11 19:19:07]

Done.

+  // intended to seek to the start of the media.
+  const base::TimeDelta seek_time =
+      start_time_ < base::TimeDelta() || time == base::TimeDelta()

[acolwell GONE FROM CHROMIUM, 2014/09/11 18:34:42]

Why not simply set seek_time to start_time_ if time < start_time_ and
start_time_ is >= 0? That seems like it would be less fragile especially since
the HTMLMediaElement will still be advertising a [0,maxTimeSeekable) seekable
range so technically any timestamp in [0, start_timestamp_] can get here I
think.

[DaleCurtis, 2014/09/11 19:19:07]

Done.

+          ? time + start_time_
+          : time;
 
   // Choose the seeking stream based on whether it contains the seek time, if no
   // match can be found prefer the preferred stream.