Intent to Unship: MediaController

[Philip Jägenstedt]

This falls outside the documented launch process, but here goes:

Summary

Put MediaController behind an experimental runtime flag until the implementation correctly integrates with the media engine.

Motivation

A MediaController can be used to play multiple media elements in sync, the typical use case being syncing a video with an audio track in another language or a sign language video overlay.

Spec: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#media-controllers

MediaController was implemented in http://trac.webkit.org/changeset/100159 and is currently supported in WebKit and Chromium browsers.

Unfortunately, the implementation does not integrate with the media engine, which means that the slaved media elements are not actually kept in sync. Without this integration the API is little more than a "C++ polyfill." Had the feature not already been shipped, I think it would be a bad idea to ship it in its current state, since without a full implementation it's hard to judge what the true complexity of the feature is.

Also, I don't think anyone in the Blink project has a sense of ownership for MediaController. No real work has been done on it since http://trac.webkit.org/changeset/136295, in December 2012.

I discussed the situation with Aaron Colwell and Andrew Scherkus a few months ago and added a use counter (see below) to determine what the options might be. It turns out that MediaController is very rarely used, which means that it can be safely unshipped if we want to. I think doing so would be wise until we can confidently say that the complexity of the feature is something we want to accept forever.

Compatibility Risk

MediaController is very rarely used and not supported in Firefox or IE, so the risk seems very low.

Alternative implementation suggestion for web developers

In short, do whatever you do to support Firefox and IE. Simply seeking two media elements (while paused) and playing them at the same time should give roughly the same result as when using Blink's current MediaController implementation.

Usage information from UseCounter

http://www.chromestatus.com/metrics/feature/timeline/popularity/259

[Aaron Colwell]

It might not be clear from the Motivation section so I'll be explicit about it. I support unshipping this feature. It is a non-trivial effort to implement synchronization across media engines and we just don't have the cycles to work on it right now. There is also vastly different behavior between Android and Desktop because different media engines are involved. I think it is a disservice to our users to tease them with the presence of this API and then to let them down with an incomplete and non-compliant implementation.

Aaron

[Ojan Vafai]

LGTM

[Alex Russell]

LGTM as well.

I'd also like to see MediaController's relationship to Web Animations rationalized somehow. Surely synchronizing media with animations is something that the various controllers should be seeking to enable.

LGTM

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[TAMURA, Kent]

LGTM2.

--
TAMURA Kent
Software Engineer, Google

[Jochen Eisinger]

LGTM3

