CUNY Academic Commons

Definitely going to get this done! And I'll use this ticket for updates moving forward.

Great -- thank you, Michael!

I've created a Commons Live blog to host live streams, tutorials, and eventually archive past videos:

http://live.commons.gc.cuny.edu

There was a bit of sorting out for myself how embedding a live stream works based on the method figured out by Tim Owens:

http://www.timmmmyboy.com/2011/08/streaming-live-video-without-ads-for-pennies/

So I built a page that has only the code for streaming, for review and testing purposes on my site:

http://live.michaelbransonsmith.net/

There's three parts to making this work: the Wowza streaming server, the encoder, and the embedding of the stream.

Wowza is probably the best known streaming software out there right now as it's able to deliver any kind of stream to any kind of client. It's pretty expensive to buy, so for this pilot we're using my Amazon web services EC2 account to do this. It's really, really inexpensive so I'm happy to do it. All I do is fire up an virtual server instance when someone wants to stream and turn it off when they're done. It only costs 15 cents an hour while running, so even if it's started up hours in advance I'm not worried. If the pilot turns out to be successful, we can move toward purchasing the software and setting up our own server.

The encoder is the software on the video source computer that will be sending a stream to the Wowza server. There are a number of options and I use Wirecast bought by York College, but it's a little expensive as well. Adobe's free Flash encoder works perfectly fine and we can have it installed on encoding computers during the pilot. I'll also create a tutorial for how to set it up to send the stream to the Wowza server.

Last is the methodology for embedding the stream into a web page. This is what I'm hoping we can do right now on the http://live.commons.gc.cuny.edu site. Embedding uses the free (for orgs, edus, and govs) JWPlayer which is a Flash and HTML 5 video player:

http://www.longtailvideo.com/players/jw-flv-player/

A site needs to upload the shockwave player 'player.swf' and a javascript used in the header to parse which client is requesting the stream, 'jwplayer.js.' Then there is a javascript used in the HTML body to customize the player on the page and point to the Wowza server:

http://www.longtailvideo.com/blog/17376/live-streaming-using-wowza-ec2

The source code for my sample page http://live.michaelbransonsmith.net illustrates these three parts. You'll see an image by default when there isn't an active stream, so I'm planning to create something for the Commons. Also, I used the latest JWplayer which is supposed to now point to the HTML 5 player on Android devices, but we'll have to test that out.

The Commons has one plugin that uses JWPlayer, Wordtube, but it's for embedding uploaded media files. It does install the player.swf and a javascript to query clients but it doesn't work for streaming. We could install on the Commons the plugin made by the authors of JWPlayer http://wordpress.org/extend/plugins/jw-player-plugin-for-wordpress/ , but we will still need a method to allow for the embed javascript in the body of the post.

For the sake of pilot, the easiest thing would likely be to upload the player.swf and jwplayer.js files to the Commons Live blog, and create a method for allowing the embed javascript, a shortcode maybe?

Thanks, and looking forward to doing some live streaming on the Commons!

Thanks, Michael -- I'm excited about this. I believe I'll have some grant funding to pay for the software, so can you email me a budget for your dream setup? We want the best possible set-up for some high-profile events that will be coming along . Many thanks.

Will do. I'll work with Danny on that part, he's been looking to figure it out for York as well.

Matt/Boone,

Any chance we can look at the javascript issues that will allow for JWPlayer embeds while pricing a Wowza solution? I would then be able to test with my stream in the meantime.

- Michael

Any chance we can look at the javascript issues that will allow for JWPlayer embeds

Which issues are you referring to?

There are three parts to allow for the live stream JWPlayer to be embedded:

The 'player.swf' has to be uploaded to the Commons site.

There is a javascript in the header 'jwplayer.js' that looks at the client making the request and sends either the HTML 5 or FLV stream.

And there is an embed javascript used in the body of page/post to customize the player display and points to the stream source.

Looking at the source on my sample page illustrates all three:

http://live.michaelbransonsmith.net

And the earlier post points to links to documentation about the JWPlayer and Wowza live stream embeds.

JW Player - http://www.longtailvideo.com/players/jw-flv-player/
Wowza embed javascripts - http://www.longtailvideo.com/blog/17376/live-streaming-using-wowza-ec2

