Add support for HTMLMediaElement::getStartDate()

Add support for HTMLMediaElement::getStartDate()

Implements minimal logic for exposing "timeline offset"
information according to the HTML5 spec. These changes
add a timelineOffset() method to the WebMediaPlayer so that
Chromium code can provide Blink with this information.
HTMLMediaElement uses this new method to expose the
information to JavaScript.


BUG=312699

[acolwell GONE FROM CHROMIUM, 2014-04-14 17:04:40]

adamk: Source/core/html 
abarth: public/platform/

This patch depends on the following Chromium-side change.
https://codereview.chromium.org/236023003/

I'm planning on adding a LayoutTest shortly. I just want to make sure the
approach I'm taking is ok here.

[adamk, 2014-04-14 17:22:40]

This seems fine, although I'm a bit surprised to see a Date in WebIDL again
after all the back-and-forth last year about whether or not that type was
appropriate for such things (but it matches the spec, so I won't argue further
:)

[philipj_slow, 2014-04-15 23:26:24]

I think this should be RuntimeEnabled until it's supported on all platforms.
Given how many times this stuff has changed (initialTime, startTime, startDate
and now getStartDate) it would be nice to make sure not to ship it prematurely
this time :)

[acolwell GONE FROM CHROMIUM, 2014-04-15 23:44:47]

On 2014/04/15 23:26:24, philipj wrote:
> I think this should be RuntimeEnabled until it's supported on all platforms.
> Given how many times this stuff has changed (initialTime, startTime, startDate
> and now getStartDate) it would be nice to make sure not to ship it prematurely
> this time :)

Define "supported on all platforms"? This information may not be available in
the '.src=' path on Android because of Android API limitations. We might
eventually be able to get there once Android is moved over to something similar
to the existing desktop code, but I don't think we should delay the whole
feature until that happens. We can still provide compliant behavior that lets
the application detect if the mapping is available or not.

[philipj_slow, 2014-04-17 22:32:51]

On 2014/04/15 23:44:47, acolwell wrote:
> On 2014/04/15 23:26:24, philipj wrote:
> > I think this should be RuntimeEnabled until it's supported on all platforms.
> > Given how many times this stuff has changed (initialTime, startTime,
startDate
> > and now getStartDate) it would be nice to make sure not to ship it
prematurely
> > this time :)
> 
> Define "supported on all platforms"? This information may not be available in
> the '.src=' path on Android because of Android API limitations. We might
> eventually be able to get there once Android is moved over to something
similar
> to the existing desktop code, but I don't think we should delay the whole
> feature until that happens. We can still provide compliant behavior that lets
> the application detect if the mapping is available or not.

I was hoping that supporting this on Android wouldn't require replacing the
whole media stack, but I guess it's unlikely that
http://developer.android.com/reference/android/media/MediaMetadataRetriever.h...
is anything other than the freeform dates in various containers...

How can a script tell the difference between "media resource has no start date"
and "media engine can't extract start date"? If there is no way then maybe it's
better to ship it only on the platforms where it's supported? Of course there
are lots of things about HTMLMediaElement that are suboptimal on Android, so if
you think singling this out would be silly I will not object.

[acolwell GONE FROM CHROMIUM, 2014-04-18 17:20:47]

On 2014/04/17 22:32:51, philipj wrote:
> On 2014/04/15 23:44:47, acolwell wrote:
> > On 2014/04/15 23:26:24, philipj wrote:
> > > I think this should be RuntimeEnabled until it's supported on all
platforms.
> > > Given how many times this stuff has changed (initialTime, startTime,
> startDate
> > > and now getStartDate) it would be nice to make sure not to ship it
> prematurely
> > > this time :)
> > 
> > Define "supported on all platforms"? This information may not be available
in
> > the '.src=' path on Android because of Android API limitations. We might
> > eventually be able to get there once Android is moved over to something
> similar
> > to the existing desktop code, but I don't think we should delay the whole
> > feature until that happens. We can still provide compliant behavior that
lets
> > the application detect if the mapping is available or not.
> 
> I was hoping that supporting this on Android wouldn't require replacing the
> whole media stack, but I guess it's unlikely that
>
http://developer.android.com/reference/android/media/MediaMetadataRetriever.h...
> is anything other than the freeform dates in various containers...

I can take a look at the Android code to see if this could work. The description
makes me think this couldn't be completely relied upon to provide the
information that the HTML spec requires. Depending on the interpretation of
"creation time" this may not actually map to the wall clock timestamp that
should be associated with presentation time 0. I'm pretty sure of a
"modification time" was returned this would be the totally wrong thing to use.

> 
> How can a script tell the difference between "media resource has no start
date"
> and "media engine can't extract start date"? If there is no way then maybe
it's
> better to ship it only on the platforms where it's supported? Of course there
> are lots of things about HTMLMediaElement that are suboptimal on Android, so
if
> you think singling this out would be silly I will not object.

The thing is that I know I can provide the right information for MSE playbacks
on Android. So it doesn't have to be an all or nothing situation for that
platform.

