Add set_timestamp to cma's DecoderBufferBase

Add set_timestamp to cma's DecoderBufferBase

I'm currently refactoring some code that uses DecoderBuffer to use
DecoderBufferBase instead (so it can run in a cma backend).  It also
depends on DecoderBuffer::set_timestamp, so we need an equivalent
in DecoderBufferBase.

BUG=

Committed: https://crrev.com/7f98d797e90515c702379d89f879a202afd7287d
Cr-Commit-Position: refs/heads/master@{#333138}

[halliwell, 2015-06-05 18:43:44]

halliwell@chromium.org changed reviewers:
+ erickung@chromium.org, gunsch@chromium.org

[gunsch, 2015-06-05 20:02:48]

https://codereview.chromium.org/1145163005/diff/1/chromecast/media/cma/base/d...
File chromecast/media/cma/base/decoder_buffer_base.h (right):

https://codereview.chromium.org/1145163005/diff/1/chromecast/media/cma/base/d...
chromecast/media/cma/base/decoder_buffer_base.h:37: virtual void
set_timestamp(const base::TimeDelta& timestamp) = 0;
Today, DecoderBufferBase is immutable, which is a pretty nice property. We can
pass every single DecoderBufferBase around as const.

What about making something like a builder that makes a copy of a
DecoderBufferBase with a new timestamp, or perhaps a subclass
(TimeShiftedDecoderBufferBase) that takes a DecoderBufferBase and a new
timestamp in its constructor?

[halliwell, 2015-06-05 20:16:48]

https://codereview.chromium.org/1145163005/diff/1/chromecast/media/cma/base/d...
File chromecast/media/cma/base/decoder_buffer_base.h (right):

https://codereview.chromium.org/1145163005/diff/1/chromecast/media/cma/base/d...
chromecast/media/cma/base/decoder_buffer_base.h:37: virtual void
set_timestamp(const base::TimeDelta& timestamp) = 0;
On 2015/06/05 20:02:48, gunsch wrote:
> Today, DecoderBufferBase is immutable, which is a pretty nice property. We can
> pass every single DecoderBufferBase around as const.
> 
> What about making something like a builder that makes a copy of a
> DecoderBufferBase with a new timestamp, or perhaps a subclass
> (TimeShiftedDecoderBufferBase) that takes a DecoderBufferBase and a new
> timestamp in its constructor?

Hmmm ... I could definitely do either of those if we want these to be immutable,
although:
* Although it's all 'const', it's not exactly immutable (see writable_data!)
* I don't believe we pass them around as const.  They seem to be passed as const
scoped_refptr<_>& a lot, which is fine to call non-const members on the enclosed
pointer.

Let me know what you think :)

[gunsch, 2015-06-05 20:37:03]

Reasonable. Per offline discussion, lgtm as-is, I guess it's more a stylistic
choice then if you want to have an adapter class that overwrites the timestamp
or if you want to add the mutator to all classes.

[halliwell, 2015-06-05 21:27:17]

The CQ bit was checked by halliwell@chromium.org

[commit-bot: I haz the power, 2015-06-05 21:27:47]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1145163005/1

[commit-bot: I haz the power, 2015-06-05 21:38:39]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2015-06-05 21:39:25]

Patchset 1 (id:??) landed as
https://crrev.com/7f98d797e90515c702379d89f879a202afd7287d
Cr-Commit-Position: refs/heads/master@{#333138}