Sounds good, and good that the docs were enough to get you going. It's just the nature of free open source that you need to do some legwork. I spent maybe 100 hours over just two weeks preparing the latest couple versions, so imagine having to do even more work.

Any version of VCS from maybe two years back should come with a compatible pre-built OpenCV dll, so you only need the OpenCV headers as long as you have that previous VCS. You could probably do a 64-bit build without changing anything but the couple required libraries (and 64-bit Qt + compiler).

lushen124 wrote on 2021-04-10, 22:38:

After a few hours of trial and error, I finally was able to build a version that works. I will say that the instructions are likely inadequate for somebody that isn't already familiar with software development and tracking down old versions of OpenCV and MinGW isn't particularly straightforward either. In the end, I had to resort to manually building OpenCV 3.2 in an x86 flavor (needing to find and use CMake to do so) because the available download for this only has a x64 flavor in the download. I ran through two different versions of MinGW until I found one that worked with the appropriate posix libraries for Windows. Maybe it's worth writing a bit more on the build instructions, at least for setting up in a Windows environment.

In any case, I still want to thank you for writing up this application for interfacing with the Datapath Vision line of capture cards.

Any chance you could share your built version?
I tried building this now for a couple of hours but no luck. I have no experience with this tool chain. At least for me the information on github and comments here are not enough to get me going.

happy wrote on 2021-07-18, 13:48:

Any chance you could share your built version?
I tried building this now for a couple of hours but no luck. I have no experience with this tool chain. At least for me the information on github and comments here are not enough to get me going.

For building OpenCV, see if the answer over at https://answers.opencv.org/question/122696/is … -32bit-windows/ helps. VCS uses the "world" version of OpenCV (BUILD_opencv_world).

The binary's again now hosted on GitHub, https://github.com/leikareipa/vcs/releases, since the server isn't coming back any time soon. Keep in mind it's an evaluation version. If you continue using it, you're required to leave ten bucks on a bench next time you go out. If that's illegal in your area then you need to find a legal way.

I had found the link for building cmake before but apparently used a too new cmake. I managed to compile everything in the meantime. But thank you for hosting the binaries again! Your tool makes a big difference in quality with my VisionRGB-PRO1

Is there any way to get this to compile on newer versions of Linux? I had to symlink the opencv2 include folder, but now get the following error:

1src/filter/filters/delta_histogram/filter_delta_histogram.cpp: In member function ‘virtual void filter_delta_histogram_c::apply(u8*, const resolution_s&)’:
2src/filter/filters/delta_histogram/filter_delta_histogram.cpp:67:96: error: ‘CV_AA’ was not declared in this scope
3   67 | oint(x1, y1b), cv::Point(x2, y2b), cv::Scalar(255, 0, 0), 2, CV_AA);
4      |                                                              ^~~~~
5
6make: *** [Makefile:1458: generated_files/filter_delta_histogram.o] Error 1
7seth@Linux-Testbench:~/Downloads/vcs-2.4.0$ 

If you know how to do so, I'd gladly drop some money to you for this.

NightSprinter wrote on 2021-10-28, 01:56:

Is there any way to get this to compile on newer versions of Linux? I had to symlink the opencv2 include folder, but now get th […]
Show full quote

Is there any way to get this to compile on newer versions of Linux? I had to symlink the opencv2 include folder, but now get the following error:

Copy code to clipboard

1src/filter/filters/delta_histogram/filter_delta_histogram.cpp: In member function ‘virtual void filter_delta_histogram_c::apply(u8*, const resolution_s&)’:
2src/filter/filters/delta_histogram/filter_delta_histogram.cpp:67:96: error: ‘CV_AA’ was not declared in this scope
3   67 | oint(x1, y1b), cv::Point(x2, y2b), cv::Scalar(255, 0, 0), 2, CV_AA);
4      |                                                              ^~~~~
5
6make: *** [Makefile:1458: generated_files/filter_delta_histogram.o] Error 1
7seth@Linux-Testbench:~/Downloads/vcs-2.4.0$ 

If you know how to do so, I'd gladly drop some money to you for this.

