- From: <bugzilla@jessica.w3.org>
- Date: Mon, 08 Apr 2013 21:33:51 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21333
Aaron Colwell <acolwell@google.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |LATER
--- Comment #15 from Aaron Colwell <acolwell@google.com> ---
(In reply to comment #14)
> Unfortunately a publisher doesn't always have a lot of control over the ad
> provider.
>
> While often a publisher will use "1st party" ads that they encode (meaning
> they can make sure its matches their content), almost all publishers have a
> lot of unsold ad inventory in their streams. Publishers will use ad
> networks and other 3rd-party sources of ad content to fill the remnant
> inventory.
>
> When using a 3rd-party source for ads the publisher has no connection to the
> ad provider, and no way to enforce that the ad content matches the primary
> content. These restrictions will essentially make it impossible to use
> 3rd-party sources for ads.
I think this is a little overstated. These restrictions simply keep the status
quo for what is currently possible with HTML5. If the Ad networks and
publishers don't coordinate their efforts then, yes, they don't get the
seamless splicing benefits that MSE can provide right now. If they do work
together, then they can benefit. I think this is a reasonable compromise for a
v1 since we enable some improvements, but don't necessarily improve every
conceivable possibility.
I think it is important to get an initial version of the spec done and gain
implementation experience before we add more complexity by easing these
restrictions. Also there is nothing stopping people from experimenting with
extensions to MSE that do what you want. I just don't think it belongs in the
v1 spec.
--
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Monday, 8 April 2013 21:33:53 UTC