-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Add standalone NVENC encoder #1427
Conversation
0d3cee2
to
6836c6e
Compare
LGTM. Let's try to get this refactoring in soon if possible. I've got some AV1 and client-side cursor changes that I'd like to work on, but I don't want to stomp all over your work. If you can back out any debugging changes or WIP test changes (the scheduling priority revert?), I can test this across all my systems and we can get it merged. |
Understandable. Wired the encoder to use the existing configuration page, since some new options pretty much depend on whether I can make it work with realtime priority (and priority selection itself will add another option). Haven't tested native HDR (only SDR in BT.2020) and CUDA path on Linux (didn't make drastic changes, but there's always a chance). Other than that, should be alright to merge in its current state. The rest of the features shouldn't produce conflicts, and can be done in later PRs. |
3ea8f10
to
a318da3
Compare
The latest changes look good. Once you squash the fixup commits and rebase, I'll do a final testing pass on my local machines and we can get this in. |
Shouldn't matter on x64 since everything is fastcall here, but cdecl is the correct declaration.
Squashed and rebased. Also added small "fix" for nvapi, it doesn't affect anything since we're strictly x64, so no point in opening full pull request for it. |
Everything looks good in my tests:
|
Description
Add standalone NVENC encoder for reference frames invalidation right now. And possibly for VFR-like bitrate adjustment and more somewhere down the line. Windows version is fully functional . Linux cuda (and possibly opengl) support is out of scope for this PR, but can easily be done later (at least the encoder side),
In later PRs
Type of Change
.github/...
)Checklist
Branch Updates
LizardByte requires that branches be up-to-date before merging. This means that after any PR is merged, this branch
must be updated before it can be merged. You must also
Allow edits from maintainers.
Things to implement before merge (may be expanded)
Result: use 5 ref frames buffer, which corresponds to DPB=5 in h264 terms, and DPB=6 in HEVC. Both are required minimums that must be supported by decoder profiles for given resolution.
Update: h265 level 4 only supports 4 ref frames, but in this case the client can set the limit, this level is very outdated nowadays
Verdict: when L0 (forward prediction) list size is 1, it should always use last frame as reference,
Verdict: may be possible for h264, close to impossible for HEVC, either way too much hassle
NV_ENC_CAPS_SUPPORT_CABAC
NV_ENC_CAPS_WIDTH_MAX
NV_ENC_CAPS_HEIGHT_MAX
NV_ENC_CAPS_SUPPORT_CUSTOM_VBV_BUF_SIZE
NV_ENC_CAPS_SUPPORT_REF_PIC_INVALIDATION
NV_ENC_CAPS_SUPPORT_YUV444_ENCODE
NV_ENC_CAPS_SUPPORT_10BIT_ENCODE
NV_ENC_CAPS_SUPPORT_MULTIPLE_REF_FRAMES
NV_ENC_CAPS_SUPPORT_QPELMV
Use Peak-Signal-to-Noise-Ratio (Y-PSNR), Structural Similarity Index (Y-SSIM), and Video Multimethod Assessment Fusion (VMAF) for default min qp valuesNot in this PRAdd configuration page and documentationNot in this PRFrom review