plugin player takeover

[jeroen]

Plugins should be able to be "on top of" the player, both in terms of z-indexing and in terms of controlling the event flow.

[jeroen]

Some use cases from Pablo:

• Overlay above video space in fixed or relative position
• Take over entire player area (including playlist and control bar)
• Take over a portion of the video display space, shrinking display (like YouTube's recommendations)
• Dock as control bar icon
• Dock in sidebar overlay (vimeo-style) or in left/right area
• Carve out space to one side of the player (I don't think this is used, with the exception of our own metaviewer plugin)
• Headless - plugin has no display elements

[jeroen]

Some more use cases (more event flow):

• The controlbar should always be on top, so above plugins such as captions.

• A preroll plugin will want to interrupt the playback flow (autostart), until it has checked for ads.
• When available, the ad should be displayed on top of the stack.
• While the ad is playing, the API should not be able to start/stop the regular video.
• When the ad has played (or is clicked), the regular event flow must be reset (autostart?)

• A video-midroll plugin will want to pause the video and intercept the event flow.
• The ad should be displayed on top of the stack again.
• When the ad has played (or is clicked), the regular event flow must be reset

[jeroen]

Phil:

Overlay ads need to be on top of z-index stack * need special handling in fullscreen/controlbar=overlay modes (controlbar currently inserts itself on top of stack, so often need to do crazy stuff like "view.getPlugin('controlbar').clip.parent.swapChildren()" * similarly, fs/overlay modes require repositioning of the overlay due to the disappearing/reappearing on-hover behavior * fullscreen positioning also requires some additional workarounds in 4.4+ due to the screen size comparison

Video ads often take over the whole display area * again the controlbar=overlay case requires circumventing to maintain z-index * video controls are often covered with a transparent tile to fake 'locking' of the controlbar * similar cover is occasionally required for the playlist when it is present * control locking usually includes: play, pause, timeline scrubbing, and next/prev video change (since fullscreen is still expected, covering the controls is an inelegant solution); does not include mute/volume/fullscreen

Video playback flow is reacted to, instead of controlled. Have to race against events to interrupt playback and prevent restart until after the ad * e.g., ltas & pre-roll ads will need to interrupt autostart * also, some ad systems require video metadata before we can load ads, regardless of ad type (e.g., adsense overlays require playback interrupt); again, we wait for metadata event and race against play events (sometimes multiple video frame slip through)

It would be nice to have a locking system that can be signaled (e.g., tell controller not to send view events until unlocked). The controlbar has a block() method which is similar, but doesn't solve all of the problems (scrubbing still possible when blocked, z-index placement is unaffected, also no visual indicator that play/pause are disabled)

Lastly, the ad plugin load is now guaranteed to occur before playback starts, but availability of the ad SWF is not guaranteed (usually, ad plugin downloads the ad logic from ad-server); perhaps not optimal, but a way to block playback until ad SWF load occurs might be useful to prevent this timing case.

[jeroen]

We could setup a single takeControl() function that'd do two things:

1. Move the plugin to the top of the z-index
2. Route all View events to the plugin (not to the browser)

[pablo]

For now, the player offers a single locking mechanism, player.lock(). This can be called by plugins at any point from initPlugin() onwards. The plugin receives a callback after locking is successful. If the player is already locked when lock() is called, the lock request is placed in a queue; the callback will be called when the previous locking plugins have released the lock using the player.unlock() method.

While the player is locked, all playback-related calls are ignored by the controller. After unlocking, the controller will resume the playback state the player was in prior to locking.

In future versions, there may be an additional methods available to locking plugins, such as a way to cover the player controls with a semitransparent sheet, changing the way the UI controls look while the player is in a locked state, or a mechanism to place the plugin at the top of the display stack.