[Ed O'Loughlin]

On Wednesday, 23 April 2014 15:30:20 UTC+1, Aaron Colwell wrote:

I think it is a disservice to our users to tease them with the presence of this API and then to let them down with an incomplete and non-compliant implementation.

Hi,

one of your users here. I just found out about the change the hard way - working code just became unworking code when run in the latest beta (36). Given that the alternative is to try to sync elements using Javascript iterating over media elements, how bad could the implementation have been in comparison (from an API user's persective)? As the API is in the draft spec and doesn't look like it's going anywhere then why remove it? I'm now going to have to replace clean code that would eventually work better without intervention with a hack that will have to be reverted when the API comes back.

As to the argument that the API doesn't exist in Firefox or IE: we're targeting HTML5 for our app with the view that our users will not mind installing  (or will already be using) Chrome as it has a huge mindshare anyway. The other browsers will eventually catch up (FF is close-ish) and having advanced, plugin-free apps available in Chrome will only accelerate this process.

I'm not trying to convince you to revert the change. It's done; I get it. I would, however, ask you to please bear my arguments in mind when making a similar decision in future. I'm developing against an evolving standard. Chrome is huge and I can't track all pending changes (I wasn't even aware of this group until today), so I have to make an call on what to use. Betting on an API that looked small and useful seemed a reasonable idea until yesterday.

Thanks,
Ed O'Loughlin.

[PhistucK]

By the way, beside caniuse.com, you can see the usage counters over at http://www.chromestatus.com/metrics/css/popularity and http://www.chromestatus.com/metrics/feature/popularity. If the percentage is small, you might want to reconsider using the feature (unless it is a recently introduced feature and then you will have to wait and see).

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Andrew Scherkus]

On Wed, Jul 9, 2014 at 2:27 AM, Ed O'Loughlin <ed.olo...@gmail.com> wrote:

On Wednesday, 23 April 2014 15:30:20 UTC+1, Aaron Colwell wrote:

I think it is a disservice to our users to tease them with the presence of this API and then to let them down with an incomplete and non-compliant implementation.

Hi,

one of your users here. I just found out about the change the hard way - working code just became unworking code when run in the latest beta (36). Given that the alternative is to try to sync elements using Javascript iterating over media elements, how bad could the implementation have been in comparison (from an API user's persective)? As the API is in the draft spec and doesn't look like it's going anywhere then why remove it? I'm now going to have to replace clean code that would eventually work better without intervention with a hack that will have to be reverted when the API comes back.

The implementation was more or less equivalent to how you would conceptually implement MediaController-like functionality in Javascript. There wasn't any sort of fine-grained synchronization between media elements. It basically called play() on multiple elements and hoped for the best.

 

Andrew

[Silvia Pfeiffer]

I still think we should be more careful about removing features in the
future, even if they are only half-working and only in blink. Using
the existing half-working solution has obviously been sufficient for
Ed (and likely others) and could have only become better for them,
when somebody starts improving the implementation. I think we've been
very keen on removing features in the last few months, resulting in
more than one roller coaster ride for some of our users and
developers. We shouldn't gloss over such feedback. Usage counters
alone are clearly not a sufficient decision criterium. Might it be
possible to find out from usage counters who actually are those sites
that use it and find out more about the use cases, in particular if
they are valid and would be broken by removing the feature? I know
it's more effort, but we're pushing effort onto develoeprs by removing
features, too, as this case proves.

Cheers,
Silvia.

[Adam Barth]

On Wed Jul 09 2014 at 7:37:21 PM, Silvia Pfeiffer <silv...@chromium.org> wrote:

I still think we should be more careful about removing features in the
future, even if they are only half-working and only in blink.

I disagree.  When we remove half-working, Blink-only features with low usage, we hear from the affected developers, but when we leave these features in, we don't hear from the large population of developers that are harmed because those developers exist in the future when we and other browsers can't improve the platform because the web has grown a dependency on the broken version.

 

Using
the existing half-working solution has obviously been sufficient for
Ed (and likely others) and could have only become better for them,
when somebody starts improving the implementation.

I haven't studied this example in detail, but that statement isn't true in general.  It's often the case that improving an API breaks existing clients.

 

I think we've been
very keen on removing features in the last few months, resulting in
more than one roller coaster ride for some of our users and
developers.

Yes, we've learned a lot from that process, which will hopefully lead to us doing better in the future.  For example, we've learned that removing old APIs is much harder than removing new APIs because the slowest moving developers tend to adopt the oldest APIs and they're less able to adapt to change.

 

We shouldn't gloss over such feedback.

Definitely not!

 

Usage counters
alone are clearly not a sufficient decision criterium. Might it be
possible to find out from usage counters who actually are those sites
that use it and find out more about the use cases, in particular if
they are valid and would be broken by removing the feature?

Unfortunately, we're unable to gather that data because of Chrome's privacy policy.  Perhaps other vendors that ship Chromium-based browsers operate under different privacy policies and would be willing to share that data with the community.

 

I know
it's more effort, but we're pushing effort onto developers by removing

features, too, as this case proves.

Yes, indeed.  We shouldn't take these decisions lightly.

Adam

 

[Yoav Weiss]

One might argue that when using Blink-only, half-baked features, authors should use a polyfill (with feature detection) in order to support non-Blink browsers, in which case, turning off that feature in Blink would have little negative impact on them.

[Ed O'Loughlin]

On Friday, 11 July 2014 03:02:35 UTC+1, Yoav Weiss wrote:

One might argue that when using Blink-only, half-baked features, authors should use a polyfill (with feature detection) in order to support non-Blink browsers, in which case, turning off that feature in Blink would have little negative impact on them.

If I can chime in one last time: The fundamental issue was that there was no obvious (to me) indication that the feature was half-baked and because it's in the draft spec I felt that, although it might change, it wasn't going to go away.

I also want to say that, as a team, your discussion around the impact of changes like this is encouraging to me.

Thanks,
Ed.

[Silvia Pfeiffer]

On Thu, Jul 10, 2014 at 4:06 PM, Adam Barth <aba...@chromium.org> wrote:
> On Wed Jul 09 2014 at 7:37:21 PM, Silvia Pfeiffer <silv...@chromium.org>
> wrote:
>>
>> I still think we should be more careful about removing features in the
>> future, even if they are only half-working and only in blink.
>
>
> I disagree. When we remove half-working, Blink-only features with low
> usage, we hear from the affected developers, but when we leave these
> features in, we don't hear from the large population of developers that are
> harmed because those developers exist in the future when we and other
> browsers can't improve the platform because the web has grown a dependency
> on the broken version.

Right, I agree that in general leaving broken features out there is
bad (and they really shouldn't make it in in the first place).

>> Using
>> the existing half-working solution has obviously been sufficient for
>> Ed (and likely others) and could have only become better for them,
>> when somebody starts improving the implementation.
>
>
> I haven't studied this example in detail, but that statement isn't true in
> general. It's often the case that improving an API breaks existing clients.

Yes, I think this case is different than the general case, because it
was working, just not at full accuracy. From a Web dev POV, the full
feature is an improvement on the existing implementation. From a
browser dev POV, tough, it's a tougher feature to fully support, so, I
can understand where the decision to unship it came from (as in: it's
easier to continue development behind a flag).

I think it would have been possible to do improvements without
removing the feature - but of course now's too late: I should have
questioned this decision when it was made (and I'll take that lesson
away from this).

>> I think we've been
>> very keen on removing features in the last few months, resulting in
>> more than one roller coaster ride for some of our users and
>> developers.
>
>
> Yes, we've learned a lot from that process, which will hopefully lead to us
> doing better in the future. For example, we've learned that removing old
> APIs is much harder than removing new APIs because the slowest moving
> developers tend to adopt the oldest APIs and they're less able to adapt to
> change.
>
>>
>> We shouldn't gloss over such feedback.
>
>
> Definitely not!
>
>>
>> Usage counters
>> alone are clearly not a sufficient decision criterium. Might it be
>> possible to find out from usage counters who actually are those sites
>> that use it and find out more about the use cases, in particular if
>> they are valid and would be broken by removing the feature?
>
>
> Unfortunately, we're unable to gather that data because of Chrome's privacy
> policy.

That's a good thing and fair enough. It might be worth, though,
publishing intents to remove features a bit more widely than just this
mailing list. Maybe on some blog, where more Web devs are monitoring
what's going on?

I'm just trying to find a better way to get input from Web devs that
will be affected.

Silvia.

[Eric Seidel]

Intents are all published at bit.ly/blink-intents which others should feel encouraged to syndicate. The highlight reel of such tend to make the various release notes.  

[PhistucK]

It was supposed to be included in http://blog.chromium.org/2014/04/chrome-35-beta-more-developer-control.html, but it apparently got missed. :(

These blog posts need better (manual?) auditing, this is not the first time, unfortunately...

☆PhistucK

[Ian Hickson]

On Fri, 11 Jul 2014, Ed O'Loughlin wrote:
>
>
> If I can chime in one last time: The fundamental issue was that there
> was no obvious (to me) indication that the feature was half-baked and
> because it's in the draft spec I felt that, although it might change, it
> wasn't going to go away.

For the record, it's not just in a "draft spec", it's in the HTML
standard. But I would certainly encourage implementors to not ship what
they consider to be "half-baked". It's often been the case that an
implementor has shipped a low-quality implementation, and we've ended up
stuck with that long-term for compatibility reasons.

--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'

[Eric Seidel]

Sorry, I meant bit.ly/blinkintents.

[Philip Jägenstedt]

Others have already commented, but since I did the removing I thought
I should say something too.

The feature itself is sound and useful in my opinion, and I don't know
of any major design flaws. However, shipping a partial implementation
is still risky, because content can come to depend on it too soon. If
a complete implementation reveals flaws in the model, it could be too
late to fix at that point. Combined with the very low usage, removal
seemed appropriate.

One thing that I don't have a good answer for is how developers can
find out about changes like this early on. I guess this will be
included in the release notes for next stable release, but that seems
too late for people who depended on this in production.

Philip

[henr...@gmail.com]

I have the same problem too as we use this feature in our product and we are now trying to figure out a workaround. This is a very useful feature in my opinion but we are totally blindsided with the removal of a feature that is in the HTML5 spec.

In general I want to know how I can track features that are "unshipped" like this and whether there will be any plans to re-ship the feature. Is there a single place that we can track things or I have hunt around message groups to figure this out?

Henry

[Eric Seidel]

chromestatus.com and (3rd party) caniuse.com track features.

bit.ly/blinkintents automatically all the public-api change announcements like this one into a spreadsheet.  I suspect others may syndicate that data in other forms, but I'm not aware of any.

[henr...@gmail.com]

This is useful but it becomes a manual process to track for deprecation of features.

For something like this which is in HTML5 standard, is there plan to re-ship the feature again, or this is permanent removal? The spreadsheet does not mention this.

Thanks

Henry

[Philip Jägenstedt]

The MediaController implementation was not removed, only put behind a
flag. In order to ship again, it needs to be completed to actually
synchronize media elements, but whether someone will prioritize that
work is an open question.

I'm sorry that this removal affected you, I hope you'll find that
simply calling play() on two media elements at the same time works
about the same, and will also work in Firefox and IE.

Philip

[judeo...@google.com]

Can someone let me know what the flag is that re-enables MediaController and MediaGroup? 

[Philip Jägenstedt]

It's controlled by MediaController in RuntimeEnabledFeatures, which
means it's part of "Enable experimental Web Platform features" in
chrome://flags.

[judeo...@google.com]

Worked perfectly. Thanks for your help.

On Wednesday, April 23, 2014 at 10:24:04 PM UTC+10, Philip Jägenstedt wrote: