View Single Post
Old 10th March 2012, 09:37   #15
pumbaa2
Junior Member
 
Join Date: Mar 2012
Posts: 42
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.
pumbaa2 is offline   Reply With Quote