GPUOpen-LibrariesAndSDKs/AMF

[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

  1. 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
image

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.

  1. git clone https://github.com/21pages/gpucodec.git
  2. cd gpucodec && git checkout amf_h265_decode_resolution
  3. open vs/AMFTest/AMFTest.sln with visual studio and run.
  4. 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.

  1. I can reproduce the problem with your app.
  2. 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
  1. 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.
  2. AMF decoder supports both: Annex B form of compressed buffers or canonical format.
  3. But decoding shows corruption with Annex B only, if PlaybackHW converts from Annex B to canonical format the clip decodes OK
  4. At the same time similar clip produced with AMF works just fine in both cases (attached).
    out.zip
  5. The Vega Analyzer shows two identical errors with your clip:
    image
  6. 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.