Certainly the fastest, easiest way to get a fully functional deployment up and running is to launch Movie Masher within the AWS Marketplace. You need to have an account and will be billed based on usage of their infrastructure.
Another fast and easy method of seeing the system in action is to run the Movie Masher Docker images locally. You need to have Docker installed, though no account with them is necessary and no charges are incurred. Docker is also available as a paid service within AWS Marketplace.
Alternatively, source code for each project is available at Github, with no account being necessary for download. The prerequisites need to be installed though, which can be a nontrivial task - the images come with all required software preinstalled, so are much simpler to work with.
The Movie Masher AMI (Amazon Machine Image) combines all three projects on one box, preconfigured to work well within the AWS (Amazon Web Services) infrastructure and optionally use additional services like S3 (Simple Storage Service) for media hosting and SQS (Simple Queue Service) for job delivery. The later option, combined with CloudWatch Alarms, can be used to deploy infrastructure that auto-scales to different traffic patterns.
All instances of the AMI have a cron job that runs the process_queues rake task from the moviemasher.rb project, which watches a directory for queued jobs. When the AMI is launched via 1-Click™ the apache daemon is also launched to deliver the angular-moviemasher UI, preconfigured to drop jobs into the queue directory. When run in this mode, the AMI Instance Identifier is used as the password - any username can be provided and each user only sees their media and mashes.
It's also possible for the AMI to be run in 'headless' mode, so only the moviemasher.rb project is active, by providing User Data at launch time in JSON format. If there is no 'angular-moviemasher' key then apache will not be launched, so a 'queue_url' key is provided instead so jobs can be polled from it. To authenticate requests the instance can be assigned a Role with permissions to the queue and and S3 buckets used, or 'aws_secret_access_key' and 'aws_access_key_id' keys can be provided.
The Deployment Wizard can be used to easily launch a scaleable cluster of AMI instances running in headless mode and (optionally) a single instance hosting the UI, as well as a queue and bucket. Whichever options are selected, the appropriate Roles are assigned to limit access to the queue and bucket.
There are two Movie Masher Docker Images available, for both the moviemasher.rb and angular-moviemasher projects. Each project contains a Dockerfile and its image is rebuilt automatically as its GitHub repository is updated. Usage instructions are in the README of each project, though angular-moviemasher contains simple run commands for both.
When run in the simplest configuration, the two containers share volumes so that jobs, media and feedback can be easily passed between them. It can be tempting and potentially difficult to map these to host directories, given permissions issues. In current versions of Docker, the cp command works for shared volumes too, so often it's easiest to just copy them to the host. Both images support the exec command as well, so cat or grep can be easily used to view log files.
There are three Movie Masher GitHub Repositories available, for each of the separate projects. The preferred method for soliciting help of all kinds is the issue tracking mechanism for each repository. Pull requests are also encouraged, but helpful to create a feature request first so plans can be discussed before much work is done.
Running the system from source is considerably more difficult than the prebuilt images, due to the dependencies involved and potential platform specific complications. The Dockerfile for each project might be helpful to review even if you're not using Docker since it contains installation commands known to work on at least one platform. Ideally, folks working with the source code are able to run images as well, so they know what standard behavior is like.
The Movie Masher codebase is grouped into three tiers, each with their own project repository, README and documentation. Two low-level tiers (moviemasher.js and moviemasher.rb) handle the dirty work of generating the initial browser preview and final video rendering, while a middleware layer (angular-moviemasher) connects them together with user authentication and other CMS (Content Management System) features.
Typically it's the middleware layer that's being customized, ported or wholly replaced in each deployment. But the lower-level components can be used individually too, if only a browser preview or video rendering is needed.
Movie Masher data is now always encoded in JSON format. All the Data Structures related to transcoding jobs, including the mash format supported by moviemasher.js and angular-moviemasher, is documented in the moviemasher.rb project. The UI layout configuration is no longer considered a data structure since it's now made up of CSS and HTML (angular-directives).