Add gapless playback support for AAC playback.

media/filters/frame_processor_base.h

Index: media/filters/frame_processor_base.h
diff --git a/media/filters/frame_processor_base.h b/media/filters/frame_processor_base.h
index cc143e29d5d3e14dac963c521a8dc0d0ba7f4e7c..988c1a662778a3c9e5756116a6d41f18868273c1 100644
--- a/media/filters/frame_processor_base.h
+++ b/media/filters/frame_processor_base.h
@@ -154,6 +154,11 @@ class MEDIA_EXPORT FrameProcessorBase {
   // http://www.w3.org/TR/media-source/#sourcebuffer-reset-parser-state
   void Reset();
 
+  // Resets the preroll buffer used for partial append window trimming of audio
+  // buffers.  Must be called if the audio config is changed between calls to
+  // ProcessFrames().
+  void clear_audio_preroll_buffer() { audio_preroll_buffer_ = NULL; }
+
  protected:
   typedef std::map<StreamParser::TrackId, MseTrackBuffer*> TrackBufferMap;
 
@@ -167,6 +172,29 @@ class MEDIA_EXPORT FrameProcessorBase {
   // with timestamp |segment_timestamp|.
   void NotifyNewMediaSegmentStarting(base::TimeDelta segment_timestamp);
 
+  // Handles partial append window trimming of |buffer|.  Returns true if the
+  // given |buffer| can be partially trimmed or have preroll added; otherwise,
+  // returns false.
+  //
+  // Since |buffer| may not have its timestamp and duration fields set, callers
+  // must provide |frame_start_timestamp| and |frame_end_timestamp| to indicate
+  // the extents of |buffer|.

[acolwell GONE FROM CHROMIUM, 2014/05/23 17:27:30]

This seems a little odd. Is there any reason we can't update |buffer|'s
timestamps before this function is called so we don't have to have these
parameters? This feels like it is leaking details of the caller's implementation
here.

[DaleCurtis, 2014/05/23 21:46:26]

wolenetz: Please comment.  I think this is reasonable, but it's a larger change
in terms of how the frame processor works.

[wolenetz, 2014/05/23 22:03:48]

Looking at this now vs our chat yesterday, it looks like the current (new)
FrameProcessor code is compatible with setting frame->DTS, frame->PTS and
frame->duration prior to the append window trimming (but this must not be done
until after the "continue;" line that reprocesses the frame with original
PTS/DTS/duration on discontinuity detection). The comments in current code's
step 5 will need slight tweaking, and the code subsequent to calling
HandlePartialAppendWindowTrimming() will need to be adjusted to use frame->
rather than the locals for PTS/DTS/duration. Probably would be good to update
step 9 comments to indicate that frame_end_timestamp remains constant to end to
the function (or, hmm, just make it const :))

[DaleCurtis, 2014/05/23 22:11:38]

Seems like this might be cleaner to do in a follow up patch set then.

[DaleCurtis, 2014/05/27 23:59:32]

Actually, I found a bug around this, so I've decided to do it in this patch set.
 Done.

+  //
+  // If |buffer| overlaps |append_window_start|, the portion of |buffer| before
+  // |append_window_start| will be marked for post-decode discard.  Further, if
+  // |audio_preroll_buffer_| exists and abuts |buffer|, it will be set as
+  // preroll on |buffer| and |audio_preroll_buffer_| will be cleared.

[wolenetz, 2014/05/23 19:59:45]

We should also clear |audio_preroll_buffer_| if it exists but does not abut the
next |buffer|, right?

[DaleCurtis, 2014/05/23 21:46:26]

Yes, this is done.

+  //
+  // If |buffer| lies entirely before |append_window_start|, and thus would
+  // normally be discarded, |audio_preroll_buffer_| will be set to |buffer|; its
+  // timestamp and duration fields will also be set accordingly.

[wolenetz, 2014/05/23 19:59:45]

Please clarify that false is returned in this case. This also seems a little
odd/leaking caller's implementation in that the assumption here is that |buffer|
is then expected to be dropped by caller and a subsequent |buffer| is expected
to be given |audio_preroll_buffer_| if it is immediately next.
 

[DaleCurtis, 2014/05/23 21:46:26]

Comment added.  It doesn't matter if it's dropped or not, so it's not a leak.
It's unfortunate there's no pass semantics for ref counted buffers here.

+  bool HandlePartialAppendWindowTrimming(
+      base::TimeDelta append_window_start,
+      base::TimeDelta append_window_end,
+      base::TimeDelta frame_start_timestamp,
+      base::TimeDelta frame_end_timestamp,
+      const scoped_refptr<StreamParserBuffer>& buffer);
+
   // The AppendMode of the associated SourceBuffer.
   // See SetSequenceMode() for interpretation of |sequence_mode_|.
   // Per http://www.w3.org/TR/media-source/#widl-SourceBuffer-mode:
@@ -183,6 +211,13 @@ class MEDIA_EXPORT FrameProcessorBase {
   // short-term plumbing of SetGroupStartTimestampIfInSequenceMode() until
   // LegacyFrameProcessor is removed.
   base::TimeDelta group_start_timestamp_;
+
+ private:
+  // The last audio buffer seen by the frame processor that was removed because
+  // it was entirely before the start of the append window.
+  scoped_refptr<StreamParserBuffer> audio_preroll_buffer_;

[wolenetz, 2014/05/23 19:59:45]

nit: Please also clarify the unstated assumption that at most one
|audio_preroll_buffer_| exists across all tracks managed by the frame processor.
If we ever allow multiplexed audio tracks in a stream that supports partial
append window trimming, the assumption would break.

[DaleCurtis, 2014/05/23 21:46:26]

That seems unnecessarily verbose given that there's only a single
scoped_refptr<StreamParserBuffer> :)

+
+  DISALLOW_COPY_AND_ASSIGN(FrameProcessorBase);
 };
 
 }  // namespace media