Thank you for this update.... Its only now that I was able to test it... and its now working good!Give this test build a try: https://github.com/glikely/obs-ptz/actions/runs/944188476
Thank you for this update.... Its only now that I was able to test it... and its now working good!Give this test build a try: https://github.com/glikely/obs-ptz/actions/runs/944188476
I recently bought a PTZ - usb - webcam (OBSBOT Tiny Camera).... in OBS, in the properties, I can change all the PTZ settings... do you think your plugin will work to control the PTZ of this webcam ??
I wonder if this plugin can be integrated with this face tracker plugin in the future https://obsproject.com/forum/resources/face-tracker.1294/
Hey team, I'm the biggest noob here. I've had some success with an IP Network for a live stream, and am now trying to get a PTZ online. I can pull an image, but cannot control the camera. I know it is Pelco, which seems to preclude me from a lot of functionality. Will this plug in help? Any support would be appreciated!
What specific camera are you using? Are you needing to control it over serial cable, or over the network. I have not implemented PELCO support. It isn't hard to do, but I don't have any PELCO equipment to test with.
Please file a feature request for PELCO support as an issue on the GitHub page
Copy that, I'll look into filing a feature request. I'm trying to control the camera over a network. I got the camera from Ali Express. It's a ANPVIZ 5.0MP 5xIP PTZ Dome POE Camera.
I have no trouble building this plugin as a .so for (Ubuntu) linux. I just don't see it showing up in OBS. I've tried putting just the so in
/usr/share/obs/obs-plugins/
or in
$HOME/.config/obs-studio/plugins/
and I've also tried with a ptz-controls/ subdirectory under both those directories.
I'm also interested in that idea.I wonder if this plugin can be integrated with this face tracker plugin in the future https://obsproject.com/forum/resources/face-tracker.1294/
I'm also interested in that idea.
The face-tracker is mainly running on graphics thread to get the frame data. I'm not sure what is the best way to send the data. One possibility is having a source-callback on face-tracker, obs-ptz periodically poll by using the callback and send to the camera. I'm appreciate if you have something better idea.
Integer arguments for pan/tilt/zoom is preferable for tracking from my plugin. Since the moving speed is not proportional, I'm making a table to convert. Another change is removing `bind`, which I believe is unnecessary for UDP-client. If two or more cameras use the same UDP-port, I didn't try it but I guess it will conflict to receive data. Other changes are just removing global variables just in case it conflicts. Your code is well organized that it is easy for me to modify.I noticed that you've been hacking on the obs-ptz code, and I took a look at how you've been using it in your face tracking plugin. Cool stuff. I hadn't thought of using the obs-ptz backend as a library. Are there ways that you'd like to see the ptz code restructured so it is easier to use by the face tracker?
I think so, too. The polling is not the best way. I'm not so familiar with frontend and not sure any event can be defined by plugin developers. Maybe also need to define the destination. Using the signal of Qt might work. Because I'm not so good at Qt, one of the difficulties would be making it thread-safe.Instead of polling, would it be possible for the facetracking code to send events to the frontend thread?
Integer arguments for pan/tilt/zoom is preferable for tracking from my plugin. Since the moving speed is not proportional, I'm making a table to convert.
Another change is removing `bind`, which I believe is unnecessary for UDP-client. If two or more cameras use the same UDP-port, I didn't try it but I guess it will conflict to receive data.
Other changes are just removing global variables just in case it conflicts. Your code is well organized that it is easy for me to modify.
Current approach is partially working with VISCA-over-IP but it would conflict if both plugins try to access the same UART port.
I think so, too. The polling is not the best way. I'm not so familiar with frontend and not sure any event can be defined by plugin developers. Maybe also need to define the destination. Using the signal of Qt might work. Because I'm not so good at Qt, one of the difficulties would be making it thread-safe.
I see that. Actually I was struggling to get the response of inquiry commands when I removed bind.Sending was no problem, but receiving required the bind.
That's good to hear that. Thank you for surveying it. I will consider to use that in my side.From what I've read today Qt signals/slots are thread safe by default.
Yes, deg/s would be useful but it's not mandatory.If I got a bit more sophisticated, the pan/tilt values could be mapped to deg/s. The cameras I'm using (Sony) document that information, but I doubt all cameras do. Would that be useful in the face tracker? I imagine you'd also need to know the lens FOV angle and current zoom ratio to make proper use of it.
It has been a few weeks, so it is well past time for another release. The big headline in v0.5.0 is that support for the PELCO-P protocol has been merged. If you have a PELCO-P device, please do test and provide feedback.
Otherwise there have been lots of bug fixes and a few new features. The gamepad support is can now be turned on/off from the settings panel, keyboard modifies can be used on the pan/tilt buttons to adjust the speed, and information about VISCA devices is now outputted to...