Re: [whatwg] Removing mediagroup/MediaController from HTML

[Philip Jägenstedt]

On Tue, Nov 3, 2015 at 4:20 PM, David Singer  wrote:
>
>> On Oct 3, 2015, at 13:39 , Silvia Pfeiffer 
wrote:
>>
>> On Fri, Oct 2, 2015 at 10:27 AM, Domenic Denicola  wrote:
>>> From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of
>>>
 is removal really the right thing to do, given that we have an
 implementation?
>>>
>>> I agree this is a problematic question. I opened
https://github.com/whatwg/html/issues/209 for the more general issue but am
happy to have the discussion here since that hasn't gotten much replies. Do
check out the examples listed there though. E.g. Blink is in similar
situations with  and HTML imports.
>>>
>>> The web seems to end up with a lot of APIs like this, where the spec
ends up just being documentation for a single-vendor implementation. I
don't really know what to do in these cases. If our goal in writing these
specs is to produce an interoperable web platform, then such features seem
like they shouldn't be part of the platform.
>>
>>
>> There is also a question about the why of the current state: is it
>> just a single-vendor implementation because nobody at the other
>> vendors has gotten around to implementing it or is it because they
>> fundamentally object to implementing it. If there are objections, then
>> it's reasonable to consider removing the feature. Otherwise, it would
>> be premature to remove it IMHO.
>
> Yes.  It wasn’t even our proposal (see <
https://lists.w3.org/Archives/Public/public-html/2011Mar/0436.html>) and we
feel it answers some important cases that we can’t otherwise answer.  Some
insights from others would be welcome.

My main concern with the API, and the reason I unshipped it in Blink, is
the apparent difficulty in implementing it really well, to actually get the
sync sample-accurate at the media framework level. I understand that it's
not really *that* hard in principle, but still enough work that it wasn't
done for Safari, or Chromium. Some frameworks seem to make it fairly
straightforward, I wouldn't be surprised if QuickTime has supported it
since the 90's. When I looked into implementing it using GStreamer for
Presto, it seemed like it was a matter of using a single pipeline with a
single audio output node and thus a single clock. What seems quite tricky
to me is to dynamically split or merge pipelines as media elements join or
leave a media controller. I never really looked much deeper than this,
maybe it's quite doable.

Another more recent concern that I have is that media controller builds on
top of an already quite high-level abstraction that is HTMLMediaElement. In
the interests of a layered and (somewhat) rational platform, I wonder if it
wouldn't be more sensible to crack open HTMLMediaElement, exposing the
primitives all the way down clocks and audio output devices, so that one
could create and connect demuxers and decoders to the same driving clock in
a way that's more similar to how you'd to it using the underlying
frameworks. Of course this isn't even half-baked, and it would be a
many-year project to bring sanity to the media stack (media elements + MSE
+ EME + Web Audio + WebRTC) of the web.

Philip

Re: [whatwg] Removing mediagroup/MediaController from HTML

[David Singer]

> On Oct 3, 2015, at 13:39 , Silvia Pfeiffer  wrote:
> 
> On Fri, Oct 2, 2015 at 10:27 AM, Domenic Denicola  wrote:
>> From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of
>> 
>>> is removal really the right thing to do, given that we have an
>>> implementation?
>> 
>> I agree this is a problematic question. I opened 
>> https://github.com/whatwg/html/issues/209 for the more general issue but am 
>> happy to have the discussion here since that hasn't gotten much replies. Do 
>> check out the examples listed there though. E.g. Blink is in similar 
>> situations with  and HTML imports.
>> 
>> The web seems to end up with a lot of APIs like this, where the spec ends up 
>> just being documentation for a single-vendor implementation. I don't really 
>> know what to do in these cases. If our goal in writing these specs is to 
>> produce an interoperable web platform, then such features seem like they 
>> shouldn't be part of the platform.
> 
> 
> There is also a question about the why of the current state: is it
> just a single-vendor implementation because nobody at the other
> vendors has gotten around to implementing it or is it because they
> fundamentally object to implementing it. If there are objections, then
> it's reasonable to consider removing the feature. Otherwise, it would
> be premature to remove it IMHO.

Yes.  It wasn’t even our proposal (see 
) and we 
feel it answers some important cases that we can’t otherwise answer.  Some 
insights from others would be welcome.


David Singer
Manager, Software Standards, Apple Inc.

Re: [whatwg] Removing mediagroup/MediaController from HTML

[Silvia Pfeiffer]

On Fri, Oct 2, 2015 at 10:27 AM, Domenic Denicola  wrote:
> From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of
>
>> is removal really the right thing to do, given that we have an
>> implementation?
>
> I agree this is a problematic question. I opened 
> https://github.com/whatwg/html/issues/209 for the more general issue but am 
> happy to have the discussion here since that hasn't gotten much replies. Do 
> check out the examples listed there though. E.g. Blink is in similar 
> situations with  and HTML imports.
>
> The web seems to end up with a lot of APIs like this, where the spec ends up 
> just being documentation for a single-vendor implementation. I don't really 
> know what to do in these cases. If our goal in writing these specs is to 
> produce an interoperable web platform, then such features seem like they 
> shouldn't be part of the platform.


There is also a question about the why of the current state: is it
just a single-vendor implementation because nobody at the other
vendors has gotten around to implementing it or is it because they
fundamentally object to implementing it. If there are objections, then
it's reasonable to consider removing the feature. Otherwise, it would
be premature to remove it IMHO.

Silvia.

Re: [whatwg] Removing mediagroup/MediaController from HTML

[David Singer]

> On Oct 1, 2015, at 6:49 , Anne van Kesteren  wrote:
> 
> In https://github.com/whatwg/html/issues/192 we're planning on
> removing mediagroup/MediaController from HTML since other than WebKit
> no implementations appear interested in implementing these features.

Hi

is removal really the right thing to do, given that we have an implementation?  
I can understand a note saying that this interface is not currently broadly 
implemented, as a warning to authors.  If there are technical problems, and we 
have or can imagine a better replacement, I can imagine deprecation as a 
warning to both implementors and authors. But making an implementation become 
undocumented seems strange — and as a point of practice, would seem to deter 
implementors from being first-to-implement of something, or they might get 
caught like this. That’s not a good incentive.



David Singer
Manager, Software Standards, Apple Inc.

Re: [whatwg] Removing mediagroup/MediaController from HTML

[Domenic Denicola]

From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of

> is removal really the right thing to do, given that we have an
> implementation?

I agree this is a problematic question. I opened 
https://github.com/whatwg/html/issues/209 for the more general issue but am 
happy to have the discussion here since that hasn't gotten much replies. Do 
check out the examples listed there though. E.g. Blink is in similar situations 
with  and HTML imports.

The web seems to end up with a lot of APIs like this, where the spec ends up 
just being documentation for a single-vendor implementation. I don't really 
know what to do in these cases. If our goal in writing these specs is to 
produce an interoperable web platform, then such features seem like they 
shouldn't be part of the platform.

> as a point of practice, would seem to deter implementors from being first-to- 
> implement of something, or they might get caught like this. That’s not a good 
> incentive.

I'm not too worried about this. Implementers *should* be wary of implementing 
something alone, with no other vendors interested. Getting stuck with the only 
implementation of something is not good no matter what; having such features 
specced doesn't really make things better if you get caught in that situation.

Going forward we can be more vigilant about this, and not add things without at 
least interest from two vendors, and preferably commitment to implement.

The harder case is not about new features and who ships first, but about old 
features which only ever have one interested implementer, with no sign of that 
changing.