title: "Record linkage with Splink and how identities get matched across messy databases" date: 2026/08/31 tags: [entity-resolution, record-linkage, splink, data-engineering, identity, deduplication]

🌐 last30days v3.3.2 · synced 2026-08-31

What I learned:

The open-source record-linkage shelf looks well stocked and is mostly abandoned, and the one project still being worked on is not the one with the most stars - moj-analytical-services/splink sits at 2,370 stars, 261 forks and 216 open issues, written in Python, last pushed 2026-08-28. The library with nearly twice the stars, dedupeio/dedupe at 4,510 stars and 576 forks, was last pushed on 2025-07-29 and had exactly one item updated in the whole 30-day window. J535D165/recordlinkage at 1,062 stars was last pushed in February 2024. zinggAI/zingg, the Java one at 1,238 stars, is genuinely alive with 54 items updated in the window and a push on 2026-08-26. Hiring managers have not caught up: a Senior Data Scientist listing on Dice from 18 August asks for "familiarity with record linkage tools such as Splink, FastLink, Dedupe, or recordlinkage" - a list in which two of the four have not shipped code in over a year.

Splink has not cut a stable release in nearly six months, and almost everything merged in August was a dependency bump - the newest tag is v5.0.0.dev4, published 2026-07-01, and the latest stable on PyPI is still 4.0.16 uploaded 2026-03-11. Twenty-five pull requests were merged inside the window and the overwhelming majority carry the :dependabot: prefix. Only three issues were opened all month. The substantive work that did land is performance rather than statistics: PR #3162 "Python speedups", #3161 a DuckDB speedup for the comparison viewer, and #3176 "Cosine similarity in spark", which on 4 August finally closed issue #1011 asking for embedding-based similarity functions - open since February 2023 with 30 comments. The sharpest open packaging complaint has nothing to do with matching at all: issue #3235, filed 12 August, points out that MIT-licensed Splink unconditionally pulls in GPL-2.0-or-later igraph, which "makes Splink unadoptable in commercial or closed-source products that ship to customers - not because of anything in Splink's own code, but because of one transitive package used by a single optional diagnostic." The claim is contested on the issue itself: the single reply, from @gringer on 18 August, doubts anyone "would think that igraph is a substantial-enough component of Splink that it would carry across GPL protections and obligations to the rest of Splink's code", notes the obligations may not attach at all when it is the user rather than the maintainers fetching the package, and lands on "reducing platform dependencies is a good idea, even if the particular argument stated here carries little water." The reporter arrived with PR #3236 already written; it is still open.

Blocking rules are where the month's actual engineering went, and the headline idea got publicly corrected by the maintainer within hours - PR #3239, "Finding redundant blocking rules/computing marginal blocking rule value", is the busiest thread in the repo this month at 6 comments. The premise: "for each blocking rule, we look to see whether it alone is responsible for creation of some of the edges. If not, it is not serving any marginal value and can be removed", with the explicit note that projects routinely carry ten or more blocking rules, at which point "a venn diagram or equivalent upset chart" becomes unreadable. Then @RobinL killed his own chart, crediting @ADBond: "If two rules both have a marginal contribution of zero, it's safe to remove one but not both. To see this, imagine what happens if you simply include the same rule twice. So the original chart idea I posted is potentially quite misleading." @medwar99 countered with a shipped alternative, a stacked waterfall over the rule cascade where "turning off a rule never results in a later rule having a lower edge count compared to the baseline", and @aalexandersson pushed on the unglamorous part - axis labels reading l."std_ssn"=r."std_ssn" instead of std_ssn. Three more blocking PRs opened the same month: #3238 a blocking rule performance chart, #3224 reporting each block's share of total comparisons, and #3223 raising a clear error for rules with no equi-join conditions.

