AnyPS5/docs/dev/debt/libSceVideodec2.md

libSceVideodec2 technical debt

Unknown function info

• sceVideodec2InitLibrary (libSceVideodec2) throws: the FFmpeg decoders this module creates need no library-level initialisation, and neither SharpProspero nor EVO-PLAYER-PS5 declares this call, so its arguments and result are unknown. A title imports it from this module
• sceVideodec2TermLibrary and eleven other exports (libSceVideodec2) - report that they are not implemented; what they do on the console is not known. The others are QueryLibraryInfo, QueryDecoderInfo, MapMemory, MapDirectMemory, PresetDecoderConfigInfo (plain, Avc, Hevc, Vp9), CreateDecoderBid, CreateHevcDecoder and QueryHevcDecoderMemoryInfo. They are exported so that a title which imports them with sceVideodec2InitLibrary and calls none of them directly loads. Only sceVideodec2MapDirectMemory has a known parameter list, (decoder, memory), from EVO-PLAYER-PS5's sce_videodec2.h; the others take none here

Functional

• sceVideodec2Decode and sceVideodec2Flush (libSceVideodec2): the decoder core's discarded flag is not modelled: a returned picture always has OutputInfo.isDiscardedFrame (byte 0xb) at 0, and an unshown VP9 frame returns no picture. Per a #10913 review reading firmware 13.42's module (not reproduced here), the byte is written only with a returned picture and is left as the caller set it otherwise, as here. Name and offset: SharpProspero and KytyPS5; shadPS4 leaves it as padding. PPSA05110 sets only thisSize before its VP9 Decode (0x13728dd) and Flush (0x1371f7e) and takes a picture only when the byte is 0

• sceVideodec2CreateDecoder (libSceVideodec2) - One title (PPSA02225) disassembled for this entry calls it once (arguments set up at 0x8b5095-0x8b50a6) with three pointers: a structure built on its stack, a structure inside its decoder object and the address of a field of the same object. A nonzero result makes it leave the decoder setup; on one path (a flag byte set and two 32-bit fields equal to values it computed before) it passes that field to the next Videodec2 call. The codec type it requests and the meaning of the structure fields are not shown.

• AVC parameter-set units (libSceVideodec2) - an H.264 access unit with no slice NAL (types 1 to 5), such as the sequence and picture parameter sets Twispero (PPSA99474) submits on their own before a stream's first slices, is kept and put in front of the next unit that has a slice, and sceVideodec2Decode returns 0 with no picture for it, since libavcodec refuses a packet without a slice. What the console returns for such a unit is not known. HEVC units of parameter sets alone are still passed to libavcodec as they are

• HEVC and VP9 output gaps (libSceVideodec2): console frameFormat remains unknown and is 0; VP9 profile 2 output has no hardware evidence. Twelve-bit pictures and formats other than yuv420p10le throw. HEVC Main10 uses low-bit 16-bit little-endian samples, with interleaved UV after framePitchInBytes * height, following EVO-PLAYER-PS5 projects/evoplayer/media/src/evo_vdec_native.c, ro_harvest: the hardware consumer detects ten bits when byte pitch is at least twice sample pitch and uses a low-bit factor.

• HEVC frame-buffer memory sizing (libSceVideodec2): the console has an unknown extra term at 3840x2176. The two-byte-per-sample formula gives 16 KiB less than the hardware size of 24496 KB after 16 KiB alignment, while matching 6128 KB at 1920x1088. Evidence is in EVO-PLAYER-PS5 on-demand-decoder-handoff.md.

• sceVideodec2GetVp9PictureInfo: console field values remain unverified. The 88-byte projection uses SharpProspero Videodec2.cs and the VP9 specification, sections 5.26 and 6.2. Level is 0 because the elementary stream does not signal it. Pictures deeper than 10 bits throw. Superframes are submitted as individual coded frames to retain input metadata association. Only tracked single-picture VP9 metadata is projected; untracked frame-buffer metadata and other payload versions remain unsupported.

