ATEM ethernet protocol

Ask software engineering and SDK questions for developers working on Mac OS X, Windows or Linux.
  • Author
  • Message
Offline

darkos

  • Posts: 3
  • Joined: Wed Apr 28, 2021 11:55 pm
  • Real Name: Peter Belbin

ATEM ethernet protocol

PostThu Apr 29, 2021 12:10 am

In the ATEM Television Studio Switchers Manual, on page 199, it states:

Here at Blackmagic Design our approach is to open up our protocols and we eagerly look forward to seeing what you come up with!


So, where is the protocol defined that handles all of the remote control actions that the software and hardware panels manage to pull off on the ATEM switchers at?

If it's *not* available yet, *when will it be available*?

And: Where is the Linux variant of the SDK? I only see Windows and Mac offered for the ATEM SDK currently. But, I really need the Linux variant too!

Ideally, it would be available in a form that can be used on both x86 and ARM processor types.

Best Regards,
Peter Belbin
Offline

solander

  • Posts: 1
  • Joined: Sat May 01, 2021 12:46 pm
  • Real Name: Svart Adam Solander

Re: ATEM ethernet protocol

PostSat May 01, 2021 12:55 pm

I totally agree that this is sorely needed and has been for a long time!
Offline
User avatar

Xtreemtec

  • Posts: 4719
  • Joined: Wed Jan 02, 2013 11:48 am
  • Location: The Netherlands

Re: ATEM ethernet protocol

PostSun May 02, 2021 4:42 pm

The atem protocol is a secret for the last 10 years!!!
It’s a propertary protocol and bmd won’t release that one.

The offer a SDK for windows and Mac based systems to build your own software.

Skaarhoj did a reverse engineering on the protocol and documented that online. But stopped with that after FW 7,5. Probably due to legal issues with bmd for reverse engineering a propertary protocol.

If you look online there are a few C based sources on GitHub that will work with the atem ( look into the way Bitfocus companion did there implementation.. it is on GitHub so you can see how they did it. )
Daniel Wittenaar .:: Xtreemtec Media Productions ::. -= www.xtreemtec.nl =-
4K OBV Trailer, ATEM TVS HD, 4M/E Broadcast Studio 4K, Constelation 8K, Hyperdeck Studio 12G, Ursa Broadcast 4K, 4K fiber converters with Sony Control
Offline

darkos

  • Posts: 3
  • Joined: Wed Apr 28, 2021 11:55 pm
  • Real Name: Peter Belbin

Re: ATEM ethernet protocol

PostMon May 03, 2021 5:50 pm

Xtreemtec wrote:The atem protocol is a secret for the last 10 years!!!
It’s a propertary protocol and bmd won’t release that one.

The offer a SDK for windows and Mac based systems to build your own software.

Skaarhoj did a reverse engineering on the protocol and documented that online. But stopped with that after FW 7,5. Probably due to legal issues with bmd for reverse engineering a propertary protocol.

If you look online there are a few C based sources on GitHub that will work with the atem ( look into the way Bitfocus companion did there implementation.. it is on GitHub so you can see how they did it. )



From what I can see, *all* of their protocols are proprietary, pretty much, so why not also release this one??

Reverse engineering only goes so far. And, I have seen reports of people using non-official clients (ie: using reverse-engineered clients) talking to ATEM switches being pointed at as causing reliability issues (ATEM not being controllable in middle of a live production), and BMD washing their hands when they hear non-official SDK clients are being used.

IF BMD want to keep their ATEM protocol unpublished, they need to release supported clients for more software development platforms and languages. In particular, supporting languages that are hardware and operating system-agnostic: JavaScript, Java, for example. This would allow way more flexibility beyond just what native libraries for Windows and Mac provide.

It might be even better if they add support for a more modern approach rather than what they're doing. eg: status updates broadcasted rather than per-client.

eg: It seems that, in at least some cases, the number of concurrent client connections is restricted. It's understandable if they're not using broadcasting to provide status updates to same-subnet clients. If every client has to be sent it's own copy of the data, it becomes a burden on both the network and the ATEM having to manage all of that data. Broadcasting would eliminate this issue, but cause others, depending on how many switches are on the same network (manageable with VLANs potentially).

Alternatively, they could provide 'supported' proxy applications that are external to the switch, and create only a single ATEM connection, to which *many* other devices (and they would potentially leverage broadcasting to efficiently share the same status data with many clients) can connect without issue.

