During few other investigations i found out that some flags do not properly apply in some conditions.

1. AVC and HEVC cannot be set to --preset slower. AV1 one works properly. [VCEEnc accepts input, but sets --preset slow instead]
   Also not sure about AVC --preset fast. But because from TranscodeHW output i also get only two disctinct patterns [speed+balanced]/[quality+highquality], i assume it should work?
   HEVC should definitely have 4 distinct encoder presets, based on testing, though.
   VCEEnc reports that they encode on slow preset, though [comparing outputs also show that slower preset did not apply properly]:

%~dp0\VCEEncC64.exe -i %1 -o "%~n1_[AVC_VBR10000_slower]%~x1" --codec avc --vbr 10000 --max-bitrate 30000 --preset slower
Output:        H.264/AVC  High @ Level 4.1
               1920x1080p 1:1 23.976fps (24000/1001fps)
               avwriter: h264 => matroska
Quality:       slow
VBR:           10000 kbps
Max bitrate:   30000 kbps

---

%~dp0\VCEEncC64.exe -i %1 -o "%~n1_[HEVC_VBR10000_slower]%~x1" --codec hevc --vbr 10000 --max-bitrate 30000 --preset slower
Output:        H.265/HEVC  main @ Level 5.1 (main tier)
               1920x1080p 1:1 23.976fps (24000/1001fps)
               avwriter: hevc => matroska
Quality:       slow
VBR:           10000 kbps
Max bitrate:   30000 kbps

2. HEVC --ltr 14 produces throughly corrupted output in which only IDR frames (keyframes) can be decoded properly, but does encode completely silent (aka no errors). --ltr 15 and higher, on other hand, just do not encode at all, producing stream of errors for every single frame (it does not stop after single set of errors).
   [reference] For AVC VCEEnc breaks encode instantly after LTR cap goes above 15, as 15 is max amount of LTR that can be set.
   [reference] TranscodeHW (AMF reference) throws an error for HEVC if i set >13 LTR.
   2025-08-04 01:20:04.970 CBC8 [EncodeCore] Error: c:\constructicon\builds\gfx\one\25.10\drivers\enc_core\uve\hevcuvepicturemanager.cpp(1443):Failed to find any picture storage for current decoded picture.
   [UPD: Hmm, i tested TranscodeHW with more gradation, and i guess it does indeed write LTR=14 in the same way, but still throws same error... Weird. So writing output this way probably is not VCEEnc issue, but i guess error can be parsed?]

Hmm, now that i think about it... That is actually similar to what happens in this issue: GPUOpen-LibrariesAndSDKs/AMF#563
I have source that produces single corrupted GOP on same exact principle if i use HEVC, preanalysis and automatic LTR management.
May that referenced issue be somehow related? Not sure if VCEEnc has anything to deal with these flags.
[UPD: Maybe they are, but after doublechecking issues between outputs are not quite same. Basically single frame error vs every P frame being corrupted type of difference.]

UPD2: this second issue (with HEVC and LTR=14) was accepted on AMF side, not sure about what will happen with it next.