Hi everyone, I’m happy to announce a massive update to the project. v2.0 is out!

Before diving into the details, check out the new video in the README. It demonstrates the setup process, from configuring the server on a modern Mac to running the client on a PowerMac G4, finally showcasing transcoded modern media playing on Tiger: 👉 https://codeberg.org/jjmarcos/retrostream-py

What’s new in v2.0?

• Jellyfin Support: You can now connect to Jellyfin servers as well as Plex.
• New Server GUI: For the server side (the modern machine), there is now a proper GUI to manage settings, view logs, and start/stop the service without touching the command line.
• Extended HW Acceleration: Transcoding now supports VAAPI (Linux), D3D11VA (Windows), and VideoToolbox (macOS), in addition to CUDA/QSV.
• Smarter Transcoding: Better and more complex automatic fallback chains (if hardware encoding fails, it gracefully falls back to the next available engine) and hardware-accelerated scaling.
• New Players: Added support for mpv and ffplay alongside MPlayer.

Compatibility
As always, the focus is on getting modern media onto vintage screens.

• Clients: Mac OS X, Windows 98 SE, Windows XP, Linux.
• Server: macOS (Intel/Silicon), Linux, Windows 10/11.

Downloads
Standalone binaries are available for several platforms (no Python installation required).
You can grab the v2.0 zip files here: https://codeberg.org/jjmarcos/retrostream-py/releases

Please have a look at the extensive documentation 😉

Let me know if you run into any issues!

Just a quick update to let you know RetroStream v2.5 is available now.

The big focus for this release was optimizing for legacy hardware, audio track selection and handling large libraries better. Here are the highlights:

• MPEG-1 & Audio Optimization: Added MPEG-1 video encoding with automatic MP2 audio selection (Stereo/44.1kHz). This prevents your retro CPU from wasting cycles on real-time resampling (48kHz to 44.1kHz) during playback.
• Custom Resolutions: You can now manually input resolutions (e.g., 320x240 or just x240) with auto-aspect ratio calculation, great to match your display.
• Audio Track Selection: Added support for selecting specific audio tracks (languages/commentary) directly from the UI.
• Major Performance Boost: Re-architected the library engine to use asynchronous lazy loading. Large libraries (tested up to 10k items) load much faster now, and metadata is only fetched when you click an item.
• Fixes: Solved a subtitle transcoding crash caused by special characters/apostrophes in filenames.

Head over to Codeberg to download the v2.5 binaries:
https://codeberg.org/jjmarcos/retrostream-py/releases

I have also updated the repository with detailed instructions:
https://codeberg.org/jjmarcos/retrostream-py

If you want to understand the general workflow, check out the demo video from v2.0 (the core usage remains the same):
https://www.youtube.com/watch?v=vR4VbrVm9Aw

Sounds pretty cool.
I'm not asking you to do it, but it'd be cool if someone integrated a tool like this into a retro-proxy type thing.

eg: automatic "making it compatible with 9x" like early html only, and converting media to flash and pics to early jpg/gif

Congrats its a very good proyect. A question regarding hardware , what's the minimun requirements? would a 233MMX or a k6-2+ be enough?
Edit : just read the readme on the website... It seems it can!

MarmotaArmy wrote on 2026-01-08, 14:22:

Congrats its a very good proyect. A question regarding hardware , what's the minimun requirements? would a 233MMX or a k6-2+ be enough?
Edit : just read the readme on the website... It seems it can!

Yes, indeed! The v2.5 update was actually designed specifically to target that hardware tier (Pentium MMX / K6) by adding MPEG-1 support.
While I haven't personally tested a 233MMX yet, it meets the theoretical baseline I calculated. One tip: on that class of hardware, having a video card that supports Hardware YUV-to-RGB Overlay (like an ATI Rage II) could make a big difference.
I'd be very interested to see how it performs on your setup, please let me know how it goes!

myne wrote on 2026-01-08, 13:10:

Sounds pretty cool.
I'm not asking you to do it, but it'd be cool if someone integrated a tool like this into a retro-proxy type thing.
eg: automatic "making it compatible with 9x" like early html only, and converting media to flash and pics to early jpg/gif

It’s definitely a cool concept, but way outside the scope of what I'm trying to do here. My goal is strictly to bridge modern self-hosted libraries (Plex/Jellyfin) to native desktop apps.
I think projects like WebOne or Protoweb are closer to that "universal proxy" goal.

Yeah, of course. It would be a huge amount of extra work.

However, if you make your bit architected well, I'm sure one or both of those might adopt it as a plugin

I downloaded the server and after reading the readme i realized it requires quite a few steps to install , i just don't have the time right now.
The file client-py3_win_v2-5.zip is flagged by windows defender with Win32/Wacatac.B!ml malware, probably a false positive.-

MarmotaArmy wrote on 2026-01-09, 13:41:

I downloaded the server and after reading the readme i realized it requires quite a few steps to install , i just don't have the time right now.
The file client-py3_win_v2-5.zip is flagged by windows defender with Win32/Wacatac.B!ml malware, probably a false positive.-

Thanks for the heads-up! I've checked into this, and it is definitely a false positive (common with Python apps compiled with PyInstaller, unfortunately).

Interestingly, my own Windows Defender flags the exact same file as "Win32/Sabsik.EN.A!ml", while yours sees "Win32/Wacatac.B!ml".
The !ml tag stands for "Machine Learning", meaning the heuristics are just guessing based on structure, not a specific virus signature.

I have already submitted the file to Microsoft for analysis to get the detection cleared. Hopefully it won't take long!

@MarmotaArmy I recompiled the client code with Nuitka this time to address the false positive. It is testing clean on two different Windows 11 machines now. I have updated the zip file on the releases page, could you please re-download and test it? Thx!

I have done this only with real, but no stream or transcode and lower end hardware, xvid/divx/mpeg2 stuff at RagePro/Rage128Pro. From old cards, RagePro has very wide OS support and good Mpeg1/2, Rage128Pro is even better. Rage Pro has media player and driver support for Win3x, i have been using mostly Win9x. Rage2+DVD was one of the first with DVD support and my drivers work with them, i may need to check how DVD part in Rage2+DVD works out, but i have tested mostly Rage3 cards out and thats perfect for Rage Pro and RageXL. Lowest CPUs i have used are AMDK6266 mobile (the first one) and lower end PentiumII-s for Mpeg2.

I have some mplayer special builds for Win9x and first i tought i need some gui, but now i have used mplayer without gui, it just simple drag it and go and its great to use if you know the buttons. Special builds i mean for 3DNow and first SSE, maybe there is MMX ones even. ATi DVD works faster, less CPU work, how to use Mplayer without GUI and use ATi mpeg2/mpeg1 there, mpeg1 also very fast. I would like to have one player for all and with hardware acceleration, not have to use mpeg1, mpeg2 with ati dvd and xvid/divx with mplayer. I would like to have cpu/gpu together at acceleration , not just one or other.

marxveix wrote on 2026-01-12, 01:00:

I have done this only with real, but no stream or transcode and lower end hardware, xvid/divx/mpeg2 stuff at RagePro/Rage128Pro. From old cards, RagePro has very wide OS support and good Mpeg1/2, Rage128Pro is even better. Rage Pro has media player and driver support for Win3x, i have been using mostly Win9x. Rage2+DVD was one of the first with DVD support and my drivers work with them, i may need to check how DVD part in Rage2+DVD works out, but i have tested mostly Rage3 cards out and thats perfect for Rage Pro and RageXL. Lowest CPUs i have used are AMDK6266 mobile (the first one) and lower end PentiumII-s for Mpeg2.
I have some mplayer special builds for Win9x and first i tought i need some gui, but now i have used mplayer without gui, it just simple drag it and go and its great to use if you know the buttons. Special builds i mean for 3DNow and first SSE, maybe there is MMX ones even. ATi DVD works faster, less CPU work, how to use Mplayer without GUI and use ATi mpeg2/mpeg1 there, mpeg1 also very fast. I would like to have one player for all and with hardware acceleration, not have to use mpeg1, mpeg2 with ati dvd and xvid/divx with mplayer. I would like to have cpu/gpu together at acceleration , not just one or other.

Nice hardware collection! You're spot on, Rage overlay is perfect for this.

RetroStream actually solves your "one player for all" wish. Since the modern-ish computer (a laptop, your home server, your current game rig...) handles the transcoding, everything arrives as a MPEG-1/MPEG-2 stream, so you don't need to swap between different media players.
The last release of this software allows you to select specific bitrate, resolution and codec to use, so your retro machine can play whatever content you have smoothly.
You can also absolutely use your custom 3DNow!/SSE builds, just point the client config to your specific MPlayer .exe.

For that K6-2, definitely try the new MPEG-1 mode in the current v2.5 version. It prevents the CPU from wasting cycles on audio resampling, so it runs super smooth on that generation of hardware.

