An agent can't scan drive recordings on its own. It needs a search tool over video that has already been indexed. The pattern that works: export the camera streams as video, index them in a system that can match a written scenario description to what's visible on screen, let the agent query it and gather candidate time ranges into a review list, then have people check every candidate before it goes into a training or eval set. The main decision is who builds and runs that index.
What "scenario" means for camera search
Search by description works for things a camera can see: a pedestrian stepping out between parked cars, a cyclist merging from a bike lane, a vehicle stopped in the lane ahead, glare at a tunnel exit. It doesn't work for scenarios defined by signals the camera never recorded, such as how hard the car braked or the exact distance to a lead vehicle. Those belong in your log tooling. Most useful queries combine the two: signal triggers flag the events you already know how to detect, and camera search catches what nobody wrote a trigger for.
Drive video also has no useful speech, so transcript-based search, which carries a lot of weight in other kinds of video search, contributes almost nothing here.
Four routes
Paste frames into a chat. Fine for asking about one clip, useless across a fleet's recordings.
A filesystem connector. An agent with file access sees log names, which usually encode vehicle, date and route. That's good for narrowing by metadata. It tells the agent nothing about what happened in the frame.
Build your own index. Sample frames, embed them, store the vectors, and expose a text-to-video search tool to the agent. The common answers to this question describe exactly this kind of in-house data engine. It gives you full control over storage and models, and you own its build and upkeep. How multimodal video search works covers the moving parts, and the cost of generating embeddings is worth checking before you commit.
A hosted video search connector. A service indexes uploaded video and exposes search over MCP, so the agent calls it like any other tool. Less to build, but the footage has to be uploaded to the service first.
Pull candidate scenarios from uploaded drive video through your agent
Vivu connects to any assistant or agent that supports MCP, such as Claude or ChatGPT. Camera footage in common video formats uploads directly to a Vivu project, streams recorded inside ROS bag or MCAP logs have to be exported to video files first, and the upload is indexed once in the cloud. Ask the agent in plain language, for example "find where a pedestrian steps out from between parked cars", and a precise search runs as a job the agent waits on before it returns time ranges you can open and preview one by one on the results page. The agent can then write those ranges into a candidate list with source file and time range per row. Building that list is the agent's work, and every row still gets a person's review before it goes anywhere near a training or eval set.
Reviewers should record why they rejected a candidate, not just drop it. Near-misses show where the wording of a query drifts from the scenario you meant.
Where this route doesn't fit
Vivu searches one project at a time and only sees camera video that has been uploaded and indexed in the cloud. Searches draw on an allowance, with a free tier and paid tiers and the limits listed on Vivu's pricing page, and results are openable time ranges, not frame-exact boundaries, so a reviewer still sets precise in and out points. Search gives you candidates. Labeling and dataset versioning stay in the tools you already run.
You may not need camera search at all. If the scenarios you care about are defined by vehicle signals, and your triggers already catch them, a log query is faster and more precise. If you have a small set of recordings, someone watching them will find more than any query.
Choosing your side
Ask what your last few missed scenarios had in common. If a signal could have flagged them, invest in triggers. If the only way to spot them was to watch the camera, give the agent a video search tool, and decide whether you'd rather build the index or upload to one.
FAQ
Can an agent search drive video stored in ROS bag or MCAP files?
Not directly through a video search service. Export the camera topics to ordinary video files first, then upload or index those. The other sensor data in the log stays in your own tools.
Does natural-language search replace scenario triggers from the log pipeline?
No, the two cover different ground. Triggers catch events the vehicle measured. Description search catches things the camera saw that nobody wrote a trigger for, which is usually where new edge cases come from.
How should candidates be reviewed before they go into an eval set?
A person opens each range, confirms it matches the scenario definition, sets exact boundaries and records a short reason. Keep the rejected candidates with their reasons, because they show where the queries need tightening.