Physical vs Virtual Ingest

Overview

When you ingest footage into Onset Engine, you choose between two fundamentally different storage strategies. This decision affects disk usage, render speed, and library management.

Physical Ingest (Default)

Physical ingest extracts individual clip files from your source videos:

Source: wedding_ceremony.mp4 (45 min, 12 GB)
      ↓ Scene detection + CLIP analysis
Output: clips/
  ├── clip_0001.mp4  (3.2s, 18 MB)
  ├── clip_0002.mp4  (4.1s, 22 MB)
  ├── clip_0003.mp4  (2.8s, 15 MB)
  └── ... (347 clips)

Characteristics

Aspect	Physical
Disk usage	High — clips are duplicated as separate files
Render speed	Fast — clips read directly from individual files
DJ Mode seek	Instant — each clip is a standalone MP4
Portability	Self-contained — can move clip folder independently
Best for	Working sets < 500 GB, maximum render performance

How It Works

1. FFmpeg splits the source video at scene-change boundaries
2. Each clip gets a CLIP embedding (768-dim float32 vector)
3. Motion score, duration, and peak frame are computed
4. Metadata is stored in library.db (SQLite)
5. The physical .mp4 file is written to the clips/ directory

Virtual Ingest (Pointer-Only)

Virtual ingest creates database references without copying any files:

Source: wedding_ceremony.mp4 (45 min, 12 GB)
      ↓ Scene detection + CLIP analysis
Output: 0 bytes on disk (only DB entries)

Database entry:
  source_path: "D:/footage/wedding_ceremony.mp4"
  start_time: 34.2
  end_time: 37.4
  embedding: [0.023, -0.117, 0.891, ...]
  is_virtual: 1

Enable it with the “Pointer Only” checkbox in the Ingest dialog.

Characteristics

Aspect	Virtual
Disk usage	Zero — only SQLite metadata, no file copies
Render speed	Slightly slower — FFmpeg seeks into source files
DJ Mode seek	Uses start property in MPV — no first-frame flash
Portability	Tied to source paths — moving files breaks references
Best for	Data hoarders, 1TB+ libraries, NAS-backed storage

How It Works

1. FFmpeg probes the source video for scene-change boundaries
2. Each segment gets a CLIP embedding from the peak frame
3. The database stores source_path, start_time, end_time, and all metadata
4. No physical clip file is created — the source video IS the clip storage
5. During render, FFmpeg seeks to start_time in the source file

Tip

Virtual ingest is ideal for indexing massive archives (anime series, raw drone footage, surveillance archives) where duplicating files would consume terabytes of disk space.

Mixing Modes

You can use both modes in the same library. Some sources can be physically ingested (your working set) while others are virtual (your deep archive). The render pipeline handles both transparently.

library.db
  ├── Physical clips: 2,400 (from working set)
  └── Virtual clips: 18,000 (from archive NAS)

The Studio render and DJ Mode don’t care whether a clip is physical or virtual — they follow the same selection logic. The only difference is at the file I/O level during rendering.

When to Use Which

Scenario	Recommendation
Small project (< 100 GB footage)	Physical — faster renders, simpler management
Large archive (1TB+)	Virtual — saves disk space, indexes everything
NAS-backed storage	Virtual — avoid copying over network
Portable project (USB drive)	Physical — self-contained clip folder
Mixed workflow	Physical for active project + Virtual for archive browse

Progressive Ingest

Both modes support progressive ingest — you can start working before all files are processed. The minimum threshold is 50 clips before DJ Mode becomes available. Studio Mode requires at least one clip.

During progressive ingest, the Vision Matrix dashboard shows live thumbnails and AI tags as each video file completes analysis.

Related Articles

• Style Presets
• Studio Mode