Count how often a Media Fragments URI is applied in HTMLMediaElement

Count how often a Media Fragments URI is applied in HTMLMediaElement

http://lists.w3.org/Archives/Public/public-media-fragment/2014Feb/0000.html
http://lists.w3.org/Archives/Public/public-media-fragment/2014Feb/0002.html

In this thread about looping over media fragments it became clear that
no spec actually says how media fragment end times integrate in
HTMLMediaElement. (The start time is mapped to the "initial playback
position", which almost matches what Blink does.)

Blink/WebKit pauses at the fragment end time once. Firefox Nightly does
the same, while IE11 appears to not support MF URIs at all.

The counter data will tell us whether or not breaking changes can be
made and the relative usage could help inform the spec discussion.

BUG=none
R=acolwell@chromium.org

Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=168441

[acolwell GONE FROM CHROMIUM, 2014-03-04 01:22:15]

lgtm

https://codereview.chromium.org/185363002/diff/1/Source/core/html/HTMLMediaEl...
File Source/core/html/HTMLMediaElement.cpp (right):

https://codereview.chromium.org/185363002/diff/1/Source/core/html/HTMLMediaEl...
Source/core/html/HTMLMediaElement.cpp:2406: if (!m_mediaController && !m_paused)
{
The mediaController portion of this condition seems rather odd. It seems like
the element should pause independent of the controller. Is this backed by the
spec somewhere? I would expect the entire presentation to pause or at least it
to continue w/o this element playing anything further. It just seems weird to
continue as if the end time wasn't specified at all.

[philipj_slow, 2014-03-04 03:53:20]

https://codereview.chromium.org/185363002/diff/1/Source/core/html/HTMLMediaEl...
File Source/core/html/HTMLMediaElement.cpp (right):

https://codereview.chromium.org/185363002/diff/1/Source/core/html/HTMLMediaEl...
Source/core/html/HTMLMediaElement.cpp:2406: if (!m_mediaController && !m_paused)
{
On 2014/03/04 01:22:15, acolwell wrote:
> The mediaController portion of this condition seems rather odd. It seems like
> the element should pause independent of the controller. Is this backed by the
> spec somewhere? I would expect the entire presentation to pause or at least it
> to continue w/o this element playing anything further. It just seems weird to
> continue as if the end time wasn't specified at all.

I hadn't given the controller condition any thought, but I agree that it's
weird. None of this is backed by a spec because no spec says how the fragment
end time interacts with HTMLMediaElement at all, I suppose this just seemed
sensible at the time of implementation. If no one else in the linked discussion
thread does, I'll file a HTML spec bug to specify how the fragment end time is
supposed to work.

[philipj_slow, 2014-03-04 03:53:44]

The CQ bit was checked by philipj@opera.com

[commit-bot: I haz the power, 2014-03-04 03:53:52]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/philipj@opera.com/185363002/1

[commit-bot: I haz the power, 2014-03-04 03:53:53]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-03-04 03:53:53]

Failed to apply patch for Source/core/frame/UseCounter.h:
While running patch -p1 --forward --force --no-backup-if-mismatch;
  patching file Source/core/frame/UseCounter.h
  Hunk #1 FAILED at 298.
  1 out of 1 hunk FAILED -- saving rejects to file
Source/core/frame/UseCounter.h.rej

Patch:       Source/core/frame/UseCounter.h
Index: Source/core/frame/UseCounter.h
diff --git a/Source/core/frame/UseCounter.h b/Source/core/frame/UseCounter.h
index
c447c567fc73eafe24188e97d2fbd1b6434ab3f5..6d1c92be898905352dfdb7c8c12d395d27a75e5c
100644
--- a/Source/core/frame/UseCounter.h
+++ b/Source/core/frame/UseCounter.h
@@ -298,6 +298,8 @@ public:
         JavascriptExhaustedMemory = 277,
         InsertAdjacentHTML = 278,
         SVGClassName = 279,
+        HTMLMediaElementSeekToFragmentStart = 280,
+        HTMLMediaElementPauseAtFragmentEnd = 281,
         // Add new features immediately above this line. Don't change assigned
         // numbers of any item, and don't reuse removed slots.
         NumberOfFeatures, // This enum value must be last.

[philipj_slow, 2014-03-04 06:50:42]

The CQ bit was checked by philipj@opera.com

[commit-bot: I haz the power, 2014-03-04 06:50:52]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/philipj@opera.com/185363002/20001

[nessy, 2014-03-04 07:54:37]

On 2014/03/04 03:53:20, philipj wrote:
> 
> I hadn't given the controller condition any thought, but I agree that it's
> weird. None of this is backed by a spec because no spec says how the fragment
> end time interacts with HTMLMediaElement at all, I suppose this just seemed
> sensible at the time of implementation. If no one else in the linked
discussion
> thread does, I'll file a HTML spec bug to specify how the fragment end time is
> supposed to work.

To be fair, the Media Fragment spec has a non-normative recommendation on this:
"For a temporal URI fragment, it is recommended to start playback at a time
offset that equals to the start of the fragment and pause at the end of the
fragment."
http://www.w3.org/TR/media-frags/#media-fragment-display

[philipj_slow, 2014-03-05 07:27:30]

Committed patchset #2 manually as r168441 (presubmit successful).