As far as I can tell there would be no way to signal the difference between "no
start date" and "I cannot extract a start date if it was present".  I do believe
the application could determine this though if it happened to know that a start
date should be present in the URL it sent to the element. For example if it
provided a URL to a live stream and it saw that getStartDate() return NaN then
it could reason that the UA was unable to extract the start date and take action
accordingly. This would be no different then what it would have to do today
given that this information isn't even available. If a non-NaN value was
returned, then it could enable any other functionality that it wants to sync w/
wall clock time.

[philipj_slow, 2014-04-19 14:16:57]

On 2014/04/18 17:20:47, acolwell wrote:
> The thing is that I know I can provide the right information for MSE playbacks
> on Android. So it doesn't have to be an all or nothing situation for that
> platform.

Oh, well that changes things, then there's no sane way to only expose the API
when it's fully implemented.

[acolwell GONE FROM CHROMIUM, 2014-05-06 00:49:24]

PTAL. I've put the feature behind a runtime flag for now and I've created an
MSE-based layout test to test this feature. The necessary changes for Android
(https://codereview.chromium.org/263333004/) are in the CQ right now. This
should provide consistant behavior on Android and Desktop for MSE playbacks.

Normal .src =  playbacks will still be inconsistent for some content because the
Android's stagefright code does not provide the necessary information at this
time. I'll file a bug against Android to have this fixed.

[philipj_slow, 2014-05-06 11:13:51]

LGTM % trivial nits

https://codereview.chromium.org/209223002/diff/60001/Source/core/html/HTMLMed...
File Source/core/html/HTMLMediaElement.cpp (right):

https://codereview.chromium.org/209223002/diff/60001/Source/core/html/HTMLMed...
Source/core/html/HTMLMediaElement.cpp:1615: // 2. Update the timeline offset to
the date and time that corresponds to the zero time in the media timeline
established in the previous step, if any. If no explicit time and date is given
by the media resource, the timeline offset must be set to Not-a-Number (NaN).
Nit: this is a very long line. There isn't a lot of consistency, but many spec
comments seem to be limited to 100 columns, so that would work.

https://codereview.chromium.org/209223002/diff/60001/public/platform/WebMedia...
File public/platform/WebMediaPlayer.h (right):

https://codereview.chromium.org/209223002/diff/60001/public/platform/WebMedia...
public/platform/WebMediaPlayer.h:132: // 'timeline offset' and January 1, 1970
UTC. Use base::Time::ToJsTime() for
s/for/to/

[philipj_slow, 2014-05-06 11:15:59]

Oh right, will you send an Intent to Implement and link to it in the commit
message and/or bug? I thought I'd seen one already but I can't find it. Should
easily get its LGTMs, anyway.

[philipj_slow, 2014-05-15 11:37:59]

https://codereview.chromium.org/209223002/diff/60001/Source/core/html/HTMLMed...
File Source/core/html/HTMLMediaElement.cpp (right):

https://codereview.chromium.org/209223002/diff/60001/Source/core/html/HTMLMed...
Source/core/html/HTMLMediaElement.cpp:1943: return m_timelineOffset;
My colleague has noticed that this value will be wrapped in a Date directly, so
it needs to be multiplied by 1000, probably here.

[acolwell GONE FROM CHROMIUM, 2014-05-15 13:01:21]

https://codereview.chromium.org/209223002/diff/60001/Source/core/html/HTMLMed...
File Source/core/html/HTMLMediaElement.cpp (right):

https://codereview.chromium.org/209223002/diff/60001/Source/core/html/HTMLMed...
Source/core/html/HTMLMediaElement.cpp:1943: return m_timelineOffset;
On 2014/05/15 11:38:00, philipj wrote:
> My colleague has noticed that this value will be wrapped in a Date directly,
so
> it needs to be multiplied by 1000, probably here.
It is already supposed to be in milliseconds since
WebMediaPlayer::timelineOffset() that base::Time::ToJsTime() should be used to
generate this value. I've made a note to update the documentation on
m_timelineOffset.

https://codereview.chromium.org/209223002/diff/60001/Source/core/html/HTMLMed...
File Source/core/html/HTMLMediaElement.h (right):

https://codereview.chromium.org/209223002/diff/60001/Source/core/html/HTMLMed...
Source/core/html/HTMLMediaElement.h:446: // number of seconds since January 1,
1970 or NaN if no offset is in effect.
s/seconds/milliseconds.

[philipj_slow, 2014-05-15 13:28:28]

https://codereview.chromium.org/209223002/diff/60001/Source/core/html/HTMLMed...
File Source/core/html/HTMLMediaElement.cpp (right):

https://codereview.chromium.org/209223002/diff/60001/Source/core/html/HTMLMed...
Source/core/html/HTMLMediaElement.cpp:1943: return m_timelineOffset;
On 2014/05/15 13:01:22, acolwell_OOO_5-12_to_5-15 wrote:
> On 2014/05/15 11:38:00, philipj wrote:
> > My colleague has noticed that this value will be wrapped in a Date directly,
> so
> > it needs to be multiplied by 1000, probably here.
> It is already supposed to be in milliseconds since
> WebMediaPlayer::timelineOffset() that base::Time::ToJsTime() should be used to
> generate this value. I've made a note to update the documentation on
> m_timelineOffset.

Thanks!