A few months ago @belbous was telling me about the AV1 video codec — how great it is. Recently I decided to experiment with it. Turns out my Ubuntu laptop has the right hardware — an NVIDIA GPU with support for hardware AV1 encoding via NVENC. This capability only arrived with the RTX 40 series: on the 30 series and older, NVENC can decode AV1 but not encode it — for that you're stuck with software on the CPU. Thankfully, it's all integrated into ffmpeg, ready to use.

With Claude Code's help, I dialed in the right settings using a handful of video files as test cases. The goal was to preserve quality while reducing file size. As a result, bitrate doesn't even appear in the configuration. What came out is a bash script that analyzes a video file with ffprobe and, depending on the resolution and color scheme, sets the CQ and other parameters.

Claude Code didn't just pick values at random: it ran several passes on a clip of video, compared the input and output files, pulled out frames, and evaluated the quality itself, even describing the scenes it was comparing — a footprint in the snow, a landscape with trees, Dexter's face 😁.

Initially, Claude Code based its approach on comparing three codecs — H.264, H.265 (aka HEVC), and AV1. The baseline assumption was: H.264 → H.265 yields about 50% compression, and H.265 → AV1 adds another ~30% at the same quality. That said, those 30% apply to software encoders (libaom, SVT-AV1) — hardware AV1 in NVENC runs many times faster, but at the same bitrate it loses to them in quality. I was mainly after disk space savings, so the tradeoff suited me.

On the side, I downmixed the audio to stereo with the Opus codec, since I'm going to be watching on a TV with regular (and pretty mediocre) stereo sound anyway, and I planned to play it from an iPad — which, historically, for some reason can't output 5.1 audio over HDMI (instead of sound, you get hissing).

The results are impressive. An episode of Foundation — 4K, HEVC, HDR — shrank from 10.2 GB down to 2 GB. Five times smaller! At visually the same picture quality. To be fair, though: the 5x compression here isn't pure AV1 efficiency so much as a consequence of the source having a very high bitrate (rips usually leave a generous margin). On files that are already compressed more tightly, the gains will be more modest.

A 45-minute episode took about 15 minutes to re-encode. For 4K video, that's very fast. And a 50-minute episode of Dexter in 1080p SDR re-encodes in just 5 minutes. Beautiful.

But there are downsides — out of the box, NVENC doesn't support HDR10+ or Dolby Vision, so that dynamic metadata gets lost during re-encoding. Regular HDR10 with static metadata passes through fine, so basic HDR is intact — the problem is only with the extended formats. There's some workaround where you encode that part separately and splice it back in afterward, but I decided not to bother — my TV isn't all that fancy, it wouldn't have displayed HDR10+ or Dolby Vision anyway. You could also use a different codec that does everything on the CPU — better quality there, and metadata is preserved — but then this same 4K episode would take many hours instead of 15 minutes. So it looks like I've landed on the perfect quality/time balance.

Today at an IT breakfast meetup I was singing the praises of Video Player — a video player from GNOME, formerly known as Showtime. As far as I understand, at some point it became the default video player, including in the latest version of Ubuntu.

I like its minimalism, it plays the files I need, and I appreciate that when you pick an audio track it shows the name of the translation (the dubbing studio) — for some reason not every player does this.

Got home, decided to compare it with other players, opened a file with HDR and Dolby Vision — looks like I praised it a bit too soon. In the screenshot, from top to bottom: Video Player (Showtime), Cine, and VLC.

All three render the colors differently. I think I'll switch to Cine. Judging by its repo, it's a fairly young video player. Like Showtime, it's also based on MPV and written in Python. It just develops more actively, updates ship more often, and — most importantly — the colors come out right. Showtime, as far as I remember, has had issues with HDR for years now, and updates only come out every three to six months.

VLC is a legend, of course — it can play just about anything that's playable — but the interface, in my opinion, has aged quite a bit. Time to make room for the new generation.

After shipping swift-adwaita, I've been focused on building a first app using it. Something simple, but handy for myself. So now the first app has been shipped.

Swifty Notes is a native GTK/libadwaita Markdown notes application for Linux written in Swift.