Thanks for the summary, Michael. (I'd gotten a bit lost in the above.)

I've added Dom as a watcher here, as I'd like him to write the plugin that will be required. Dom, this'll involve the following:

- the plugin directory should contain the proper asset files (player.swf, jwplayer.js)
- the plugin should enqueue the jwplayer.js script when appropriate
- you should register a shortcode to inject the script into the post itself. Something like: [livestream src="http://foo.com"], maybe with some optional height/width params. See https://codex.wordpress.org/Shortcode_API for more info on shortcodes; you may also want to look at how Ray implemented the Google Docs shortcode plugin, to get a sense of how the callbacks work IRL https://github.com/castiron/cac/tree/master/wp-content/plugins/google-docs-shortcode

Dom, I know you're working on a list of other priorities. Can I ask you to slot this one ahead of 412 (Featured Themes)? I have a feeling that 412 is going to be a doozy, and it would be nice to get this one out of the way so that Michael can have at it.

Thanks Boone for planning this out, and looking forward to tinkering with the plugin Dom.

Boone, Michael,

I've started a very basic plugin that replicates the functionality of http://live.michaelbransonsmith.net. The plugin provides a shortcode that embeds all the javascript needed to accomplish the live streaming. The shortcode will accept the following attributes (defaults included):

[livestream width="800" height="500" image="balloons.jpg" autoplay="true" file="" streamer=""]

However, the only required attributes are:

[livestream file="" streamer=""]

Boone, are you going to push this to cdev for Michael to test out?

Michael, let me know what works and what doesn't. I've purposefully left the plugin simple, going through your links above I found the jwplayer page that outlines all the various options available. Let me know what features you'd like added/removed after testing out the functionality.

commit: https://github.com/castiron/cac/commit/857ff2daaae5f40c6348df3437bad1173ee08d67

Dom, the plugin is beautifully simple. Thanks.

Michael, I've put it onto cdev. To test, go to a cdev blog where you have admin rights (or create one) and activate the new "CAC Livestream" plugin. Then use the shortcode in the way Dom describes. Do let us know if there are issues - the fact that you'll be testing on a site that is locked down by Apache (with the username/password you've got to log in just to get the page to load) may cause unexpected issues.

It's working in the browser Dom, exciting! But not mobile (HTML 5). :(

I'm running a test from my office at:

http://live.cdev.gc.cuny.edu/

And I think the problem is that the jwplayer.js script is being placed in the body of the post, when it needs to be in the header to allow the client query as the page loads. That's the difference I see between the plugin's placement of the script versus my sample page:

http://live.michaelbransonsmith.net/

I also customized the dimensions and background image which worked flawlessly. Great work.

- Michael

Glad to hear it's already working well. You could be right about the placement of the jwplayer file. However it could also be the fact that in an attempt to keep things simple, the embedded code is currently hard coded to flash inside the plugin.

Let me update that code a little to allow for more flexibility in the formats and then we'll know for sure whether or not jwplayer has to be in the head.

I'll get some new code up asap.

Sounds good regarding the additional tweeks, but I'm pretty sure the jwplayer.js file needs to be in the head based on my discussions with Tim Owens some time back.

BTW, you can see my typing this right now! :)

http://live.cdev.gc.cuny.edu/

HA! that's awesome!!! :-)

OK, I spent some time in the configuration section of JWPlayer's support docs and I think I've worked out the issues initially experienced with mobile HTML5 video.

Specifically, this page helped me get the HTML5 functionality working the way I believe we want this plugin to operate. JWPlayer embraces the idea of graceful degradation. The plugin now outputs an HTML5 video specific structure and JWPlayer's setup() method handles falling back to flash if the browser doesn't support those features. It's actually quite a powerful player! I've also adjusted some of the shortcode's attributes to try and make them a little more descriptive. Here is an example of the shortcode you can place into a page (with the plugin's defaults listed):

[livestream
  width="800" 
  height="500" 
  image="(right now this defaults to the balloons pic)" 
  autoplay="false" 
  mp4file="" 
  flashfile="" 
  flashstream="" 
]

I switched autoplay to false by default cause there might be a lot of situations where a computer is connected to a projector/audio system and the user may not want the stream to start until they're ready.

