On Tue, Nov 3, 2015 at 4:20 PM, David Singer <sin...@apple.com> wrote:
>> On Oct 3, 2015, at 13:39 , Silvia Pfeiffer <silviapfeiff...@gmail.com>
>> On Fri, Oct 2, 2015 at 10:27 AM, Domenic Denicola <d...@domenic.me> 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 <dialog> 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.


Reply via email to