BETA CUDA interface: support for approximate mode and time-based APIs #917
+207
−148
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
meta-cla
bot
added
the
CLA Signed
NicolasHug
changed the title
NicolasHug
changed the title
This was referenced Oct 3, 2025
scotts
reviewed
Oct 3, 2025
|
|
||
| static int CUDAAPI | ||
| pfnDisplayPictureCallback(void* pUserData, CUVIDPARSERDISPINFO* dispInfo) { | ||
| BetaCudaDeviceInterface* decoder = |
There was a problem hiding this comment.
Nit: I prefer auto when the expression on the right has the literal type we're getting on the left.
scotts
reviewed
Oct 3, 2025
| parserParams.pfnSequenceCallback = pfnSequenceCallback; | ||
| parserParams.pfnDecodePicture = pfnDecodePictureCallback; | ||
| parserParams.pfnDisplayPicture = nullptr; | ||
| parserParams.pfnDisplayPicture = pfnDisplayPictureCallback; |
There was a problem hiding this comment.
This is the key difference, correct? That is, by registering this callback, we get the new behavior and can delete all of the relevant code?
There was a problem hiding this comment.
yes that's correct
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR:
If we weren't relying on the NVCUVID callback, then we would have to solve both problems above ourselves, with codec-specific solutions. As a resut this PR also drastically simplifies future support for additional codecs - spoiler, I already added #919 and #920 for HEVC and AV1.
In #910, I described this design alternative and at the time, I thought it wasn't compatible enough with our
sendPacket() / receiveFrame()architecture. With #910 now merged as a minimal clean-ish skeleton of the interface, I can reason about this more clearly. And after spending a few days trying (and failing) to solve the frame-reordering problem for H264 only, I came to the conclusion that this solution, in this PR, is well worth it.This new simplified design does come with a minor trade-off. I explain it in a note, in the code.
Why is approximate mode and time-based APIs now supported? Let's first answer: why was approximate mode and time-based APIs not supported before? It was because
receiveFrame(avFrame, desiredPts)was only able to return a frame if we were able to find one with the exactdesiredPts. On approximate mode, we can't guarantee that desiredPts corresponds to a frame's pts, so there generally can't be a match. Same with time-based APIs: desiredPts may not correspond to where a frame starts.In this PR, we don't need that exact
desiredPtsmatching logic anymore. But we can still guarantee thatreceiveFramereturns frames in display order, so we got approximate mode and time-based support for free.