• sceVideodec2Decode after sceVideodec2Flush (libSceVideodec2) without sceVideodec2Reset restarts FFmpeg's decoder (avcodec_flush_buffers) and decodes the unit, where it threw before. TEKKEN DARK RESURRECTION (PPSA31371), which runs in Sony's PSP emulator, decodes after a flush without a reset (#7118), so the console accepts the call. Pictures the flush decoded but has not returned yet are returned before the new ones. A flush with no picture pending (each decoded unit has returned its picture) leaves the decoder and its reference pictures as they are, so a stream that continues without a new IDR picture keeps decoding: Daxter (PPSA09695), also in the PSP emulator, flushes after every access unit of its H.264 movies, and restarting the decoder there lost every P picture until the next keyframe. What the console returns for pending pictures, and for a stream that continues across a flush that had pictures pending, is not measured.

• sceVideodec2Decode (libSceVideodec2) and sceVideodec2Flush output the coded picture, with the chroma plane after its luma rows, as the console does for 1080p H.264 and HEVC streams coded at 1920x1088. An HEVC or VP9 picture whose size is not a multiple of 16, such as HEVC coded at 1920x1080, is output at that size; whether the console pads it is unverified. sceVideodec2GetPictureInfo reports no frame cropping

• sceVideodec2Decode of an empty access unit (libSceVideodec2) returns 0x811D010E for a null auData and 0x811D010D for an auSize of 0, with no picture, where it threw before. The values are ACCESS_UNIT_POINTER and ACCESS_UNIT_SIZE in the error table of shadPS4's videodec_error.h, whose libSceVdecsw codes this repository already uses; they are not measured on a PS5, and neither is whether the console leaves the decoder's state alone on that call, as this does. Media Player Classic PS5 (PPSA99015) submits empty units: its own converter reads a 4-byte length prefix of 00 00 01 xx as a start code and drops the rest as a non-base HEVC layer. It goes on after the error.

• Picture getter argument compatibility: other firmware/process modes, native pointer faults and physical-console behavior remain unverified. The common prologue follows BunnyFl's native-code emulator report and clarification for 13.42 module SHA256 5825514d06cee0b7fdc87de4f428065ff7c2b761b40443f95ee580e1be18776d, with sceKernelIsPs4Process returning 0. This was not independently reproduced here and establishes no valid metadata fields. Named getters share ordered errors, early four-byte validity/padding clears and the unsigned frameBufferSize > pictureCount * 0x400 check. Host-write refusal throws without inventing a console fault result.

• HEVC picture metadata: exact console field values remain unverified. The complete 184-byte layout follows SharpProspero, and syntax follows ITU-T H.265 (09/2023). Named getter wrappers share argument validation and select the supported projection from tracked decoded-frame metadata, independently of the caller's codec tag. The 184-byte HEVC and 88-byte VP9 projections retain delayed/flushed picture association. Other accepted payload versions, two-picture projections and untracked frame-buffer metadata throw after the early validity clears; their native payload behavior is not inferred from successful argument checks.

• AVC picture-info payload: the existing 56-byte host prefix is not a supported native picture-info version and returns the reported structure-size error. Accepted native AVC payloads have an unimplemented tail and are not filled by these getters. H.264 decoding remains available; no padded native AVC layout or missing field values are fabricated.

• Unsupported HEVC metadata projections: crop/default-display windows, temporal sublayers, multilayer streams, SPS extensions, VPS-only timing, unavailable parameter sets, unsupported SEI/NAL syntax and ambiguous picture-timing association throw at query time after the common validity-word clears and before other metadata writes. Differing parameter sets under an existing ID and malformed parameter histories keep queries unsupported through Reset until decoder recreation, since FFmpeg retains parameter state. Alternative-transfer persistence follows CLVS boundaries; conflicts, pictureless transfer messages and ambiguous continuation after reset/flush reject metadata. Unknown crop units, singular sublayer selection and console handling of these cases are not guessed. Decode behavior is retained when metadata cannot be projected.