Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SuperSource reports all boxes at default values #9

Closed
kellyzdude opened this issue Oct 12, 2021 · 7 comments
Closed

SuperSource reports all boxes at default values #9

kellyzdude opened this issue Oct 12, 2021 · 7 comments
Labels
bug Something isn't working

Comments

@kellyzdude
Copy link

I'm utilizing PyATEMMax in an effort to set SuperSource settings, but I'm also trying to gather the current SuperSource state before making changes.

I have this block of code pulling SuperSource state from my ATEM Mini Extreme ISO:

        for box in range(zboxes):
                zvalues[box] = {}
                zvalues[box]['enabled'] = switcher.superSource.boxParameters[box].enabled
                zvalues[box]['source'] = switcher.superSource.boxParameters[box].inputSource
                zvalues[box]['posx'] = switcher.superSource.boxParameters[box].position.x
                zvalues[box]['posy'] = switcher.superSource.boxParameters[box].position.y
                zvalues[box]['size'] = switcher.superSource.boxParameters[box].size
                zvalues[box]['crop'] = switcher.superSource.boxParameters[box].cropped
                zvalues[box]['croptop'] = switcher.superSource.boxParameters[box].crop.top
                zvalues[box]['cropbottom'] = switcher.superSource.boxParameters[box].crop.bottom
                zvalues[box]['cropleft'] = switcher.superSource.boxParameters[box].crop.left
                zvalues[box]['cropright'] = switcher.superSource.boxParameters[box].crop.right
        pprint.pprint(zvalues)

It gets me this output:

{0: {'crop': False,
     'cropbottom': 0.0,
     'cropleft': 0.0,
     'cropright': 0.0,
     'croptop': 0.0,
     'enabled': False,
     'posx': 0.0,
     'posy': 0.0,
     'size': 0.0,
     'source': PyATEMMax.ATEMProtocolEnums.ATEMConstant(name=, value=None)},
 1: {'crop': False,
     'cropbottom': 0.0,
     'cropleft': 0.0,
     'cropright': 0.0,
     'croptop': 0.0,
     'enabled': False,
     'posx': 0.0,
     'posy': 0.0,
     'size': 0.0,
     'source': PyATEMMax.ATEMProtocolEnums.ATEMConstant(name=, value=None)},
 2: {'crop': False,
     'cropbottom': 0.0,
     'cropleft': 0.0,
     'cropright': 0.0,
     'croptop': 0.0,
     'enabled': False,
     'posx': 0.0,
     'posy': 0.0,
     'size': 0.0,
     'source': PyATEMMax.ATEMProtocolEnums.ATEMConstant(name=, value=None)},
 3: {'crop': False,
     'cropbottom': 0.0,
     'cropleft': 0.0,
     'cropright': 0.0,
     'croptop': 0.0,
     'enabled': False,
     'posx': 0.0,
     'posy': 0.0,
     'size': 0.0,
     'source': PyATEMMax.ATEMProtocolEnums.ATEMConstant(name=, value=None)}}

Which 1) does not match the ATEM configuration (boxes 1 and 2 are enabled, both are scaled, and have non-0,0 positions), and 2) looks an awful lot like default values are being output.

Is this a defect in the module, or am I doing something wrong in gathering these details?

$ pip3 show pyatemmax
Name: PyATEMMax
Version: 1.0b5
Summary: A Python library to monitor and control Blackmagic Design ATEM video switchers.
Home-page: https://github.com/clvLabs/PyATEMMax
Author: Tony Aguilar
Author-email: onixag@gmail.com
License: GPL
Location: /home/administrator/.local/lib/python3.6/site-packages
Requires:
$
$ python3 --version
Python 3.6.9

I have not yet tried setting SuperSource parameters -- maintaining a cache of what I've told SuperSource to do would be a viable, though not-preferred workaround.

Happy to share any additional debug data if needed, just let me know what I need to provide.

@clvLabs
Copy link
Owner

clvLabs commented Oct 19, 2021

Hi kellyzdude,

First of all, thanks for your report. :)

Your code looks OK, it does seem as you're getting default values as you say.

I've been taking a look at the code, searching the keyword: supersource to see what I could find.

I used the original protocol reverse engineering docs to have a little extra info on the switcher's parameters.

Keep in mind I'm no expert in video switchers, in fact I have no experience at all using them. :·O

There goes a list of thoughts extracted from reading the code.

  • It seems you have to receive a _top (Topology) message to know the number of available SuperSources.
  • Also, you should expect some InPr (Input Properties) messages having Port Type equal to 6 (SuperSource) indicating if the SuperSource Box and SuperSource Art are available.
  • To have something filling the switcher.superSource.boxParameters[] you're looking at, you should have received some SSBP (SuperSource Box Parameters) messages detailing that data.
  • SSrc (SuperSource) messages might be interesting as well.

Please have a look at the logging section of the docs, more specifically the Specifying ATEMMax log level section.

You want to activate the DEBUG logLevel by adding a switcher.setLogLevel(logging.DEBUG) before your switcher.connect(), so you start seeing the messages you're receiving from the switcher, e.g.:

01:33:51.366 DEBUG    [ATEMConnectionManager] Received: [_ver] (Protocol Version)
01:33:51.366 DEBUG    [ATEMConnectionManager] Received: [_pin] (Product Id)

You'll have to look for the _top/InPr/SSBP/SSrc messages to understand what is happening.

Something which makes me a little suspicious is the fact of seeing 4 SuperSources in the output you send. The ATEMVideoSources constant, defined in ATEMProtocolEnums.py only has 2 sources related with this:

  • superSource: 6000
  • superSource2: 6001