HTML5 video works by passing an MP4 file path to the <source> attribute of the HTML5 <video> tag. If this is defined in the shortcode, JWPlayer will use it. If not defined, then JWPlayer needs the "flashfile" and "flashstream" attributes. When all three of these tags are included in the shortcode JWPlayer will try to play the HTML5 video first and then gracefully degrade to flash if HTM5 is not supported.

Michael, two things: I've tested this on my local install using the following shortcode:

[livestream
  width=880
  mp4file="http://content.bitsontherun.com/videos/a95zAVN1-600331.mp4" 
  flashfile="myStream.sdp" 
  flashstream="rtmp://23.23.204.139:1935/live"]

That mp4 url points to one of the example videos used on the pages of JWPlayer's docs. What we need from you is an mp4 file on EC2 that corresponds with a live stream. Once that's in place we can test further to make sure my code is actually pulling in what it's supposed to. The above example shortcode will play the HTML5 video in Chrome and then if I remove it and reload the page, it loads the flash stream.

One final thought. The plugin still does not load jwplayer.js in the <head>. There are two reasons I am pushing back against your suggestion to move it.

1.) All of the JWPlayer docs show this file being included right along with all the other code in the middle of a page, and the HTML5 video is now loading in chrome on my machine.

2.) I am having some difficulty finding an appropriate hook that will load this file only on the page dedicated to live streaming created by the user. If this revision still doesn't work on your phone, let me know and I will figure out how to get it in the <head> section. I have a feeling this is going to work though. :-)

Let me know how it goes on your end.

Latest commit: https://github.com/castiron/cac/commit/1d13a3561c16694b1d4a33c519e195d6372078d7

Hi Dom,

I'll test it out based on my best understanding of how the streaming works. Can you re-install the plugin on the dev site? I can't seem to find it.

Boone will need to push it up to cdev for you, I don't think I have access to that.

Hi gang. I've pulled the latest version of Dom's plugin to cdev.

We have success! Working on both iOS and the browser.

http://live.cdev.gc.cuny.edu/

We should probably set up a time to test other clients on a variety of devices.

Thanks Boone and Dominic this is going to be a lot of fun to bring to the Commons!

Awesome!! I've got an older Samsung Prevail from Boost that I'll test on when I get a chance. Will let you know if I run into any issues.

I'm so glad it's working!!

Boone, should this little plugin get its own spot on the Commons Github repo? I know it's kinda specific to our site, but the code could help others with getting JWPlayer working on their own site.

Let me know.

Can't wait to check this out. Many thanks to you all!

Boone, should this little plugin get its own spot on the Commons Github repo?

