First of all, credit for this idea goes to Akshat:
https://twitter.com/#!/akshatj_96
HDSLR cameras (our current primary target) produce a heck of a lot of data. And for a distributed workflow to be practical, ideally we would upload all the video shot to the cloud, say, each night after a production day. However, in most places residential Internet access provides pretty shitty upload speeds. So we need to be smart and scrappy, find a way to work around the problem.
Scenario: you're making a low budget (but high production quality) movie or TV show. During your production days, you probably have a crew of at least 10 people there with you.
Solution: dmedia sends those 10 people home with files on their laptops, those 10 people leave their laptops on over night, and dmedia coordinates a distributed upload of those files, giving you 10 times the upload bandwidth. Think reverse BitTorrent.
Based on how dmedia is designed and what's already implemented, this is a fairly easy thing to do. There are basically three missing pieces:
1) We need any easy way to add devices into the set of peers (laptops) over which the files will be distributed (while on set) to then later be uploaded. We already have a need for an easy but secure way peering of devices for fast sharing over the local network. We also already have a need for sharing a dmedia database (or project) with remote peers, say other people in your distributed team. So we can basically reuse whatever solution we come up with for these, but with one twist: we only care about devices that are actually present there on the set, on that day.
2) A dmedia instance (say the one running on the workstation used for imports on set) needs to coordinate spreading the captured files across the laptops there on set. We probably want each file to be copied to at least 2 laptops (given sufficient storage) so that if one person has Internet troubles, the file is also stored on another persons laptop.
3) The native dmedia protocol needs to have a way to assign a specific range of leaves to be uploaded by a specific peer. The native dmedia transfer protocol can already be resumed, tell a peer which leaves are missing. The addition we need is for it to spit the leaves among multiple peers. Say one peer uploads the even leaves, another uploads the odd. That probably isn't a great algorithm, but it illustrates the point.
Thanks for the idea, Akshat!
