The CLI is self-describing and ships its own API reference. Use dapi --help, dapi media --help, and dapi media <command> --help to enumerate every command, argument, and option, and treat live help as authoritative rather than working from memory. If dapi is unavailable, read installation.md.

Watching footage

How to understand source material. Inspect only the modalities the question turns on — speech, action, music, graphics, or atmosphere may lead, so there is no fixed priority. Sample the picture against what the audio tells you.

• Always probe first. dapi media probe <id|path> reports the container and its tracks, telling you up front whether the file has a video track, an audio track, or both. Everything after branches on that.
• Get the lay of the land. Render a dapi media waveform (audio) and a dapi media filmstrip (video) for a fast, cheap overview of where the loud and quiet stretches fall, and where the visual scene changes are. A filmstrip shows coarse structure and scene state, not crop, framing, readability, or an exact cut frame.
• Listen to the audio. Run dapi media listen with a prompt tailored to the context (what you actually need to know), and explicitly ask the model to include timestamps in its answer. See media-listen.md for prompt patterns.
• Transcribe speech. For speech, dapi media transcribe prints the full transcript with word-level start/end times directly — read any segment straight from it.
• Sample the video against the audio. Use dapi media grab to pull frames. When the audio has already pointed you at specific moments, feed those timestamps straight in from the transcript or listen output, e.g. -t '00:32' '00:45' .... When you need a visual pass without such cues, reach for --auto: it scans the footage and keeps only the frames where the picture settles into a new visual state, dropping near-duplicates.

Matching depth to the question

Read only as much of the footage as the answer requires — each pass costs time, and listen costs credits.