I think you'll either need to install OpenCV 3.2.0 or to edit the VCS source code to resolve the build errors (the problem is the OpenCV API changes a lot between versions, e.g. CV_AA might be cv::LINE_AA nowadays, but it should be doable without tons of work).

I have OpenCV 3.2.0 on Ubuntu 20.04, but can't remember how I got it there. Should be possible anyway.

As this seems to be the main place for VCS issues, I thought I would share a discovery in case it relates to anyone else. I couldn't get VCS working at all on my system with the VisionRGB-X2 aka DGC133E. It's a PCI-X card and is installed in the only PCI-X board I have, an HP OEM version of the TR-DLS with dual Tualatins.

It crashes with an error in module Qt5Gui.dll, code 0xc000001d. Turns out the Qt5 libraries use SSE2 instructions, which the Pentium III doesn't have. Fun times.

brassicGamer wrote on 2021-11-30, 11:05:

As this seems to be the main place for VCS issues, I thought I would share a discovery in case it relates to anyone else. I couldn't get VCS working at all on my system with the VisionRGB-X2 aka DGC133E. It's a PCI-X card and is installed in the only PCI-X board I have, an HP OEM version of the TR-DLS with dual Tualatins.

It crashes with an error in module Qt5Gui.dll, code 0xc000001d. Turns out the Qt5 libraries use SSE2 instructions, which the Pentium III doesn't have. Fun times.

Cool hardware. I guess one way is to manually compile the Qt libraries with SSE2 disabled. But since VCS is fairly CPU-heavy it might not run so well on those CPUs.

vvbee wrote on 2021-12-03, 16:52:

Cool hardware. I guess one way is to manually compile the Qt libraries with SSE2 disabled. But since VCS is fairly CPU-heavy it might not run so well on those CPUs.

Thanks! Indeed it does not run so well. Even with just the Vision display window open, GUI performance plummets (especially as AGP is not available on this board). I also had issues using alternative capture tools such as VirtualDub, which crashed during capture. It works fine on a faster machine (it turns out this card will work perfectly in some 32-bit PCI slots, provided the correct drivers can be obtained). Video editing packages such as Pinnacle Studio don't even recognise my Datapath card as an input device (I guess they don't use Direct Show). It has been an interesting process.

This might be a stupid question but I'm trying to understand the aspect ratio setting:

Capturing an input resolution of 640x400, is forced aspect ratio 4:3 and output resolution to 200% the same as setting aspect ratio to native and output resolution to 1067x800?

happy wrote on 2022-02-02, 12:47:

This might be a stupid question but I'm trying to understand the aspect ratio setting:

Capturing an input resolution of 640x400, is forced aspect ratio 4:3 and output resolution to 200% the same as setting aspect ratio to native and output resolution to 1067x800?

It might be slightly slower with aspect ratio correction since it needs to letterbox the image, but the output image (ignoring the letterboxing) should be the same.

Forcing the aspect ratio lets you more freely size the output window, e.g. to match your screen resolution if you want to use full-screen mode.

There's currently a bug with the forced aspect ratio mode that can trigger an assertion failure and program termination, so if that's not an issue for you then it should be ok.

Ok cool. Haven't encountered this bug yet so all is good 👍

And I noticed the capture is very fast in general! It's one frame of lag with Prince of Persia, which has around 20 fps.

