NvDecoder fails to decode 4096x4096 yuv.

Hello everyone,

I have an issue with NvDecoder.
I can’t decode 4096x4096 yuv frame properly. The decoder just stop after one frame (not even complete), the video source get the packet flag CUVID_PKT_ENDOFSTREAM and stop the frame queue. I always have the CUDA_SUCCESS flag during the whole process.

I used the sample project in the Video Codec SDK 8.0.14 to test if it comes from my application but I have the same results.
The encoding seems fine because the only visible part of the frame in the output yuv is fine.

I prepared some files to explain my problem → [url]MEGA

• input_X.yuv are my source files.
• output_X.yuv are yuv generated by NvGLDecoder sample project.
• compressed_X.265 are HEVC lossless compressed file generated by my application.
• SDK_compressed_X.265 are HEVC lossless compressed file generated by NvEncode sample project.

There is a difference between yuv but it’s ok because I only use the Y componant.
I test with file 2048x2048, 2048x4096, 4096x4096 and the last doesn’t work.

I’m working on a GTX 1070 so I should handle HEVC lossless up to 4096x4096 according to the documentation NVIDIA VIDEO CODEC SDK | NVIDIA Developer.

My launch parameters are :
(encode) -i input_4096x4096.yuv -size 4096 4096 -o SDK_compressed_4096x4096.265 -codec 1 -inputFormat 0 -preset lossless
(decode) -i=SDK_compressed_4096x4096.265 -o=output_4096x4096.yuv -decodecuda

Are there any limitations I’m not aware of ? Any idea about where to look ?

Best Regards.
LM

Sorry, my post was wrong and I can’t see how to delete it.

We tested 4K HEVC lossless encode/decode and it works fine. We’d like to see if there is anything peculiar about the files you are using.

However, we are not able to access the files you shared at MEGA. It says “quota exceeded” every time I try.

Is it possible for you to share the files via Dropbox or Google Drive?

Sure, here it is :

[url]https://drive.google.com/file/d/0B3lOH0s8UFRpeVkwZVpTTnVkN1E/view?usp=sharing[/url]

We are able to access the files. It seems to be a bug in the parser code. It will be fixed in next release of the Video Codec SDK. Thank you for reporting.

Thanks for the answer, I can stop searching now.