[Question]: the upper portion is green with AMF H.265 Decoding at 1600x900, 1440x900 Resolution
21pages opened this issue ยท 6 comments
Describe the bug
I am encountering a peculiar issue while using AMF H.265 decoding at resolutions of 1600x900, 1440x900. The problem is that the upper portion of the video display appears with a green tint, whereas there are no issues when using H.264 decoding.
To Reproduce
Steps to reproduce the behavior:
using code: https://github.com/21pages/gpucodec/blob/main/amf/src/decode.cpp
- decode h265 at resolution 1600x900
Setup (please complete the following information):
- OS: Windows 11
- Driver Version: 31.0.12044.47003
- GPU: AMD Ryzen 7 5800H with Radeon Graphics
- Which component has the issue: Decoder
Debug Log (please upload or paste):
no error log
Expected behavior
normal
Screenshots
play decoded NV12 with yuvplayer
Additional context
Add any other context about the problem here.
I cannot repro the issue. I created a 1600x900 HEVC file using AMF EncoderLatency sample, played it with PlaybackHW sample or dumped raw NV12 with SimpleDecoder sample and verified with yuvplayer.exe. I used very similar GPU/APU.
- Could you please try to the update the driver? There is newer version on www.amd.com
- Could you please try to play the clip in PlaybackHW sample?
- Could you please share the HEVC clip? Seems it doesn't have cropping info in VUI header.
Thank you for your reply. I used PlaybackHW sample to play the H.265 file, and the display was normal. So this is not a bug with AMF. However, I don't know where the problem lies. I have written a runnable example, the h265 file is in the project, vs/AMFTest/test.h265
.
git clone https://github.com/21pages/gpucodec.git
cd gpucodec && git checkout amf_h265_decode_resolution
- open
vs/AMFTest/AMFTest.sln
with visual studio and run. - open
texture/texture.yuv
with yuvplayer, 1600x900, nv12
If I follow the example of SimpleDecoder and use BitStreamParser to set AMF_VIDEO_DECODER_EXTRADATA, and use BitStreamParser::QueryOutput to retrieve data, the decoded data is normal. However, my data source is real-time transmitted H.265 data, so I need to submit data directly.
- I can reproduce the problem with your app.
- I can reproduce the problem with AMF PlaybackHW sample if I change HevcParser class in BitStreamParserH265.cpp as:
- m_bUseStartCodes = true in HevcParser::HevcParser
- HevcParser::GetExtraDataSize() returns 0
- By default, HevcParser converts from Annex B (00 00 00 01 separator) to canonical format. The change above keeps buffers within Annex B as it is in the parsed file.
- AMF decoder supports both: Annex B form of compressed buffers or canonical format.
- But decoding shows corruption with Annex B only, if PlaybackHW converts from Annex B to canonical format the clip decodes OK
- At the same time similar clip produced with AMF works just fine in both cases (attached).
out.zip - The Vega Analyzer shows two identical errors with your clip:
- The HEVC clip produced with AMF doesn't show errors.
Conclusion: It seems the issue is in the clip, can be decoded in canonical format only.
Note: canonical format requires extradata.
More info: what's wrong with the clip: the clip actual height is 928. bottom cropping is 28. This is OK based on HEVC spec. But normally cropping is<16, as HEVC vertical alignment requirement is 16, there is no point to encode with cropping more than 15.
If extradata is not set, AMF initializes decoder using height aligned to 16: to 912 with cropping = 12, which causes the corruption. If extradata is set, AMF extracts height = 928 and cropping = 28.
I added some code to AMF runtime to extract the correct height and cropping regardless of source for SPS/PPS: extradata or the first frame. The update will come in the future drivers. In addition, I added to HevcParser ability to generate extradata in Annex B form if Annex B output is requested.
In addition, I added to HevcParser ability to generate extradata in Annex B form if Annex B output is requested.
If set extradata to AMF_VIDEO_DECODER_EXTRADATA
, can old driver decode Annex B format H265 correctly?
Yes. It should work with the older driver in extradata is set before Init call. But if you submit Annex B buffers, the extradata should be also a buffer with SPS/PPS/VPS NAL units in Annex B format, no sizes just pure NALs with 00 00 00 01 separators.