Don't rebase timestamps for positive start times.

Don't rebase timestamps for positive start times.

This is wrong according to the HTML Media specification:

http://dev.w3.org/html5/spec-preview/media-elements.html#offsets-into-the-media-resource

"If the media resource somehow specifies an explicit timeline whose
origin is not negative (i.e. gives each frame a specific time offset
and gives the first frame a zero or positive offset), then the media
timeline should be that timeline."

BUG=413292
TEST=updated unittest.

Committed: https://crrev.com/93c37f1b01ef982bce30d4404562f05c7b1d439e
Cr-Commit-Position: refs/heads/master@{#294461}

[DaleCurtis, 2014-09-11 18:11:34]

Patchset #1 (id:1) has been deleted

[DaleCurtis, 2014-09-11 18:12:23]

dalecurtis@chromium.org changed reviewers:
+ acolwell@chromium.org

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

Just a few minor comments. Please also create some LayoutTests that actually
tests this at an integration test level and make sure that we handle
.currentTime = 0 and .currentTime =
something_less_than_start_time_but_greater_than_0.

https://codereview.chromium.org/562323002/diff/20001/media/filters/ffmpeg_dem...
File media/filters/ffmpeg_demuxer.cc (right):

https://codereview.chromium.org/562323002/diff/20001/media/filters/ffmpeg_dem...
media/filters/ffmpeg_demuxer.cc:601: // blink, we also want to special case
seeks to zero; they're unambiguously
nit: Please file a bug to track the seekable range work and reference it here.

https://codereview.chromium.org/562323002/diff/20001/media/filters/ffmpeg_dem...
media/filters/ffmpeg_demuxer.cc:604: start_time_ < base::TimeDelta() || time ==
base::TimeDelta()
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]

https://codereview.chromium.org/562323002/diff/20001/media/filters/ffmpeg_dem...
File media/filters/ffmpeg_demuxer.cc (right):

https://codereview.chromium.org/562323002/diff/20001/media/filters/ffmpeg_dem...
media/filters/ffmpeg_demuxer.cc:601: // blink, we also want to special case
seeks to zero; they're unambiguously
On 2014/09/11 18:34:42, acolwell_leaving_chromium_9-23 wrote:
> nit: Please file a bug to track the seekable range work and reference it here.

Done.

https://codereview.chromium.org/562323002/diff/20001/media/filters/ffmpeg_dem...
media/filters/ffmpeg_demuxer.cc:604: start_time_ < base::TimeDelta() || time ==
base::TimeDelta()
On 2014/09/11 18:34:42, acolwell_leaving_chromium_9-23 wrote:
> 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.

Done.

[acolwell GONE FROM CHROMIUM, 2014-09-11 19:24:39]

lgtm

[DaleCurtis, 2014-09-11 19:28:09]

The CQ bit was checked by dalecurtis@chromium.org

[commit-bot: I haz the power, 2014-09-11 19:33:46]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patchset/562323002/40001

[commit-bot: I haz the power, 2014-09-11 20:46:05]

Committed patchset #2 (id:40001) as a4ddb0a44e6ddcc63efe5910774e0c7a4e259f53

[commit-bot: I haz the power, 2014-09-11 20:55:27]

Patchset 2 (id:??) landed as
https://crrev.com/93c37f1b01ef982bce30d4404562f05c7b1d439e
Cr-Commit-Position: refs/heads/master@{#294461}