Latest WACUP public preview for x86 & x64 is build #25452 (November 4th 2026) (x86 & x64 changelogs)
Latest restricted WACUP beta release is build #25452 (November 4th 2026) (x86 & x64 changelogs)

Author Topic: nsv video playback for x86  (Read 36 times)

lemondrop

  • Newbie
  • *
  • Posts: 1
    • View Profile
nsv video playback for x86
« on: Yesterday at 09:43:56 AM »
I've seen mention of video functionality for NSV streams being possible with supporting dlls for in_nsv in older build changelogs and I wanted to know which dlls were needed to get video working again, if it's still possible with the latest x86 preview build?

dro

  • Admin / WACUP Developer
  • Administrator
  • Hero Member
  • *****
  • Posts: 5976
    • View Profile
    • WACUP (Winamp Community Update Project)
Re: nsv video playback for x86
« Reply #1 on: Yesterday at 03:41:24 PM »
Sort of is the simple answer. 1.99.36.22278 is the last build that attempted to install & apply the patches needed on the various files from the 5.666 installer (i.e. a build from over a year ago which isn't supported at this point) along with when it is installed it'll usually be set to be disabled by default which can be changed via preferences -> plug-ins -> input if in_nsv is in the plug-in list.

The problem is that the recent installers remove some of those files even if the intent from the user side is to keep them around along with me doing no testing against in_nsv as I either rely on the directshow filters for local files or I'm ok with the audio-only playback of the streams that my in_url plug-in provides.

The simplest option vs trying to piece files together & missing on them being patched as needed would be for me to not remove the files the installer is removing & change how the plug-in is flagged as not to be loaded by default to avoid the problems I was having with in_nsv that led to it being removed. That would then allow installing 1.99.36.22278 & then installing the next preview build back over it & if needed manually enabling in_nsv (since the core still has the handling to enable the other dlls it needs) vs the handling that is now in place per the prior paragraph). Or use an old build that supports it & hope the build picked behaves.