- Thread starter Warmuptill
- Start date
Warmuptill
Active Member
Thank you for your efforts in narrowing down the root cause!
I think I have an idea what could be causing the issue.
I am directly modifying widgets from an non UI thread.
I believe that is something you are not supposed to do in Qt and could explain why the crashlogs point to random points in the Qt libs.
I reworked the preview / area selection dialog so it no longer does this, but instead uses the Qt signal / slot mechanism.
A build with this change should be available here in a few minutes:
Rework preview dialog to use signals / slots to update image data · WarmUpTill/SceneSwitcher@31ad9da
An automated scene switcher for OBS Studio. Contribute to WarmUpTill/SceneSwitcher development by creating an account on GitHub.
github.com
I would appreciate if you could give this a try.
Last edited:
will get it loaded and see if I can break it. Hopefully notThank you for your efforts in narrowing down the root cause!
I think I have an idea what could be causing the issue.
I am directly modifying widgets from an non UI thread.
I believe that is something you are not supposed to do in Qt and could explain why the crashlogs point to random points in the Qt libs.
I reworked the preview / area selection dialog so it no longer does this, but instead uses the Qt signal / slot mechanism.
A build with this change should be available here in a few minutes:
Rework preview dialog to use signals / slots to update image data · WarmUpTill/SceneSwitcher@31ad9da
An automated scene switcher for OBS Studio. Contribute to WarmUpTill/SceneSwitcher development by creating an account on GitHub.
I would appreciate if you could give this a try.
Ok,
You are a Rock Star, the selection window has never been more responsive and I have tried everything to get it to crash with no luck.
It would appear that you hit the nail on the head with the fix
Will let you know if it rears it's ugly head again but it seams to work better now than any of the previous releases and I have crashes is all of them but the newest. The fix seams to be rock solid
I had a project years ago with Qt, and I can confirm that doing UI stuff from non-UI threads is indeed problematic. And the signal/slot mechanism is indeed the correct way to do it.
I've since moved from Qt to wxWidgets for my own stuff, but that general rule still applies: only the single UI thread reads and writes the UI. All other threads use the provided mechanism to communicate with the UI thread; they never touch the UI directly.
It *is* okay to have the UI thread do other stuff as well, so it's entirely possible (and often practical for small apps) to do everything in that one thread. But it also risks slowing down the UI for the more complicated stuff.
Any suggestions on how to trigger the ASS to write the replay buffer
video source changes by flashing a number (I want to trigger on this, wait 1/2/3 seconds, then write the buffer)
number goes away to a white screen until some time later a new number is displayed and cycle repeats
For some reason I get 3 and 4 triggers with 1 number display. Currently trigger is if source changes in defined area. So I could see two triggers as the number shows up and goes away but I get 3 and 4 or more triggers
Any ideas would be appreciated
Thanks again for all that you do. It is simply amazing what the ASS can do
video source changes by flashing a number (I want to trigger on this, wait 1/2/3 seconds, then write the buffer)
number goes away to a white screen until some time later a new number is displayed and cycle repeats
For some reason I get 3 and 4 triggers with 1 number display. Currently trigger is if source changes in defined area. So I could see two triggers as the number shows up and goes away but I get 3 and 4 or more triggers
Any ideas would be appreciated
Thanks again for all that you do. It is simply amazing what the ASS can do
Warmuptill
Active Member
That is great news! :)
Thank you for your patience in getting this sorted out!
I have to suggestions that might help here:
- I would enable pattern matching to prevent any video compression artefacts incorrectly triggering this condition.
- Adding a duration modifier of the type "with the last ..." to the video condition in combination with macro option "Perform actions only on condition change" will result in the macro only executing its actions at most every X seconds. (Assuming there are no other conditions that might conflict with this setting)
Hope that helps!
here is a video
Untitled video - Create and share your videos with Clipchamp
Watch videos made with Clipchamp, the best video maker for everyone.
Might help explain
Warmuptill
Active Member
The condition being highlighted in green does not mean that the actions are being necessarily being executed as well.here is a video
Untitled video - Create and share your videos with Clipchamp
Watch videos made with Clipchamp, the best video maker for everyone.clipchamp.com
Might help explain
If you enable all highlighting options you will see if the action is executed, when it is highlighted in green. (Just like a condition would be if it is true).
If the "Perform actions only on condition change" checkbox is flashing yellow that means that the execution of the actions was prevented due to that checkbox being ticked.
For example:
Will play around with it some more. All I know is every time it flashes it writes a file.
Found a possible solution but more complicated than it should be.
I un-pause a separate macro (Replay) , Run it , then wait a second (or 2) , pause the macro (Replay)
Replay: If Macro1 count = 1, It will wait a second, write the buffer, wait another second, then reset the counter
Seems to work, will need to work on the delays a little. goal it end up with say 7 seconds before # and 1 or 2 after.
your idea is cleaner if I can make it work
now if I can just get the replay buffer to be the length it is told. 7 seconds ends up being 4-8 seconds randomly
Found a possible solution but more complicated than it should be.
I un-pause a separate macro (Replay) , Run it , then wait a second (or 2) , pause the macro (Replay)
Replay: If Macro1 count = 1, It will wait a second, write the buffer, wait another second, then reset the counter
Seems to work, will need to work on the delays a little. goal it end up with say 7 seconds before # and 1 or 2 after.
your idea is cleaner if I can make it work
now if I can just get the replay buffer to be the length it is told. 7 seconds ends up being 4-8 seconds randomly
Just a side-note for device compatibility: I often read this forum and comment with a Raspberry Pi (still use the main rig to test stuff and get screenshots), and for some reason ClipChamp doesn't work on the Pi. It just hangs on the first frame. YouTube does work.here is a video
Untitled video - Create and share your videos with Clipchamp
Watch videos made with Clipchamp, the best video maker for everyone.
Might help explain
I don't think I *need* to see that particular video - looks like Warmuptill has you covered already - but just FYI for future reference, and for anyone else that might happen to see this.
So like I said, not a programmer
How do I use variables?
Want to set a variable in a macro and then use it to write a file with that name
What would be even better (probable no way to do it) is to set a variable in a macro, then use that variable as the file name prefix and write the replay buffer with the prefix and other stuff
How do I use variables?
Want to set a variable in a macro and then use it to write a file with that name
What would be even better (probable no way to do it) is to set a variable in a macro, then use that variable as the file name prefix and write the replay buffer with the prefix and other stuff
Warmuptill
Active Member
Unfortunately I don't think that is possible yet.
So through much trial and error I have a way to Change the name of the replay buffer file automatically.
So I have ASS write a text file with the prefix I want name the file (This will be dynamically changing)
Then when condition is met to write the replay buffer
Ass writes the replay buffer,
waits 1 second to make sure it is saved
Runs a batch file to rename the file with the prefix stored in text file previously written and delete original file (might just move it to a new folder but will see how it goes)
I do change the prefix on the replay buffer to make the file start with "Replay" and then use that to find the file to rename.
Did it on a test case now just have to add it into my macros
So I have ASS write a text file with the prefix I want name the file (This will be dynamically changing)
Then when condition is met to write the replay buffer
Ass writes the replay buffer,
waits 1 second to make sure it is saved
Runs a batch file to rename the file with the prefix stored in text file previously written and delete original file (might just move it to a new folder but will see how it goes)
I do change the prefix on the replay buffer to make the file start with "Replay" and then use that to find the file to rename.
Did it on a test case now just have to add it into my macros
I wonder if you can simplify it a little bit by passing a variable as an argument to the batch file. So you'd skip the "name file", and call the batch file with the desired name instead. You could also pass it the (constant) path to the raw file, just to keep all of the change-able stuff inside of OBS. (but still in two places)
I'm using OBS to record snail locomotion from multiple angles with overlays to improve speed measurements for a research project. I'd like to use advanced scene switcher to make an "alarm system" that changes the scene briefly to flash red and play an alarm sound when the snail ventures off the desired path to let me know I need to reset and abandon the run. My current macro is set up to switch to a different scene if the video feed on either side of the main track has changed. While this recognises when my hand crosses through the area, the snail appears to enter the restricted section too slowly for the software to notice the change. Is there a way to improve the accuracy of this set-up? Or are there different macro conditions that might work better?
Sounds to me like you need a static detector instead of a dynamic one. "This area not empty" instead of "this area changed." I haven't used the machine vision part of Adv. SS, but maybe you can give it a picture of an empty track to compare to, along with a detection area? (might be in the same picture, depending on how it actually works)
Warmuptill
Active Member
I agree with @AaronD.
Instead of using the "has changed" check type using "matches pattern" might yield better results.
The pattern would be the background where the alarm should be triggered (without any snail).
A macro would then trigger if a snail ventures into the given area of the screen and thus the pattern no longer matches the empty background.
An example of using the pattern matching can be found here:
Activate overlay to hide parts of the screen
An automation tool for OBS Studio. Contribute to WarmUpTill/SceneSwitcher development by creating an account on GitHub.
github.com
I must admit I could have never imagined the plugin being used for something like this when I created it and that kind of made my day!
So thanks for that! :D
Let me know if you have any questions!
MattEatsMochi
New Member
There's also an If Not option...