Blocking sets a recall ceiling nobody scores, and the flag that reveals it is only wired into one of four evaluation methods - discussion #3257 on 27 August lays out the asymmetry precisely. Setting positives_not_captured_by_blocking_rules_scored_as_zero to False measures "discriminative performance of the FS model as a binary classifier"; leaving it at the default True measures "performance of the entire linkage pipeline including the blocking rule filtering", zeroing labelled pairs that blocking never generated so they show up as false negatives. The catch is that only accuracy_analysis_from_labels_column() accepts the argument. accuracy_analysis_from_labels_table() does not, and neither prediction_errors_...() method does, so "the FN/FP always reflect model-scoring here, not blocking-exclusion effects." The poster names why that matters in practice: "having a good quality label column is tricky, and clerical review often produces pairwise labels" - the path most teams actually use is the one without the switch. Splink's own threshold selection docs make the underlying rule explicit: only links covered by the blocking rules get scored at all.

Every practitioner writing about thresholds this month treats them as a cost decision rather than a hyperparameter - the clearest statement is a repo description. jkelly-dev1/roster-entity-resolution, created 23 August to reconcile four disagreeing provider rosters, states it flatly in its own description: "The matching threshold is a cost decision, not a tuning parameter", the trade being what a false match costs against a missed one, and whether a human override survives the next file. Discussion #3232 on 9 August works the same arithmetic on NHTSA vehicle-incident filings against consumer complaints: "a missed link inflates a non-match rate that I report openly. A false link fabricates a discrepancy between two unrelated events and attaches it to a named company. So the resolver is biased hard toward not linking, and every link it does produce is marked low confidence." That asymmetry is not a stylistic preference. The linkage-error literature treats false links as a missing-data problem in which erroneous links attenuate downstream regression coefficients rather than merely adding noise, and work on bias due to linkage error in electronic health records finds the bias grows when the match rate is low or the identifier error rate is high - which puts the largest errors on exactly the records with the worst data quality. A field guide to missing data published on 24 August points readers at the same terms: "probabilistic record linkage", "Fellegi-Sunter", "blocking record linkage", "linkage error bias".

The failure mode people ask about is not typos, it is errors that correlate with another real record - discussion #3254, opened 26 August, calls it "PII bleed": "the data isn't typo'd in some random way, but rather is correlated with another record. As an example, two people with radically different names have the same email, phone number, address, and even the same date of birth." The poster's honest position is that they simply exclude such data from training. @medwar99's reply is the most useful paragraph in the repo this month, because it refuses to treat the case as an error at all. One bullet: "I could legally change my first and last name and still retain all my other information, both those records should belong to me as a real-world entity". The next: "I could be sharing an email/phone/address with my differently-name twin and the records should not be linked". The same ambiguity recurs on every field, the "Same fields but different DOB" case reducing to "Is this John Smith Sr and John Smith Jr living at the same address, or one John Smith with an error in DOB?" The structural cause is named directly: "the FS model assumes independence between information, and Splink is scoring based on comparison buckets (exact match, distance etc.) rather than the specific values themselves." The suggested fix is feature engineering rather than a model change, concatenating fields so that name || email can separate johnsmith_johnsmith@email.com from janedoe_johnsmith@email.com, and the resolution is explicitly declared to be a business judgement: "whether you are pushing for precision or recall, availability of contextual information, linkage quality reporting practices."

The most instructive answer of the month is about which direction you standardise strings, and it is a blocking argument in disguise - discussion #3250 asks why Splink's tutorial says to expand "St." to "Street" rather than the reverse, when abbreviating seems like it would let the distinctive part of an address dominate. The reply reframes it entirely: "directionality matters because you are choosing which collisions to create, not because Splink scores 'Street' as more informative than 'St.'" Expanding 10 Main Street and 10 Main St. merges the two rows that should merge. Compressing merges those two and silently swallows 10 Main Saint as well, because abbreviations are a many-to-one map. The intuition about common tokens dominating is answered by pointing at term frequency adjustments rather than by deleting the suffix, and the blocking consequence is stated outright: "street as a block key is rare enough not to explode, and st as a block key is huge (and polluted by Saint)." The practical bottom line for anyone with an existing pipeline is that consistency beats direction - "mixing 'full words in A, abbreviations in B' is the case that actually hurts."

Outside that one repository the subject barely exists, and what does exist is vendor copy and an unbenchmarked claim - across 24 Reddit threads pulled from r/dataengineering and r/datascience carrying 1,426 upvotes and 576 comments, not one was about record linkage; the corpus is career advice, Fivetran cost complaints and DuckLabs joining AWS at 225 points. Hacker News produced three stories in 30 days and none of them were about entity resolution. The two Splink videos on YouTube drew 26 views and 37 views. The single genuinely on-topic X post, @anirudhg192 on 28 August - "A name is not an identity. If an OSINT system finds 'Ravi Kumar' in 100 documents, it has not necessarily found one person. It has found 100 mentions" - drew two replies, while a post about agentic knowledge graphs in the same corpus took 67 likes. The web layer that fills the gap is almost entirely commercial: WinPure selling MatchAI, AWS Entity Resolution promising "flexible, configurable workflows that take minutes to set up", and Quantexa selling a single customer view. The loudest performance claim in the window is a GitHub repo description: benseverndev-oss/goldenmatch, 130 stars and created in March, advertises "Fellegi-Sunter beats hand-tuned Splink. Arrow-native/Rust, 250M rows in 11.2 min" with no published benchmark behind either half of that sentence.

Takeaways:

1. Splink is 2,370 stars against dedupe's 4,510, but dedupe has not been pushed since July 2025 and recordlinkage not since February 2024 - per github
2. No stable Splink release since 4.0.16 in March 2026; the newest tag is a v5 dev build from 1 July, and most of August's 25 merged PRs were dependency bumps - per releases
3. Two blocking rules can each show zero marginal contribution and still both be load-bearing, so pruning by marginal value alone is misleading - per @RobinL
4. Blocking sets a recall ceiling that only one of four evaluation methods lets you toggle into view, and the labels-table path most clerical reviews produce is not that one - per discussion #3257
5. Practitioners frame the match threshold as a cost ratio between a fabricated link and a missed one, not as a number to tune - per roster-entity-resolution
6. False links do not just add noise, they bias downstream estimates, and the bias grows exactly where the match rate is low and identifier errors are common - per linkage error research
7. The hard case is correlated error, not random typos: two people sharing email, phone, address and date of birth breaks the Fellegi-Sunter independence assumption outright - per discussion #3254
8. Expand abbreviations rather than compress them, because compression is many-to-one and turns st into a polluted, exploding block key - per discussion #3250
9. Whether one GPL transitive dependency used by a single optional diagnostic really blocks commercial redistribution of MIT-licensed Splink is disputed on the issue itself, and the fix PR is open either way - per issue #3235
10. Zero of 24 Reddit threads, zero of 3 Hacker News stories and 63 total YouTube views: the entire practitioner conversation lives in one repository's discussion tab - per splink discussions

title: "Kdenlive and what editors say after finishing real projects on it" date: 2026/08/31 tags: [kdenlive, video-editing, opensource, nle, linux, kde]

🌐 last30days v3.3.2 · synced 2026-08-31

What I learned:

The release that landed inside the window is a polish release, and the project says so in its own announcement - KDE Gear 26.08 shipped on 20 August per linuxiac and @linuxiac, whose post at 74 likes and 4 reposts is the highest-engagement on-topic X item in 30 days. KDE's own announcement gives Kdenlive one sentence: "Kdenlive is KDE's feature-rich video editor. 26.08 comes with lots of quality of life improvements and polishing." linuxcompatible counts "171 packages and the first net additions to the suite in years," with Kdenlive receiving "a major overhaul with GSoC-contributed effect widgets and timeline improvements." The previous series closed out alongside it: Kdenlive 26.04.3, covered on 19 August as the final maintenance update in that series, carrying "crash fixes, timeline improvements, effect corrections, and continued security hardening." Two release announcements inside 48 hours is the whole shipping story of the month.

What actually changed is a list of small ergonomics fixes, and nearly all of them live in the Titler and the timeline - the KDE announcement is specific where the press coverage is not: "Down on the timeline, you can copy a selection to a new sequence, or have Kdenlive create audio tracks automatically as needed for your clips. You can also reorder tracks and configure different colors for each item type." In the Titler you can now "copy and paste objects, give rectangles rounded corners, and snap objects to the center and edges of the screen as well as to other items," with a visual guide, a detail 9to5Linux repeats verbatim. On effects, linuxiac reports the Transform effect "now lets you move the rotation axis instead of forcing rotation around the center," and the Gradient Map effect supports multiple gradient stops; desdelinux compresses the same set to "free rotation axes, visual alignment guides, and nested sequences to the timeline." The most concrete artifact in the entire window is a 7-view commit-log video from GVG on 14 August, whose description carries the raw entries: "Fix crash selecting keyframe in time remap," "pop out the effect parameter widget to a new window for curve parameter," "Categorized new effects," and "Update KDDockWidgets tabbar proxystyle on application palette change, fixes unreadable tabs on Windows BUG: 522933 FIXED-IN: 26.08.0."

Every first-person crash report in the window is against an unreleased build, on Windows, and comes with a precise reproduction - both are on KDE Discuss and both name 26.11.70, a pre-release of a series that has not shipped. Big crash - Windows [26.11.70] on 18 August lists the steps in order: "In a 'Sequence' → 'Duplicate clip' - Renamed the 'Sequence' - Replaced elements using 'Replace with bin selection' - Manually deleted 7 frames and audio tracks from the timeline and saved the file straight away." Crash when Kdenlive opens the project with faulting module: Qt6Core.dll on 13 August is a save-and-reopen loop on Windows 11 standalone that ends with the application's own message, "Kdenlive crashed on last start. Reset config and restart?" Neither is a report about the version most people are running. The GitHub mirror shows 5.6K stars and 0 open issues, which is the tell that it is a mirror and not where anything gets filed - the BUG: 522933 in the changelog above points at KDE's own tracker, and the forum is where the repro steps land.

Hardware acceleration is the one question nobody in the window gets a straight answer to, and proxies are the answer everyone gives instead - the State of hardware accelerated GPU features in Kdenlive thread on 8 August asks it plainly: "I'm wondering about the expected state of GPU decoding in Kdenlive. What should I actually expect on an Intel platform (Skylake) which has verified working GPU-accelerated decode/encode on common H264 and H26…" The third-party writeups are far more confident than the forum, and notably they answer a different question - encoding, not decoding. Picturesque says "Kdenlive's render dialog lets you enable NVENC H.264/H.265 or VAAPI H.264 under Settings > Configure Kdenlive > Playback" and calls it a path that genuinely cuts encode times on NVIDIA hardware, and TryUncle reports that "Kdenlive's own documentation recommends 8 CPU cores and 16GB of RAM for 4K work, and recent versions have added hardware-accelerated proxy encoding through NVENC, VAAPI, and QuickSync." For playback the standing advice is proxies: iTechGuides tells you to "generate proxy clips if high-resolution footage makes preview playback choppy," and the most honest caveat of the month comes from a listicle - rottenwifi writes that its recommendation "is a practical recommendation, not a promise of smooth performance: editing speed depends on the codec, resolution, frame rate, GPU, storage, cache location, effects, and proxy settings." The corresponding user-side thread is How can I configure kdenlive to run on my potato pc! at 8 points and 10 comments.

The community around it is far smaller than the headline source counts suggest, and the arithmetic checks out exactly - the engine pulled 16 Reddit threads carrying 2,061 upvotes between them, which reads healthy until you split it by subreddit. 1,856 of those upvotes sit in r/kde on threads that have nothing to do with video: "Don't think Percentage works this way, Dolphin!" at 600, a tooltip suggestion at 435, "Uhhh…what just happened?" at 349, KDE Connect redesign at 162, a Moonlight extended-monitor post at 159 and a Filelight window-resizing post at 151. Another 142 sit in r/editors on general craft questions about cutting down content and career disillusionment, neither of which mentions the editor. That leaves 63 upvotes total across all six r/kdenlive threads in the window: a macro pad post at 20, "Kdenlive suddenly broke" at 18 with 10 comments, the potato-PC thread at 8, a white-text question at 7, a crystal effect at 7, and "I updated Kdenlive and now I'm getting the same error twice on every startup" at 3. Hacker News carried zero Kdenlive stories in 30 days.

The one first-person report of finishing real work is a large throughput claim, and it is unopposed mainly because nothing else in the window is first-person - @LudensLudonauta on 30 August, at 18 likes and 4 replies: "I was looking at my first videos, when I used to use Blender video editor. It took me 20h some times more to make a video. Using Kdenlive now it takes something like 3~4h (scripting included). Sometimes we take these workflow improvements for granted." That is the entire practitioner layer on the positive side. On the negative side the reports are equally short and equally personal: @danielbergholz asking Omarchy users "how do you edit photos and video? I'm currently using CapCut and Kdenlive just ain't as good," and @x0shreyash on 31 August with "You think your life is hard then try editing a basic video on Linux with Kdenlive, Shotcut or OpenShot." The most balanced verdict is a one-line reply from @gongbaodd: "I think KDEnlive is enough, DaVinci is too hard core😂."

The questions people actually bring to the project are beginner questions, not long-timeline questions - a snapshot of r/kdenlive in the window captures the two live threads exactly: someone wanting a transparent background behind an avatar during a transition who notes "this is my first time using kdenlive, any help?", and someone whose automatic subtitles never appeared after following the setup - "First I downloaded the Python thing. Then I downloaded the English model mentioned... it showed successful, but I can't see the subtitles." The same texture shows up off-platform, where a TikTok topic page describes editors battling "the struggles with keyframe velocity settings but also dealing with unexpected software glitches that can derail any project." There is no thread anywhere in the corpus from someone reporting how a two-hour timeline behaved after a month of work. The nearest thing to a finished-project post is I made a music visualizer in Kdenlive - what would you improve?, posted on 30 August with no score recorded.

Most of Kdenlive's circulation this month is as a row in a substitution table, and the biggest such table does not include it - @franpradasAI ran a multi-post paid-to-free list that puts Kdenlive on three separate rows - "Adobe Premiere Pro → Kdenlive," "Final Cut Pro → Kdenlive," and "DaVinci Resolve Studio → Kdenlive" - at 6, 3 and 2 likes respectively. The highest-engagement swap list of the window, @AiWithBDN at 36 likes, 8 reposts and 23 replies, routes "Adobe Premiere Pro → DaVinci Resolve" and never names Kdenlive at all. A Portuguese-language recommendation thread from @ro_urubu puts it second by design: DaVinci Resolve Free is "provavelmente a melhor opção," then "Kdenlive: gratuito e open source." Meanwhile the more interesting activity treats Kdenlive as a substrate rather than an application - Omarchy ships it preinstalled alongside OBS Studio per @guangGitHub, @meowludo answered a challenge to "vibe up kdenlive" with vibecut, "an open source video editing program that allows you to describe what you want, then goes and just does it," and HKUDS/CLI-Anything lists a cli-anything-kdenlive adapter driving it through "MLT XML + melt renderer." That last one is the quiet structural fact: the editing engine underneath is reachable without the GUI at all, which is exactly what a substitution table can never capture.

Takeaways:

