NSVx Open Sourced

[ken52787]

I've decided to release my NSVx ActiveX control as open source under the GNU GPL license.

What the control does is it allows people to easily make NSV sourcing applications because it handles all the hard work. Rather than deal with Shoutcast and parse NSVs, you only had to tell NSVx where Shoutcast was, give it some header information, and then give a file path to the NSV, and NSVx handled the rest.

Anyways, you can have your way with the source code now. Download it here.

EDIT: I should probably tell you that this is written in Visual Basic 6.

[ravetrax]

interesting...

[rockouthippie]

outstanding!.

[Jkey]

superb !

[Inedible Bulk]

incredulous!

[retrostation]

superexpradiciousexpialidocious!

[WatchLive]

Does it mean we now can make the vp6.2 activeX player ?

[Jkey]

What the control does is it allows people to easily make NSV sourcing applications because it handles all the hard work. Rather than deal with Shoutcast and parse NSVs, you only had to tell NSVx where Shoutcast was, give it some header information, and then give a file path to the NSV, and NSVx handled the rest.

so no watchlive.

[WatchLive]

does it mean we can decode live nsv in flash ?

[rgATL]

Originally posted by WatchLive
does it mean we can decode live nsv in flash ?

I guess I'm question is similar. Would this help with playing a SHOUTcast stream through a Flash animation in Internet Explorer? (I heard there were some ActiveX issues).

Thanks,
rg.

[sns2015]

You are all not reading what this does. NSVx is not the same as NSVPlayX. NSVx is a sourcing/shouting ActiveX plugin that sends NSV information to a shoutcast server. This will NOT play NSV files/streams.

[robertut]

Link is dead... any mirrors out there...?

[Smelter]

I'll get it to you I have it onboard somwhere.

[Smelter]

I think this is it.

Not the original copy but i think I havnt messed it up.

[pumbaa2]

I have the original copy, however I will look at your code changes. In efforts to keep this ActiveX alive, I would like to maintain this project (any objections?). I've spent 2 days going over the code and found a few very minor problems that I would like to ultimately resolve. One is Frame Search. NSVx uses Frame "Markers" to calculate the speed it should send the data stream.

For the most part this code does run correctly but the control pulls 1K chunks out of the NSV File and does the search, however, since the frame tag is a multi-byte match, there is a possibility that part of that frame tag is in the first 1k chunk and the second part comes in on the second 1k chunk. If this happens, Ken's code will fail to detect that particular frame tag. This will offset the frame counter and cause it to search for the next frame tag. The end result is a stream that will feed slightly faster than the actual speed (because the code literally counts frames per second). He also matches against 2 different tags... One is the real frame tag and the second is the NSV Sync Header. However, I'm not completely convinced that the Sync Header should qualify as a frame advance. I'm going to move the frame counting code into its own project so I can make it do a raw count of frames in a NSV file, then compare those notes to what Winamp tells me.

The second problem is the position calculation. His code calculates position using "Current File Position / File Length." This is not entirely accurate, especially when it comes to VBR files (VP8, etc). A file may have a very "active" video in the beginning and level off at the end. In this particular scenario, it would cause the beginning of the file to grow faster than the end. Depending on VBR Settings, it may actually report it is further along than it actually is. The reverse could also be true, not so active video at the beginning and very active video at the end, the result would be the reverse. It would show its not as far along in the video than it actually is. Ultimately, it would mean the "Progress" won't advance steadily like it should.

It took some real work on the internet to come across the code. Most people who wrote streamers are using 1.0.1 of the ActiveX, if you still have the project and wish to rebuild it, please use 1.0.2 (Still Kens original code). Until I get that version in my files area, feel free to message me and I'll send you a link. 1.0.1 has issues keeping up with the stream, especially at higher bitrates. RayLine NSV Streamer is now using 1.0.2 as of version 1.0.6. 1.0.7 will have the ActiveX built into the executable itself. I had a user complain on my Forums about the ActiveX itself, which caused my program to not load on their station.

I've built version 1.0.3 and made a MSI Merge Module for it. Anyone creating installers using Visual Studio Installer should use the Merge Module. I've also added some code to gather some more specific information from the control itself. The NSVx1.ProgressComplete will return a integer value between 0 and 100 that reflects the current position in the file. This makes it easy to attach a Progress Bar from "Windows Common Controls 6.0" and set the value directly to NSVx1.ProgressComplete like so: "ProgressBar1.Value = NSVx1.ProgressComplete" The default value range for ProgressBar1 is already set to 0-100. I also plan to set informational properties to get information like framerate, resolution, codec (perhaps). That way people can display that information in their program easily.