With reference to parser triggered callbacks the docs state that
Parser triggers callbacks registered while creating parser object synchronously from within cuvidParseVideoData(), whenever there is sequence change or a picture is ready to be decoded and/or displayed. If the callback returns failure, it will be propagated by cuvidParseVideoData() to the application.
however I am not sure exactly how this should work. For example if decodecaps.bIsSupported==false and I return 0 (fail, see below) from the CUVIDPARSERPARAMS::pfnSequenceCallback
/***********************************************************************************************************************/
//! Parser callbacks
//! The parser will call these synchronously from within cuvidParseVideoData(), whenever there is sequence change or a picture
//! is ready to be decoded and/or displayed. First argument in functions is "void *pUserData" member of structure CUVIDSOURCEPARAMS
//! Return values from these callbacks are interpreted as below. If the callbacks return failure, it will be propagated by
//! cuvidParseVideoData() to the application.
//! Parser picks default operating point as 0 and outputAllLayers flag as 0 if PFNVIDOPPOINTCALLBACK is not set or return value is
//! -1 or invalid operating point.
//! PFNVIDSEQUENCECALLBACK : 0: fail, 1: succeeded, > 1: override dpb size of parser (set by CUVIDPARSERPARAMS::ulMaxNumDecodeSurfaces
//! while creating parser)
//! PFNVIDDECODECALLBACK : 0: fail, >=1: succeeded
//! PFNVIDDISPLAYCALLBACK : 0: fail, >=1: succeeded
//! PFNVIDOPPOINTCALLBACK : <0: fail, >=0: succeeded (bit 0-9: OperatingPoint, bit 10-10: outputAllLayers, bit 11-30: reserved)
/***********************************************************************************************************************/
I would expect the error to be propagated and cuvidParseVideoData() to return an error but it always returns CUDA_SUCCESS. Is this the expected behaviour?
Digging through the sample code it looks like the any failures inside PFNVIDSEQUENCECALLBACK are dealt with by throwing exceptions. Is this the recommended way to deal with errors inside the callbacks.
Hi @cudawarped,
since this is more of a question on coding paradigms in CUDA than about video codecs, I took the liberty of moving the question to the CUDA forums. I hope that is ok.
Thanks!
Do you think anybody is going to answer it?
Possibly @Robert_Crovella might want to comment, or knows someone from the wider CUDA team who could?
I don’t have any information on it. It’s not a CUDA question from what I can see, and the correct place for it on our forums as far as I can tell, was the original spot where it was posted. The question is asking about the expected behavior of cuvidParseVideoData which is not part of the CUDA toolkit. I can move the question back to its original spot, if desired.
1 Like
From my experiance I think it is unlikely. I don’t think any of the Nvidia Video Codec SDK developers answer posts on this forum so the only answers you are likely to get are going to be opinions from other users. This is a shame for me because it would be nice if I could integrate this more fully with OpenCV but without support its not worth my time.
1 Like
I was getting an exception from cuvidParseVideoData when decoding an AV1 GOP (it never calls Handle_Picture_Display, just Handle_Picture_Decode). The code worked with H264. I ran the GOP through ffmpeg and it sees a lot of problems with it too, i.e. :
[h264 @ 000001c555be3dc0] missing picture in access unit with size 104
[extract_extradata @ 000001c555bb8100] No start code is found.
0000.av1: could not find codec parameters
[NULL @ 000001c555be3dc0] missing picture in access unit with size 163
Last message repeated 1 times
[NULL @ 000001c555be3dc0] missing picture in access unit with size 205
[NULL @ 000001c555be3dc0] missing picture in access unit with size 1710
[NULL @ 000001c555be3dc0] missing picture in access unit with size 1859
[NULL @ 000001c555be3dc0] missing picture in access unit with size 3953
[NULL @ 000001c555be3dc0] missing picture in access unit with size 6067
[NULL @ 000001c555be3dc0] missing picture in access unit with size 6150
[NULL @ 000001c555be3dc0] missing picture in access unit with size 6717
[NULL @ 000001c555be3dc0] missing picture in access unit with size 8630
[NULL @ 000001c555be3dc0] missing picture in access unit with size 9713
So I conclude there’s an issue with my encoder impl for AV1. But I have to guess at it without more useful error validation/info.
The statement “if the callbacks return failure, it will be propagated by
cuvidParseVideoData() to the application” was initially added to nvcuvid.h in SDK 9.1 and then added to the NVDEC programming guide in a later version. This indeed looks really confusing, and imho is probably a documentation error. cuvidParseVideoData() returns a CUDA driver API error code, and does not forward the user-provided error codes from the callbacks. The intended behavior of the callbacks, I believe, is that if anyone returns an error code representing failure, the other subsequent callbacks will be skipped. For instance, if the decode callback fails, the picture-display callback will not be triggered.
What you observed seems a bug in the driver specific to the sequence callback. I wonder if @mandar_godse could help and comment on this issue.
PS: In my experience, cuvidParseVideoData() also returns success even when CUDA errors have occurred in the callbacks, from the out-of-memory error to the more serious misaligned-memory-access error (which requires host process to be terminated).
1 Like
Thank you @Robert_Crovella, I think you are right, I misinterpreted the request. Moving the topic back.
And thank you to @King_Crimson for tracking this down and adding Mandar to the discussion.