obs-StreamFX
obs-StreamFX copied to clipboard
Xaymar
The new version of OBS 28 Beta 1 not work StreamFX 0.12.0 Alpha 45
Operating System
Windows 10 1903 and higher
OBS Studio Version
OBS 28 Beta 1
StreamFX Version
StreamFX 0.12.0 Alpha 45
OBS Studio Log
II will attach the log file in the "steps to reproduce the problem"
OBS Studio Crash Log
No response
Current and Expected Behavior
load the plugin "streamfx"
Steps to Reproduce the Problem
When I start the new beta version of OBS -
The error:
The following obs plugins could not be loaded:
StreamFX
Please update or remove these plugins.
and the log of obs 2022-08-05 12-23-29.txt
Any additional Information we need to know?
No
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
Beta and Release Candidates of OBS Studio are not supported, as they are Beta and Release Candidates instead of full releases.
Progress so far on OBS Studio 28.x support:
- Building with Qt6 is working, although not on all platforms.
- Linking against new FFmpeg, CURL and similar dependencies is also working, with similar limitations.
- Plugin appears to crash more than before with OBS Studio 28.x.
Progress so far:
- Windows is failed to link because it can't find CURL, but at the same time found CURL. This is probably the weirdest problem I've ever encountered, and suggests a bug in StreamFX's CMakeLists.txt.
- MacOS is failing to find 'obs.h', but it is definitely present. Seems like the
libobsConfig.cmakefiles are not setting the include directory correctly, or the CI cache is malformed. Whichever it is, it is breaking MacOS. - OBS exports invalid compiler flags with no regard to the compiler being used in the end. This is mostly harmless, but does incorrectly propagate flags to code not owned by obs-studio. Most likely these flags were supposed to be attached to libobs header files, and not the entire project.
- For some reason, libOBS requires the user to modify CMAKE_PREFIX_PATH, which mismatches the official CMake documentation. Perhaps this will be remedied in the future, but at the current time it is definitely weird for the end user.
For interested people, there are test builds available in #870. These builds are more alpha than alpha, and still need a lot of work, but they do finally build on at least one platform.
The path for Qt6(mac) is "A", not "6".
example: QtCore.framework/Versions/A/QtCore
Therefore, the path to the install_name_tool command will also need to be changed.
COMMAND install_name_tool ARGS -change "${T_QT6CORE_LINK}" "@executable_path/../Frameworks/QtCore.framework/Versions/A/QtCore" $<TARGET_FILE:${PROJECT_NAME}>
Thanks.
Therefore, the path to the install_name_tool command will also need to be changed.
Any idea why the libobs.Framework cmake config file does not have an INTERFACE_INCLUDE_DIRECTORIES entry only on MacOS?
Status:
- Build is working for Windows and Linux, for both Qt5 and Qt6.
- MacOS is failing as libobs.Framework has no INTERFACE_INCLUDE_DIRECTORIES, and as such can't figure out where
obs.his.
Any idea why the libobs.Framework cmake config file does not have an INTERFACE_INCLUDE_DIRECTORIES entry only on MacOS?
Sorry, I don't know.
After a day of delving into the Mac issue, I think I've tracked it down to the include directorioes property being completely empty when installing the obs_libraries component. I'll apply a temporary conditional workaround to make it work as expected again.
StreamFX v0.12.0 Alpha 77 supports OBS Studio 28.0. This issue is therefore solved.
Not sure if issue related, but I get following error when launching OBS on Linux with StreamFX;
QWidget: Must construct a QApplication before a QWidget
Aborted (core dumped)
using OBS 28.0.1-tytan652-1 (linux) could be that same Qt5 issue thats been reported for OBS v28, for plugins that use Qt5 in OBS v28 it will cause it to crash. I have no idea of identifying if it's related to StreamFX, but it would make sense if it does since it is referencing Qt related issue for QWidgets. (See: https://aur.archlinux.org/packages/obs-studio-tytan652#comment-879924)
As StreamFX's frontend starts loading after OBS Studio signals OBS_FRONTEND_EVENT_FINISHED_LOADING, this is most likely not caused by StreamFX. It would also affect all other platforms if it did.
I dunno, but this could be related to this similar issue in https://github.com/Xaymar/obs-StreamFX/issues/379
The bug described in the link has been fixed long ago. If you are using a StreamFX version that old, you will encounter much weirder problems. Anyway, track down what causes the issue, then report a new issue.
No, literally not it, I'm NOT trying to use an older version, I'm saying that the issue looks similar to what I've described before with the QWidget: Must construct a QApplication before a QWidget which is same literal error as seen in that other issue.
Please create your own issue, instead of abusing someone else's issue. There are releases for every possible version of OBS Studio, and none of them have this issue. Verify you fulfil the System Requirements, and if you do the next stop is the support Discord.
abusing someone else's issue
lul get real... what planet you from? Hows that abusing? It's literally describing similar issue to the one mentioned. Way to completely dismiss a perfectly valid issue, what kind of dev completely invalidates an issue like that, without even considering the possibility of "What If" the issue somehow returned as a result of something else wrong with the code that may possibly cause said issue, because such things can and will happen where an old issue may return. This kind of attitude will just turn people away and not bother filing reports on issues like these.
lul get real... what planet you from? Hows that abusing?
Earth. This issue is about v0.11.1 not supporting OBS Studio 28.0, which is expected as time appears to still flow in one direction only. There are builds of StreamFX available for OBS Studio 28.0, or you can spend your free time backporting the fixes to get v0.11.1 working on OBS Studio 28.0, or you can be like everyone else and wait for a full release to be available. What you've done here is be a complete entitled moron, and publicly too at that.
without even considering the possibility of "What If" the issue somehow returned as a result of something else wrong with the code that may possibly cause said issue, because such things can and will happen where an old issue may return.
The bug you linked was fixed over a year ago, and was only possible by the Qt code running before Qt was actually initialized. Because all Qt-dependent code is now listening to the front-end events, which can only happen after Qt is initialized, the problem lies with something on your end. Most likely you ignored everything written on the Release Notes of the release, and as such now run into the problems you could have avoided.
This kind of attitude will just turn people away and not bother filing reports on issues like these.
If it helps keep people like you away, good. Congratulations on breaking the record on an interaction ban by the way, the previous one was 3d22h, the new one set by you is less than 4h. New Record!