Releases: 2600th/dlss5-video-player
Release list
dlss5-video-player-v0.23.0
Windows x64, an RTX GPU and NVIDIA driver 610.47 or newer. Community project, not an
NVIDIA product; the neural runtime is a modified, unsigned community build.
Download dlss5-video-player-v0.23.0-win64.zip below - player plus the pinned neural
runtime, assembled by the maintainer and attached before this release was published.
DLSSVideoPlayer-v0.23.0-core-win64.zip is the player alone, with no runtime in it,
built and attested by CI. Each has a .sha256 beside it; GitHub's "Source code" zip
does not run.
0.23.0 (2026-09-16). A verification pass over the whole player, with
seven audits read against the source and the findings fixed rather than filed.
Two of them a user could have met: Save converted video after a live session
used to write the last rendered hole under the film's name - toggle neural on at
0:20 and the saved file was twenty seconds long - and is now offered only when a
single render covered the whole video; and a cancel that reached the neural
helper just after a job had finished cancelled the next job before its first
frame, which is fixed and tested with a real command channel.
When the graphics device is removed or stops responding during playback, the
player now stops, says so in the status bar and rebuilds its renderer once
instead of freezing the picture with the audio still running; an export no
longer retries a frame up to 120 times on a dead device. A render whose backend
evaluated fewer frames than were captured is refused - the check that was meant
to catch that compared a number with a copy of itself. Switching streams no
longer leaves the player describing the previous one, a decode-thread
allocation failure ends that playback instead of the player, every helper
child has a wall-clock bound, and YouTube streams are fetched with certificate
verification forced on and only https/tls/tcp allowed. Partial downloads
and refused renders parked under the cache's staging/ are reaped a few per
launch instead of accumulating until a manual clear.
Both executables ship with Control Flow Guard and CET compatibility. Releases
are now created as drafts - so the complete package the notes name is attached
before anything is public - with every workflow action pinned to a commit and a
provenance attestation on the CI-built core package. Two agent-era planning
documents are retired, the guides that ship in the package are corrected, and
each carries a Verified against line that the release gate checks.
Every detail, including what was measured: CHANGELOG.md for 0.23.0.
Full Changelog: dlss5-video-player-v0.22.0...dlss5-video-player-v0.23.0
dlss5-video-player-v0.22.0
Windows x64, an RTX GPU and NVIDIA driver 610.47 or newer. Community project, not an
NVIDIA product; the neural runtime is a modified, unsigned community build.
Download dlss5-video-player-v0.22.0-win64.zip below - player plus the pinned neural
runtime. DLSSVideoPlayer-v0.22.0-core-win64.zip is the player alone, with no runtime
in it. Each has a .sha256 beside it; GitHub's "Source code" zip does not run.
0.22.0 (2026-09-16). A session now renders the whole video, not one run
forward from where you pressed D. Coverage is a set of rendered regions: the
part you are watching is rendered first, then the rest, nearest the playhead,
and the status line says how much of it is done. Seeking is no longer limited to
what has been rendered - land in rendered frames and playback continues on them
wherever they are on the timeline; land in frames nobody has rendered and the
original plays there at once while the render moves to that part of the video.
Nothing already rendered is discarded when you seek, which is what the old
behaviour did: it deleted every segment the new playhead was not inside and
rendered those seconds again.
Colour was wrong in every render before this. The encoder tagged the file
only when the GPU did the conversion, so a BT.709 source became a file that
declared no colour space while carrying BT.601 pixels - a pure-red frame came
back Y=81 U=90 V=240 - and any player that assumes BT.709 for HD, which is the
usual default, showed those colours shifted. Renders now state bt709/tv and
convert to match. The Motion vectors switch also changes the picture again:
it had been zeroing the CPU grid while the hardware flow pass kept writing the
texture NGX reads, so turning it off paid a full re-render and produced
identical pixels.
Two things that made playback stutter are gone. Asking whether a stream's cached
copy existed hashed 60 MiB of it, six times a frame, on the thread that draws:
the same clip and machine went from FPS 1 rendered / 30 source with 1877
dropped to 30 / 30 with 25 dropped. And the decode pipe was sized for two
1080p frames, so a 1440p source ran at 28.85 fps against its 30; it now holds
29.93. Turning neural rendering on a second time in one session reaches a
picture in 2.44-2.52 s instead of 5.23-5.41 s, because the helper stays
alive between jobs and exits after 30 s idle.
Seeking during a live render got the rest of the work. Seeking back on a YouTube
video used to turn neural rendering off: the seek re-resolves the stream,
rendering is unavailable for those two seconds, and two refusals in a row
counted as a session that had failed. A stream also stops being a stream once
its copy is on disk - a render always works from a local copy, and playback now
moves onto that copy the first time a seek would have gone back to the network,
so seeks take 223-345 ms instead of 1.2-1.9 s. The render waits a second for
you to stop moving before it follows: tapping the seek key six times used to
restart the job five times and render nothing while you did it. You see the
original a moment longer where you landed, and the render keeps working instead.
A finished part also used to hold the next one back for 18 seconds. That was one
call: checking the joined file asked FFprobe to decode every frame to count
them - 23.8 s on a 1440p render - where the same count comes out of the container
in 0.05 s. The wait is now about a second on a clip of this length, and it still
grows with the render, so a feature-length video will want the next round of
this. The speed on the status line is the render's speed again, not the
download's: a first watch spends its first minute fetching the video, and that
was being averaged in.
Renders made by earlier versions are retired on purpose - the cache key now
carries the driver version and a digest of the model files - so the first render
of a video after upgrading is made again.
Every detail, including what was measured: CHANGELOG.md for 0.22.0.
Commits in this release
What's Changed
- Compile the same program for tests and release, straighten the decode/UI layering, and find Visual Studio 2026 by @ctype-lab in #10
- refactor(neural): compile and inject the offline renderer's collaborators instead of selecting them by macro by @ctype-lab in #11
New Contributors
- @ctype-lab made their first contribution in #10
Full Changelog: dlss5-video-player-v0.21.2...dlss5-video-player-v0.22.0
Contributors
Assets 6
0.21.2 - a live session no longer plays one frame forever
A live session could get stuck on one frame.
If the render's first finished segment began a frame later than the playhead - 12.0662 s against 12.0329 s - playback refused to join it, the stalled-attach recovery restarted the same session at the same instant, and it repeated until the clip ran out while the render kept publishing segments. Playback now joins at the first rendered frame, and the recovery is bounded to one restart before the session ends and hands the original stream back.
Also in this release:
- Video > Compare > Wipe has a divider you can see on bright footage: a white core inside a dark edge, instead of a single white pixel column that vanished into a white shirt or a sky. Presentation only - exports and cached frames are unchanged.
- A comparison mode refused for want of a resident pair says so in the log instead of doing nothing silently.
- A play press made while the neural buffer fills shows on the button, and the status line says whether the fill will start playback or stay paused.
- A neural toggle pressed during a seek is queued and applied when the seek lands.
The README has a new 21-second demonstration video: The Godfather and GTA VI, each paused and magnified 2x in the player, split down the face with the original on the left and the render on the right, then playback with the render running ahead. Live 2560x1440 sessions on an RTX 5090, recorded as they ran.
| Package | What is in it | Size |
|---|---|---|
dlss5-video-player-v0.21.2-win64.zip |
Player plus the pinned neural runtime. This is the one you want. | 308 MB |
DLSSVideoPlayer-v0.21.2-core-win64.zip |
Player only, no neural runtime. | 31 MB |
Needs Windows, an RTX card and NVIDIA driver 610.47 or newer. Community project, not an NVIDIA product; the neural runtime is a modified, unsigned community build.
Full Changelog: dlss5-video-player-v0.21.1...dlss5-video-player-v0.21.2
dlss5-video-player-v0.21.1
dlss5-video-player-v0.21.0
dlss5-video-player-v0.20.1
dlss5-video-player-v0.20.0
0.19.0 - NVDEC/NV12 export transport
Experimental build. Community project, not an NVIDIA product; the neural runtime is a modified, unsigned community build.
Get it
| Download | What it is | Size |
|---|---|---|
dlss5-video-player-v0.19.0-win64.zip |
Player plus the pinned neural runtime. Take this one. | 308 MB |
DLSSVideoPlayer-v0.19.0-core-win64.zip |
Player only, no neural runtime. | 31 MB |
Unzip into a new empty folder, keep neural-runtime/ next to the exe, run DLSSVideoPlayer.exe, press D. The .sha256 files match the zips beside them. The "Source code" archives do not run.
Needs NVIDIA driver 610.47 or newer. Feature 18 lives in the driver's own NGX core, so an older driver refuses the render whatever the card is. Checked on an RTX 4080 SUPER and an RTX 5090.
What is new
Export transport moved onto the GPU's engines. NVDEC decodes the source, the pipe carries NV12 instead of BGRA (4.2 MB rather than 11.1 MB per 2578x1080 frame), NVENC gets its CUDA context at spawn, and the local-file queue thread blocks on the pipe instead of poll-sleeping. On an RTX 5070 Ti at 2578x1080: 7.8 to 4.2 ms per frame with presents off, first-frame stall on each live segment 126 to 59 ms, 389 encoder write stalls of 10 ms or more down to none. With presents on, the loop is the neural evaluate itself at about 8.4 ms, so roughly 0.4 ms of pipeline overhead is left.
DLSS > Encoder settings. NVENC preset p1-p7, plus switches for where each colour conversion runs. Separate window from the model settings, because these apply to the next render and leave cached renders valid. All three settings windows resize now.
Both conversion switches ship off. GPU capture conversion measured slower than the CPU path while the neural pass is running (8.35 against 8.66 ms), and GPU source conversion assumes BT.709 limited range while nothing reads the source's colour tags yet, so an SD or full-range clip would render with shifted colour.
Fixes
- Opening a second settings window freed the first one's tooltip text while its tooltips were still attached. Reachable on any card.
- Settings windows sized their frame at 96 dpi, so on a scaled display the buttons landed on top of the note text.
- A cancelled decoder read threw away bytes it had already taken out of the pipe, which would shift every later frame in that session.
hevc_nvencasks forautosplit encode rather thanforced: a card that refuses forced striping made the whole export fall back to software H.264 with nothing in the log.
Most of the transport work is ctype-lab's PR #6, squashed. Full detail in CHANGELOG.md.
dlss5-video-player-v0.18.0
DLSS Video Player v0.17.2
Download dlss5-video-player-v0.17.2-win64.zip (308 MB) unless you already have the neural runtime. The core zip is the player on its own. A .sha256 sits beside each one.
The feature-18 failure is fixed
If your render stopped with "A frame was not produced by feature 18", this is the release to try. The player was releasing and rebuilding its DLSS feature 60 presents into a job. That is the same window in which it re-presents one frame, up to 120 times, waiting for the neural add-on to publish a fresh evaluation. Releasing the feature there tore down the add-on's neural state, so the count it was waiting for never moved again. Whether a machine survived that was luck, which is why the same build worked here and failed on a 4070 Ti (#4) and an RTX PRO 6000 (#3). The feature is now built once and kept for the whole job.
Checked on an RTX 4080 SUPER: 313 of 313 frames verified in a live session, past evaluation #300, on a single CreateFeature.
Also in this build
- Small sources upscale again. DLSS refuses an input outside the range its runtime advertises, and the player used to give up and fall back to the plain scaler. It now lowers the output until the source fits. A 436x572 clip that was refused renders at 872x1144 (#1, #2).
- A downloading source shows how far it has got, in MB and percent. It used to show nothing at all for the length of the download, which looked like a hang (#2).
- A job that stops reporting for too long is stopped and says so, instead of leaving the progress bar running.
- Photos can start a render from the toolbar button. It was permanently greyed out on a still image (#2).
- On a GPU with no measured render pace, the player says the pace is unmeasured rather than implying it checked and passed.
- One scene change no longer resets the DLSS temporal history six times in twelve frames. A weak cut is now ignored within 0.6 s of the last one; a decisive one still cuts immediately.
- The release build attaches a checksum for the package it produces.
Full detail: CHANGELOG.md.
Full Changelog: dlss5-video-player-v0.17.1...dlss5-video-player-v0.17.2