Originals and playable media
Preserving a camera file and displaying it in a browser require different bytes. Avichive keeps the original content identity while creating attachments suited to galleries, previews and playback. Conversion changes the viewing representation; it does not replace the preserved original or establish that every media item has a derivative.
Resolve the source first
Typed Photo and Video records retain their original paths and connect to UniqueFile by content identity. The shared source resolver uses the B2 original when that content is recorded as uploaded, otherwise a reachable local archive path. Cloud materialization streams the object into a temporary file, yields that path to the processing tool and removes it afterward. This lets tools that expect filesystem input operate on preserved cloud content. See the source resolver (app/models/concerns/file_entry_backed.rb:64).
Cloud materialization defaults to a configurable 2 GiB size boundary, limiting downloads into working storage. The era browser separately refuses preview preparation above 2 GiB and offers the original download path. Missing source data, unsupported formats and conversion errors remain visible outcomes. A catalog entry or uploaded-original flag alone does not demonstrate a ready preview. See the cloud reader (app/services/archive_originals.rb:195) and era preparation action (app/controllers/era_files_controller.rb:13).
Photographs: full frame, then display variants
The photo preparation path creates a full-resolution WebP attachment. Smaller display variants are generated from that attachment: a 200×200 cropped tile and an 800-pixel bounded preview. The method is historically called thumbnail generation, but its attached source is a full-frame representation, which also matters for face analysis.
Common raster formats and selected RAW formats have preparation paths. RAW input is converted through dcraw_emu to TIFF before libvips writes WebP. The process can fill missing dimensions and records processing, ready or error state. Availability depends on the installed decoders, source and tools; an extension on the supported list is not a promise that every damaged or unusual file will decode. See photo conversion (app/models/concerns/photos/conversion.rb:27) and display variants (app/models/photo.rb:9).
Video: inspect streams before choosing work
Video conversion probes the actual source with ffprobe instead of trusting an old filename or stored codec label. The result chooses among three paths:
| Observed streams | Processing |
|---|---|
| H.264 video with AAC or no audio | Remux into MP4, copying streams |
| H.264 video with other audio | Copy video and encode audio as AAC |
| Other video codecs | Encode H.264 video and AAC audio |
Each output uses MP4 faststart positioning for browser delivery. Remuxing avoids re-encoding streams that already fit the output; other inputs incur conversion work. The probe also supplies codec, dimension and duration metadata. See the strategy selector (app/services/videos/probe.rb:10) and conversion implementation (app/models/concerns/videos/conversion.rb:65).
Preparation locks the shared content record so separate occurrences do not independently start the same work. Playback looks across matching copies for an existing attachment, then processing/error state. The job stores a web-video attachment and ready/error outcome; a failed conversion does not become a playable result simply because it was queued.
Keep storage roles separate
B2 preserves canonical original content. Served image and video derivatives use the application’s Active Storage configuration, with Wasabi providing production media storage. Database transfer packages serve a third purpose: moving catalog records between environments. Those packages do not synchronize attachment readiness. Production generates and owns its own derivative records, including prepared images for synced People annotations.
This separation allows an original download even when preview preparation is unavailable, and allows derivatives to be regenerated without redefining the historical content. It also explains why local gallery readiness cannot be treated as production coverage. Read cloud preservation for original integrity and operations for environment ownership and sync.