Support for Player V3

Hi..

You can refer below link :-

http://support.ooyala.com/developers/documentation/concepts/player_v3_de...

Attached a patch to use the V3 way to embed the player.

A few things:

• There's a new field on the settings page for the Player Branding ID, it wouldn't work without it.
• If you can't find the Player Branding ID in your backlot, use the scratchpad and call /v2/players to find the id
• The additional params are in a valid javascript, but invalid JSON format, so the $params is handcrafted with only width and height support for now

There is definitely more work to do, but I am hoping at least this gives us a starting point to open a new branch for v3.

+++ b/ooyala.moduleundefined
@@ -865,10 +866,12 @@ function theme_ooyala_player($vars) {
-  return '<div id="' . $vars['params']['playerContainerId'] . '"></div><script type="text/javascript" src="http://player.ooyala.com/player.js?' . htmlspecialchars(drupal_http_build_query($vars['params'])) . '"></script>';
+  $params = '{width: ' . $vars['params']['width'] .', height: ' . $vars['params']['height'] . '}';
+
+  return '<div id="' . $vars['params']['playerContainerId'] . '"></div><script type="text/javascript"> var videoPlayer = OO.Player.create("' . $vars['params']['playerContainerId'] . '",' . '"' . $vars['embedcode'] . '", ' . $params . ');</script>';
 }
 
 /**
-- 
1.7.9.6 (Apple Git-31.1)

I think this line needs to be something like $params = json_encode($vars['params']); or drupal_json_encode().

Otherwise you're not allowing other modules to add additional paramaters to the OO.Player.create() call.

Powered by Dreditor.

That's what I had at the beginning, but Ooyala doesn't know how to read the JSON. The issue is json_encode creates {'width': '123', 'height': '123'} instead of {width: 123, height: 123}. Ooyala needs to read the second format, which is technically invalid JSON but valid JavaScript.

I've passed the feedback about player.onCreate along to Ooyala so we'll see what happens there.

Another thing to point out is that we might want to make the entire player URL configurable not just the playerID portion of it. The reason being you can pass in additional paramaters to the URlL like ?version={{VERSION}} or ?debug=true

So maybe a textfield for 'ooyala_player_id', and one for 'ooyala_player_url'

I made a start at this, provided by the patch attached.

I've noticed we have numerous places depending upon the old API, i.e. ooyala_merkers module, that will need to be updated to use the new subscriber "bus" model. The new API is nicer, IMO, but currently still pretty buggy.

Oh, as implied by the patch, I had started to make this be a backwards compatible system for existing users who want to stick with the v2 player. Of course that means we'd need to abstract out any use of the API to use both v2 and v3 players.

json_encode creates {'width': '123', 'height': '123'} instead of {width: 123, height: 123}

This is only true if '123' is a string, rather than an integer data type. I'm pretty sure it gets formatted correctly assuming it the right type. We can manually set these to ensure they're correct.

Hiya @torgosPizza! Glad to know you're still following this issue.

EDIT, also I'm not seeing any admin config form to set the 'ooyala_player_version' so I've added that as a textfield in ooyala.pages.inc.

Sorry I was going to post a new reroll today. My patch is ON TOP of makangus's patch in #4.

I feel like this should be a per-node-type field as well. Maybe instead of using a variable, we make a new field available to content types?

I think you're right that more control over players is necessary. I believe it's also possible to pull the player ID from backlot on a per-video basis. It seems like that would make a lot of sense rather than asking the user what Player ID should be used at all. Or alternatively we can retrieve the list of players and let the user choose the desired player from a list. As you say this could be per-field or per-video. I'm not sure where the right balance is.

Player IDs are a bit weird. For each player you use on the site, you have to give it a separate namespace (see http://support.ooyala.com/developers/documentation/reference/player_v3_d...), which also has the effect of changing the global variables used to access some of the APIs. All of this makes me think using a single "default" player ID for now might be a good starting point to get rolling with the v3 player.

Sorry I was going to post a new reroll today. My patch is ON TOP of makangus's patch in #4.

Actually on further inspection my previous patch is all kinds of messed up. I'm working on a followup patch that does things correctly.

Here's a reroll that adds backwards compatibility for existing users if they need the V2 player (however currently it will switch them to V3 upon patching, maybe we should write an upgrade path?) Really appreciate your thoughts @torgosPizza!

A notice or an upgrade path would probably be good, since it's (as of last time I checked, anyway) required that you contact Ooyala to have V3 configured on your account.

Good point, and more importantly, users *must* enter a player ID currently for the V3 player to work. Since we can't determine that automatically (afaik) we should add an upgrade path that sets the default version to V2 for existing users and leaves the default of V3 for new installs. I'll put on an upgrade hook that simply sets the variable (note this means you'll have to set your player *back* to V3 after running the upgrade).

Here's a patch that adds an upgrade hook that sets the player variable to v2 for existing installs. New installs will default to v3. Backport to D6 also attached. After testing everything functions the same as D7, I've committed the patches to the corresponding 2.x branch.