Welcome to the PTZOptics forum(s)!
This thread has been created for end users to discuss the topic of PTZOptics potentially adding Broadcast Frame Rates to the cameras capabilities.
Please make sure to respect the experience level(s) of all users at all times when posting within our forums or your account may have access removed.
Currently PTZOptics cameras only provide solid frame rates for the video outputs.
Please provide any thoughts or feelings on the potential addition of broadcast frame rates as a capability of the cameras.
I have not heard of that issue yet... but with it being experimental I am sure there is certainly a chance of additional delay.
One suggestion I can make at the moment that may help improve performance is to temporarily test setting the IP outputs to 30 fps, or lower, rebooting the camera and re-testing the SDI output latency.
Either way I would love to hear some more details when you have the opportunity to fully test / trial the suggestion above.
I just started using this firmware on our 20x-SDI and I'm noticing more delay also. I've also experienced an issue where I lose video signal and it goes black for a split second then comes back. I'm not sure if this is related to our new Thor Broadcast SDI to fiber converter, which also transmits rs-485 data over a single strand of single mode fiber or the firmware.
I'm going to try and switch back to solid frame rate and see if the issue clears up (1080i 60)
FYI we are running at 1080i @ 59.94
We have not heard of the issue as you have described... yet.
You're the lucky first with this problem ;-)
If you could let us know if the solid frame rates showcase the same issue via your Thor SDI to Fiber Converter we would love to know.
That little Thor F-M1SDI-TX/RX looks like a pretty fantastic little box; the only thing of note is the HD-SDI limitation.
This should operate fine at the firstname.lastname@example.org as you've mentioned you're using but just wanted to bring it up as trying email@example.com may be worth testing along with the solid frame rates just to see how the system responds.
Every little bit of information helps us to try and resolve any potential issues when possible so any feedback is always appreciated.
Hopefully we can get to the bottom of this miscommunication between products in a timely fashion for you.
Thank you very much for following up here with this updated information.
Sorry to hear about the troubles with the Thor product, hopefully it's just a single problematic unit.
The data drop outs sound spot on if you saw that type of irregular behavior with hardwired control; sounds identical to when there's data drops with the IP version of our controller.
If there is anything we can do to be of assistance please don;t hesitate to reach back out here or to our support team at firstname.lastname@example.org
Thank you very much for the update and super glad to hear that everything is working as expected now.
If there's anything else we can help with don;t hesitate to come back :-)
Just to be clear, has this new "broadcast frame rate" firmware been moved from beta and thus is the firmware you get when you use https://ptzoptics.com/firmware-finder/
This beta feature will never exit beta for our G2 platform due to limitations in hardware that we are unable to correct.
This being said the feature does not cause complications or loss of any features for standard users not wanting to take advantage of broadcast frame rates and as such it is available for download for the following models via the firmware finder.
If you have any additional questions please let us know and we'll respond as soon as possible.
Thanks for taking the time to help.
So sort-of a matter of semantics... the firmware that includes broadcast rates is now standard issue, however, the new feature of broadcast frame-rates is a beta feature.
I know this is an old thread, but I finally got a chance to do some more troubleshooting last night on the video delay issue we're seeing from the 20X-SDI. I needed a way to prove that the Blackmagic capture card and vMix weren't causing the problem, so I looped four different manufacturer's cameras through a Decimator DMON-6S MultiViewer and then just captured it's output (quad split.)
While still running the original version of the beta firmware (that made broadcast frame rates available), there is a delay of 133 ms from the 20X when the output is set to 1080p30.
I then installed the most recent version of the firmware and changed the camera's output back to 1080p59.94. The delay is still there.
To workaround this issue for now, I've manually applied delays to vMix, but this puts the video displayed in the back of the room out of sync with the audio. (Can't delay the audio any more without impacting the rest of the room.) It's just too bad there isn't some way to eliminate this 8 frame delay (at 59.94) that we're getting from the 20X.
On a slightly different note, the newest firmware still does not allow the 20X at 59.94 to work with the Blackmagic capture card. I know you've said this is an 'A' vs. 'B' issue, but it seems there is more to it than just that. Two of the four cameras I'm using are outputting 1080p59.94 'A' and the Blackmagic card is not having any problems with them. I also took the SDI output from the Decimater and switched it back and forth between 'A' to 'B' and had no issue capturing it with the Blackmagic card either. There is something odd about the 20X's SDI output encoding that doesn't allow it to work with the Blackmagic capture card (at 1080p59.94), and based on this testing it seems to be more than just an 'A' or 'B' issue.
Is it possible for an older PTZ w/ POE will not do the broadcast frame rates? I have the same setup on both cameras, and the newer one works fine showing up in the ATEM 1 m/e, but the older one does not work unless I use a Decimator. They are both PTZ POE models.
This is entirely possible... and is one of the reasons that the broadcast frame rate option will never exit beta / experimental for the G2 platform.
It sounds like you have already taken this step, but felt worth mentioning, to make sure that the problematic camera is running the latest and greatest firmware version that can be located on the PTZOptics Firmware Finder
All of that being said I do have one (1) additional step to try that will hopefully resolve your issue...
After loading new firmware to the camera(s) you can occasionally be left with a camera that isn't behaving as you would expect.
I have left the descriptions of possible problems vague as it can showcase itself in a variety of fashions all typically leaving someone scratching their head.
If you find yourself in this boat, much as you described above, I would highly recommend performing a full factory default reset via the cameras OSD after the firmware update.
When a new firmware load is performed there occasionally can be stray data that was not fully wiped by the firmware upgrade process.
When you perform a full factory default reset after a firmware load you are ensuring that stray data, if present, is fully removed.
If you wouldn't mind sharing if this extra step was able to solve your issue we would greatly appreciate it.
If this does not solve your problem and you are able to share your cameras serial number I would be happy to do some testing on a unit produced at a similar time to see if I can replicate the issue.
Hoping we can get that second camera working the same as your other one (1).