1. KDE Gear 26.08 landed 20 August and KDE's own wording for the Kdenlive share is "lots of quality of life improvements and polishing" - per kde.org
2. The previous series closed out alongside it, 26.04.3 being "the final maintenance update in the series," carrying crash fixes and security hardening - per Linux Today
3. The shipped changes are ergonomics in the Titler and timeline: copy a selection to a new sequence, auto-create audio tracks, reorder tracks, per-item-type colours, object snapping with a visual guide - per 9to5Linux
4. Both crash reports in the window are against the unreleased 26.11.70 on Windows, and both come with exact reproduction steps - per KDE Discuss
5. The GitHub mirror shows 5.6K stars and 0 open issues, which is why the bug traffic and the repro steps are on the forum and the tracker instead - per KDE/kdenlive
6. GPU decoding is an open question on the forum while the writeups answer a different one - NVENC, VAAPI and QuickSync for proxy encoding, enabled under Settings > Configure Kdenlive > Playback - per TryUncle and Picturesque
7. The honest performance caveat came from a listicle, not the project: smoothness "depends on the codec, resolution, frame rate, GPU, storage, cache location, effects, and proxy settings" - per rottenwifi
8. Of 2,061 Reddit upvotes across 16 threads, 1,856 are r/kde threads about Dolphin and KDE Connect and 142 are general r/editors craft questions, leaving 63 across every r/kdenlive thread in the window - per r/kdenlive
9. The only first-person account of finishing real work reports a 20-hour edit dropping to 3 or 4 hours after moving off Blender's video editor - per @LudensLudonauta
10. Kdenlive travels as a table entry more than as a tool, and the month's biggest paid-to-free swap list sends Premiere users to DaVinci Resolve without naming it - per @AiWithBDN

title: "FFmpeg hardware AV1 encoding on NVENC and what it costs in quality" date: 2026/08/31 tags: [ffmpeg, nvenc, av1, hardware-encoding, codecs, transcoding]

🌐 last30days v3.3.2 · synced 2026-08-31

What I learned:

FFmpeg 9.0 shipped inside the window and its only NVENC entry is a deletion - the official Changelog for version 9.0 contains exactly one line mentioning NVENC, "Remove deprecated NVENC options and support for pre-11.1 SDK versions," and zero lines mentioning AV1. Hardware AV1 on NVENC is not new; "nvenc AV1 encoding support" is listed in that same file under version 6.0. The feature work that did land is documented only in the maintainer's own writeup: Jean-Baptiste Kempf records that "NVENC gains AV1 hierarchical B-frame reference mode, compatibility with Video Codec SDK 13.1, and accepts 12-bit input formats" while it "drops the old preset aliases, the legacy rate-control modes and support for SDKs older than 11.1." He puts the whole release at "more than 2200 commits from over 160 authors," touching 1781 files. Phoronix and 9to5Linux both carried the removal line and neither carried the addition.

