Add GStreamer based transcoder

[Jason Gerard DeRose]

There are two major use cases for transcoding in dmedia:

 1) For publishing, we take a master file and create a version of the video for each codec and resolution we need. Target resolutions should probably be 1920x1080, 1280x720, 800x450, and perhaps 640x360

 2) For video editing, we take an original clip and generate a proxy version, useful both because proxy will be a smaller file size (so you can get it across the network to peers quicker than the original clip), and because the proxy will make the editing experience more responsive. For 1920x1080 source clips, 960x540 makes a great proxy resolution (exactly halves hight and width). Because editing performance is more important than getting smallest file size possible, the proxy files will use a fairly low keyframe interval (say no more than 16 frames between keyframe).

The transcoder is going to require 1 addition to the FileStore API. Currently the FileStore can deal with transfers (chash and size are known) and imports (only size is known). But we need something like FileStore.allocate_for_write(), for cases when neither chash nor size is known.

This bug will definitely deliver the low-level transcoder. I have written so many little Python gst transcoders over the years that I'm pretty much going to copy and paste one in, write a bunch of unit tests.

But we also need the higher-level functionality for queuing and dispatching transcode jobs. As usual, we will queue the jobs in CouchDB so that the transcoding is fundamentally distributed... eg, you might have a local cluster, and we want any of those machine to take on jobs from the transcode queue. Depending on how much work the high-level piece is, and what other changes it will require, I might open a separate bug for the transcode job queue and dispatch.

As far as video codecs, Novacut only really cares about Theora and VP8, but we have no problem making sure that dmedia can reliably transcode to other codecs as well.