Files
AnyPS5/docs/dev/debt/libSceVdecsw.md
T

2.5 KiB

libSceVdecsw technical debt

Unknown function info

  • libSceVdecsw (libSceVdecsw) - structure layouts follow shadPS4's vdecsw.h and were checked against PPSA05684's movie decoder (movie-decoder-vdecsw.cpp), which asserts pictureCount == 1 at offset 0xb of OutputInfo and reads InputResult offset 0x10 as the number of frames an access unit produced. The compute, decoder memory and decode input structures and the first 0x28 bytes of the 0x50-byte decoder config are those of libSceVideodec2, and decoding goes through it. The 0x78-byte AVC picture info is filled with Videodec2's leading fields and the cropping fields only. OUTPUT_PENDING (0x81510115), INPUT_QUEUE_EMPTY (0x81510116) and DECODE_PENDING (0x81510117) follow from the codes each call's assert accepts. At most four decoded pictures are queued and the last one is held until sceVdecswFinalizeDecodeSequence; the console's queue depth is unknown. sceVdecswSyncDecodeInput / sceVdecswSyncDecodeOutput retry the TrySync variants until they stop returning DECODE_PENDING / OUTPUT_PENDING; they do not sleep beyond a yield, so another thread must drain outputs when the picture queue is full. sceVdecswGetHevcPictureInfo still throws: the 0xb8-byte HEVC picture layout is in shadPS4's vdecsw.h, but this wrapper only keeps AVC picture info from Videodec2

  • sceVdecswGetVp9PictureInfo (libSceVdecsw) - no console behaviour is recorded; the signature and 0x58-byte layout come from SharpProspero's Vdecsw.cs, and shadPS4 has no VP9 getter. It copies the leading thisSize - 8 bytes of the picture's info, as shadPS4's sceVdecswGetPictureInfo does for AVC and HEVC, from Videodec2's VP9 info (level is 0 there). An output with no picture returns 0 and writes nothing. Null pointers, thisSize below 8, two pictures and a frame buffer no VP9 decoder returned (an H.264 picture too) throw; console error codes are unknown. VP9 decoding goes through Videodec2 and rejects pictures deeper than 10 bits

Functional