As we announced previously, 4Site has just released HubDub, a Drupal module that leverages the jPlayer framework and Popcorn JS to overlay web content—such as social media, maps, or web forms—directly onto a video as it plays. So... how does it work?

Storing the Data

The Drupal end of HubDub is relatively straightforward. All of the information about a video is stored in a fieldable custom entity, called HubDub Video. Apart from the usual metadata like title, description, author and a unique identifier, what do we need to keep track of? First, we need the location of the video itself. HubDub needs direct access to an M4V video file (or a live RTMP stream), so we store its location in the URL field. A planned enhancement will let this URL be the actual Vimeo (and eventually YouTube) sharing URL, which is a lot easier for end users to find. The module would then parse out the actual video file location.

For each overlay, we need to track the start time, end time, and the content of the overlay. We could have used Drupal’s built-in field types inside a field group for this, but that can get messy for unlimited fields, so we decided to create a custom HubDub Overlay field type. As a former TV engineer, my first instinct was to use something like SMPTE timecode for the time fields. But jPlayer can’t place overlays with anything approaching frame accuracy, so we went with two simple integer fields, representing the elapsed time in seconds since the start of the video. To make it easier to deal with overlays in longer videos, especially now that HubDub supports live RTMP streaming, we’ll probably use a field formatter (such as the HMS Field module) to display these fields in hours:minutes:seconds.

The overlay field is a textarea, using Drupal core’s Filter module to format the text for display. Allowing custom CSS, Javascript, and jQuery inside overlays opens up some awesome possibilities… and also some not-insignificant security issues. So by default we allow only the Filtered HTML text format, but the administrator can change this for trusted users.

Finally, to declutter the edit form, we provide an administrative title for each overlay, and collapse the field by default.

Displaying a Video

Okay, we’ve now got all of the information about a video stored in Drupal’s database. Now how do we display a video? Well, first of all, where do we display it? By using Drupal’s Entity API we get a page display for each video (almost) for free, but we wanted to give site owners the flexibility to place videos wherever they wanted, so automatically creating a block for each video was a no-brainer.

I’ve created lots of blocks in code before, but I’d never done so dynamically for all instances of an entity type before. It was a lot easier than I expected, as I learned from looking through the Views module. In the hook_block_info() implementation I load all the HubDub Video entities, then iterate through them with a foreach and add each video to the array. Then, in the hook_block_view() implementation, it’s just a matter of calling the callback with the right delta. There are still a few to-dos here, namely dealing with entity titles longer than 32 characters, and adding some caching for performance.

The page callback and block callback are almost identical. Pages need a title, so the page callback sets it, then it and the block callback each call the same display function, hubdub_view_video(). That function loads the HubDub Video entity, then dumps all of the metadata fields for that entity into Drupal's Javascript Settings array. Next, it iterates through all the values of the Overlay field and adds each overlay to the Settings array. Then everything gets passed to a theme function, which loads the tpl.php file that contains the div structure that jPlayer needs, and creates a series of hidden divs with the contents of each overlay. Finally, we attach some CSS, and the Javascript, which is where all the real magic happens. Look for a follow-up post in the coming days on the Javascript side of HubDub.

What’s Next?

The initial release of HubDub is our “minimum viable product.” It works, but there’s so much more we have planned. A few of the things on our roadmap:

• More granular access control for CRUD operations. Right now, all HubDub actions are controlled through one global “administer hubdub” permission. We’ll soon be adding the Drupal standard edit/delete own/any permissions.
• Support for additional video providers, including YouTube, and non-m4v file formats.
• Greater cross-browser HTML5 support.
• Additional jPlayer options, configurable through the admin UI.
• Media module support.
• More user-friendly support for skipping to another point in the same video, or branching to another video, from within an overlay.
• Better support for overlays on live streams. Right now, overlays are timed from the start of playback, but this doesn’t make sense for live streams. We’re considering just using the server time in hours:minutes:seconds, but we’d love to hear potential use cases and their requirements.
• Eventually, a more user-friendly way of adding overlays. We’re considering a video player on the edit form, with a button in the player controls to add an overlay at the current playback point.

We're eager to hear your feedback! Please post bug reports, feature requests, and support questions in the HubDub issue queue.

We have even more details to share on how HubDub works under the hood, so stay tuned over the coming days. If you'll be attending the Nonprofit Technology Conference next week in Austin, stop by our booth (#214)! We'd love to chat and give you a demo. If you’re interested in a custom HubDub solution, integration with your CRM or AMS, or video production or editing services, please contact us.