GPUOpen-LibrariesAndSDKs
[Bug]: At some point transcoding some corrupted sources started to cause encode to fail.
Describe the bug Not sure if it is bug, but... Some old corrupted sources i had (for testing purposes), stopped encoding at some point. 2 of these sources just have some corrupted frames and one source have extremely weird "flicker" between interlaced and non-interlaced frames. They came from same source, even if from different files.
Tbh, i was not much interested in sources corrupted frames, as original issue related to those was fixed at some point AMF: https://github.com/GPUOpen-LibrariesAndSDKs/AMF/issues/446
But i still tested third source transcode of which with HW decoder in use produces output that skips encode of about 20 minutes of video track. Just in case something has changed with time (sadly, it did not same as corruption on seek/timeskip with HW decode on source that only containes non-IDR keyframes). AMF: https://github.com/GPUOpen-LibrariesAndSDKs/AMF/issues/458
... Anyways, different issue related to these sources came up recently (presumably with 25.5.1 driver, aka AMF Runtime 1.4.37?) Now instead of just affecting output they cause encode to completely fail. Moreover, while VCEEnc throws out some weird error, TranscodeHW suddenly starts to load CPU until terminal window is closed, despite having no progress.
To Reproduce Steps to reproduce the behavior:
- Use TranscodeHW (even though issue is not limited to it)
- Most basic command line is enough
%~dp0\TranscodeHW.exe -input %1 -output "%~n1_TranscodeHW_1%~x1" - Use one of these sources. https://drive.google.com/file/d/1pmUASEYTY-5Xm_Vbp8k9OretFHWsPyzw/view?usp=drive_link https://drive.google.com/file/d/1wqV-5G8kf9CvgMtuXyjg8p9l8QRnOt58/view?usp=drive_link
Third file (with switching interlaced frames) is bit too large, so i won't apply it as unnecessary for this particular issue.
Setup (please complete the following information):
- OS: Windows 11, 23H2, build 22631.5262
- Driver Version: 25.5.1
- GPU: RX 9070 XT
- Which component has the issue: Decoder? Encoder? Both?
Debug Log (please upload or paste):
2025-05-11 04:01:31.837 3434 [h264_hevc_util] Error: C:\constructicon\builds\gfx\six\25.10\drivers\amf\stable\runtime\src\components\VideoStreamParser\parsers\common\h264_hevc_util.cpp(369):Assertion failed:element=pCurrSlice->start_mb_nr val =4080 out of range(0,4079)
2025-05-11 04:01:31.837 3434 [H264Parser] Error: C:\constructicon\builds\gfx\six\25.10\drivers\amf\stable\runtime\src\components\VideoStreamParser\parsers\h264\H264Parser.cpp(2656):AMF_ERROR 5 : AMF_OUT_OF_RANGE: FirstPartOfSliceHeader() failed
2025-05-11 04:01:31.837 3434 [H264Parser] Error: C:\constructicon\builds\gfx\six\25.10\drivers\amf\stable\runtime\src\components\VideoStreamParser\parsers\h264\H264Parser.cpp(1890):Assertion failed:ProcessSlice() failed
2025-05-11 04:01:31.837 3434 [H264Parser] Error: C:\constructicon\builds\gfx\six\25.10\drivers\amf\stable\runtime\src\components\VideoStreamParser\parsers\h264\H264Parser.cpp(2137):Assertion failed:ret != READ_ERROR
2025-05-11 04:01:31.837 3434 [AMFVideoStreamParserImpl] Error: C:\constructicon\builds\gfx\six\25.10\drivers\amf\stable\runtime\src\components\VideoStreamParser\VideoStreamParserImpl.cpp(201):AMF_ERROR 1 : AMF_FAIL: SubmitInput : m_pVideoParser->ParseBuffer
2025-05-11 04:01:31.838 3434 [AMFDecoderUVDImpl] Error: C:\constructicon\builds\gfx\six\25.10\drivers\amf\stable\runtime\src\components\DecoderUVD\DecoderUVDImpl.cpp(666):AMF_ERROR 1 : AMF_FAIL: SubmitInput() - Parser SubmitInput Failed
SubmitInput() returned error: AMF_FAIL
Expected behavior I would assume for it to be normal that encode should finish for these sources. (Until it started to fail just some frames were skipped, or distortion was transcoded at corruption locus)
Well, at some point AMF updated elementary stream parsers to make them more strict and added checking for errors. Now instead of producing corrupted frames decoder just fails. This is expected. Caller app should check for errors and react. There were many reasons for such change including security considerations. Try FFmpeg, they have similar checking.
Thank you for response.
Tried ffmpeg SW - SW encoder. Produced output for all 3 samples. Dropped corrupted frames (1/1/3). It indeed throws an error on corrupted frame, but in the end it still does full encode. Two others produce no errors, but warnings. [Just in case i tried H264, HEVC and AV1. Outside of AV1 absolutely awful 0.1 fps encode speed they all produced valid output]
SW decoder - HW encoder Produced output for all 3 samples. Dropped corrupted frames (1/1/3) Threw error on one sample. Did not error on two others. [Also fully encoded that interlaced source, but i guess it is just SW decoder robustness]
D3D11VA decoder. Produced output for all 3 samples. Dropped corrupted frames (1/1/X) Threw error on 1 output, and stopped encoding on interlacing fragment of third sample [which is separate issue, and i don't really know on whose side it is to address, and source for this issue is pretty much unique].
AMF decoder. All 3 encodes completely stopped at 0 frames encoded on every source. And for each such encode ffmpeg instance continued to consume CPU cycles until i closed terminal window. Same behaviour is with TranscodeHW.
[h264_amf @ 0000013a5215f480] SubmitInput() returned error 1
[vist#0:0/h264 @ 0000013a5102ee00] [dec:h264_amf @ 0000013a5215f200] Error submitting packet to decoder: Invalid argument
I am not against throwing an error/warning/flag on corrupted frame. But i don't think that it should completely break encode, only drop corrupted frame.
If it is on application side to implement automatic drop of corrupted frames, then i will just create issue for VCEEnc. But ffmpeg and TranscodeHW are also affected. Thus me opening first issue here.
AMF decoder returns error code on corrupted input. It is up to the calling app to react. Current implementation in AMF samples (TranscodeHW and PlaybackHW) and in FFmpeg to return error to upper layer and eventually abort. The question is: do we/AMF team want to deal with every corrupted file and explain why frames are dropped or just report a error? Abort makes sense for AMF samples, FFmpeg - debatable, VCEEnc - can ignore submission error and continue.
VCEEnc made detection on start of encode to switch to software decoder if malformed input is detected. So in theory this issue can be closed. But i got another question.
As i tested out some of my samples i can now see that it is not just corrupted frames that are being detected, but whole video streams from the get go (aka if corrupted spot is 1 hour into video stream, every frame at the beginning of the stream still triggers corruption detection)...
So i tried to play corrupted samples i had in PlaybackHW. These old ones with single digit corrupted frames that crashed driver long time ago (it was fixed). So now they play with half viewport being green.
As i know that these are malformed in some way (but only singular frames actually had damaged parts), i now wonder why whole video shows as half-green. (and on cycle, aka second or more playback, that green part flickers green->black->green).
So this is mostly a question of "if this supposed to happen?" or is this something that should not be a thing?
[Sample in context: https://drive.google.com/file/d/1wqV-5G8kf9CvgMtuXyjg8p9l8QRnOt58/view?usp=drive_link But two other sample also had such behaviour. ]
P.S. Also Vulkan presenter has a trip with these videos. It plays video as if it has splitted playback between two separate timestamps seconds apart and flickers between future and past timestamped video playing them back simultaneously. In addition to having half of the viewport green.