Great idea. Please check to make sure that the packaged libraries are licensed in such a way that we can release under a GPL. (If you're not sure, ask :) )

Also, let me know what you want the repo to be called, and I'll create it.

This is so great Boone and Dom, Tim Owens is going to be so excited for this one too!

I think we should just call it cac-livestream since that's what it was designed to do. It's not a general purpose player so something like cac-player would be a little disingenuous, and we'd have to build it out some more to cover more edge cases of JWPlayer.

I'll check out licensing and write up a little readme and let you know when its ready to push up.

Sorry if this throws a wench in things but I've been looking at players for one of my classes and noticed that jwplayer is not open source. I found one that looks like it works well and is:
http://mediaelementjs.com/
It's gplv2 and on github
https://github.com/johndyer/mediaelement/

I don't know if it would be too hard to swap out jw player for this and it means more work for you Dom.

I have a friend at expo.tv who raves about mediaelementjs.

Dodging wrenches is what being a developer is all about, so (Michael / Boone) let me know if you'd like me to investigate pros/cons of switching.

JWPlayer appears to be free for non-commercial, which is fine for us to use, but could cause headaches if we're distributing this plugin - either through Github or the WordPress Plugin Repo.

Thanks for looking into it, Chris.

Dom, spend a few minutes with mediaelement to see how hard it would be to switch over. If it's super easy, just do it. If it's moderately difficult, we can post the current version on Github, sans jwplayer, with notes in the readme file about how to download it for yourself.

JWPlayer appears to be free for non-commercial, which is fine for us to use, but could cause headaches if we're distributing this plugin - either through Github or the WordPress Plugin Repo.

This is correct.

Understood, I'll check in as soon as I've got an answer.

You might want to look at the terms used by the creators of Wordtube, a plugin that uses the JW Player and we use on the Commons.

http://wordpress.org/extend/plugins/wordtube/

Also look at this plugin as the creator talks specifically about GPL issues.

http://wordpress.org/extend/plugins/stream-video-player/

I tried to make mediaelements work the same way we have JWPlayer working but I can't get it to load a stream.

Michael, there is a media elements plugin for WordPress: http://wordpress.org/extend/plugins/media-element-html5-video-and-audio-player/. Have you tried it yet?

The links to those other JWPlayer plugins seem to follow Boone's advice above - don't distribute JWPlayer and provide instructions for how to download it and install it with the plugin.

Please let me know what you guys think the best direction is to go from here. I will keep working with medaelements if we want a pure GPL2 package or split up the current JWPlayer implementation. It seems to me that if this particular plugin is just for streaming JWPlayer may be the way to go?

I tried using the mediaelement.js plugin on my site – http://mbsx.org – but could only get the html player to work , but not the fallback flashplayer. I'm not sure how to figure that one out, but I imagine it could be done.

So I can't say what the right answer to this one is. I know that jwplayer works, but possibly mediaelement could be made to work as well.

Thanks to all for your testing.

I'm going to make the call here that, for the moment, we'll do the following:

1) On the Commons, go ahead with the jwplayer implementation, which is known to be working.
2) For the Git repo, let's go with the jwplayer implementation for now, but exclude jwplayer itself. Put a note in the documentation explaining that jwplayer can't be included for licensing reasons, and give brief instructions on how to download and set it up.
3) In the medium to long term, it may be worth spending some time with mediaelementjs to see if we can get a fully free working copy. But for now, let's back burner this, as I don't want to monopolize too much dev time for something that is, for all intents and purposes, working fine already (with jwplayer)

Any objections?

Sounds like a good plan, this will allow us to move on to conversations about getting people in the Commons community access to the stream, create tutorials, etc.

Thanks Boone.

Sounds good to me too. Do you think we should contact the developer of mediaelement and see if he's interested in taking a look?

Great plan. Thanks, Boone.

Just sending out a reminder to bump up the installation of Dom's plugin to the Commons. So we can do some streaming this fall, instead of waiting for the 1.5 release which is scheduled for January.

Dom, are there tickets related to this one? If so, can you add the through the "related issues" interface above? Many thanks.

Matt,

I searched Redmine for "live," "stream" and "video." There were no results. I believe this is the only issue related to streaming a live feed through the Commons.

Boone,

Since the plugin I created for this is already in master, it should be in the 1.4.6 release.

I assume that we want to keep this issue open for a little while, until we've verified with Michael that it works on the prod site.

I'm thinking we should punt it to 1.4.7 or 1.4.8. Let me know what you think.

Dom, could you go ahead and merge the topic branch into 1.4.x, to make sure it goes out in this release? Thanks.

Also,

I'm thinking we should punt it to 1.4.7 or 1.4.8. Let me know what you think.

Let's keep it in 1.4.6 and mark it Resolved. That way, when we look back on the milestone in Redmine, we'll see that it was indeed part of the 1.4.6 release. If there are problems with the plugin after it goes live, let's open new tickets.

I kinda jumped the gun on this one when I was cleaning up topic branches and have already removed it both locally and on Github.

My assumption was that you always merge to master before pushing a release. Is this not correct? The plugin is in master:

https://github.com/castiron/cac/tree/master/wp-content/plugins/cac-livestream

Since I now know git cherry-pick I could do this:

git checkout 1.4.x
git checkout -b cac-livestream
git cherry-pick "RELEVANT" 
git cherry-pick "COMMITS" 
git cherry-pick "FROM" 
git cherry-pick "MASTER" 
git checkout 1.4.x
git merge cac-livestream
git branch -d cac-livestream

As soon as I know what you want me to do I will mark this as resolved so we can open new tickets in the future if needed.

My assumption was that you always merge to master before pushing a release. Is this not correct?

Yes. But this doesn't mean that the plugin is in the 1.4.x branch. There are other ways that code can get into the master branch, though.

Go ahead and carry out your cherry-pick plan. That looks great.