This is an area where they could/should do way better than what they've been offering so far.

How about it Blackmagic?
Offline
User avatar

Xtreemtec

  • Posts: 4719
  • Joined: Wed Jan 02, 2013 11:48 am
  • Location: The Netherlands

Re: ATEM ethernet protocol

PostTue May 04, 2021 4:38 pm

darkos wrote:How about it Blackmagic?


This is a User Forum.. So you wont get any official reply on this matter from a BMD employee.. :oops:

Yes you are correct.. Using other sources can become unstable, can lead to issues when a new FW build comes out..

The protocol BMD set up is a 2way UDP protocol to each client that is connected. So yes there is a limit to the connections..

And since it's UDP there are timers and packet counters in each packet to ensure packets are accounted for.. And connections are dropped when some client becomes offline.

All in all it's a very intensive protocol and i have a feeling the protocol is not there own build from the ground up.. I think it is already a rather old protocol that comes out of the Echolab time.. When Atem was still from echolab.. I have the feeling there is something that prevents them from opening it up..
And that has to do with a license or patent that is used in the protocol that prevents them from releasing it officially..


I completely agree with you that opening it up would more people benefit from it and also BMD would have more integration into the market.. On the other hand they now are the Only provider that sells the bigger 2ME and 4ME panels.. As nobody can build such panel.. And this was in the past used as "excuses" for not releasing the protocol.. But now the new panels dropped significant in price compared to the older panels.. And come at a pricepoint that a 3rd party builder is not even able to build something for.. It cant be that anymore..

On the other hand i think that they might want to keep people out of the implementation of the Atem protocol.. As poor implementation will lead to a LOT more support handling.. Which they now have largely in control because it's there own source that is communicating with the Atem.

Anyway the Atem protocol is there for about 10 years now.. And in 10 years there is not changed anything about opening it up..
So guess it wont happen in the next 5 years either..

BTW there is something going on with the new Atem mini's While it still accepts Atem protocol. It is possible with the newest firmware to control routing of sources for each output and internal endpoint...

So basically you have the option to switch PGM and AUX with Telnet commands..
But this did not trickle down the big Atems yet.. As there has not been any FW update for the bigger Atems in 12 months.... :roll: :roll:

Edit>> Topic about this >> viewtopic.php?f=12&t=123422
Daniel Wittenaar .:: Xtreemtec Media Productions ::. -= www.xtreemtec.nl =-
4K OBV Trailer, ATEM TVS HD, 4M/E Broadcast Studio 4K, Constelation 8K, Hyperdeck Studio 12G, Ursa Broadcast 4K, 4K fiber converters with Sony Control
Offline

darkos

  • Posts: 3
  • Joined: Wed Apr 28, 2021 11:55 pm
  • Real Name: Peter Belbin

Re: ATEM ethernet protocol

PostWed May 05, 2021 2:38 am

This is a User Forum.. So you wont get any official reply on this matter from a BMD employee..


That may be so, but, I *do* see the occasional post from Blackmagic Design staffers, so I would not say it's impossible, or beyond reason, to think that the posts are being monitored at least, especially for good ideas.

I see the telnet / videohub protocol being supported is a nice 'plus', as I expect it allows the videohub controllers to have rudimentary effectiveness talking to switchers, which probably helps solidify / expand their value. But, unless it is expanded upon so it can do everything the ATEM protocol supports, it's going to be of limited use.

On the other hand i think that they might want to keep people out of the implementation of the Atem protocol.. As poor implementation will lead to a LOT more support handling.. Which they now have largely in control because it's there own source that is communicating with the Atem.


I think you may be surprised as to how many clients are actually *not* using the official SDKs. There are a number of clients out there, and some of them are being used with *very popular* dedicated button keyboard controllers, and others that are parts of automation systems.

This is exactly why I suggested that additional language support be added, so that they would still be in control of the SDK / library that is used, but, provide support additional technology platforms than just native Windows and macOS. Java and NodeJS based clients being supported with libraries would be a huge win. These languages are highly agile in terms of the platform that they execute on, and there's already evidence that reverse engineering has happened, so this would be an opportunity to really improve the situation and make them able to be 'reliable'.

As an alternative, or, in addition, Blackmagic could also provide a verification tool that would allow 3rd party developed clients to be validated as being compliant, so there would be a way to know for sure whether the client is really behaving as it should.

Return to Software Developers

Who is online

Users browsing this forum: No registered users and 3 guests