(I'm using a VisionRGB Pro)

Heyho, I am a new owner of the card and already posted some stuff in the VGA capture thread. But as the developer seems active here, I will also put some of that here, plus some other observations I made.
First of all, thanks for the work. The tool is already super helpful!

I am using Version 251.
-If you start the tool while anything is active it will always start out with 640x480, even if the resolution is 320x200(720x400) or 800x600. Only after changing the resolution ones on the recorded signal OR forcing the new resolution in the program, it will update. I found that especially strange as the original software detects it correctly upon startup.
-I am not quite sure regarding the frames dropped. If I set to OpenGL it aims for 60fps and was its basically dropping 15 frames per second. I think the little icon in the taskbar isn't helping too much. I am not sure what a "normal" value is, but with dropping dozens of frames per second (and with software per minute) being normal that "notification"doesnt help much and is rather irritating. Also the "$areFramesDropped" overlay is just always showing that frames are dropped, but nothing else.
This {!} can also potentially lead to issues if you tell any other program to capture that specific window

Possibly a feature request:
I saw that you got Aliases for Input modification and you got presets for input modification
You got filters for modifications between set inputs and outputs
But you don't have any output modification based on input.
For example it would be great that you could say that 320x200(720x400) is being upscaled to 1280x1000, while 640x480 is upscaled to 1280x960. As far as I can see it, right now you would need to manually switch each time.

Hey, thanks for the feedback.

The initial resolution being 640 x 480 seems like a bug specific to the Windows version of VCS and may be a regression that's been around for a while. Like we talked about in the other thread, it seems to be about VCS not hooking up to the active video mode on startup and falling back to its default 640 x 480 until something forces it to update. I haven't used VCS in Windows in a while, but when I did, I usually captured at 640 x 480 anyway, so it's possible the bug's been around for some time and people just put up with it. Probably not a difficult fix, but I don't have access to my capture hardware under Windows right now, so I'll get to it at some point in the future.

The dropped frames indicator basically alerts you to the fact that VCS isn't outputting all the frames the hardware is capturing, likely because VCS isn't able to process them fast enough to keep up. Usually you wouldn't want this to happen at all, so the indicator aims to be somewhat intrusive. That said, dropped frames can happen just by navigating the VCS UI, so it's not always helpful. If you get dropped frames while you're not clicking around the UI then that's a problem - like your PC not being fast enough for the current output settings or whatever. But I can add an option to disable the notification.

I've been thinking about implementing frame scaling as an image filter, like instead of an output gate you could have a customizable output scaler. We'll see about it - the way output scaling is done is pretty fundamental to how the program works, so it might be a choice between one way or the other rather than having both. Also if you're recording the output then you need to normalize it to a specific resolution anyway, so whether having different scaling rules in the middle helps in the end is a question.

Thank you!
Yeah, the starting is a glitch, but also not really that problematic. In the end it's just 1-2 additional clicks. Would be cool if it can be fixed, but not a big deal.

The dropped frames: Once I see it to open GL it just caps the framerate to 60. So there is ano way to avoid that 15 frames are dropped per second. But yeah, on software its mostly when doing something in the interface. But if that notification could be removed, that would be great.

Yeah, I was thinking about whether this could work as filter as well. I mean in theory you could also just add it to the input cocnfiguration, that would also do the job. But the filters right now also seem a bit unintuitive.
You'd usually assume that when you set the output, this is the output you get, and not just another requirement.
Ofc changing that, and having the output and all scalers and so on in the "filters" (and possibly renaming that to "processing" or somthing) would be cool, but probably also tons of additional work.
Ofc that way you could do fancy things like:
Input 320x200 -> Scale to 1280x1000 (linear) - > Center and add black border -> Output as 1920x1080
Input 800x600 -> Scale to 1440x1080 (area) -> Put left and add black border -> Output as 1920x1080

Not sure I'd use these last 2 steps personally though, as thats likely better be handled via OBS. and the whole process would take more screenspace. And OBS will not windowcapture anything which is not visible on screen.

If you're hitting vsync with OpenGL and it's not your graphics driver or whatever forcing it then it may be a Qt issue, since the VCS code makes an effort to have vsync off. I can't verify it on my system right now, but I'll have a look later.

I agree that the naming of the input and output gates for the filters isn't ideal, but I haven't come up with more fitting names for now. I'm open to suggestions.

There's a temptation to give the filter graph various powers, but it can also become a mess for the user pretty quickly. That said, I think the scaling chain examples you gave could be reduced to "input > output scaled with letterboxing" or something like that, which would also do away with one need for intermediate scaling filters.

Custom output scaling with optional letterboxing is now experimentally available as a filter. You can check it out by building from the master branch or by waiting for the next release (2.6), whenever that'll be. I've done the bare minimum of testing on this feature at this point and it's not release-ready, but there's a chance it works more than not as-is.

Cool, thank you! Got to wait for the release though, as I got no idea how to to "build from the master branch".