Embracing the open, despite its flaws... why PEG should learn to love FFmpeg

I feel like I'm posting too often to the group, but there is so much information we are trying to share. Since there is a conversation about FFmpeg on the ACM Announce list and it came up in a call with Austin, I thought I should try to get some of what we've been doing with FFmpeg posted. Most of the discussion on the ACM list has been about applications that wrap FFmpeg up with a graphic interface. That's a great introduction, but to really leverage FFmpeg the PEG community is going to have start developing some collective knowledge about FFmpeg's command line configuration options.

The Open Media System leverages FFmpeg, but Brian Hiatt has had to put a lot of time and effort into modifying Drupal to be able to deal with the large, broadcast quality files the PEG community works with. In addition to large files, Brian invested a lot of reverse engineering and testing FFmpeg settings to generate files that comply with the ACM's (secret) standard for MPEG2. The command line configuration we're using with Media Mover is...

If you aren't using Media Mover, you'll need to replace %in_file and %out_file. This configuration produces a MPEG2 that has worked on both Princeton and Leightronix.

FFmpeg came up last week on our call with channelAustin. Kevin King from Root6 (developers behind the Content Agent encoding wonder box) joined us on the call. The big question we were trying to answer was whether Content Agent had an API/web service other systems can communicate with or is this product going to be a step back to the drop box/hot folder workflow that DOM had been using with the Canopus/Grass Valley Pro Coder? Content Agent offers a number of really nice graphical user interfaces for setting up different workflows, but as far as interfacing with other systems Content Agent is a 'dumb' encoder. By 'dumb' I mean any other system can give it a file, but while that file is encoding the other system is just left waiting. This is 'dumb' like http requests were dumb before AJAX... way back in Web 1.0. Now, asynchronous calls from javascript allow much more functionality than the basic Get and Post requests the web was originally limited to. The same type of improvements in the standards that allowed the development of browser based applications like Gmail, are also available between servers. FFmpeg already supports this type of asynchronous communication with other systems.

The good news for Austin is Root6 is in the process of adding a web service layer to Content Agent that should give us something to work with in the future, but it doesn't look like that interface will be available in March. That means channelAustin will need to run FFmpeg on video being processed through the Open Media System, but will also be using Content Agent to process video entering their workflow through other channels.

It says a lot about me that I could care less who won the Super Bowl, but I'm actually excited about the chance to run these encoding systems side by side.

When comparing open source solutions like FFmpeg to commercial options like Content Agent, there are a number of things to consider to determine which solution is right for you. Legal issues, the pace of change, quality of the user interface, and community vs. 1-800 support are big considerations.

• Legal Issues

  The legalities of using FFmpeg came up during the Austin call. Like most developers, FFmpeg's try to stay clear of the legal discussions in their legal FAQ.

  Whether it's Drupal or FFmpeg's GPL requirements, content with Creative Commons licenses, or patent issues surrounding codecs, legal issues are a common topic of conversation when working with Drupal and sharing media. When you add Fair Use to the mix, there are very few people who can speak with much authority.

  Note that much of this discussion is based on precedent, or what has happened in the past under similar circumstances. Very little consideration is given to what could happen. If you use your imagination, you can visualize any dire scenario and cease doing any productive work.

  When addressing the specific question of using patented algorithms...

  Q: Does FFmpeg use patented algorithms?
  A: We do not know, we are not lawyers so we are not qualified to answer this.

  I'm not a lawyer either, but we are talking to lawyers and people that are much more informed about these issues (like the IP lawyer, PhD, and librarian who authored the upcoming book, Intellectual Property Law and Interactive Media: Free for a Fee). My understanding regarding the specific question of using FFmpeg to encode H.264 version of a video is that if the video being created for personal on non-profit use, there is no need to pay the licensing fees requested by MPEG LA. To my knowledge there is no legal precedent to support either my opinion that PEG stations don't need pay licensing to use FFmpeg or Root6's opinion that all FFmpeg users have to pay licensing fees.

  Attempts to scare customers into paying for commercial solutions instead of moving to open source competitors has been happening since open source has existed. Some of the more memorable licensing scares in the relatively short time I've been working in technology include; Forgent Networks and JPEG, SCO and Linux, and Universal and DeCSS.

  Organizations filling their community's PEG needs should take some comfort in the fact that Archive.org is using FFmpeg to create both Ogg and MPEG4 versions of video. They've been very open their FFmpeg configuration for Ogg encoding, but I haven't found anything about how they've interpreted the MPEG licensing fees. If MPEG LA goes after Archive.org and they end up paying, we'll likely all have to pay for MPEG encoding... unless we move to Ogg Theora.

• Pace of Change

  The development and adoption of new codecs like Ogg happen much faster in open source solutions. IMHO, the basic life cycle of developing software products for profit slows the pace at which improvements are made. The process involves investing in the development and then profiting from that investment as long as possible before investing in the development of a new release selling customers on the benefits of paying for an upgrade. Consider how much individuals and organizations have invested in upgrades to Microsoft Word over the last 20 years. Have we seen substantial improvement in functionality for that investment?

  Open source solution are more about solving shared problems since there is no profit to be made selling the updates. First Google and now the Mozilla Foundation have contributed $100,000 to solving the problem of claims of patented math in codecs.

• User Interface

  This is an area where the commercial option almost always wins and Content Agent is no exception. Media Mover's interface to FFmpeg is functional, but could hardly be considered end user friendly.

  

  FFmpeg is not nearly as nice graphical (other than clients like FFmpegX for OSX, FFmpeg has no GUI), nor is there anyone to call about problems you run into.

• Support

  A big advantage of a system like Content Agent is that it comes with a 1-800 number for support. The biggest advantage of FFmpeg is that it is free... and open. FFmpeg is a lot like Drupal that way. Both open source solutions have a community of users contributing documentation and volunteering help to new users, but until you actively engage it is difficult to find the information you are looking for or know who to contact about the problem.

  The knowledge base around Drupal has grown substantially within the PEG community since the first stations embraced it. We need to start developing that same type of community around FFmpeg. On the ACM Announce list, Jamie Capach (Executive Director, Pemi-Baker Community Access Media) wrote...

  If you also happen to be a Leightronix user you can find a tutorial and ffmpegX preset for creating files for your NEXUS server in their support site under tutorials in the NEXUS section. It has worked very well for me here.

  I'm really glad Leightronix supports using open source front ends to their playback servers, but that's the type of information PEG stations need to openly sharing with each other. Not only is the ffmpegX tutorial closed, the discussion about the fact that it even exists is closed. If you Google FFmpeg and Leightronix, my post about UPTV is the first thing you'll find. That said, I'm not suggesting David Leighton or Aaron Todd stop working on adding an RSS feed of upcoming shows and to change the permissions on their tutorials. Leightronix has become very supportive of the Open Media Project and all of their customers should thank them for the work they are doing to open their playback server up. We getting very close to have the Broadcast Synchronization module working with a playback server other that Princeton.

  Developing the open, transparent places to share this type of information and developing a community that is capable of supporting itself is a large part of the Open Media Project.

Making a decision to use open solutions like FFmpeg to save your organization money is a good first step, but if that is the only step you take you are just an open source "user" in a negative sense. We need to be openly contributing and sharing information to offset the disadvantages of open source.