Muvu
A cloud platform for your personal media.
Muvu — a play on movie — was a startup project focused on building a multi-device SaaS for personal media.
The idea was to make photos and videos captured on your phone available from anywhere: smartphones, tablets, PCs, Smart TVs and game consoles, including Xbox and PlayStation.
But the interesting problem wasn't simply storing and serving media.
It was finding the right balance between keeping the user's original content intact and making that content practical to consume from the cloud.
- Role
- Software Engineer
- Focus
- Backend · Media Processing · Cloud Infrastructure · Multi-device Applications
The problem with storing your own media
Existing cloud platforms could make your photos and videos available across devices, but typically optimized the content for online consumption.
We wanted to take a different approach.
The original file should always remain available to the user, like it would with a service such as Dropbox. But when someone wanted to watch a video from the cloud, we needed an optimized version suitable for streaming.
That immediately created a difficult trade-off.
If we transcoded every video when it was uploaded, we would have to:
- spend compute resources processing videos that might never be watched;
- store additional encoded versions of every video;
- maintain those versions alongside the originals;
- and continue paying for that additional storage regardless of whether the user ever consumed the content.
For a personal media service, that could become an expensive proposition very quickly.
Encoding only when it matters
The approach we explored was to treat video processing more like live streaming.
Instead of transcoding everything when it was uploaded, the system would keep the original file as the source of truth and generate the optimized representation when the content actually needed to be consumed.
That shifted the economics of the platform.
We would always pay to store the user's original content — which is the service we actually provide — but we would avoid paying to permanently store derived versions of content that might never be watched.
The idea sounds straightforward.
At the time, implementing it wasn't.
Going below the application layer
AWS did not yet provide a managed video transcoding service that solved this problem for us.
I worked directly with FFmpeg and modified MPEG-TS processing to adapt the encoding pipeline to the requirements of this approach.
I then built the video transcoding service responsible for taking the original media and producing the representation required for playback.
The work involved understanding the video pipeline at a much lower level than typical application development: encoding, containers, streams, buffering and the behaviour required to make the generated content suitable for streaming.
The codec modification was driven by the product constraint, not by a desire to build something low-level for its own sake.
We were trying to make the economics of the platform work.
A platform for every screen
Video was only one part of the multi-device challenge.
The product was designed to make personal content available across a wide range of devices, each with different capabilities and constraints.
I built proof-of-concepts for Smart TV applications and game consoles, exploring how the same underlying media platform could be exposed through very different client environments.
These experiments helped validate the concept and identify the technical constraints that would shape the eventual product.
My role
My work covered several layers of the system.
I developed the services responsible for uploading content to Amazon S3, built the video transcoding service, worked directly on the modified codec and created proof-of-concepts for new client platforms.
The project required moving continuously between levels of abstraction: from cloud storage and backend services to media formats, encoding and device-specific behaviour.
What I'm proud of
The part I'm most proud of is the connection between the product idea and the low-level engineering required to make it viable.
The codec work wasn't an isolated technical experiment. It came from a simple product question: why should we pay to process and store a video that the user may never watch?
That question led to a different approach to media processing, which led to a different architecture, which eventually meant modifying the tools and codecs underneath the application itself.
It was one of those projects where the product constraints forced us to go deeper into the technology.
Sometimes the right solution is another managed service. Sometimes it is an application. And sometimes you need to understand the codec itself.
Contact
Let's talk.
Open to conversations about architecture, platforms and teams. The fastest way to reach me is LinkedIn.
