Split edge cases into the ones you can describe and the ones you can't. The ones you can describe, like a child running into the street after a ball, a car reversing out of a hidden driveway, or an officer waving traffic through a red light, can be searched for directly in recorded video. The ones nobody has named yet have to come from signals such as driver interventions, hard braking, or places where your model's output turned out wrong. The two feed each other: signals find the first example of something new, and search finds more like it. Every candidate still gets a human review before it goes into a training or evaluation set.
Two kinds of edge case
Answers to this question usually describe the automated mining strategies of large self-driving programs. They're useful to read, but they skip a practical split that shapes everything downstream. A describable edge case has a picture you can put into words. An undescribed edge case is one nobody has put into words yet, and by definition you can't search for it by name.
Keep one running document with both: the named scenarios you want more examples of, and a log of surprises that haven't been named yet. That document is your query set, your review checklist, and a record of how your definition of "edge case" has changed over time.
Finding the ones you can name
Write each scenario as actor, action and context, in terms a camera would see: "cyclist riding against traffic in the bike lane at night", "truck partially blocking the lane with hazard lights on". Avoid labels that need a judgment, like "dangerous" or "unusual", since neither a reviewer nor a search tool can check them in a frame.
Then choose how to search. Watching footage at speed with the list open works for small volumes and is the most accurate per clip. Building your own frame-embedding search works if you have engineering time and want full control, and it leaves you stitching frame hits back into watchable segments. The third option is a search layer that indexes uploaded video once and takes descriptions as queries.
Once a trigger has shown you one instance of something new, Vivu can take its written description as a query across driving video uploaded to a project and return other time ranges where something similar is visible, as candidates for review. It only sees the picture, so an edge case defined by what the vehicle did and not by what the camera saw won't come back from a description.
The same pattern on robot episodes, with an agent running the queries, is covered in searching robot episode videos with an agent.
Finding the ones you can't name
For undescribed cases the tools are different. Moments where a safety driver took over, hard-braking events, places where your system's predictions and the recorded outcome disagreed, and plain random sampling that people actually watch are all ways to find footage worth a look without knowing in advance what's in it.
Treat each surprise these turn up as a new entry for the document. Name it, write the visual description, and search for siblings. A single disengagement clip isn't a dataset. Once it's described and searched, it can grow into a slice of the set. Running those scenario searches through an agent shows one way to automate that loop.
Review is where the set gets its quality
Search and signals only produce candidates. A reviewer opens each one, checks it against the written description, trims it to the relevant stretch, and records why it was accepted or rejected. The ambiguous ones deserve their own pile: they're usually a sign that the description needs splitting into two scenarios. Rejects are worth keeping too, since they show which descriptions are pulling in the wrong footage.
When you don't need a search tool
If your edge cases are mostly defined by vehicle behavior, the logs already hold them and video is for review, not discovery. If the fleet is small and the footage fits into people's review time, watching with a good checklist is simpler. And if you only need a handful of examples of one scenario, a quick text search over video may be more setup than the task deserves.
Look at your document. If most entries on the named side are things you'd recognize on sight and you need many examples of each, searching the video pays off. If most of your work is still on the unnamed side, invest in signals and sampling first, and bring in search once there's a list worth searching for.
FAQ
What counts as an edge case in driving data?
An edge case is a situation that shows up rarely in your recordings but matters for how the system behaves, such as unusual road users, odd road layouts, or rare combinations of weather and lighting. What counts is specific to your system: a scenario that's common in one city's data can be rare in another's.
Can I find edge cases in driving footage without LiDAR or other sensor data?
Yes, for the ones that are visible. A pedestrian stepping out, a vehicle going the wrong way, or glare across the windshield can all be found in video alone, by watching or by describing them to a search tool. Edge cases defined by vehicle dynamics or sensor readings need those logs.
How many examples of an edge case do I need before it's worth searching for more?
One clear example is enough to start. It lets you write an accurate visual description, and the description is what you search with. Searching a second time with sharper wording, based on what the first round's rejects taught you, usually helps more than starting with a larger seed set.
Should search results go straight into a training set?
No. Search results are candidates. Each one should be reviewed by a person against the written scenario description, with a reason logged for accepting or rejecting it, before it goes into any training or evaluation set.