"No valid source or titles found"

HandBrake began life as a DVD ripper, and it still thinks in the vocabulary of optical media. A DVD or Blu-ray does not contain "a video" — it contains a set of titles: the main feature, the trailers, the menus, each a separately addressable program on the disc. HandBrake kept that abstraction for every source it accepts, so even a single .mp4 or .mov is presented to you as Title 1. Before it will let you add anything to the queue, its engine (libhb) runs a scan — hb_scan — whose whole job is to open the source and build that list of titles. When the list comes back empty, the front-end (Windows, macOS or the GTK build) shows exactly one message: "No valid source or titles found."

For a plain file rather than a disc folder, HandBrake does its demuxing through the FFmpeg libraries (libavformat/libavcodec) — the same engine behind almost every player. The scan calls avformat_open_input to parse the container header, then avformat_find_stream_info to learn what tracks exist, how long they run and how to seek them, and finally it decodes a short preview to confirm there is a real, playable stream. An MP4 or MOV is a tree of boxes (atoms): ftyp declares the brand, mdat holds the raw encoded samples, and moov is the index — the sample tables that say where each frame lives and which codec decodes it. If moov is missing or corrupt, if a box announces a length that runs off the end of the file, or if stray bytes sit in front of ftyp, that scan chain fails, no title is built, and you get the empty-list error — even though the frames in mdat are perfectly intact.

The cure is to give libavformat a container it can actually parse. When the encoded samples survived but the map is broken, the tool remuxes: it scans the surviving stream data, reconstructs the sample tables the format needs, and writes a fresh, well-formed MP4/MOV around the same footage. No frames are re-encoded, so there is no quality loss — these are the original bytes you recorded, just correctly indexed again. Where the moov was never written — the classic unfinalized recording, when a camera, dash-cam or phone app is cut off before you press stop — the tool rebuilds that index from the structure of the media stream so a scanner has the frame map it was looking for. If the damage is garbage bytes ahead of ftyp (a common result of a bad copy or a mangled transfer), it strips them so the box tree starts where it should.

Once the file has a coherent ftyp/moov/mdat structure again, point HandBrake at the rebuilt copy and re-scan: avformat_open_input succeeds, find_stream_info reports a real track and duration, the preview decodes, and Title 1 appears so you can transcode as normal. All of this — reading the boxes, rebuilding the index, writing the new file — happens inside your browser tab. There is no HandBrake plug-in, no command line, and no server ever receives the video.

Rebuilding the container only works when the container is what broke. Repair recovers frames that are present; it cannot invent frames that were never written. If the recording was truncated — the power died, the card filled, the app crashed mid-write — everything after the cut is simply not on the disk, and the tool can only return the footage up to that point. That is the honest ceiling on any recovery, ours or anyone's. Likewise, if the underlying mdat was overwritten or returned as zeros by a failing card or drive, there are no good samples to re-index; recover the raw bytes from the storage first, then repair.

Two other cases are genuinely out of scope, and it is worth naming them so you do not waste time. A file that is not really a video — a document, an image, or a broken fragment wearing a .mp4 extension — has no title to find, and no container repair changes that. And a pure codec problem — a stream in a format HandBrake's libraries have no decoder for — is not something a structural rebuild fixes; the container can be perfectly valid while the decode is simply unsupported. When the footage is there and only the structure failed, though, the browser-only approach means sensitive material — evidence, personal recordings, unreleased work — is repaired without being copied anywhere. Open the Network tab and you can confirm 0 bytes of the clip are ever sent.