Project 08 / Case study
Infrastructure · storage · video production
A production company with shared editing in DaVinci Resolve: several people opening the same projects and the same sequences at the same time. That environment runs its own data server, and it is the best example I know of the argument that runs through all of my infrastructure: when the volume is large and access is continuous, cloud storage stops being a reasonable expense and becomes the problem. This page is shorter than the others because I can hardly show any figures; what I can do is explain the reasoning.
Editing video between several people requires everyone to see the same thing at the same time at local network speed. The material is hours of footage in heavy codecs, and a Resolve project does not reference one file: it references thousands. Uploading that to a consumer cloud plan is simply unworkable, and as soon as you add egress traffic and per-user licences, the discussion ends by itself.
A data server on the network itself, with the material and the projects shared and accessible from every editing station. It is the answer almost any small production company gives before the cloud ever pays off: the storage is paid for once and access runs at the speed of the rack's cable, not at the speed of the office upload.
That the real cost of an infrastructure is the curve, not the monthly bill. There are workloads that belong in the cloud and workloads where the cloud is a tax. Learning to tell them apart is what this environment taught me, and it is what I apply afterwards when deciding what to build at home and what to leave as a subscription.
Why this is in a software portfolio
A storage environment defines which formats are accepted, which tools can be used and what gets automated. Here I have a concrete, verifiable example.
What I bring to that environment is software, and its most honest part is a video downloader I wrote to feed those folders. I did not invent its main restriction: it only accepts H.264 video (avc1) and AAC audio (mp4a), and it rejects VP9, AV1 and Opus explicitly. The reason is written in the project itself: in some Resolve installations those formats show up as Media Offline, which is an editor's elegant way of telling you the material does not exist. A downloader that fetches the best quality available is worse than one that fetches a worse quality and opens it.
On top of that it imposes a ceiling of 1080p at 30 frames per second, and if the video has no such variant it downloads the best lower quality instead of marking the link as failed. It is the same logic as the CRM when a data enrichment returns nothing: the job has to finish. A batch of a hundred links cannot stall because one of them arrives in 4K and will not open.
And then there is the underlying argument, the one that justifies this page existing at all. The cloud sells convenience, and for code, small databases or spikes of work it is the right choice: it is what I do with the deployments of my services. For video material it is a tax, because the volume never comes down, access is continuous and egress is charged every time someone retrieves their own files. I know which box to put each workload in because I have seen both extremes: the inference server on the previous page and this storage answer the same calculation, made with two opposite workloads.
avc1AAC mp4aVP9, AV1 and Opus rejectedceiling 1080p · 30 FPSautomatic quality fallbackDecisions
None about the server: about what I write so that it works with it.
A video's list of formats is inspected before anything is chosen, and if there is no H.264 with AAC it downloads the best variant that does work. The cost is giving up the highest resolution available. The benefit is that nobody in the edit suite finds a red clip and the material has to be requested again. Catching the problem at the entrance costs seconds; catching it once the edit is assembled costs an afternoon.
A link without its preferred variant is not marked as an error: the highest lower quality that exists is downloaded. The batch finishes entire. The trade-off is that the result is heterogeneous: one clip comes in at 1080p and another at 720, and that forces a review before editing. I chose the uneven result over the incomplete batch, because an incomplete batch cannot be shown to anyone.
Equipment model, number and size of drives, copy scheme, protocols and, of course, the material: none of it appears here or anywhere else public. I apply the same rule to my own machines: this website is not going to show you the specifications of any equipment, hired or mine. That costs me the most impressive page in my portfolio, because a production company's NAS with clients inside it is somebody else's asset, and because even an asset of my own is no argument for showing it off. It seems to me the clearest evidence of what this website is trying to sell: someone you can trust with an environment that cannot be shown.
Limits of this page
So that nobody has to guess it by reading between the lines.
Can be verified: the software that feeds that environment is in my repositories, with its codec constraints, its quality ceiling and its fallback logic. That is what I wrote and that is what this page rests on.
Cannot be verified, and I am not claiming otherwise: the build of the server, its configuration, its copy scheme and its operation. That is the production environment where the deliverables live, not an installation I built or could sign off. What I take from it is the cost reasoning I apply to my own machines and the tools I wrote to fit into it.
If a conversation requires seeing the environment, it is shown in the conversation, with the people and under the conditions the production company decides. A portfolio is not the place.
Write the downloader checking first against the codecs the editor actually swallows, rather than finding out through the edit suite. And document the restriction where whoever maintains the code in a year will read it, which is what I ended up doing: today the reason behind Media Offline is in the README, not in my head. If one day I take part in designing an environment like this from scratch, the conversation starts with the cost curve of the volume and the copy plan, not with the box.