Update Decode() for ImageDecoder API 3.1.0

[cinema-ONE]

Readies the add-on for ImageDecoder API 3.1.0 (xbmc/xbmc#29068), which added size_t pixelBufferSize to the C++ Decode() signature.

This is a source break rather than a rebuild: the old five-argument Decode(...) override no longer matches the base virtual, so it fails to compile against the new dev-kit.

Two commits, separable. The first is the signature alone and unblocks the build. The second uses the argument for a bounds check and can be dropped if you would rather not take it now.

The check is worth having here because the loop is driven by m_height and row_stride from the JPEG rather than the height Kodi passed, and each of the m_images is tiled at a further m_width / 2 * 4 offset.

Verified by building against a Kodi tree carrying the merged API: configure and build clean, .so produced. The generated addon.xml picks up minversion="3.1.0" version="3.1.0" from the dev-kit on its own, so nothing needs hardcoding in addon.xml.in.

---

_{Written by my AI co-author (Claude Code); posted from my account.}

[greptile-apps]

Greptile Summary

Updates the add-on to ImageDecoder API 3.1.0 by accepting the new pixel-buffer-size argument and using it to reject undersized output buffers.

• Adds pixelBufferSize to the Decode override declaration and definition.
• Adds a per-image output-extent check before writing decoded JPEG scanlines.

Confidence Score: 3/5

This PR should not merge until the bounds check uses the exact same destination-offset calculation as the write loop.

The signature update is consistent, but the new safety check can approve a buffer smaller than the actual write extent for later images when the aggregate width is odd.

Files Needing Attention: src/MPOPicture.cpp

Security Review

The new output bounds check does not exactly mirror the guarded destination-offset expression. For odd aggregate widths, it can underestimate the write extent and leave a buffer overrun reachable. How this was verified: The check divides m_width before multiplying by image, while the write pointer multiplies first, and those integer expressions differ for reachable odd widths.

Important Files Changed

Filename	Overview
src/MPOPicture.cpp	Adds the buffer-size guard, but its horizontal-offset calculation can underestimate the guarded write for odd aggregate widths.
src/MPOPicture.h	Updates the virtual Decode declaration to match the ImageDecoder API 3.1.0 signature.

_{Reviews (1): Last reviewed commit: "Refuse a decode that would not fit the o..." | Re-trigger Greptile}

[greptile-apps]

Bounds check truncates offset

When an MPO has an odd aggregate m_width, this check divides the width before multiplying by image, while the guarded destination pointer multiplies first. For later images the check therefore underestimates the actual write extent, allowing the pixel loop to overrun a tightly sized output buffer. How this was verified: The two integer expressions produce different offsets for reachable odd widths.

Suggested change

	static_cast<size_t>(m_height - 1) * pitch + image * (m_width / 2 * 4) +
	static_cast<size_t>(m_height - 1) * pitch + image * m_width / 2 * 4 +

[cinema-ONE]

Greptile's security finding was right, and I introduced it — the guard's horizontal offset did not mirror the write.

The write loop computes image * m_width / 2 * 4, which evaluates as ((image * m_width) / 2) * 4. My check had image * (m_width / 2 * 4). Those diverge whenever m_width is odd and image >= 2: for m_width = 1921, image 2 reaches 7684 bytes while the check approved 7680 — so an undersized buffer could pass and the overrun stay reachable, exactly as described.

Corrected in adf5664 (was 5957720) by mirroring the expression instead of re-deriving it:

const size_t tileOffset = image * m_width / 2 * 4;

Checked the sibling PRs for the same class of error — heif and raw derive their extent from the same operands in the same order as their loops, so neither diverges.

The branch has also gained a third commit since that review: Refuse formats the add-on does not implement. The copy loop writes B,G,R and fills the fourth byte only for A8R8G8B8, so every other ADDON_IMG_FMT returned true with output that did not match the request; ADDON_IMG_FMT_A8 asked for one byte per pixel and got three.

---

_{Written by my AI co-author (Claude Code); posted from my account.}

[garbear]

Thanks for the improvement!

[garbear]

@cinema-ONE I got all the "Update Decode()" PRs, the rest might need to be rebased.

[cinema-ONE]

All four are rebased already — #72, #73, #74 and xbmc/imagedecoder.heif#92 are MERGEABLE as of now.

#71 conflicted with #73 and #74 in MPOPicture.cpp (the format whitelist landed where #73's setjmp guard sits); both keep the two guards side by side, and I rebuilt against the merged API rather than assuming.

Order that reads easiest: xbmc/imagedecoder.heif#92 and #72 are the TinyEXIF resync and stand alone. #73 is the libjpeg exit() fix, no parser changes. #74 is stacked on #73, so its diff includes #73's commit — merging #73 first collapses it to two commits.

---

_{Written by my AI co-author (Claude Code); posted from my account.}