Search for what was said inside the video. That is the thing people actually remember, and it is almost never what the file is called. File names record the job: the client, the shoot date, v3_FINAL_v2. Memory records a moment, like the founder standing on the factory floor or the line about the 40-year warranty. The two indexes do not line up, which is why searching the drive for "brand" gives you sixty folders and none of them is the one. There are four routes teams use for this, and the right one depends mostly on how big the library has gotten.
Ask whoever cut it
For a library under a few hundred videos with the original editor still on the team, one message in Slack beats every tool below. It is free and it usually works in under a minute. The problem is that the archive map lives in one person's head. When that person is out, or leaves, the map goes with them and you are back to the next route. If your library is small and your team is stable, honestly, stop reading here.
Search the transcripts you already have
If the videos shipped with captions, or you had transcripts made for accessibility or for cutting social versions, you have a text layer already. Pull the SRT or VTT files into one folder and grep them. Free, fast, and good enough a lot of the time.
Two things break it. Transcripts only cover speech, so a silent product shot with music over it is invisible to search. And most teams have transcripts for the published cuts only, so all the raw material stays dark: the b-roll, the interview takes that never made the edit, the fifty minutes of a webinar recording that surround the two minutes you want. There is also a spending trap. Teams sitting on big back catalogs sometimes pay per episode to have transcripts produced, and at a few hundred episodes that bill adds up. What you own at the end is a pile of documents that someone still has to read.
Build your own index
The DIY version is real and people ship it. Run everything through open-source speech-to-text, store the text with timestamps, put a search box in front of it. If you want visual search too, frame embeddings will get you approximate results. A capable engineer can have version one working in a week.
These projects rarely die during the build. They die in year two, when new footage quietly stops getting indexed because the person who built the pipeline moved to another team.
Search the footage itself
The last route indexes the content of the material, so you search with the memory you actually have instead of the file name somebody else typed. You describe the founder on the factory floor and get back points in a timeline with enough context around them to tell whether that is the one, without having to recall the exact words anyone used.
Vivu works this way, and the part that answers the year-two problem above is that the indexing is not yours to run. Footage put into a Vivu project is indexed once in the cloud, and the step left on your side is uploading new material as it comes in. The folders that caused this problem in the first place can stay exactly as messy as they are, since the search reads what is in the files.
The honest limit is that a large back catalogue still has to be indexed before any of it is searchable, and none of this helps with a shot that was never filmed.
When you don't need any of this
If the whole library is a few dozen videos and one person made all of them, a naming convention and a spreadsheet will beat software. The same is true if this search happens twice a year. It is annoying when it happens, but an annoying afternoon twice a year is cheaper than onboarding anything. The honest threshold is when finding old footage stops being an event and turns into a weekly tax on somebody's job, or when the people who knew where everything lives have moved on.