DIY: Private Video Sharing for a school, a district, or an organization

I've been involved in a couple conversations recently about setting up tools within institutions to maintain video archives. Andy Rush wrote up a post describing some great work integrating Wordpress and Mediawiki; and on a listserv discussion about tools for sharing video, I mentioned that this could be done using Drupal. My remark prompted Miguel Guhlin to ask The Question: How would you do it?

So, here are a few ways to get this done. As with any technical solution, the best approach will be determined by the combination of an organization's mission and their technological resources. At the risk of stating the obvious, all the tools discussed in this post are Open Source tools, and available under a GPL or LGPL license.

The Problem: Create a video sharing tool within the Walled Garden, or behind a District firewall.

Create the video:

Creating video can be done using a variety of well documented methods and tools. For this step, the format is of secondary importance, as a video, like any other file (ie, an image, or a link to a downloadable pdf) can be accessed from a web page very easily.

However, we don't want to see this:

We want to see this:

Displaying video within a site

The next question that needs to be addressed is whether the video would be compressed from the original format to FLV format. FLV videos are generally smaller than other types of video files, so displaying movies as FLV files can reduce the amount of bandwidth consumed while moving and viewing video files. However, setting up the tools that convert video to FLV makes for a more complicated setup, and require more in the way of server resources (specifically, memory and processing power). So, in making this choice, one should consider how much video will be stored and viewed, and where an IT system is strongest. If a district has ample bandwidth but is low on tech support personnel, then setting up a system that doesn't convert video to FLV would be an acceptable compromise. In working with people to match solutions to their teaching and learning needs, I tend to advocate for the simplest solution possible, as, in general terms, simpler usually translates into fewer things that can go wrong.

So, we'll look at examples that embed video without conversion first, and at examples that incorporate FLV conversion second.

Section 1: Display video without conversion

For embedding content into a web page, there are some good options available using Wordpress, Mediawiki, or Drupal.

For Wordpress, the Podpress extension works nicely, with a good balance between features and ease of use.

For Mediawiki, there are a range of extensions handling many kinds of media, including different types of video files. Unfortunately, in the last few days, a few of the extensions for embedding YouTube or Google Video into Mediawiki expose the site to cross site scripting (or xss) vulnerabilities. But, given that we are talking about a site that explicitly cuts YouTube and Google Video out of the picture, that's not much of a concern for us. Also, even with the few affected extensions, there are still several secure options for embedding video using Mediawiki.

Drupal also provides several options for embedding video. The Video Module, the Video Field Module, the Media Field Module all solve similar issues. For this use case, I would recommend either the Video Module of the Video Field Module, as they both install cleanly and, as of this writing, are under more active development.

Given that these three options all do similar things, here are some things to consider when choosing one tool over another:

  • How many people are using video?
  • How much content is getting created?
  • Will the video be re-used in any way?
  • Is it important to be able to display the video in different contexts?

While Wordpress is probably the simplest solution, it provides the fewest options for flexible reuse and redisplay of video over time. Wordpress, not surprisingly, does a great job of showing a progression of content over time. If, for example, teachers are posting student video, then Wordpress would be where I'd start. Like many blogging platforms, however, tracking and organizing even moderate amounts of content over time can be difficult.

Mediawiki provides good options for embedding video and subsequently reusing it in different contexts. Mediawiki is great at providing a collaborative space that highlights content; however, Mediawiki, unlike blogs, does not organize content chronologically. Unlike Wordpress, where a blog post can effectively be owned by one user, content in Mediawiki is accessible and editable by a wider range of site members. While this can be restricted by use of access control settings in Mediawiki, setting up and using access controls over pages in Mediawiki is not intuitive (at least not relative to the other options being discussed here).

Drupal provides a middle point between the group editing capabilities of Mediawiki, and the personal ownership of Wordpress. Additionally, Drupal provides flexible options for sorting through and displaying content. Drupal's flexibility is simultaneously its greatest strength and most formidable barrier; the amount of options available (both in the form of contributed modules and administrative features) can be overwhelming. In rolling out Drupal sites, we stress the need for (at minimum) two types of users on the site: the site maintainer/site admin role (aka, the geek who is comfortable working with the options) and the user (the person who just wants to get their work done and go home). By the way, if you're still reading this post at this point, you're probably more of the former. In rolling out a Drupal site, you need to spend some time using Drupal's flexible menu structure to present a simple user interface (UI) for your users. This way, the main users of the site can do their work without having their screen cluttered with unnecessary and potentially confusing options.

Section 2: Enter the Compression!

Compressing videos requires FFmpeg, a linux utility for compressing and converting video formats. The methods for doing this are well documented. However, among the documentation describing how to do this there are cries from the frustrated, the confused, and the downright angry. So, if you are going down this road, you should be reasonably comfortable working in Linux; a term such as "apt-get" shouldn't throw you, and this should make you laugh.

Installing FFmpeg

You can install FFmpeg on Fedora using yum, and on Debian/Ubuntu using apt-get -- more info here.

Or, if you don't want to deal with these issues at all, host the video conversion with an ISP -- Cirtex hosting packages come with FFmpeg installed and accessible. You can also install FFmpeg at Dreamhost. And no, I am not affiliated with either of these companies in any way, shape, or form.

Uploading, Compressing, and Displaying Video

Using Wordpress: phpVideo will get the job done.

Using Drupal: Two options exist at present, and a third bears mentioning.

Option 1: FlashVideo -- the flashvideo module allows users to upload videos which are subsequently converted to FLV format and available for display. Full instructions by the author of the module are available here.

Option 2: Media Mover -- this module allows users to upload videos that are subsequently converted into FLV files and moved to a separate storage location; in the case of the module in its current form, it stores the converted files on Amazon S3. This module has the capability to be a fairly robust tool to run large scale video and audio sharing via the web. The advantage of managing this functionality within a tool like Drupal is that Drupal allows for very flexible presentation and access restrictions to content. However, if users within the Drupal site wanted to make these files available for embedding in other platforms (such as Wordpress or Mediawiki), that would also work. So, using either FlashVideo or MediaMover, a district could support embedding media as described in section 1. In this specific use case, however, the district- or organization-controlled video repository has replaced Google Video or YouTube.

Another option worth mentioning: SWFTools. This general use module provides a framework for embedding Flash content into web sites. This module is under active development by a strong programmer, and has the potential to simplify using flash and flv files within Drupal sites.

Closing notes:

  1. The setup of the systems described in this post requires some technical expertise. If it was easy to build a video management system, everybody would be doing it. However, in working with a system like this, it's necessary to emphasize that the complexity of the setup does not translate into a system that is difficult to use. On the contrary: we want the complex setup to be handled by technical folks (aka, the geeks) so that the end users don't need to worry about it. The end user can show up and use the system. The technology isn't the point; supporting learning is.
  2. Converting video and serving video files requires a solid infrastructure, both in terms of server resources and available bandwidth. If video is a big part of your educational program, make sure you have the infrastructure to support it.


Thanks for the post. Since it has been almost 4 years since your post, what would your recommendations be now?

Thanks in advance for your time.

In general terms, I would look at media players/options that supported HTML5, and degraded to flash where HTML5 wasn't supported.

For a Drupal-based option, I would recommend using the Media module, as that provides the most flexible options moving forward.

I'll probably do a follow-up post at some point over the next couple months that will go into more detail.

Add new comment

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
To prevent automated spam submissions leave this field empty.
This question is for testing whether or not you are a human visitor and to prevent automated spam submissions.