There is no single unit to compare. One price page counts hours of footage processed, another counts storage, another counts seats, another counts searches, and most combine two or more of those. So a pricing comparison is really a sizing exercise: write down what your own library looks like, then push those numbers through each meter. Prices also move, and larger plans tend to get quoted rather than published, so the durable thing to compare is the meter, not last quarter's number.
What price pages are actually metering
Four meters cover almost everything you will see. There is the ingest meter, which counts hours of video that go through indexing. There is storage, which counts what sits there afterwards, media and index together. There is the query meter, which counts searches. And there is the seat meter, which counts people with a login.
They behave differently over time, which is the part that decides the bill. Ingest is a one-time charge against an hour of material, so it is heavy on a back catalog and mild on a weekly show. Storage and seats are rent, and they recur whether anyone searches or not. Queries scale with use, which is cheap while two people are evaluating and less cheap once finding footage is the normal first step for everyone.
Four numbers about your own library
Before you open anyone's pricing page, get these: hours already recorded that you want searchable, hours you add in a typical month, how many people will search and how often, and how long material has to stay searchable before you would archive it. The last number is the one that decides whether a rent-shaped bill or a one-time ingest bill wins. A library that gets indexed once and then queried for years prices out very differently from one that turns over every quarter.
Rolling your own
You can build this. Transcribe, generate embeddings, put them somewhere you can query, write the retrieval path. The bill is your own cloud bill, which makes it legible in a way vendor pricing is not: you pay for what you process, you pay to keep the index alive, and you pay again whenever you decide to reprocess with a better model. What the estimate usually leaves out is the glue, the retries, the re-runs when a format breaks, and someone owning it next year. Putting real numbers on the processing side is worth doing first either way, because it sets the floor that every other option gets measured against.
Asset managers with search layered on
The second route is a media asset manager that does content search as part of the platform. What to establish before comparing is which meters the quote actually contains, whether the search layer is included or priced separately, and what it is metered on when it is separate. A per-seat number looks small next to a per-hour number until you count how many logins the team needs, and a storage tier looks generous until you load video into it. Comparing these systems on their own terms is a separate exercise, and it is easier to do before cost enters the conversation.
Retrieval layers
The third route is a layer whose only job is search. Material goes up, it gets indexed on the way in, and afterwards you describe what you want in plain language and get back spans you can open. Pricing follows the shape of that job, with an ingest side tied to hours of material and a query side tied to how much searching happens. The trade is a one-time cost per hour against a recurring cost per question, which is the opposite trade from a seat-based system. Vivu is built on that shape: each video is indexed once when it goes into a project rather than reprocessed per question, so the ingest side follows hours uploaded and not how often anyone searches, while the searches themselves draw on a separate allowance. What the free tier and the paid tier include is written on Vivu's pricing page.
Not every search costs the same
One line on a price page can hide two different behaviours. Retrieval layers often have a quick mode and a deeper mode, and they do not hand back the same thing. Run against a set of short product films, a question about a phone lock screen showing the time and notifications came back from the quick mode as whole films, with no spans and no reasoning, enough to tell you which clips might be relevant and nothing more. The deeper mode on the same question returned short spans with a line explaining what was on the screen, took longer to finish, and drew more of the search budget. If your workflow needs the span rather than the file, build your query estimate on the expensive mode, because that is the one you will actually use.
When the comparison does not matter
If the footage you search is the footage you shot this month, none of this is worth pricing. Indexing starts costing the moment you turn it on and keeps costing while it sits there, so a library nobody queries is a subscription to a problem you do not have. The running cost of search only pays back when the question comes up often enough that answering it by hand has a visible price.
The way to settle it is to match the meter to your own shape. A large back catalog that has stopped growing wants a one-time ingest charge and as little rent as possible. A small library that grows weekly and gets searched constantly wants the reverse. If you cannot say which one you are, the four numbers will tell you before any vendor can.
FAQ
What should I ask before comparing video search pricing?
Ask what the meter is and when it fires. Four things cover most of it: whether indexing is charged per hour of material, whether storage is billed separately, whether searches are counted, and whether seats are counted. Then ask what happens when you go past each limit, because overage behaviour varies more than headline pricing does. A plan that throttles and a plan that invoices you look identical on paper.
Do you pay to index the same video more than once?
It depends on when the indexing happens. If indexing runs at ingest, each video is processed once and the cost attaches to the hour of material rather than to how often it is searched. If a system processes at query time instead, that work recurs, and your cost tracks usage rather than library size. Reprocessing also comes back when you change the underlying model later, which is a real line item on anything you build yourself.
What happens to the cost if we delete old footage?
Storage stops, and so does anything metered on what is stored. Deleting a project or a video removes the media and its index from the cloud, so the material stops counting and also stops being searchable. The thing to watch is that putting it back later means paying to index it again, so trimming a back catalog to save storage can cost more than it saves if someone asks for that footage afterwards.
Does per-search pricing get expensive with a big team?
It can, and the way to check is to estimate searches instead of seats. Per-search pricing looks cheap during an evaluation, when two people are trying it, and grows once looking in the archive becomes the default first step. Check whether every search costs the same, too. Deeper search modes generally take more of the budget than quick scans, and those are the ones that return spans you can hand to an editor.