Skip to content

Read files in place for metadata, and decode only image headers - #103

Merged
djthorpe merged 1 commit into
mainfrom
djt/1015/metadata-memory
Oct 15, 2026
Merged

djthorpe merged 1 commit into
mainfrom
djt/1015/metadata-memory

Conversation

@djthorpe

@djthorpe djthorpe commented Oct 15, 2026 •

Copy link
Copy Markdown
Member

Extracting metadata from large files used a lot of memory.

Changes

  • No whole-file buffer: metadata.GetMetadata copied every input into memory before running its handlers, so a large video was read in full.
    • An input that can be read at an offset and seeked, such as an *os.File, is now read in place. Each handler gets its own io.SectionReader of the input, from its current position.
    • ffmpeg seeks, so it reads only the parts of a video it needs.
    • The input's position is left unchanged.
    • Any other input is still read into memory once, as before. Each handler gets a section reader of that, so it can seek too.
  • Image headers only: the general image handler uses image.DecodeConfig instead of image.Decode to get the format, width and height, rather than decoding every pixel.
  • What's unchanged: the HEIF and RAW handlers still read the whole file, because libheif and libraw take their input as one block of memory. Without the extra buffer, that's now one copy, the size of the file.

Testing

  • Test_metadata_014: handlers read a file from its current position, can seek in it, and get its name. The file's position is unchanged afterwards.
  • Test_metadata_015: a reader that can't be read at an offset is read into memory, and handlers can still seek in it.

GetMetadata read every input into memory before running its handlers, so
indexing a large video read all of it into memory, once for each file
being indexed. An input which can be read at an offset and seeked, such as
a file, is now read in place: each handler has its own section reader of
it, so it reads only what it needs, and the input's position is unchanged.
Other inputs are read into memory once, as before, and each handler can
seek in them too.

The image handler decodes the image's format and size from its header,
rather than decoding the whole image.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Copilot AI balanced review requested due to automatic review settings October 15, 2026 13:02
@djthorpe djthorpe self-assigned this Oct 15, 2026

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟢 Approval recommended

The focused changes and regression tests have no identified blocking issues.

0 open findings

What changed in this PR

Reduces metadata extraction memory use by reading seekable inputs in place and decoding only image headers.

Changes:

  • Gives handlers independent section readers, retaining buffering for other inputs.
  • Uses image.DecodeConfig for image format and dimensions.
  • Tests seeking, filename preservation, unchanged file position, and buffering fallback.
File Description
metadata/​metadata.go Adds in-place reading with a buffered fallback.
metadata/​metadata_test.go Tests both reader paths and handler isolation.
metadata/​image/​image.go Extracts dimensions without decoding pixels.

🧠 Review effort: Balanced


💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

@djthorpe
djthorpe merged commit 1008645 into main Oct 15, 2026
10 checks passed
@djthorpe
djthorpe deleted the djt/1015/metadata-memory branch October 15, 2026 13:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants