nordisk/znippy

znippy-plugin-media — crate card

Reverse-engineered (from source — verify, don't trust the name)

• One-line pitch: Pure-Rust media metadata handler — parses image/audio/video headers into queryable Arrow columns without ever re-coding the (already-compressed) blob.
• Does: Defines MediaKind, MediaMeta (unified optional record: dims, color, EXIF, duration, sample_rate, channels, codecs…) and MEDIA_EXTENSIONS/MEDIA_TYPE_ID = 25. Parses images via image + kamadak-exif, audio via lofty, video via mp4 (MP4/MOV) and matroska (MKV/WebM). native.rs provides NativeMediaPlugin implementing the plugin trait; on any parse failure the extractor returns None (never panics, never blocks compression).
• Key deps: znippy-common, image (no-default, jpeg/png/webp/gif/tiff/bmp), kamadak-exif, lofty, mp4, matroska — all pure Rust, no C/ffmpeg.
• Shape: lib (rlib only — no WASM target), ~600 LOC: lib.rs (312), native.rs (153), tests.rs (145); test fixtures under tests/fixtures.
• Observed role in the workspace: Registered in znippy-cli/handlers.rs as NativeMediaPlugin::new(); contributes the media sub-index so DuckDB/Polars can query e.g. width > 1920 over an archive.

Fill in (one line each — only the human knows these)

• Primary consumer(s):
• Why it exists (vs the obvious alternative):
• Hard constraint (airgap / no-C-deps / no-FFI / pure-Rust / etc.):
• Release cadence & independence (rides a parent? own repo someday?):
• Status (production / prototype / experimental / stubbed):
• Must-NOT-change invariant:
• Biggest known gap or TODO:
• Anything a newcomer would get wrong about it: