Fix encapsulated frame index offsets#33
Conversation
There was a problem hiding this comment.
Codex Review: Here are some suggestions.
Reply with @codex fix comments to fix any unresolved comments.
About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you open a pull request for review, mark a draft as ready, or comment "@codex review". If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex fix this CI failure" or "@codex address that feedback".
| let fragments = pixelSequence.items.dropFirst() // Skip BOT item | ||
| let totalFragmentLength = fragments.reduce(0) { $0 + ($1.data?.count ?? 0) } | ||
|
|
||
| // Get BOT (Basic Offset Table) offsets from first item | ||
| if let offsets = pixelSequence.basicOffsetTable(), !offsets.isEmpty { | ||
| guard totalFragmentLength > 0 else { | ||
| throw FrameIndexError.noFramesFound | ||
| } |
There was a problem hiding this comment.
[P1] Derive encapsulated size from fragment lengths instead of Data buffers
The new implementation computes totalFragmentLength by summing ($1.data?.count ?? 0). When encapsulated pixel data is read in streaming mode (readPixelSequence with a handler), each fragment’s data remains nil even though its length was parsed from the file. In that common path the total becomes 0, causing buildEncapsulatedFrameIndex to throw noFramesFound even though the Basic Offset Table contains valid frame offsets. The previous version did not depend on fragments being materialized. Consider summing item.length (or falling back to it when data is nil) so streamed pixel data can still be indexed.
Useful? React with 👍 / 👎.
Summary
PixelSequence.basicOffsetTable()as an array of byte offsetsTesting
swift test(fails: os.signpost module unavailable on Linux)https://chatgpt.com/codex/tasks/task_e_68c880d39cc8832ea81c05db620c0dca