Upgrade to play 2.1.3
Simple poc ffmpeg native interface

Mostly infrastructure to support building and loading of the native library.
It seems that the library initialization is not done until use, so this
shouldn't break anything immediately.
Convert Makefile to build.sbt; use tmp library file

Loading a fresh, temporary copy of the library each time seems to fix all the
problems, but it does result in multiple redundant linkages in dev mode.
Cleanup av.c, rename classes, no new development
Extract duration (renamed from length) from uploaded videos

Currently it'll just throw an exception if it can't read the video, or if
something else goes wrong in that whole thing.  No transcoding (yet).
Add a couple video formats
Started on excerpts and caching

Realized we should be proactive in solving the blocking problem: we do not want
play's limited thread pool to block on multiple concurrent ffmpeg extractions.
Unfortunately, I have not found a good way to solve this because java's
InputStream used by process in inherently blocking.  Furthermore, the same
problem already exists just reading object from the filesystem and accessing
the database because akka/scala/java are so far behind on asynchronous I/O.

On the other hand, we probably don't want very many concurrent ffmpegs running
on the system at all, so could just ignore this problem and bump up the thread
pool size a little and hope for the best.  I'm going to do some more research
asynchronous pipe/file I/O with actors first, though.  It should be a solvable
problem since there are all sorts of asynchronous network actors.
Concurrent caching excerpter, unused, untested
Fix a couple incorrect table/type references
Working cached image excerpts and video head images

The format handling, specifically Format.{Image,Video} values, aren't perfect
and currently hard-code the first two format ids.  The concurrent caching
hasn't been stress-tested yet, though a single client exercises most of the
code anyway.
Minor enhancements to avformat use
Add direct frame-extraction function

This is much more efficient than calling out to ffmpeg, but works by saving the
image directly to a file rather than producing a stream.  It could
alternatively just keep the image data in memory, which may make more sense for
some uses (i.e., the current use of store.StreamEnumerator.fromFileGenerator).
Also changed the temporary segment extraction to use the same approach, which
means the segment cannot be streamed efficiently before being cached, but has
the benefit of actually working.

This should hopefully be enough low-level functionality for now, though it
could be cleaned up.  In particular, all the ActiveGenerator stuff is now
unnecessary (which I should've realized earlier).  Also, segment extraction
could potentially be done more efficiently using a similar approach to the
frame code.
Cleanup now-unused code and simplify frame handling
Use in-memory image data for frame access

A basic performance test shows about 40ms to extract a random frame from a
small 40s video, though this is not significantly better than writing to files.
Add demo video for easy testing
Strip unnecessary quotes from demo data for readability
GPLv3+
Merge remote-tracking branch 'remotes/origin/master' into gui

Conflicts:
	conf/routes