padrereal2002

New Member
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'm a rookie here... in which folder do I have to copy the plugin files or folder for it to show up in OBS ??
Thanks for your help!
 

toplachi

Member
This plugin currently supports PTZ cameras that uses VISCA or VISCA over IP protocols which I don't think how OBSBOT works
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 ??
 

EB123

Member
subject tracking incorporated with PTZ would be a great thing.. it would be best if it worked more like it does with drones where it tracks an entire object you draw a box around (not just faces).. that way if you had an event and a person was moving and not always facing the camera it could still follow them.. even just face tracking would still be good though.. this sort of feature would greatly improve multi camera productions where there is only one person (or limited crew) trying to produce everything..

another feature that would be great to see with PTZ is a speed ramping function.. problem with most PTZ cameras is they look jerky when they start and stop movement.. if there was a way to ramp up/down the speed when they begin to move this would produce much nicer results.. even pressure sensitive joysticks never look consistent but if you could set a fixed ramp speed in software that was always the same it would look much smoother, more cinematic etc..
 
Last edited:

Chris Goringe

New Member
Just tried this out with a Zowietek PTZ NDI camera, and it works just fine.

Wondering if there is any chance of some way that it can be made to trigger presets when you switch scene?
 

glikely

Member
Functionality that is easy. The hard part is the UI. How would you like to have that work? e.g., when does the camera move, when a scene becomes visible in preview or program when using studio mode? Does it need to protect against moving the active camera? Etc.

It would help if you file an issue in GitHub that describes how you would like this feature to work
 

wimpy617

New Member
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!
 

glikely

Member
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
 

wimpy617

New Member
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.
 

glikely

Member
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.

From the ANPVIZ website, out looks like the camera uses the ONVIF protocol for PTZ control
 

braverock

New Member
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.

One tutorial for installing OBS plugins on linux suggested copying the pdb file resource out of a Windows zip file in addition to the .so object, but that didn't work in any of these locations either. I've never needed anything other than lua scripts and the obs-plugins *package* for ubuntu, so I'm still stumbling around in the dark as to where/how to install and enable the plugin.
 

glikely

Member
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.

Check the OBS log file to see if there is any messages from the plug-in. That will tell you if OBS is finding it. If you are still having trouble, file an issue in GitHub and attach the log file
 

norihiro

Member
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.
 

glikely

Member
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.

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?

Right now the PTZ code runs entirely in the frontend thread and is event driven. However, I don't have a clean separation between the UI and the PTZ backend. I need to rework the module initialization to manage the PTZDevice setup independently of the UI dock.

Instead of polling, would it be possible for the facetracking code to send events to the frontend thread? (Yeah, I know, that is still polling, but would be integrated into the Qt event loop.) I don't know enough about Qt yet to know how to do that though.
 

norihiro

Member
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?
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.

Instead of polling, would it be possible for the facetracking code to send events to the frontend thread?
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.
 

glikely

Member
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.

I'm currently using doubles because it was convenient for choosing relative speed. Each camera could have a different range of valid speed values. By using a double I can define "1.0" to mean fastest speed available and then let the PTZDevice instance rescale it to what the camera can do. It could be switched to int, but would need to define a scale for what those values mean.

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.

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.

I need the bind to receive UDP responses from the camera. Sending was no problem, but receiving required the bind. Also, since I've got multiple cameras I need to receive traffic from multiple cameras and send it to the correct device. The current code is very inefficient if there are lots of cameras because received packets are broadcast to *all* cameras using the same socket, but I plan to rewrite that code soon.

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.

Yes, UART will be a problem. I think if we want to support both manual camera control and driving from the facetrack plugin then we need an event/command protocol defined. Having two instances of a PTZDevice for the same camera won't work well in the long term. We'll need to either merge the plugins or have a protocol between them.

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.

From what I've read today Qt signals/slots are thread safe by default. If a signal is sent from a different thread than the receiver then Qt will default to queuing the signal in the receiver's event queue. However, that requires an object that inherits from QObject that can emit a signal from inside the facetracking thread. When the signal is emitted, Qt should notice the different thread and use a queued connection. The following was a helpful read:

 

norihiro

Member
Sending was no problem, but receiving required the bind.
I see that. Actually I was struggling to get the response of inquiry commands when I removed bind.

From what I've read today Qt signals/slots are thread safe by default.
That's good to hear that. Thank you for surveying it. I will consider to use that in my side.
Today, I released with the classes built in my plugin but I hope the communication using a protocol would be much better for users' experience.

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.
Yes, deg/s would be useful but it's not mandatory.
The zoom ratio (or raw code) is necessary. The gain for the pan and tilt has to be inverse-proportional to the zoom ratio.
I checked several manuals and find this calculation fit most cases in the range from 0x0000 to 0x4000. The code is not reached due to the problem of bind so far. The hard code 20.0f need to be configurable, for example 12.0f for max-X12 camera.
 
Last edited:

glikely

Member
glikely updated PTZ Controls with a new update entry:

v0.5.0 Released

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...

Read the rest of this update entry...
 
Top