The desktop app is the primary experience: write, organize, and preview Markdown notes with native GTK widgets, autosave, remembered workspace state, and adjustable editor settings such as font size, wrapping, indentation, and appearance.

The included CLI works on the same file-backed notes so shell scripts, automation, and AI agents can safely inspect or update notes without a separate database or background service.

• Create, rename, duplicate, export, and delete Markdown notes.
• Autosave edits, remember workspace state, and keep note-local image assets together with each note.
• Adjust editor font size and other writing preferences to fit different screens and workflows.
• Choose where notes are stored, including a cloud-synced folder, so the same plain files can stay in sync across devices.
• Import images with drag and drop and render Markdown with a native GTK preview instead of a web view.
• Use the CLI for JSON-friendly note automation from scripts, shell pipelines, and AI agents.

Swifty Notes for Linux is an open source project, source code is available on GitHub.

Star Fork

Swift Adwaita 1.1.0 has been released. I’ve been working on a first app built with this library, so I’ve extended it and fixed some bugs.

Highlights

• Added GtkSourceView integration with typed Swift wrappers for source editing, syntax highlighting, languages, and style schemes.
• Expanded widget APIs around popovers, windows, calendar compatibility, and runtime lifecycle handling.
• Improved release stability with better GLib main-loop integration, broader CI coverage, and additional regression tests.

Added

• SourceView, SourceBuffer, SourceLanguage, SourceLanguageManager, SourceStyleScheme, and SourceStyleSchemeManager.
• Typed identifiers for GtkSource languages and style schemes.
• A new source editor demo example.
• MainContext.task { ... }, task(after:), and task(every:) as cancellable GLib main-loop work handles.
• Async MainContext.run, yield, and sleep(for:) helpers for bridging Swift concurrency onto the GLib loop safely.
• Widget.unparent() and PopoverMenu.unparent().
• Convenience presentation helpers for Popover and PopoverMenu.
• Additional regression tests for widget/window parent-chain lookup and expanded coverage for source editing and media behavior.

Changed

• GtkWindow.present() now retains windows until close, making transient or locally scoped windows safer to use.
• Widget.window now resolves the containing window through the widget parent chain instead of assuming the GTK root is always a window.
• Calendar date handling now uses a GTK compatibility shim so the package builds cleanly across older and newer GTK versions.
• Documentation generation and hosted docs configuration were updated.
• CI now installs and tests with GtkSourceView 5 system dependencies.

Fixed

• Fixed deferred signal/user-data cleanup to release captured closures through the GLib main loop instead of Swift main-queue tasks, avoiding lifecycle issues in GTK applications.
• Fixed a common GTK scheduling pitfall by offering a Task-like API that stays on the GLib main loop instead of DispatchQueue.main.
• Fixed Swift 6.1 serialized suite visibility issues in the test suite.
• Fixed the popover/window regression tests to avoid GTK crash paths in CI while still validating the intended behavior.
• Fixed release documentation and installation instructions to include GtkSourceView 5 development packages.

Documentation and CI

• Added an API documentation link to the README.
• Updated installation instructions for Ubuntu/Debian and Fedora.
• Improved inline documentation consistency across the wrapper API.
• Extended CI coverage for documentation, formatting, and Swift 6.1 / 6.2 / 6.3 test runs.

This is an open-source project licensed under the MIT license. The source code is available on GitHub. Documentation with guides is available here.

Star Fork

This release focuses on Swift 6.3 compatibility, a substantial rewrite of the editor's highlighting pipeline, and much better responsiveness when editing very large HTML documents.

Added

• Added the HTMLEditorBenchmarks executable target for repeatable performance measurements.
• Added benchmark support for full-plan highlighting, overlap reuse, edit invalidation, visible-highlight remapping, and large-document local repaint paths.
• Added focused regression tests for:
  • planner cache reuse and document-scoped invalidation
  • invalid NSRange and UTF-16 edge cases
  • quoted and unquoted attribute value highlighting
  • visible highlight state remapping
  • block-based highlight coverage
  • large-document editing and scrolling policies

Changed

• Refactored the editor runtime into smaller focused components, including separate coordinator lifecycle, viewport, editing, policy, coverage, structural-range, and visible-highlight-state files.
• Refactored the syntax highlighter into planner- and builder-based components for clearer separation of scanning, planning, and application.
• Moved the editor to an adaptive runtime model that changes behavior based on document size instead of treating all HTML documents the same way.

