AnyPS5/docs/dev/debt/libSceVideodec2.md

libSceVideodec2 technical debt

Unknown function info

• sceVideodec2GetAvcPictureInfo (libSceVideodec2) - runs the sceVideodec2GetPictureInfo body (KytyPS5 binds both NIDs to one function; SharpProspero gives both the same outputInfo, first, second signature); the second (bottom field) picture info is never written, since only progressive H.264 output is modelled. prosper calls the AVC layout unestablished (no title observed calling it)

• sceVideodec2TermLibrary and twelve 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, QueryHevcDecoderMemoryInfo and GetHevcPictureInfo. 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

• 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

• sceVideodec2CreateDecoder (libSceVideodec2) decodes HEVC (codec type 974921) and VP9 (2382845) through FFmpeg, besides H.264. The tags come from SharpProspero's Videodec2CodecType and EVO-PLAYER-PS5's sce_videodec2.h, which records them from hardware runs. HEVC input is converted from length-prefixed NAL units to Annex B as for H.264, and VP9 frames are passed through. Output is NV12 for 8-bit pictures. A 10-bit picture is written as 16-bit little-endian words with the sample in the low 10 bits, Y rows then interleaved UV rows at framePitchInBytes times the picture height, with framePitch in samples and framePitchInBytes in bytes (twice the width, aligned to 256), and QueryDecoderMemoryInfo sizes a frame of an HEVC or VP9 profile 2 configuration with two bytes per sample. Evidence is from EVO-PLAYER-PS5, which decodes and presents 1080p HEVC Main10 on hardware through this path (docs/evo-pro/on-demand-decoder-handoff.md): it takes a picture as 10-bit when pitch_bytes >= pitch * 2, puts UV at pitch_bytes times the height and samples with a low-bit factor (projects/evoplayer/media/src/evo_vdec_native.c, ro_harvest), and its hardware logs give 6128 KB and 24496 KB frame buffers for 1920x1088 and 3840x2176 Main10 decoders after rounding to 16 KiB. The 1080p size is what this formula gives; at 3840x2176 it gives 16 KiB less, so the console's size there has another term that is not known. Unverified: frameFormat (still 0; no consumer found reads it), VP9 profile 2 output (no hardware evidence), and the layout of 12-bit pictures and of decoded formats other than yuv420p10le, which throw. sceVideodec2GetPictureInfo and sceVideodec2GetAvcPictureInfo throw for HEVC pictures (SceVideodec2HevcPictureInfo is not filled), and sceVideodec2GetHevcPictureInfo reports that it is not implemented

• sceVideodec2GetVp9PictureInfo uses the 88-byte layout and two-pointer signature from SharpProspero Videodec2.cs. Frame metadata follows the VP9 specification, sections 5.26 and 6.2: profile, key/intra-only flags, bit depth, color space/range, coded/render dimensions and superframe count are retained per emitted buffer. Level is 0 because the elementary stream does not signal a level; the console value is unverified. Null pointers, undersized structures and querying another codec throw; console error codes and support for other structure sizes are unknown. Pictures deeper than 10 bits are rejected. Superframes are submitted as individual coded frames to keep each output associated with its input metadata. sceVideodec2GetPictureInfo writes this layout for a VP9 picture, as shadPS4's videodec2.cpp writes the decoder's own layout; Mortal Shell 2 (PPSA34008) calls it with thisSize 88.

• 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. What the console returns for them, and for a stream that continues across the flush without a new IDR picture, 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