Sharing the Source

The amazing “Skit!” app in the app store offers a new feature that will change how we think of shared multi-media.

Background:

Most, if not all current visual sharing mediums are one-way.  The sharer offers up a video or picture and the recipient can view the share in a “read-only” fashion.  They can share it again, and in some cases they can append drawings or add their own filters. But the original content is largely baked in and not accessible.

Examples:

1) Take a video using a camera or smart phone — the video is a stream of data that cannot be changed.   Yes, it can be “edited” to take on different sequences. But the actual source video never changes.

2) A photo on Instagram that has a filter applied to it.  That photo has the filter “baked in” and the recipient does not have the ability to remove the filter and add their own.  They can only add filters on TOP of the existing filters.

Summary:

We’ve developed a technological process that allows for the sharing of both the end result (the baked in photo or video) and the source materials that were used to make the end result. Using our process, both the sender and the recipient are able to communicate and express themselves using the same base set of media.  The message can now be changed or added on to using the same “ingredients” that the original sender used to author the share in the first place.

Use Cases:
– Animation of all forms
– Photo manipulation tools like Instagram (low rez for now)
– Video Games
– Audio Mixes

The Process:

1) Save the state of all objects to be shared.
2) Save the timeline of all objects to be shared (objects that are modified over time need to be accounted for).
3) Save the properties of the share — size, number of objects, title, permissions, and other meta data like version.
4) Save binary data separate from ascii data.  Audio, bitmaps, video, all need to be saved differently from text data.
5) Package steps 1-4 into a “story” file format for optimal transfer, security, and archiving.  *.story
6) Be sure to include both preview images and a full static share of the media, so that when people are browsing their shares, an instant viewing experience is maintained.
7) Send the package to the cloud (this is two-way-editable stories, after all — not email).
8) Download the package on the remove device and un-package its contents.
9) Restore all text properties
10) Restore all binary objects in accordance to the text properties

This process will work in delayed fashion, as described above, or in real-time, where the packaging and sending is done as the objects change, similar to the process that Google Drive uses to capture and distribute the changes of a google doc.  Obviously in the real-time case, more server side technology is employed to support distribution to multiple story viewers, change histories (undo), and change conflict resolution.

Take-Aways: 

Everyone should be sharing the source assets with every share.  Bandwidth will soon be “free” like storage has become, and static source assets are small and quite sharable in large quantities.

Sharing the source is one tech hurdle.  But what you DO with the share is quite another.  We offer the continuation of a shared story, or the retelling, or “remix” of a story — both are natural responses to when you see a message from someone — you want to respond one way or another.  And until now, you could only respond by “liking.”

Now, SO much more is possible, given the simple option to change the source.

 Sharing the Source, AKA: Two-Way -Editable- Multi-Media Transfer (Sharing)

 

Leave a Reply

Your email address will not be published. Required fields are marked *