Improved

• Greatly improved large-document editing performance with:
  • viewport-first highlighting
  • document-scoped planner caches and targeted invalidation
  • cached visible-range plans
  • block-based highlight coverage tracking
  • structural dirty-range alignment around edits
  • two-phase large-file editing with immediate micro-pass and deferred wider repaint
  • burst-coalesced edit repainting
  • scroll-idle semantic highlighting
  • deferred binding synchronization for large documents
  • allowsNonContiguousLayout enabled automatically in large-file mode
• Improved highlight stability while typing in the middle of very large HTML by preserving visible overlay state and reducing repaint churn around the caret.
• Improved performance tuning and observability for large files with dedicated benchmark coverage and runtime probes.

Fixed

• Fixed compilation and concurrency issues needed for Swift 6.3 compatibility.
• Fixed several editor update-path issues related to coordinator state, highlighting tasks, and main-actor behavior.
• Fixed highlight regressions and edge cases involving:
  • partial tags
  • empty input
  • large payloads
  • attribute-value coloring
  • visible highlight loss during large-file editing
  • invalid or clipped visible ranges

Notes

• Full-document semantic highlighting is still used for smaller HTML inputs.
• Very large HTML inputs now automatically switch to a more conservative, performance-oriented editing mode to keep scrolling and typing responsive.

Try it on GitHub: https://github.com/makoni/HTMLEditor-SwiftUI

Star Fork

A project that I’ve always wanted to create: a library that enables the development of GNOME applications using Swift. While there are some similar libraries available, they appear to be incomplete or not actively maintained. Thanks to Vibe Coding, I managed to complete the project in approximately a week.

swift-adwaita is an imperative Swift 6 wrapper for GTK4 and libadwaita, built for creating native GNOME desktop applications on Linux.

It provides a modern Swift API over GTK and Adwaita with type-safe widgets, signals, property bindings, async operations, and ergonomic convenience helpers, while preserving the native behavior, styling, and feel of the GNOME platform.

• Native GTK4 and libadwaita application development in Swift
• Imperative API without a custom DSL
• Type-safe enums, signals, and property APIs
• Async/await support for common platform integrations
• Extensive widget coverage with a real demo application

Here’s a demo app built using swift-adwaita:

This is an open-source project licensed under the MIT license. The source code is available on GitHub. Documentation with guides is available here.

Star Fork

Highlights

• Refactored the internal request pipeline in CouchDBClient to use cleaner async/await-style flows and reduce duplicated response handling logic.
• Improved buffering and decoding paths for raw and typed requests, with a focus on safer EventLoopGroup execution and better performance in response processing.
• Expanded test coverage around EventLoopGroup-backed request execution, including raw and typed get, raw and typed find, attachment download, Mango index listing, and Mango query explanation.
• Refreshed user-facing documentation across the README, DocC articles, and tutorials.
• Updated documentation tooling for newer DocC workflows, including Markdown export support.

API and Behavior Improvements

• Added and refined EventLoopGroup support across more CouchDBClient request paths.
• Improved internal error-handling paths and response decoding behavior for CouchDB operations.
• Simplified request helper layering and reduced duplicated request/response processing code.
• Improved attachment-related behavior and accompanying tests.
• Added visionOS to supported platforms in the package manifest.

Documentation

• Fixed and refreshed README examples for CRUD and Mango query usage.
• Updated DocC landing pages to better reflect the current API surface.
• Corrected the Advanced Mango Query tutorial snippets to match the current typed query API.
• Corrected Vapor tutorial examples.
• Fixed Hummingbird tutorial package setup and dependency snippets.
• Updated buildDocs.sh to support:
  • configurable output and hosting base path
  • static hosting content embedding
  • experimental Markdown output
  • Markdown manifest generation
• Added a post-processing step in buildDocs.sh that injects a relative Markdown link into generated DocC HTML pages.

Tooling and Dependencies

• Updated package dependencies in Package.resolved.
• Updated the Ubuntu build workflow Swift version matrix.

CouchDB Client on GitHub | Documentation with examples and tutorials.

Star Fork