Workflows

How to Search Your Video Library Without an Internet Connection

Cloud-based video tools stop working when you are offline. A local search index means you can search your entire footage library from an airplane, a remote set, or anywhere else without a connection.

FrameQuery Team15 April 20265 min read

You are on a flight to a shoot location, reviewing your footage library to plan tomorrow's edit. You open your browser-based video management tool and get a loading spinner that never resolves. No Wi-Fi, no tool. The three hours you planned to spend preparing are gone.

This scenario is not unusual. Video professionals regularly work in places without reliable internet. Remote shoot locations with no cell coverage. Client offices with locked-down corporate networks. Hotel rooms with bandwidth that barely handles email. Aircraft with expensive, throttled connections. Studios in basements with poor signal.

Cloud-dependent tools treat these situations as edge cases. For working editors and producers, they are routine.

How most video search tools work

The typical architecture for video search platforms follows a straightforward pattern. You upload footage (or point the tool at cloud storage). The platform processes the footage on its servers, generating transcripts, metadata, and search indexes. When you search, your query goes to the platform's servers, which run the search and return results.

Every step requires a network connection. Upload, process, search, view results. If you are offline, you have nothing. Not even the ability to browse footage you uploaded weeks ago.

Some tools cache thumbnails or metadata locally, but the search itself runs server-side. Without a connection, you cannot query your own footage library. You are locked out of work you already paid to index.

How local-first search is different

A local-first architecture inverts this model. The search index lives on your machine, not on a remote server. Once footage has been processed (which does require a cloud connection for the compute-intensive AI work), the resulting index is stored locally. From that point forward, all searching happens on your hardware against your local data.

FrameQuery uses Tantivy, a full-text search engine written in Rust, as its local search backend. After processing, every transcript, scene description, object detection result, face cluster, and metadata field is indexed in Tantivy on your machine. The search engine runs entirely within the desktop application.

This means the network is only needed for one phase of the workflow: initial processing of new footage. Everything else, including the most common activity of searching and browsing your library, works without any connection at all.

What works offline

Once your footage has been processed, the following capabilities work without internet:

All four search modalities. Transcript search finds spoken words and dialogue. Object detection search finds clips containing specific objects. Scene description search matches natural language descriptions of what is happening visually. Face and speaker recognition search finds appearances of specific people. All of these run against the local Tantivy index.

Library browsing. Your complete video library is navigable offline. Table view, grid view, list view, metadata panels, duration and format information. The database backing all of this is a local SQLite file.

Scene thumbnails. Thumbnails generated during processing are stored locally. You can visually scan your footage, review scene breakdowns, and identify clips without playing the original files.

Project filtering. Project assignments, color coding, and project-scoped views all work offline since they are stored in the local database.

Metadata review. Technical metadata (codec, resolution, frame rate, color space), organizational metadata (tags, projects, source folders), and AI-generated metadata (transcripts, descriptions, detected objects) are all available locally.

The only thing that does not work offline is submitting new footage for processing. That requires the cloud pipeline. Everything after processing is local.

Performance without a network

One advantage of local search that is easy to overlook is latency. Cloud-based search involves a round trip: your query travels to a server, the server runs the search, and results travel back. On a good connection, that adds 100 to 500 milliseconds. On a slow connection, it can take several seconds or time out entirely.

Local search on Tantivy skips all of that. Queries against a library of 10,000 or more videos return results in under two seconds. There is no network latency, no server queue, no connection quality variance. Search performance is consistent regardless of where you are or what your internet situation looks like.

This matters for the way editors actually search. Searching footage is iterative. You try a query, scan results, refine your terms, search again. Each round trip adds friction. With local search, the feedback loop is tight enough that searching feels like browsing.

Practical scenarios

Preparing on a flight. You have a six-hour flight before a week of editing at a client's facility. You spend the flight searching your library, pulling selects, reviewing transcripts, and building a rough plan for the edit. None of this requires the aircraft's Wi-Fi.

Working on a remote set. A documentary crew is shooting in a rural area with no cell service. Between takes, the producer reviews the existing library to identify gaps in coverage and plan additional shots. The footage from previous shooting days is already processed and fully searchable.

Client office with a restricted network. A corporate client's IT policy blocks external connections from guest devices. You need to show the client footage options during a meeting. With a local search index, you search and present clips from your laptop without needing their network at all.

Slow or metered internet. You are working from a location with limited bandwidth, perhaps a shared coworking space or a country with expensive mobile data. With a local index, you keep your bandwidth for uploading new footage to the processing pipeline rather than spending it on search queries.

When you reconnect

Going offline does not create a backlog of problems. When you come back online, the only pending task is processing any new footage you may have added to your source folders while offline. FrameQuery's auto-scan will have detected the new files already. They sit in the queue, ready for processing the moment a connection is available.

There is no sync conflict. There is no "catching up." The local database is the source of truth, not a cache of a remote database. You were working with the real data the entire time.

If your work regularly takes you to places where internet is unreliable, unavailable, or restricted, a local-first search architecture is not a nice-to-have. It is the difference between a tool that works when you need it and one that does not. Join the waitlist to try FrameQuery when we launch.