Time to return the favor to the blogosphere and the mplayer-users mailing list, where most of this information was painstakingly discovered. I’m working on a phase of the new ArtsConnectEd site where we’re trying to automate the importing of all of our various media types into two standard, embeddable formats: mp3 and flv. The source media is in everything from Real Audio and Real Video to different flavors of quicktime (mp4, etc), old mp3 codecs, some avi, and even wav files. We also need to generate thumbnails for all the video, and properly detect the edge cases where we have an audio-only quicktime file that wants to be a video but clearly should actually be an mp3 audio file.

The solution is ffmpeg and mplayer / mencoder, and the amazing thing is it’s almost as easy as just throwing a file at it and telling it what format you want. The developers of these tools have done a truly amazing job.

Things get much trickier when you introduce Real Media into the mix. An unfortunate number of our Channel videos are in this format, so it’s something we have to solve. After many attempts and failed encodings – including one hair-pulling episode where it turned out the audio was actually out of sync in the original file and not in the transformed version – I believe I have a “good enough for now” command line formula for converting Real Media to flv. (ffmpeg actually can’t handle .rm files, so this is all done in mencoder)

mencoder realmediafile.rm -ni -o flvoutput.flv -oac mp3lame -lameopts abr:br=56 -srate 22050 -ovc lavc -lavcopts vcodec=flv:vbitrate=300:mbd=2:mv0:trell:v4mv:cbp:last_pred=3 -fps 30.000 -ofps 24 -mc 1 -of lavf -lavfopts i_certify_that_my_video_stream_does_not_use_b_frames

Some of that is over my head and I just copied it (last_pred=3??) but the real key for this process seems to be knowing and accurately setting the input stream’s framerate using -fps xx.xx. Without that, the real demuxer will sometimes guess wrong and get out of sync, resulting in an unpleasant hung process as it comes across the next data chunk. I only noticed this happening with RV40 on multirate files, RV30 seemed solid. You can pull the info about the stream, including framerate and original dimensions, using mplayer:

mplayer -identify -frames 0 -vc null -vo null -ao null realmediafile.rm

Even cooler, in the cases where the .rm file isn’t local, both of those commands work by feeding them a stream like rtsp://server/realmediafile.rm!

With any luck, someone will find this page and save themselves a day of frustration. Or someone will find this page and notice I’m doing something wrong and correct me!

Last week we officially launched the My Yard Our Message project. If you haven’t checked it out yet, it is a project we’re running over the summer, leading up the Republican National Convention in St. Paul this September. We’re asking people to design yard signs and vote for the best signs. In August, we’ll print the most-voted signs and place them in a few places in the Twin Cities. You’ll also be able to order signs of your own online for $20.

Building the site

The site is built using django, an open source web framework similar to Ruby on Rails (except neater). While the site is a project of mnartists, there was not a need to integrate it with that site and it’s more legacy java codebase. In considering how to build the site, I first considered WordPress. I am a pretty good WordPress hacker, the needs for the project (accounts, file upload, voting) didn’t seem suited for a hack of WordPress. The project seemed like a textbook perfect case for using a modern web framework, rather than shoehorning it into an existing content management system.

Even though I know a good bit of php, I wasn’t really excited about learning the CodeIgniter or Symphony frameworks. Nate is a big Symphony fan, and a friend is a CodeIgniter user. I like that PHP is ubiquitous and freely available on just about every web host, but every time I write PHP I can’t help but feel like I’m writing Visual Basic.

Ruby On Rails also seemed promising, but hosting for RoR is neither cheap nor often as reliable as I would like. Hosting it in a shared environment seemed a little scary. Looking at the syntax for the language, it seemed a little foreign, too.

The power of python

I have been attracted to python for a while, especially after listening to Guido Van Rossum, python’s creator, on FLOSS Weekly over a year ago. Here are the high points of python’s beauty:

• Clean formatting: Python denotes blocks of code with indentation, rather than curly braces or parentheses. This might seem a little weird, but after maintaining lots of messy javascript and php, it is a blessing. If you don’t have your code indented properly, it doesn’t work.
• Forgiving where it needs to be: Despite python’s strictness with indentation, it’s forgiving with other things, like commas in lists or objects. With javascript, if you have a comma after the last item in an object, some browsers will freak out:

  { item, item, item, }

  Python doesn’t care, because it understands that it makes sense to have the trailing comma. You just might want to add another item later.

• Verbosity: While python is not as verbose as AppleScript or Lingo, it is pretty descriptive. Coupled with the great formatting, it makes for very maintainable and readable code.
• The command line interpreter: PHP and javascript technically have interpreters, but python’s is very integrated into the way the language is used and taught. In most tutorials, the interpreter is used to experiment and rapidly show the way some code works. This encourages you to try ideas quickly and make your mistakes early, so you know the code you put in your app does what you expect.
• Libraries: Python has a huge assortment of libraries, but almost none of them are included by default. This is both a blessing and a curse. It means that you only import what you need, but if you need a lot, a big list of imports can seem unwieldy.
• Python performs, and is cross platform. Google uses python all over the place for glue, and it is known to perform very well. Mod_python is mature, and works easily with apache. Python also runs pretty much anywhere, there are easy installers for every major platform.

Developing with django

Django build’s on python’s goodness and uses it to make a very capable web framework. Here are some overall observations about django:

• Django is built into Google App Engine. Had I gotten a developer key in time, I probably would have built the site using App Engine. But the fact that google chose django gives me a sense that their smarty-pants engineers think it’s well put together.

• Django has a kick-butt admin system. You define your database models and with one or two lines of code, set up the way the admin works. It’s like scaffolding, except easier to use and understand.

• Django isn’t “done” yet. The current release of django is 0.96.2, but if you look around the developer lists a bit, everyone will tell you to use the development pre-0.97-svn version. There are still a lot of things to be done before 1.0 hits, and some of them are non-minor architectural changes. This also has implications for documentation. You’ll find lots of blog posts that refer to solving problems older versions of django. Often times, though, these errors have been fixed in the development version.
• File uploads are great, file uploads suck! Django is a bit memory hungry when dealing with file uploads (as MYOM does). There is a patch available to fix the way it saves files and to allow for progressive uploading, but I haven’t tried it yet. On the other hand, if you need to deal with small files and aren’t too worried about memory, it is very easy to set up forms to deal with uploaded files.
• The template system is wonderful. Its exactly what a template language should be. Powerful enough to do almost everything, limiting enough that it’s not a full-fledged programming language. You can’t write python in your template, but you can do simple tasks like iteration and flow control. It forces you to keep your fancier logic in the models or the views.
• There’s a lot of built-in support for things you often want to do (the point of a framework, after all). There’s also a large library of apps for commons tasks. We will be using django-voting in MYOM when we being voting in July.
• Developing is easy, thanks to the built-in webserver. Once you have django installed, setting up an project and app is only a few lines of code. The built-in webserver makes debugging easy. It can be a little tricky to figure out deployment, especially since the production sever is usually apache + mod_python, different than the development server. The thing to remember here is assert False.

Two resources I have found quite useful in developing the site are the Django Book (free) and Learning Website Development with Django.

The site is still in development. We still have over a month to figure out and implement voting, and a month more to implement the ordering process. Voting is not going to be overly complicated, thanks to django-voting. We are using Cafepress to print the signs, and they are very high quality. Cafepress offers an API for developers to integrate with. We’re not entirely sure yet if we’re going to go that route or simply manually enter all the signs into our store.

I hope to post more about django and this project in the future.