Back to work
AI · Database · In progress

AI Media Database — an archive that knows what is inside it (In development)

A searchable intelligence layer over an entire media archive — every frame, face, location and spoken line indexed, so finding a shot takes a sentence instead of an afternoon.

Most media archives are filing cabinets with a search box bolted on. They know a file is called FINAL_v7_GRADED.mov, that it is 14GB, and that somebody uploaded it in March. They do not know there is a drone shot of Sheikh Zayed Road at golden hour forty seconds into it. So the footage gets re-shot, because finding it costs more than filming it again.

The AI Media Database is MediaDXB's answer to that: an archive that understands its own contents.

What we built

Every asset that enters is taken apart by a stack of models and turned into something searchable. Vision models label objects, locations, camera moves and shot types. Face and voice recognition identify recurring people against a consented roster. Speech-to-text transcribes dialogue in English and Arabic and timestamps every line. Optical character recognition reads signage, lower-thirds and slates. Colour and composition analysis makes "wide, warm, handheld" an actual query.

All of it becomes vector embeddings alongside plain structured metadata, so the database answers two different kinds of question. The exact kind — every clip shot on the RED in Q3 at 4K. And the vague kind, which is how people actually look for footage: something calm, early morning, water in frame, nobody looking at camera.

Results come back to the frame, not the file. A search lands on the second of the clip that matched, with the reasoning shown — matched on transcript, matched on visual similarity, matched on a face — so an editor can tell a real hit from a lucky one.

How it is engineered

A pipeline, not a product with AI sprinkled on it. Ingest watches storage and takes whatever arrives. Processing fans out across the model stack in parallel, with each step idempotent so a failed job retries without duplicating work or re-billing inference. Results land in Postgres with pgvector for similarity search beside ordinary relational metadata, so one query can combine "looks like this" with "licensed for broadcast and shot after 2024".

Permissions are part of the data model rather than a filter on top. An asset carries its licence, its usage window and its consent status, and the search simply cannot return something to someone not entitled to see it. For archives holding talent likenesses and client-confidential material, that is the difference between a useful tool and a liability.

Everything is reprocessable. Models improve; the archive should improve with them. A new model version can be run across the back catalogue without re-uploading a frame.

What it took

The hard part was never the models — those are a call away. It was deciding what a search result means. Confidence scores vary wildly between a face match and a vibe match, and showing both as a flat list teaches people to distrust the whole thing. So the interface is honest about why something surfaced, and ranks certainty above cleverness.

The second hard part was cost. Running every model over every frame of a large archive is a way to spend a great deal of money proving a point. The pipeline samples intelligently, escalates to heavier models only where the cheap pass finds something, and caches aggressively — which is the difference between a demo and something an archive can actually afford to run.

This case study describes work in active development.