Let me know how it goes!

Hi everyone,

Just wanted to drop a quick note that RetroStream v2.5a has been released.

The main change in this version is that both the Server and the modern Windows Client (Python 3) are now compiled using Nuitka instead of PyInstaller. This change should resolve the issues where Windows Defender or other antivirus software were flagging the executables as false positives.

Here you can find the binaries:
https://codeberg.org/jjmarcos/retrostream-py/releases

As always, docs and demo video available here:
https://codeberg.org/jjmarcos/retrostream-py

Enjoy!

kahuna wrote on 2026-01-09, 18:35:

@MarmotaArmy I recompiled the client code with Nuitka this time to address the false positive. It is testing clean on two different Windows 11 machines now. I have updated the zip file on the releases page, could you please re-download and test it? Thx!

Tested with Sophos endpoint protection , no malware found.

😀

Cool project! 🙂

Can you maybe also add support for AV1 and VP9 videos (on the input side) as well?

And on the output side, perhaps support mjpeg (a.k.a. motion jpeg) in addition to mpeg1 and mpeg2 as well, since that might offer a better quality-to-cpu ratio on some older systems? Such streams would be larger, but since RetroStream will primarily be used over LANs anyway, that shouldn't be too much of an issue in most cases.

Regardless, thanks for sharing this with the world!

MarmotaArmy wrote on 2026-01-19, 13:22:

Tested with Sophos endpoint protection , no malware found. 😀

Appreciate it! Freezing/Compiling with PyInstaller has its drawbacks for sure, glad that Nuitka works great and does not trigger the "AI / ML" crappy heuristics.

digger wrote on 2026-01-19, 13:28:

Cool project! :slight_smile: Can you maybe also add support for AV1 and VP9 videos (on the input side) as well? And on the outpu […]
Show full quote

Cool project! 🙂
Can you maybe also add support for AV1 and VP9 videos (on the input side) as well?
And on the output side, perhaps support mjpeg (a.k.a. motion jpeg) in addition to mpeg1 and mpeg2 as well, since that might offer a better quality-to-cpu ratio on some older systems? Such streams would be larger, but since RetroStream will primarily be used over LANs anyway, that shouldn't be too much of an issue in most cases.
Regardless, thanks for sharing this with the world!

Thanks!
It shouldn't be much of a trouble implementing AV1/VP9 decoding on the input side.
When it comes to the output formats, it's true that MJPEG is easier on the CPU than MPEG formats, but there are two major dealbreakers for this specific use case. First, MJPEG creates a massive spike in bandwidth that the retro machine needs to handle. Second, and most importantly, MJPEG is typically wrapped in AVI containers which write the file index at the very end of the file; this renders "On-Demand" streaming impossible, as the client would be forced to wait for the entire transcode to finish before playback could even begin.
MPEG-1 remains the safer default because it streams instantly if the user wants to, balances the load perfectly between the CPU and provides pretty decent quality 😀

kahuna wrote on 2026-01-19, 23:35:

Thanks!
It shouldn't be much of a trouble implementing AV1/VP9 decoding on the input side.

Cool! It would be awesome to see that added at some point. 😇

First, MJPEG creates a massive spike in bandwidth that the retro machine needs to handle.

Fair point, although the bandwidth can be limited and throttled depending on the compression level, right?

Second, and most importantly, MJPEG is typically wrapped in AVI containers which write the file index at the very end of the file; this renders "On-Demand" streaming impossible, as the client would be forced to wait for the entire transcode to finish before playback could even begin.
MPEG-1 remains the safer default because it streams instantly if the user wants to, balances the load perfectly between the CPU and provides pretty decent quality 😀

As you say, that's a problem specifically with AVI containers. But MJPEG streams can also be wrapped in mpeg transport spreams (MPEG-TS) or in MKV containers. And if I'm not mistaken, Apple QuickTime .mov containers shouldn't have that problem either, right? So isn't it just a matter of streaming it in a proper container format? It's true that in some cases the client (retro) machine would need to have the QuickTime player or a codec pack installed, but that shouldn't be too much of an issue, right? Back in the day, people would install codec packs on their Windows 9x installations all the time. Even in Windows 3.x you can install custom codecs, if I'm not mistaken.

I do agree with you that mpeg1 is a decent and safe format for most retro machines, though. And it's probably a better choice w.r.t. "out of the box" support as well. I get that.

Thanks for this, regardless!