lgx2userspace
lgx2userspace copied to clipboard
ChrisAJS
Windows building unable to make
Hey,
I tried building on windows using the steps provided in WINDOWS.md (Without any modification to sources files yet)
I was able to do most of it till the "make" every time what ever the directory I tried on it show the error :
make: *** No targets specified and no makefile found. Stop.
Tried on both Windows 10/11 machine with both terminal and powershell (admin and non admin do no change anything :) ) I do not own Clion to try on it.
No idea what I did wrong there
Here full logs in case it could help :)
CMake Warning:
Ignoring extra path from command line:
"C:/Users/Administrator/Documents/GitHub/lgx2userspace/TC-Mingw.cmake"
CMake Warning:
Ignoring extra path from command line:
"../TC-Mingw.cmake"
-- Selecting Windows SDK version 10.0.19041.0 to target Windows 10.0.19044.
Dangerous LGX (GC550) support will not be compiled into the lgx2userspace executable.
Detected non-linux system
Building liblgx for Windows
-- Conan: Using autogenerated Findlibusb.cmake
-- Library libusb-1.0 found C:/Users/Administrator/.conan/data/libusb/1.0.26/_/_/package/5a61a86bb3e07ce4262c80e1510f9c05e9b6d48b/lib/libusb-1.0.lib
-- Found: C:/Users/Administrator/.conan/data/libusb/1.0.26/_/_/package/5a61a86bb3e07ce4262c80e1510f9c05e9b6d48b/lib/libusb-1.0.lib
-- Conan: Using autogenerated FindSDL2.cmake
-- Library SDL2main found C:/Users/Administrator/.conan/data/sdl/2.0.20/_/_/package/fa88e8551f1d81168eeb9f59d3a183e3a584c5f1/lib/SDL2main.lib
-- Found: C:/Users/Administrator/.conan/data/sdl/2.0.20/_/_/package/fa88e8551f1d81168eeb9f59d3a183e3a584c5f1/lib/SDL2main.lib
-- Library SDL2 found C:/Users/Administrator/.conan/data/sdl/2.0.20/_/_/package/fa88e8551f1d81168eeb9f59d3a183e3a584c5f1/lib/SDL2.lib
-- Found: C:/Users/Administrator/.conan/data/sdl/2.0.20/_/_/package/fa88e8551f1d81168eeb9f59d3a183e3a584c5f1/lib/SDL2.lib
-- Library SDL2 found C:/Users/Administrator/.conan/data/sdl/2.0.20/_/_/package/fa88e8551f1d81168eeb9f59d3a183e3a584c5f1/lib/SDL2.lib
-- Found: C:/Users/Administrator/.conan/data/sdl/2.0.20/_/_/package/fa88e8551f1d81168eeb9f59d3a183e3a584c5f1/lib/SDL2.lib
-- Library SDL2main found C:/Users/Administrator/.conan/data/sdl/2.0.20/_/_/package/fa88e8551f1d81168eeb9f59d3a183e3a584c5f1/lib/SDL2main.lib
-- Found: C:/Users/Administrator/.conan/data/sdl/2.0.20/_/_/package/fa88e8551f1d81168eeb9f59d3a183e3a584c5f1/lib/SDL2main.lib
PLATFORM LIBS mingw32;SDL2::SDL2main;SDL2::SDL2;libusb::libusb;-static-libgcc;-mwindows
Building Windows executable
GTK+ frontend only supported on Linux
-- Conan: Detected VS runtime: MD
-- Conan: checking conan executable
-- Conan: Found program C:/Users/Administrator/AppData/Local/Programs/Python/Python310/Scripts/conan.exe
-- Conan: Version found Conan version 1.56.0
-- Conan executing: C:/Users/Administrator/AppData/Local/Programs/Python/Python310/Scripts/conan.exe install . --remote conancenter --build missing --settings arch=x86_64 --settings build_type=Release --settings compiler=Visual Studio --settings compiler.version=17 --settings compiler.runtime=MD --settings compiler.cppstd=14 --settings os=Windows
Configuration:
[settings]
arch=x86_64
arch_build=x86_64
build_type=Release
compiler=Visual Studio
compiler.cppstd=14
compiler.runtime=MD
compiler.version=17
os=Windows
os_build=Windows
[options]
[build_requires]
[env]
conanfile.txt: Installing package
Requirements
libusb/1.0.26 from 'conancenter' - Cache
sdl/2.0.20 from 'conancenter' - Cache
Packages
libusb/1.0.26:5a61a86bb3e07ce4262c80e1510f9c05e9b6d48b - Cache
sdl/2.0.20:fa88e8551f1d81168eeb9f59d3a183e3a584c5f1 - Cache
Installing (downloading, building) binaries...
libusb/1.0.26: Already installed!
sdl/2.0.20: Already installed!
conanfile.txt: Generator txt created conanbuildinfo.txt
conanfile.txt: Generator cmake_find_package created Findlibusb.cmake
conanfile.txt: Generator cmake_find_package created FindSDL2.cmake
conanfile.txt: Aggregating env generators
conanfile.txt: Generated conaninfo.txt
conanfile.txt: Generated graphinfo
-- Configuring done
-- Generating done
-- Build files have been written to: C:/Users/Administrator/Documents/GitHub/lgx2userspace/winbuild
PS C:\Users\Administrator\Documents\GitHub\lgx2userspace\winbuild> make
make: *** No targets specified and no makefile found. Stop.```
Happy holidays! :wave:
Can you give me a little more information about your setup?
I see that you're using Visual Studio is that correct? It might be that it's generated a .sln file that you can open using Visual Studio to then build the project?
I'll try and make more explicit instructions, but let me know if this helps at all! Good luck!
Hey, Thank you, happy holidays you too :)
About my Software used to build :
cmake version 3.24.2
Conan version 1.55.0
Microsoft Visual Studio Community 2022 (64-bit) - Current Version 17.3.4
About the OS itself:
OS Name : Microsoft Windows 11 Pro 64x
Version : 10.0.22000 Build 22000
About the machine :
Processor : AMD Ryzen 5 2600 Six-Core Processor, 3400 Mhz, 6 Core(s), 12 Logical Processor(s)
RAM : 16.0 GB
GPU : NVIDIA GeForce GTX 1070
I install MinGW using same steps as there : French tutorial to install MinGW for netbean On done I launched a powershell and did install conan with pip as pointed in your documentation And proceeded with the building steps
About the .sln when I try to build from there it complain pulse audio is not found with quite a lot of warning, I will remake it clean and do proper logs dump :) if you need more information I'd be glad to help ^^
Hmm, I'll try and figure out why this is happening - I tried to generate a config.h file that will disable Pulse Audio being built if you're building on Windows.
I think I'm going to pull out all the OS specific things (Video 4 Linux, Pulse Audio) out into separate OS specific libraries to make compiling a little easier.
I'm still in the process of trying to understand why 'hand' compiled SDL2 is tons slower than pre-built for ubuntu, so the annoying thing is, you may get to a built binary but then find out that actually the graphics performance isn't enough to be able to consume a stream.
I'm also looking into what it will take to make a 'virtual webcam' on Windows (and Mac) though I think Windows 11 might be the baseline and I currently don't have any hardware capable of running windows 11 :(.
In the meantime though, if you try opening Visual Studio and going to:
Project Settings -> C/C++ -> Preprocessor -> Preprocessor definitions
You should see something like WIN32;_DEBUG;_WINDOWS;_MBCS;$(NoInherit)
If you add __MINGW32__ to the list of declarations, that should trick it into thinking you're building using MINGW32 which should prevent Pulse Audio (and Video 4 Linux) dependencies being built!
okay so I did all that, it was still complaining about pulse audio
so beside checking with #ifndef __MINGW32__ to #ifndef _WIN32 in any files it was checking, this way I way I was absolutely sure.
So after that it complained about getopt.h being no available on windows so I provided one that work the same way.
getopt.h
getopt.c
After that it complained about
unistd.h
in file lgxdevice.cpp
I just commented the import and changed C++ Standard to 17
and changed function usleep to _sleep with same usage.
After all that it only complained about flag -Wextra being no available, since I was unsure I just made them in a condition like that :
if(CMAKE_COMPILER_IS_GNUCXX)
set(CMAKE_CXX_FLAGS "-Wall -Wextra")
else()
set(CMAKE_CXX_FLAGS "-Wall")
endif()
I was able to build but it not work (no frames, image and sound) Maybe my dirty steps could point to something?
I will do more trial and error later on I may have missed something :)
I've been trying to simplify the build process and make it uniform between platforms as much as possible.
I've created a GLFW based implementation of the lgx2userspace CLI application that doesn't use SDL and instead uses OpenGL and some shaders to leverage the GPU for doing the YUV → RGB conversion.
I think this should limit issues purely down to transfer speed of USB.
I've not been able to cross compile the GLFW executable as of yet however, so that might take me sometime to produce another release.
I know this doesn't solve the underlying issue of you being able to build the project but release/0.3.0 has a GLFW variant which may improve performance for you.
I tried both build SDL & GLFW. Both got the same result nothing launch at all :) no error, no black windows nothing even with -g argument and building still has same issues and with work around that the same result ^^
Ok this is interesting. Annoyingly I built it as a window application, not console, so gathering console output might not be possible, but, I did add in a check to make sure USB3 is being used.
It might be that the cable you are using isn't USB3 perhaps, unless you're using a stock cable!
Thanks for testing, I feel like we're getting a little closer, but for the next build, I'll have dialog boxes when errors occur for Windows.
I'm also going to see if I can't get visual studio compiling the application which will help with your situation.
I am pretty sure that is the official cable but I can try two other cables :) One is official with the blue thing in the plug to indicate it is usb3 (it work with older version) One is non official I got with an usb 3 hub and the last one from a camera and both of them do not launch the app sadly
Is there any chance you can run:
lsusb -vd 07ca:
On the machine from a Linux distro?
here the result I have, if needed I can do the same with both cable but this one is the from the card itself (I had it with a label like "AverMedia GC550" and it work under mac app without trouble both image and sound)
lsusb -vd 07ca:
Bus 004 Device 003: ID 07ca:4710 AVerMedia Technologies, Inc. GC550
Couldn't open device, some information will be missing
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 3.00
bDeviceClass 0
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 9
idVendor 0x07ca AVerMedia Technologies, Inc.
idProduct 0x4710
bcdDevice 2.07
iManufacturer 1 AVerMedia
iProduct 2 GC550
iSerial 3 201478400103
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0060
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 400mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 6
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0400 1x 1024 bytes
bInterval 0
bMaxBurst 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0400 1x 1024 bytes
bInterval 0
bMaxBurst 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0400 1x 1024 bytes
bInterval 0
bMaxBurst 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0400 1x 1024 bytes
bInterval 0
bMaxBurst 15
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0400 1x 1024 bytes
bInterval 0
bMaxBurst 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0400 1x 1024 bytes
bInterval 0
bMaxBurst 15
Everything in there looks good (at least what mine looks like when it's capturing data successfully!)
Thanks for grabbing that, I'm going to try and beef up the Window's error logging to see if we can't get more information.
I've pushed a change that adds error logging for windows that results in an error dialog being displayed.
Assuming it's not just a random crash in some obscure part of the code, it should output something meaningful!
If you can give CLion a go, it might make it easier to compile on Windows whilst I figure out visual studio.
I definitely make it easier,
So I have been able to build a GC550 build.
Now without any tweak or nothing so that a progress :)
Just now the frame is all bugged like issues #21 (with all default settings I just built it with cmake -DCMAKE_BUILD_TYPE=Debug .. -DENABLE_LGX_GC550_SUPPORT=ON )
Since I had no clue what video output it was using I just modified both VideoOuput.cpp to include GLFW & SDL to be sure to tell apart them.
By default I could tell it was using SDL and I see that it has the Vsync flag already so no clue why it fail
(also no audio still but not a big deal one prob at once)
And no idea how to build GLFW at the moment ^^
Hi @Baoulettes that's great progress!
There should be a specific lgx2userspace-glfw.exe file built which will use the GLFW renderer.
I'm really hoping using the GFX card will give you the performance needed! Let me know how you get on!
I was able to build it properly without change, so far I just did "build project" and not build "build lgxuserspace" (doing build lgxuserspace only will build only SDL variant :))
But sadly GLFW build start to appear but right after the window appear it crash, sometime the window remain white some other time it start black and crash instantly
Edit: I will build as debug and see what it look like it even help
\src\cli\lgx2userspace-glfw.exe -x
Process finished with exit code -1073741571 (0xC00000FD)
that the only information I get
The 0xC00000FD means a 'stack overflow'. I think I need to look at memory allocations in the project and move to heap allocation. I'll try to get that done very shortly.
I've been trying to get good rendering going on the Windows version inside of Virtualbox using GLFW. I had to backport the GLSL code to version 1.20 which thankfully was quite straightforward but surprisingly, there is next to no difference between the SDL and GLFW version on Windows.
What I have found though, is that the video render time is causing issues due to the single threaded nature of the application as it stands.
The Windows log output was:
audioOutput - average ns: 272
streamUpdate - average ns: 2218380
videoDisplay - average ns: 6054391
Whilst the smooth linux output was:
audioOutput - average ns: 224
streamUpdate - average ns: 2329956
videoDisplay - average ns: 1009948
In a virtualised environment, video rendering takes 6 times as long as it does compared to native.
All I can take from this is that if rendering takes more than a millisecond, the frames that come after it will be corrupt, even if the streaming speed (the time spent reading from the USB) is fast (2ms).
I'm going to see if I can't introduce some kind of double or triple buffering to try and make the experience more smooth, but it will come at a cost of latency, so I'd like it to be optional if possible.
nice now it does work exactly the same as SDL (GLFW seem smoother) Meaning : Smooth frame per seconds without skip "Flickering" bottom half of the frame No sound Good colors Both have same behaviour with all my cables ^^
Thanks @Baoulettes
Ok so to confirm now:
On your Windows machine, regardless of OS, you've been unable to get stable video output?
I'm going to see if I can downsample the video to reduce the amount of processing required and rendering, which should hopefully see some noticeable improvements, of course at the detriment of quality though!
I'm also trying to find a sufficiently portable sound library, I'm looking at libao right now, but there is no conan package which will make things a little more difficult for the Windows side of things.
yes that it, Here in this link you can see it properly in this sort clip :) Short video capture (without sounds) The only remaining issues is no sound and the video that is not stable :) For the building process with Clion that literally one line right now very nice that sad CLion is not free it seem really a nice IDE
Edit: I made it working with Visual Studio Code's tasks here a pastebin link if anyone need it :)
tasks.json build lgxuserspace on windows
Edit 2 : Funny I may have found out how to make sound to work under windows !
This is going to be the best I can do for now I think! The latest commit on main has video output scaling.
If you try the SDL output and GLFW with '-S4' as the program arguments, it'll output at 1 quarter scale.
If this isn't fast enough, I'm not sure your machine is going to be powerful enough to render output successfully.
When I was testing in Virtualbox, the USB read was taking 20 ms. This means it's impossible to achieve 60fps output, but it also means that reading from the device will forever result in corrupt frames.
I have an awful feeling that Zadig may add a latency that I can't compensate for.
If you get a chance to play around with this today, please try to get output with -v added as a program argument. (The application will only output to console if you run the program in debug mode!)
so trying to launch with arguments : -v -S4 -x it load with same artefact, a bit less frequent but still (funny I had it on my macos on first revision)
it is funny to think Zadig would bring latency since older version before GLFW implementation loaded frame properly on that same machine, the 0.2.0 .exe load it properly without sound I will see every commit and see I can spot something that really strange it used to be super fine without sound and now that fail
edit: here what I mean : Video of 0.2.0 & 0.3.0 running as seen on the video the S4 newest version has some frame issues still yet the older 0.2.0 has seem totally fine :)
it is funny to think Zadig would bring latency since older version before GLFW implementation loaded frame properly on that same machine, the 0.2.0 .exe load it properly without sound
!!!
I didn't appreciate that before!
I did remove compiler optimisations; it's a real long shot, but they could play a part.
Just to confirm as well then - you're using the exact same hardware, but you're using bootcamp to run Windows on the Macbook?
It'd be incredibly useful to see the timings for things, I'm going to make -v write to a lgx2userspace.log file instead to make life easier.
@Baoulettes I really appreciate this, it's helping lots and lots!
I have two computer one that is an imac late 2013 that show same performance as the one I sent spec there
About the OS itself:
OS Name : Microsoft Windows 11 Pro 64x Version : 10.0.22000 Build 22000About the machine :
Processor : AMD Ryzen 5 2600 Six-Core Processor, 3400 Mhz, 6 Core(s), 12 Logical Processor(s) RAM : 16.0 GB GPU : NVIDIA GeForce GTX 1070
and the one I recorded the video with :) both computer has the exact same issues on windows build, it just the imac is running windows 10 over windows 11 I run on the ryzen computer
Edit: I can confirm using release build with optimisation flag it does the job :) I mean the frame are Far better now it only one broken per second (or even less)
Argh, so I've just been looking into MacOS support also. (Just pushed)
I get the same behaviour as in your video. SDL2 as provided by brew out performs SDL2 as built via conan. This used to be the case on my Ubuntu machine also, though my Ubuntu machine is an absolute beast so I never noticed.
I'm really gutted that Conan provided dependencies don't mirror those shipped out via brew or apt.
I imagine if I were to get the libs for Windows also, the performance would be much better than hand-compiling via Conan.
I could only get semi stable output on -S4 on my 2020(?) Mac Mini with the conan built dependencies, and now using the brew provided ones, I can run full resolution.
I really don't understand how a GPU based YUV->RGB conversion isn't consistently fast though.
What an adventure this has proven to be.
I'll look at using pre-built binaries for SDL on windows too to see if it fixes the performance for me in my VirtualBox environment. If it does, I imagine performance will be consistent across all other machines too.
I will try using chocolatey or anything else that can be made from cmake for everything Conan use on windows and see if that work better and edit this message