PotPlayer 1.7.22851 released: libass subtitles and built-in HLS/DASH handling
PotPlayer 1.7.22851 started rolling out on 1 April 2026 as a 53.1 MB installer for 64-bit Windows, and it changes two parts of the playback path that had not been touched for years. Subtitle rendering now runs through libass, and HLS and DASH streams are demuxed by an internal module instead of leaning on an external splitter. In our bench, the first subtitle line appears 68 ms sooner on a 4K remux, and switching between two live HLS channels takes 34 percent less time.
Libass takes over ASS and SSA rendering
The old subtitle path was written for SRT-era files and extended, patch by patch, to cope with ASS and SSA. It worked, in the sense that text appeared on screen. It did not work in the sense that a fansub release with typesetting, karaoke timing and vector drawing looked the way its author intended. Build 1.7.22851 replaces that path with libass, the same library used by mpv and VLC, and keeps PotPlayer's own font handling on top of it.
The practical difference shows up in three places. Karaoke syllables now light up on the beat instead of stepping a frame late. Typeset signs stay inside their clip rectangles when the window is resized mid-playback. And fallback fonts resolve per glyph rather than per line, so a Japanese title with a Latin subtitle track no longer forces a single font across both.
We measured subtitle start-up on the same 4K HEVC remux used in the previous release notes. In 1.7.22769 the first ASS line appeared at 240 ms after the first video frame; in 1.7.22851 it appears at 172 ms. Memory use rose by 18 MB, which is the cost of keeping the libass renderer resident. On a 16 GB machine that is not a trade anybody will notice.
“Subtitle start-up was the last obvious gap in the playback path,” said Park Ji-hoon, who leads playback QA for the PotPlayer build team. “We could hide it behind a frame buffer, but a 4K file with a heavy ASS track still stuttered for the first half second. Moving to libass removed the stall instead of covering it.”
HLS and DASH without an external splitter
The second change is quieter but matters more if you watch live television. HLS and DASH manifests used to be handed to an external module, which meant a second process, a second buffer and a visible delay when a manifest refreshed. The internal module parses the manifest itself, keeps a 6 MB read-ahead buffer, and falls back to the external path only for encrypted streams that need a key server.
Channel switching is where this is measurable. On a 200 Mbit line, zapping between two 1080p HLS channels took 1.94 seconds in the March build and 1.28 seconds in this one, a 34 percent improvement. A 4K DASH manifest with 12 variants parses in 210 ms, down from 380 ms. Memory during a two-hour HLS session stayed flat at 312 MB, where the previous build crept to 480 MB before the buffer was flushed.
“libass gave us the same output the fansub community already tests against,” said Elena Vogt, subtitle toolchain engineer on the build team. “We stopped guessing at karaoke timing and started matching a reference. That is a much shorter argument to have internally.”
The module also fixes a complaint that arrived with every sports season: a live stream that briefly dropped would leave the player stuck on the last decoded frame until the buffer drained. The new reader marks the gap and re-requests the segment without clearing the picture, so a two-second dropout now costs two seconds rather than a manual reload.
Nine fixes, two of them worth the update on their own
The rest of the changelog is maintenance, but two entries explain why some users should update immediately. Unicode characters in external subtitle files with mixed encodings no longer render as boxes; the fix touches the charset detection that used to assume a single codepage per file. And a temporary playlist queued in the player no longer restarts from the first item after finishing the last one.
The remaining fixes cover external audio tracks when several audio files sit beside a video, an HLS subtitle stream that drifted out of sync during long live playback, and three container-level regressions introduced in the January build affecting MKV and MP4 files with unusual edit lists.
Performance is otherwise unchanged, which is deliberate. Decode throughput on our RTX 3060 test rig stayed at 8K60 with 12 percent CPU load, and 4K60 HEVC with hardware decoding held 15 percent. Startup to a usable window measured 1.4 seconds cold and 0.6 seconds warm on a SATA SSD.
The build is available now for 64-bit and 32-bit Windows, both at 53 MB. Settings, skins and playlists carry over from 1.7.22769 without migration. If you have been putting off the update because the last two builds changed subtitle behaviour, this is the one to take: the rendering path is different, but it is different in the direction the files were written for.
Karaoke timing finally lines up with the audio on my Idolmaster BDs. I had assumed the discs were authored slightly off. They were not.
HLS switching is noticeably faster on my provider. Went from about two seconds of black to roughly one. Still not instant, but I will take it.
The mixed-encoding subtitle fix saved me. I have a folder of old Russian SRT files that showed boxes for years and now open correctly.
Memory went up slightly as they said, 20 MB on my machine. Nothing I can feel. Subtitle pop-in is faster, that I can feel.
Playlist no longer loops back to the first file after the last one ends. Small thing, but it annoyed me every single night.
Installed over 1.7.22769 on Windows 11, all my skins and hotkeys survived. The subtitle font fallback looks better on Japanese titles with English subs.
