[qatemswitcher example] Payload need sleep before connectToSwitcher() ?

[rem5]

Hello,

I think there is a conflict with payload data. I modified your qatemswitcher example to not use the graphical interface so MainWindow inherit in my case from QObject. I removed a lot of signals linked to the buttons and gui update.

Now I simplified the function connectToAtem with a ready known IP address. When i put a usleep (with #include ) with 1 second delay, the QAtemMixEffect gets good data.

void MainWindow::connectToAtem()
{
    QString address = "192.168.0.10";
    usleep(1000000);    
    m_atemConnection->connectToSwitcher(QHostAddress(address));      
}

But if I comment it or do a sleep with a lower value, in qatemmixeffect.cpp, the line in the function onKeDV : color.setHslF(hf, s.u16 / 1000.0, l.u16 / 1000.0); gives me sometimes

QColor::setHsvF: HSV parameters out of range

Because h.u16 has sometimes different values (58308, 64484) instead of 6 l.u16 has sometimes different values (11520, 21888) instead of 64 for example so it's out of range because divided by 1000.0 so not in the range 0.0-1.0 (http://doc.qt.io/qt-5/qcolor.html#setHslF)

I'm stuck here, do you have any idea why sometimes the payload is bad and needs a sleep at this moment ? The example here to try it: https://github.com/rem5/temp_dev (sorry not beautiful code as here... )

I think for the same reason (not enough time for payload ???), sometimes the mixEffect is not loaded so MainWindow::changeProgramInput() or MainWindow::changePreviewIntput() enter in the else part because me pointer is null/not instantiated.

Thanks for your ideas...

[petersimonsson]

Hmm interesting... I'll have a look at it and see what I can come up with

[rem5]

Hello Peter, did you have to time to look at it ?

Greetings

[petersimonsson]

Sorry no, life got in the way then I forgot about it... I'll make another try :(

[petersimonsson]

Ok, I've tried to look into this now and I can't reproduce it at all...

Which version of the ATEM firmware do you use? I've tried it with 7.1 and 7.2. I'm only able to test it against the original ATEM 1M/E Production Switcher so maybe there's something going on for other switchers... But I don't see how a sleep before connecting to the switcher would affect anything.

[petersimonsson]

Oh and I tried it on linux (dell laptop and raspberry pi3).

[rem5]

I will try to test again tomorrow and send you the most informations as I can Thank you for your first tests :)

[rem5]

Hello Peter,

I took the code from here: https://github.com/rem5/temp_dev/src

modified the IP in mainwindow.cpp, make then I launched./qatemswither -s SHOW_PC on an Atem Television Studio, firmware 7.2. It shows :

CONNECTING TO...
QATEMMIXEFFECT setHslF :  6  |  12  |  64
[doCCdP] Unknown camera feature: 8
[onCCdP] Unknown adjustment domain: 4
[onCCdP] Unknown adjustment domain: 11
CONNECTED
ARGUMENT SITUATION :  "SHOW_PC"
SHOW_PC ...

(good behaviour)

but if I launch the command again in a delay lower than approximately 1 second (as fast as you can in the console) it shows:

CONNECTING TO...
QATEMMIXEFFECT setHslF :  64484  |  12  |  21888
QColor::setHsvF: HSV parameters out of range
[doCCdP] Unknown camera feature: 8
[onCCdP] Unknown adjustment domain: 4
[onCCdP] Unknown adjustment domain: 11
CONNECTED
ARGUMENT SITUATION :  "SHOW_PC"
SHOW_PC ...

or

CONNECTING TO...
QATEMMIXEFFECT setHslF :  58308  |  12  |  11520
QColor::setHsvF: HSV parameters out of range
[doCCdP] Unknown camera feature: 8
[onCCdP] Unknown adjustment domain: 4
[onCCdP] Unknown adjustment domain: 11
CONNECTED
ARGUMENT SITUATION :  "SHOW_PC"
SHOW_PC ...

Can you try again with multiple calls as fast as you can, one after another ? If you can test it again theses days I'll very appreciate it. :) (I have here available for the tests a Television Studio and also an ATEM 1 M/E 4K but the last one is more difficult to use ; maybe next week...)

Thanks again !

[petersimonsson]

Ah I see... I wonder if you run into some limitation of the switcher. I'll have to test it a bit myself and have a look at the udp packets.

If you intend to send several commands in quick sucession I'm not sure bringing the connection up and down all the time is the best solution considering how slow the management cpu on the atem is. I would set up a daemon that talked to the atem and talk to that daemon instead.