[johnmaia]

What

sceVideodec2CreateDecoder accepted only H.264 (codecType == 1). EVO-PLAYER PPSA99039 v0.11.0 creates resident decoders at start-up for AVC, HEVC and VP9, and with its default build for HEVC Main10 and VP9 Profile 2 too. With #1916 and the PRs for its earlier stops, it stopped at the HEVC one:

EVO boot: INFO  EVO vdec native: HEVC config codec_type=974921 profile=1 max_level=123 max=1920x1088 dpb=auto depth=4
  what():  Videodec2: unsupported codec

• Codec types: 974921 (HEVC) and 2382845 (VP9) open FFmpeg's HEVC and VP9 decoders. Both are already in the bundled FFmpeg build. The tags are SharpProspero's Videodec2CodecType (Interop/Video/Videodec2.cs: Avc = 1, Hevc = 974921, Vp9 = 2382845). EVO-PLAYER's media/include/sce/sce_videodec2.h gives the same values and records sceVideodec2CreateDecoder accepting them on hardware. Any other value still throws unsupported codec.
• Input: HEVC access units go through the existing length-prefixed to Annex B conversion, as H.264 does. VP9 frames are passed through unchanged.
• Output: 8-bit NV12, as for H.264.
  • A decoder for HEVC Main10 or VP9 Profile 2 is created, since EVO creates both at start-up.
  • A decoded frame deeper than 8 bits throws instead of being converted silently, because the console's 10-bit output layout is unknown.
  • QueryDecoderMemoryInfo reports the 8-bit frame size for those decoders.
• Picture info: sceVideodec2GetPictureInfo and sceVideodec2GetAvcPictureInfo throw for HEVC and VP9 pictures instead of writing the AVC layout; SharpProspero gives them separate SceVideodec2HevcPictureInfo and SceVideodec2Vp9PictureInfo layouts. GetHevcPictureInfo and GetVp9PictureInfo are not exported. EVO calls none of these.
• All of the above is recorded in TechnicalDebt.

Tested

• guest_videodec2, extended:
  • A 64x40, 6-frame HEVC Main clip with B-frames (display order differs from decode order), decoded once with start codes and once length-prefixed.
  • A 64x40, 6-frame VP9 profile 0 clip.
  • Every picture's NV12 is hashed and compared in output order with a reference decoded by a separate FFmpeg 9.0.2 (-pix_fmt nv12); all 12 hashes are distinct. The output reports the codec type, the size and the 256-byte pitch.
  • GetPictureInfo throws for these pictures.
  • HEVC and VP9 decoders with profile 2 are created, and decoding a Main10 HEVC frame throws.
  • The H.264 cases are unchanged.
  • With Export.cpp from main, the test fails at Videodec2: unsupported codec.
• Platforms:
  • Linux (Ubuntu 24.04.5, GCC 13.3): guest_videodec2 passes.
  • Windows 11 (WinLibs GCC 15.2.0 r7): guest_videodec2 passes.
• EVO-PLAYER v0.11.0 built from source, on main f1451396 plus feat(libkernel): implement sigaction #1916, feat(libSceNet): implement sceNetResolverStartNtoaMultipleRecordsEx #1838, feat(libkernel): implement getdents and getdirentries #1634, feat(videoout): implement sceVideoOutGetResolutionStatus #1714, feat(libkernel): implement the sigset functions #1641, feat(libkernel): implement msync #1857 and fix(relinker): keep Linux imports declared from host modules off guest exports #1529, Linux, RX 7600:
  • All its resident decoders now come up (RESIDENT AVC/HEVC/VP9/HEVC10 decoder up).
  • Start-up goes on through its audio and AGC device setup.
  • It now stops at sceAgcCreatePrimState: invalid context register offsets, which is unrelated to this change.

Checklist

• Based on current main; no other open PR implements the same functions
• One topic per PR; follow-ups go in a new PR
• No comments in code except technical debt
• Unimplemented paths throw (NotImplemented_nid_no_patch); silent stubs are listed in TechnicalDebt
• No notes, investigation .md files or images added to the repository (attach them to this PR)
• New third-party code is a submodule built from source
• Generic behaviour, not specific to one title
• Depends on: none
• AI-assisted: yes

🤖 Generated with Claude Code

https://claude.ai/code/session_01DwFnKjMxmwGDWiuYYf1v4D

[klosixgaming-arch]

Reviewed against the repo's bar. This is a clean, well-scoped extension and I can approve it.

What holds up:

• CodecId centralises the codec dispatch and throws on any unknown tag, so no silent fallback. The create path calls CodecId(config->codecType) before allocating, which rejects bad tags early rather than after OpenCodec.
• 10-bit guard is the right call: av_pix_fmt_desc_get(...)->comp[0].depth > 8 throwing instead of silently converting is exactly what the repo wants for unknown console output layouts, and it's debt-documented.
• GetPictureInfo throws for HEVC/VP9 pictures rather than writing the AVC layout — correct, and the debt entry names the real separate layouts.
• Test coverage is real, not symbol-checks: 6-frame HEVC clip with B-frame display/decode ordering, an independent FFmpeg 9.0.2 reference hash comparison of every NV12 frame (12 distinct hashes), length-prefixed vs Annex-B for HEVC, Main10/Profile-2 create-plus-throw, and a negative control (main fails at unsupported codec). Good.

Notes (non-blocking):

1. The VP9 branch writes into decoder.annexB then points unit at it, whereas H.264/HEVC go through ToAnnexB. Confirm annexB isn't also holding an H.264 stream for a decoder that is both (it isn't — one codec per decoder) so the reuse is safe; just flagging the shared member.
2. QueryDecoderMemoryInfo reports the 8-bit size even for Main10/VP9-P2 decoders that then throw on decode. That's debt-documented and acceptable, but a title probing memory for a 10-bit buffer will get an undersized value — worth a sentence in the debt entry that the query also lies in that case (it currently only says the frame throws).

Written with AI assistance.

[johnmaia]

Thanks @klosixgaming-arch. On note 2: the debt entry already covers the query. It ends with "a decoder for HEVC Main10 or VP9 Profile 2 is created, but a frame deeper than 8 bits throws, since the console's 10-bit output layout is unknown, and QueryDecoderMemoryInfo reports the 8-bit frame size for it". On note 1: right, each decoder has one codec, so the shared annexB buffer only ever holds that codec's data.

[github-actions]

Other open pull requests touch the same code. Merging one will break the other, or both implement the same thing. If this one builds on them, list them in Depends on.

Pull request	Conflicting files (lines on main)	Same exports	Same new files
#1819	docs/dev/TechnicalDebt.md L355
#1831	docs/dev/TechnicalDebt.md L355
#1969	docs/dev/TechnicalDebt.md L355
#2052	docs/dev/TechnicalDebt.md L355
#2053	docs/dev/TechnicalDebt.md L355
#2054	docs/dev/TechnicalDebt.md L355