Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug]: MJPEG decoder crashes with some JPEGs #469

Open
Alex18947 opened this issue Apr 2, 2024 · 3 comments
Open

[Bug]: MJPEG decoder crashes with some JPEGs #469

Alex18947 opened this issue Apr 2, 2024 · 3 comments
Labels
bug fixed-in-future-release A fix has been made internally and is awaiting to be included in a future public driver release.

Comments

@Alex18947
Copy link

Description:

Passing certain JPEGs to the AMF MJPEG decoder crashes the decoder, an access violation error in amdxx64.dll can easily be produced.

To Reproduce:

  1. Create a decoder component with AMFVideoDecoderUVD_MJPEG.
  2. Create an AMFBuffer from the sample jpeg file attached.
  3. Submit the input frame with the SubmitInput method.

Setup:

  • OS: Windows 11
  • Driver Version: 24.3.1 (latest)
  • GPU: tested with AMD Radeon 740M

Additional context
I have not checked the jpeg file for absolute correctness, but it looks fine when opening in most apps. So I would definitely not expect a driver crash of this kind. We observed these errors from time to time with our application and were able to save a sample of the JPEG data that is causing the problem for us. With this file, we can always reproduce the crash in our testing environment.

Sample JPEG file causing the crash:

test.zip

@Alex18947 Alex18947 added the bug label Apr 2, 2024
@rhutsAMD
Copy link
Collaborator

I found that the provided file “test.jpg” has some metadata which causes the AMFVideoDecoderUVD_MJPEG to act up. The “comments” section of the metadata is particularly suspicious.

image

I have created an internal ticket to the decoder folks to address this issue with handling the metadata. Scrubbing the metadata from the file allows decoding to proceed without issue. You can use this as a workaround for now until the fix is released in a public driver update.

@Alex18947
Copy link
Author

Thanks for looking into this. Yes, the comment is unusual to say the least. These images are coming from IP cameras out of our control. Knowing the nature of the issue, getting rid of the comment is a viable idea for us. It would be great though if the API just returned some error result in such cases or even in cases when frames are corrupted (like I see e.g. here).

Thanks.

@rhutsAMD
Copy link
Collaborator

The issue has been fixed internally and the fix will be available in a future public driver release.

We will notify when the release is made publicly available.

@rhutsAMD rhutsAMD added the fixed-in-future-release A fix has been made internally and is awaiting to be included in a future public driver release. label Jun 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug fixed-in-future-release A fix has been made internally and is awaiting to be included in a future public driver release.
Projects
None yet
Development

No branches or pull requests

2 participants