Also, I don't think the library would initialize items from 0 to 3 in switcher.superSource.boxParameters if it didn't receive any SSBP.

Could it be a problem with your switcher's protocol version?

I'm guessing you'll see those SSBP messages received. If you do so, you may have to set the DEBUG mode to the internal socket, using switcher.setSocketLogLevel(logging.DEBUG) before switcher.connect(). Then you'll be able to look at the inside of the messages and check it with the reverse engineering docs to see if you're really receiving those zeroes from the switcher.

If you can't make sense of this part, please capture those verbose logs and send them to me, I'll take a look at them.

@kellyzdude
Copy link
Author

No problem! Thanks for the feedback.

logLevelDebug.txt

I see the _top, I also see _SSC a little further down
02:59:19.907 DEBUG [ATEMConnectionManager] Received: [_top] (Topology)
02:59:19.908 DEBUG [ATEMConnectionManager] Received: [_SSC] (Super Source Config)

I see multiple InPr messages:
02:59:19.912 DEBUG [ATEMConnectionManager] Received: [InPr] (Input Properties)

I also see multiple SSBP/SSRC messages, though they indicate errors in the data:
02:59:19.994 DEBUG [ATEMConnectionManager] Received: [SSrc] (Super Source)
02:59:19.994 DEBUG [ATEMConnectionManager] Received: [SSBP] (Super Source Box Parameters)
02:59:19.995 WARNING [ATEMConnectionManager] UNKNOWN ATEMBoxes 30 - processing [SSBP]
02:59:19.995 DEBUG [ATEMConnectionManager] Received: [SSBP] (Super Source Box Parameters)
02:59:19.995 WARNING [ATEMConnectionManager] UNKNOWN ATEMBoxes 244 - processing [SSBP]
02:59:19.995 DEBUG [ATEMConnectionManager] Received: [SSBP] (Super Source Box Parameters)
02:59:19.996 WARNING [ATEMConnectionManager] UNKNOWN ATEMBoxes 101 - processing [SSBP]
02:59:19.996 DEBUG [ATEMConnectionManager] Received: [SSBP] (Super Source Box Parameters)
02:59:19.996 WARNING [ATEMConnectionManager] UNKNOWN ATEMBoxes 110 - processing [SSBP]

Looking at the Socket level:
logCombined.txt

To be honest, I'm not sure what I'm looking at. It does appear to have the extra socket level debug data, but I don't know how to read it.

As far as protocol version -- it's possible.

To be clear, the four boxes I'm looking at are representing boxes on the SuperSource layout -- the Extreme only has a single SuperSource available, but it presents up to four video sources on the view. I'd like to be able to move those around on the canvas, but ideally I need to first know what the current state is.

@clvLabs
Copy link
Owner

clvLabs commented Dec 1, 2021

I think I found it!

Please bear with me... I'll release a new version with this bug fixed as soon as I can.

If you're in a hurry and feel brave about making changes in the library's code, it's just 1 byte (I guess/hope):
In ATEMCommandHandlers.py, line 755 you'll find:

        box = self._getBufEnum(3, 8, self._p.boxes)

Change the first parameter from 3 to 0:

        box = self._getBufEnum(0, 8, self._p.boxes)

... and you should be ready to go!

If you make this change, please let me know. Otherwise you'll have a new version soon, as I said.

@clvLabs
Copy link
Owner

clvLabs commented Dec 1, 2021

Besides that... while reading the debug dump you sent me I found something strange.

According to the original protocol description, inside the SSBP message :

  • Byte 10 contains the Cropped field
  • Byte 11 is tagged as unknown

The SSBP messages in your debug log contain:

Box Enabled Input Source Position X Position Y Size Cropped (Unknown) Crop Top Crop Bottom Crop Left Crop Right
00 (box1) 01 (ON) 1e00 (30) 03fb (64259) 1e01 (286) 5e01 (350) f4 (244) 01 (ON) 0100 (1) 0000 (0) 0027 (9984) 1027 (10000)
01 (box2) 01 (ON) f400 (244) 0201 (258) 2c00 (44) 0002 (512) ee (238) 00 (OFF) c200 (194) 0000 (0) 0000 (0) 0000 (0)
02 (box3) 01 (ON) 650b (2917) c3fb (64451) 16fe (65046) 5701 (343) 2c (44) 00 (OFF) c000 (192) 0000 (0) 0000 (0) 0000 (0)
03 (box4) 00 (OFF) 6e00 (6) 0000 (0) 0000 (0) 0003 (768) e8 (232) 00 (OFF) 6f00 (111) 0000 (0) 0000 (0) 0000 (0)

This makes me think that:

  • The documentation has bytes 10 and 11 swapped.
  • Your Box 1 was indeed cropped while the others were not.
  • There is really some information in that unknown field (sad we don't know what it is)

Is the information you see in the table right in any way ?

clvLabs added a commit that referenced this issue Dec 1, 2021
@clvLabs
Copy link
Owner

clvLabs commented Dec 1, 2021

Version 1.0b6 is already available on pypi, you can do a pip install PyATEMMax --upgrade

I won't close the issue yet, still waiting for your response on my last comment :)

@clvLabs
Copy link
Owner

clvLabs commented Jan 20, 2022

Just got a new pull request that seems to be related with this, looks like good news! 😄

@clvLabs
Copy link
Owner

clvLabs commented Jan 25, 2022

Hi there, @kellyzdude !
I just merged the pull request I was mentioning and just published version 1.0b7 on pypi.org.
I am almost sure this will solve your issues.
Please let me know so I can close this issue :)

@clvLabs clvLabs closed this as completed Aug 15, 2022
@clvLabs clvLabs added the bug Something isn't working label Aug 30, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants