The nested decode from an input callback is an unimplemented path whose
console behaviour is unknown, so the test no longer requires it to throw.
The production guard stays.
Co-Authored-By: Claude Sonnet 5.5 <[email protected]>
parseStream and decodeStream held a reference into the stream map
outside streamMutex while the guest's input callback ran. A callback
that deleted the handle, or a delete or new parse on another thread,
erased the stream under the running call.
- The map holds shared streams; each call keeps its own stream until
it returns, and the callback still runs outside streamMutex.
- A call that reaches a stream another call is still reading throws,
as the console's answer is not known; the debt entry says so.
- Tests: deleting the handle from the callback during a parse and
during a decode, and a decode re-entered from the callback.
- The test no longer requires parse operation 0x11 to throw.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Match PS5 firmware 13.42 module behavior by returning 0x80650012
(DECODE_ERROR) rather than 0x80650010 when input-control parse ends
before the frame header or encounters malformed marker data. Drop
the throw assertions for unsupported down scale and missing header
decodes in GuestJpegDecInputControl.cpp as requested in review.
Assisted-by: Antigravity:gemini-3.8-flash
The parse phase kept asking the callback for input until it ended. It now stops once the buffered bytes do not start with SOI, reach EOI or break the marker structure before a frame header, so a source that never ends cannot loop. The debt entry also notes that a stream stays in host memory when the work memory is freed without sceJpegDecDelete.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01SNqSvnFwRBz3D76n476yw6
The export takes the decoder handle, a 0x38-byte parameter block and an
image-info pointer. The block starts with an input callback and its
argument; the callback fills a {data, size} chunk and a negative result
or an empty chunk ends the input. Operation 0x10 parses the header and
fills the image info, and 0x20 continues the same stream, with a new
callback if given, and decodes into the image buffer. Bit 0 is the
decode mode. The decode checks match sceJpegDecDecode's and run before
any more input is read, and the result is the packed output size.
Both phases run through the same header, image-info and decode steps as
the memory-based calls, so the decode path is shared with
sceJpegDecDecode: its target checks and image writing move into helpers.
Read from libSceJpegDec.sprx, firmware 12.00, not measured on a console.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01SNqSvnFwRBz3D76n476yw6