The biggest thread of the month about FFmpeg contains 97 comments and not one of them is about hardware AV1 - the Hacker News submission of the 9.0 release notes on 4 August took 466 points and 97 comments, the single largest item in the window by a wide margin. A keyword scan of every comment in it returns one hit for "nvenc" (inside gyan's verbatim changelog paste) and zero hits for "av1," "hardware encoding," "x264," "x265," "svt," "vmaf," or "nvidia." What the thread actually argued about was Anthropic's Claude for Open Source sponsorship, animated WebP decoding, and a video encoder for the Playdate handheld. The second thread on the same release, pointing at Kempf's blog, took 48 points and 13 comments, most of them complaining that the release notes read as AI-written. The codec change that matters to GPU users passed without discussion.

The one person in the window who actually measured it got the opposite of the advertised result, and published the table - u/HomidWay on r/handbrake on 8 August, 7 points and 36 comments: "no matter what i tried (including building custom FFMPEG with VHQ tune for AV1), i get filesizes nearly doubling what H.265 does. As for quality they are the same, and i mean it, you wouldn't be able to tell which one is which." The edit carries the numbers, an RTX 5070 Ti for the hardware passes and a Ryzen 5700X for the software one. NVENC H.265 at slowest preset and CQ 27: about 3 minutes, 339 MB, median VMAF 91.899171. NVENC AV1 at the same slowest preset and CQ 27: about 2 minutes, 638 MB, median VMAF 93.456927. SVT-AV1 at preset 2, RF 30, tune vq: 55 minutes, 263 MB, median VMAF 92.321889. The software encoder produced the smallest file in the set and still scored higher than NVENC H.265, at roughly 18 to 27 times the wall clock.

The thread could not agree whether that test was valid, and the disagreement is the actual finding - the objection landed within eight minutes of the post. u/Stolberger pointed out that "the CQ value between different codecs is not comparable. So CQ 27 for H265 might be visually similar to CQ 32 for AV1," noting the scales differ outright, "0-51 for H264/265 and 0-63 for AV1." u/blu3ysdad put it as a cost curve: "Your quality on av1 is hugely different, a 93 score is like 10x the space/compute cost. Instead of using the same settings, dial the settings down on av1 until it's quality score matches hevc then compare file size and encode time." The measured table supports them, because the largest file also carried the highest VMAF. The OP held the opposite line, that "CQ is not the same as RF, RF does scale differently but CQ is basically a quality target," and reported the same-CQ-same-VMAF behaviour held between NVENC and VideoToolbox. Nobody resolved it. u/Turnips4dayz summarised the thread accurately: "no idea why only maybe 3 people in this entire thread understand what you're actually doing and asking." The most useful sentence in the whole window is the same person's follow-up on 23 August, two weeks later, where he narrows the win condition rather than defending the original claim: "With NVEnc: AV1 wins in when source is of extremely high quality, like 10/12 bit, HDR, very high bitrate source, this way AV1 preserves same/similar quality with slightly less bitrate. HEVC wins every other time basically." The margins are asymmetric and worth reading twice. On ordinary material HEVC comes out "~20-30% smaller file in favor of HEVC," and where AV1 wins, "it is around 5% smaller file." Hardware AV1 pays off on the sources that were already expensive and loses by a wide margin on everything else.

Every explanation offered points at analysis depth rather than at the codec - u/EtherealPlatitude gave the mechanism: "Software encoding can pull all the tricks in the book to help make the file small and use lookahead etc to help allocating each frame. While Nvenc cannot do that, its hardware & parallel and is designed for speed not quality." The same argument turns up in a completely different community. On r/macmini on 27 August, u/Due_Mousse2739 answered a question about Apple's missing AV1 encoder with "Hardware encoding for speed, low power, low latency, and real-time throughput. A software encoder can do much more exhaustive analysis before deciding how to encode each frame," and added a measurement of his own: "On a M4 Pro Mac for example, svt_av1_10bit (profile 3) encoding is faster than x265 (slow) encoding on the same material." The one August tutorial that addresses it directly, Tech Tutorials on 4 August, states it flatly: "A slow libx264 or libx265 CPU encode still beats NVENC on compression efficiency at the same bitrate," while conceding NVENC "wins when speed matters: live streams, bulk transcodes, and any job where the CPU would take hours." The blunt version came from r/handbrake on 12 August, where u/BoredHalifaxNerd told a new user that "GPU encoding performs quite badly at file size efficiency" and closed with "Video encoding is 'speed, quality, or size. Pick one, compromise on one, and forget the other.'"

The two documented ways to close the quality gap both delete the reason you used the GPU - the first is money in bitrate. An OBS encoder guide dated 15 August reports "I use 12000 to 16000 kbps for 1080p60 streams to YouTube, which gives NVENC plenty of room to produce near-perfect quality. The higher bitrate essentially eliminates the quality gap with x264." That is a fix for streaming and a non-fix for the storage case that started the r/handbrake thread. The second is NVIDIA's own answer, and it has been measured. A longitudinal NVENC study by Kasidis Arunruangsirilert and Jiro Katto, submitted to arXiv on 2 May 2026, finds Blackwell "achieving a 5.94% BD-Rate gain in standard modes and up to 22.79% in UHQ modes," then names the bill: UHQ "operates as a hybrid pipeline, offloading complexity to CUDA cores and enforcing aggressive temporal structures (up to 7 B-frames) that increase end-to-end latency by over 400% and GPU board power consumption by up to 40%." Their conclusion is that UHQ "successfully bridges the quality gap with software encoders" but is "unsuitable for interactive real-time communications." The gap closes exactly when the GPU stops being fast.

The tooling moved considerably faster than the conversation - rigaya/NVEnc, 1,377 stars and 9 open issues, shipped six releases inside the window: 9.28 on 1 August, 9.29 on the 3rd, 9.30 on the 4th, 9.31 on the 8th, 9.32 on the 15th, 9.33 on the 29th. Release 9.32, announced by @rigaya34589 to 15 likes, rebased the bundled libraries from ffmpeg 8.0 straight to 9.0.1 and bumped libvmaf from 3.0.0 to 3.2.0, three days after 9.0.1 itself was announced on Wednesday 12 August. That point release carried the one genuinely AV1-specific NVENC change of the window, per UbuntuHandbook on 13 August: "A reusable FFmpeg helper for creating AV1-formatted timecode metadata is added in the library. And, NVENC now uses it to write AV1 timecode metadata." The measure-it-yourself instinct is visible but tiny: framicheli/av1converter, last pushed 27 August, "auto-detects available hardware encoders, verifies output quality with VMAF, and manages the full encoding pipeline through a TUI," and sits at 6 stars.

The hardware floor is the constraint nobody mentions until it bites, and it cuts in both directions - 9.0 dropping pre-11.1 SDK support is the upstream half; the downstream half showed up on X, where @drc777777777 reported on 19 August that "ffmpeg is now far enough removed from the nvidia drivers pascal is stuck on that nvenc no longer works in OBS, and I'm so comically CPU-bound that I pretty much can't record anymore." At the other end, Tech Tutorials notes AV1 encoding "needs an RTX 40-series card or later," and Apple still has no hardware AV1 encoder at all, which is what the r/macmini thread on 26 August was complaining about: "It's a shame that Apple is still only including a hardware decoder." AMD's position improved by report rather than by measurement. On r/MoonlightStreaming on 31 August, someone weighing an RTX 5070 against an RX 9070 XT got three replies and none of them discouraging, with one caveat worth keeping: "Only downside to amd cards is no hardware encoding/decoding of yuv444 hdr."

Takeaways:

1. The FFmpeg 9.0 changelog's version 9.0 section has exactly one NVENC line, a removal, and zero AV1 lines; the AV1 feature work exists only in the maintainer's blog - per FFmpeg Changelog and jbkempf.com
2. The window's biggest FFmpeg discussion ran 466 points and 97 comments with zero mentions of AV1, hardware encoding, x264, x265, SVT or VMAF - per Hacker News
3. The only first-person measurement in the window put NVENC AV1 at 638 MB against NVENC H.265 at 339 MB from the same source at the same CQ 27 - per r/handbrake
4. In that same test SVT-AV1 at preset 2 produced the smallest file, 263 MB at median VMAF 92.32, and took 55 minutes against about 2 to 3 minutes on the GPU - per r/handbrake
5. The strongest counter-argument is that CQ is not a comparable scale across codecs, which the measured table supports because the largest file also scored the highest VMAF - per u/Stolberger and u/blu3ysdad
6. The tester's own two-week follow-up narrows hardware AV1's win to 10/12-bit, HDR and very high bitrate sources at about 5% smaller, while HEVC wins ordinary material by 20 to 30% - per r/handbrake
7. Every explanation offered names lookahead and per-frame bit allocation rather than the codec, including from a Mac user reporting SVT-AV1 10-bit beating x265 slow on speed on an M4 Pro - per r/macmini
8. Closing the gap with NVIDIA's UHQ tuning costs over 400% end-to-end latency and up to 40% GPU board power for a 22.79% BD-Rate gain, which removes the reason to use the GPU - per Arunruangsirilert and Katto, 2 May 2026
9. The tooling outran the discussion: rigaya/NVEnc shipped six releases in 29 days and rebased from ffmpeg 8.0 to 9.0.1 three days after that point release landed - per rigaya/NVEnc releases
10. The version floor bites at both ends, with Pascal cards losing NVENC in OBS as FFmpeg moves on and AV1 encode still requiring RTX 40-series or later - per @drc777777777 and Tech Tutorials