-
Notifications
You must be signed in to change notification settings - Fork 5.8k
cudacodec::VideoReader
: fix nv12 to bgr/bgra/grey conversion
#3468
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
cudacodec::VideoReader
: fix nv12 to bgr/bgra/grey conversion
#3468
Conversation
cudacodec
: fix nv12 to bgr/bgra/grey conversioncudacodec::VideoReader
: fix nv12 to bgr/bgra/grey conversion
2ea6f4a
to
2b476dd
Compare
I see build issue with my CUDA 10.2 on Ubuntu:
|
@@ -329,6 +329,7 @@ struct CV_EXPORTS_W_SIMPLE FormatInfo | |||
CV_PROP_RW cv::Size targetSz;//!< Post-processed size of the output frame. | |||
CV_PROP_RW cv::Rect srcRoi;//!< Region of interest decoded from video source. | |||
CV_PROP_RW cv::Rect targetRoi;//!< Region of interest in the output frame containing the decoded frame. | |||
CV_PROP_RW bool videoFullRangeFlag;//!< indicates if the black level, luma and chroma are using the full range 0-255. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The flag corresponds to BGR 709 HDTV (true) / RGB 709 CSC (false) conversion. I propose to use it naming or at least to define it in documentation string. Also, it makes sense to mention, that the flag is set automatically from stream parser.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The flag corresponds to BGR 709 HDTV (true) / RGB 709 CSC (false) conversion. I propose to use it naming or at least to define it in documentation string.
The flag indicates whether the luma and chroma samples are represented using the full range of 8 bit values (0-255) or a smaller range. From my understanding the limited range is the most common for video. This is applicable to BGRA, BGR and Gray conversion not just BGRA.
The name is to be consistent with the definition in Annex E of the ITU-T Specification (video_full_range_flag) and the name given internally in the Nvidia Video Codec SDK (videoFullRangeFlag). I can add these details to the documentation string but I think the name is valid?
Also, it makes sense to mention, that the flag is set automatically from stream parser.
Agreed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, let's presume naming, but add reference to BGR 709 HDTV / RGB 709 color spaces.
Apologies, it looks like it wasn't introduced until CUDA 11.0, I will add build guards for this. In my defence Nvidia's documentation doesn't mention this anywhere in the release notes, you have to manually go through the NPP documentation to see that it wasn't in CUDA 10.2 and was in CUDA 11.0, come on Nvidia!! I promise I will be more rigorous next time. |
2b476dd
to
d996792
Compare
Updated and tested on Windows 11 built with VS2019 against CUDA toolkit 10.2 and the latest version of Nvidia Video Codec SDK (12.0). All cudacodec tests passing on RTX 3070 Ti. |
Works for me with CUDA 10.2 and Ubuntu 18.04. |
nppSafeCall(nppiNV12ToBGR_709HDTV_8u_P2C3R_Ctx(pSrc, decodedFrame.step, outFrame.data, outFrame.step, oSizeROI, nppStreamCtx)); | ||
else { | ||
#if (CUDART_VERSION < 11000) | ||
CV_LOG_DEBUG(NULL, "Color reproduction may be inaccurate due CUDA version <= 11.0, for better results upgrade CUDA runtime or try ColorFormat::BGRA."); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I propose to make the check in constructor, and use LOG_INFO to not generate spam. M.b. could you also add own conversion kernel for BGR in the same way as BGRA?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I propose to make the check in constructor, and use LOG_INFO to not generate spam.
Unfortunately that information isn't available until a frame has been run through the decoder. This is something I've wanted to change for a while and was going to add in another PR. Should I add that change to this PR or simply remove the debug output which is not really necessary?
M.b. could you also add own conversion kernel for BGR in the same way as BGRA?
Actually I would prefer to remove the BGRA kernel. Much as I am not a fan of the NPP libs (buggy, performance oscillates depending on the CUDA version etc.), they should be the best option for performance on future hardware + they should get more user testing than the OpenCV CUDA modules.
Let's stay it as is then. Let's merge things as is for now and tune the behavior later. |
Fixes #3458.
Dependent on opencv/opencv_extra#1051
Pull Request Readiness Checklist
See details at https://github.com/opencv/opencv/wiki/How_to_contribute#making-a-good-pull-request
Patch to opencv_extra has the same branch name.