Fix incorrect opus seek preroll and flaky pre-skip removal.

media/filters/ffmpeg_demuxer.h

Index: media/filters/ffmpeg_demuxer.h
diff --git a/media/filters/ffmpeg_demuxer.h b/media/filters/ffmpeg_demuxer.h
index 98ee3b2844aa4ae9c12b0719a18ee24a99be8658..bc7c3bd525320e2bd33c04923b9e0aa83264934a 100644
--- a/media/filters/ffmpeg_demuxer.h
+++ b/media/filters/ffmpeg_demuxer.h
@@ -77,12 +77,17 @@ class FFmpegDemuxerStream : public DemuxerStream {
 
   base::TimeDelta duration() const { return duration_; }
 
-  // Enables fixes for ogg files with negative timestamps.  For AUDIO streams,
-  // all packets with negative timestamps will be marked for post-decode
-  // discard.  For all other stream types, if FFmpegDemuxer::start_time() is
-  // negative, it will not be used to shift timestamps during EnqueuePacket().
-  void enable_negative_timestamp_fixups_for_ogg() {
-    fixup_negative_ogg_timestamps_ = true;
+  // Enables fixes for files with negative timestamps.  Normally all timestamps
+  // are rebased against FFmpegDemuxer::start_time() whenever that value is
+  // negative.  When this fix is enabled, only AUDIO stream packets will be
+  // rebased to time zero, all other stream types will use the muxed timestamp.

[chcunningham, 2015/08/04 20:38:09]

Let me check my understanding

if we had a webm file with vp9 and aac, any negative timestamps in vp9 and/or
aac would be rebased and not discard.

but if that same file is vp9 and ogg, only the ogg is rebased and negative
portions are discarded, while the vp9 is not rebased nor discarded ... and I
guess negative timestamps make it all the way to the renderer in such cases? 

I follow our special handling of ogg, but if the above is correct, I'm not sure
I completely understand why video rebasing is not done in the ogg case.... is it
just because there's too much noise to do it with any confidence? If I have this
right, we should def rename this method/var to indicate its special to audio,
and maybe add some comment (even more lol) as to why we don't do video in these
cases.

[DaleCurtis, 2015/08/04 21:38:34]

I assume you mean vp9 and vorbis since you can't put vp9 in ogg. It's important
to understand that negative timestamps are a part of ffmpeg, not part of the
encoded packet.  FFmpeg shifts these timestamps to be negative without touching
other streams like video.

We don't know of any cases where negative timestamps are returned for video,
only audio.  In the non-opus, non-ogg case we will simply rebase the negative
timestamps to be positive.

So your first statement is correct, vp9+aac (in separate containers) would be
rebased w/o discard. vp9+vorbis in webm doesn't have any negative timestamps
that we know of either, and hence this fix is not enabled. (theora|vp8)+vorbis
in ogg or (vp8|vp9)+opus in webm do have negative timestamps, but the negative
timestamps are manufactured by ffmpeg (and not baked into the video timestamps),
as such we only want to rebase and drop the audio timestamps while leaving video
alone.

Leaving video alone is not the default behavior, the default behavior is
everything gets rebased to >= 0, so this method is not specific to audio or
video and is not named as such.

+  //
+  // Further, when no codec delay is present, all AUDIO packets which originally
+  // had negative timestamps will be marked for post-decode discard.  When codec
+  // delay is present, it is assumed the decoder will handle discard and does
+  // not need the AUDIO packets to be marked for discard; just rebased to zero.
+  void enable_negative_timestamp_fixups() {
+    fixup_negative_timestamps_ = true;
   }
 
   // DemuxerStream implementation.
@@ -155,7 +160,7 @@ class FFmpegDemuxerStream : public DemuxerStream {
 #endif
 
   std::string encryption_key_id_;
-  bool fixup_negative_ogg_timestamps_;
+  bool fixup_negative_timestamps_;
 
   DISALLOW_COPY_AND_ASSIGN(FFmpegDemuxerStream);
 };