search

CasparCG / server

CasparCG Server is a Windows and Linux software used to play out professional graphics, audio and video to multiple outputs. It has been in 24/7 broadcast production since 2006. Ready-to-use downloads are available under the Releases tab https://casparcg.com.
GNU General Public License v3.0
904 stars 269 forks source link

Ember+ Integration #930

Open Phil403 opened 6 years ago

Phil403 commented 6 years ago

Hi all,

I just wanted to bring up a discussion about an integration of Ember+ Protocol from Lawo. It could be a good addition to the existing OSC Protocol, especially for Broadcast use. https://github.com/Lawo/ember-plus

Let me know what you think about this.

Regards Phil

jesperstarkar commented 6 years ago

Hi Phil.

Sure, it would be awesome. We have discussed this already with several broadcasters. One approach is to have CasparCG Clients which talk AMCP and still maintain control over CasparCG. However, some features of CasparCG could perhaps be directly controlled by Ember+? Is this what you are thinking? Du you have any idea on which features you would like to control over Ember+, directly or via a middleware/client?

Phil403 commented 6 years ago

Hi Jesper I think AMCP is a good way of controlling Caspar, so my thought was to either use Ember+ as an additioal protocol or as a substituion for OSC. In this case I would suggest that it should be implemented directly in the server instead of a middleware. I was thinking about translating OSC to Ember+ in a middleware but if there is an option to support it natively it would be better. Regarding the features I would say as a first step to only have read-only values supported. Something like frame-postition, infos about the layer, media etc.

Phil

jesperstarkar commented 6 years ago

After working with Ember+ integrations for the last week, I really see how it would fit CasparCG well. However, I struggle to see obvious benefits over the current OSC functionality. Do you see anything better in Ember+ other than interoperability with other broadcast-centric equipment?

5opr4ni commented 6 years ago

I think that ember+ belongs in the client, firstly.

Phil403 commented 6 years ago

Interoperability with other broadcast equipment and control systems could be a good feature to Caspar, especially since Ember+ was integrated by many manufacturers as well. I guess there could be three options for this:

  1. using a translation service OSC <> Ember+ this could be done in the client as well, but personally I would prefer a separate service for that

  2. adding Ember+ as an addition to OSC into the server this might be more interesting to people who do not use the standard client

  3. only using Ember+ instead of OSC this will lead to compatibility issues with current clients, so might not the best solution to start with...

As I said in the beginning, this is a topic which needs further discussion and investigation. looking forward to hear your thoughts.

dotarmin commented 6 years ago

@5opr4ni I think that ember+ belongs in the client, firstly.

I agree. I'm not sure how this would fit into the server it-self. I'm really trying to find another perspective on this but I really don't see it yet.

mint-dewit commented 6 years ago

I'm not sure how this would fit into the server it-self. I'm really trying to find another perspective on this but I really don't see it yet.

Not going to go on a rant here but have you tried to do a full implementation of OSC client sided yet? Over 2.0.7, 2.1.0 and 2.2.0 we've changed the structure of the paths just as many times. Then there's the wonky client/server set up, where the amcp client becomes the osc server. Causing multiple amcp connections from the same machine to not be able to use osc at the same time. And let's not forget that it sends out static information at the channel frame rate, which is fine but rather obnoxious.

I guess what I want to say is that a new native protocol would be a good start for discussion of how to properly implement sending state information from CasparCG.

dotarmin commented 6 years ago

@baltedewit Not going to go on a rant

Feel free! 😄

I can agree about OSC paths having been changed, most notably between 2.1.0 and 2.2.0 and that OSC is not the "quickest" thing to work with, I understand that. But I'm still skeptical about this (or neutral) but that can have to do with my lack of not working with Ember+ that much. I'm just trying to get new picture on this and understand how it would fit into the server! :bowtie:

I guess what I want to say is that a new native protocol would be a good start for discussion of how to properly implement sending state information from CasparCG.

I'm not trying to hold this back, I'm all open for it but is Ember+ the right choice or are there better alternatives for this purpose? I don't know. Nether less what protocol is used (or implemented) decision needs to be taken to do it the right way and stay that way to be consistent.

Julusian commented 6 years ago

I think something worth discussing for some distant future release is could ember+ (or something else) replace amcp too? Not doing to do in a hurry, as I too don't know enough about ember+ or other protocols to know what would fit best.

My reasoning for this is that the amcp parsing code can sometimes get confused (play 1-10 loop) or some commands arent very easy to understand unless you know exactly what order the params have to be in (cg 1-10 play 0 lt_demo 1). Having something more structured with each parameter named (eg json/xml) would help with both of these

dewiweb commented 5 years ago

If someone wants to develop an OSC<>Ember+ middleware, it could be relatively easy with npm . Effectively you could find to pieces for this with https://github.com/evs-broadcast/node-emberplus and https://github.com/colinbdclark/osc.js

Phil403 commented 5 years ago

@dewiweb thanks for the input, it does look interesting. Personally I am not that good with JS, since I do mostly .NET. But from my point of view the main discussion should be about using Ember+ in the server, probably instead of OSC. I think @baltedewit has some good points. OSC has some limitations and Ember+ could come in handy here.

5opr4ni commented 5 years ago

Just so that you know, we use OSC fifty times a second and we consume these packages in different applications.

Phil403 commented 5 years ago

Olle, you are right, I use OSC in different applications myself and it would be a pain to rewrite everything, so if Ember+ will be integrated in the sever OSC should stay for backwards compatibility. When you state 50 times a second, the valuable information which is transported is a lot less. The server sends OSC messages regardless if they are new or static information. Ember+ could help here since it would not update those. In the longterm, it might be worth switching to Ember+. happy to hear your thoughts.

dotarmin commented 5 years ago

Just so that you know, we use OSC fifty times a second and we consume these packages in different applications.

@Phil403, as @5opr4ni says it's heavily used and removing OSC or replacing it with something else is not an option. However an additional protocol could be added in the future (such as Ember+) giving developers the option what to use instead of having one. But before any protocol is added in addition to OSC, maintenance needs to be taken into consideration and the amount of work keeping those up to date.

:)

/Armin

Phil403 commented 5 years ago

However an additional protocol could be added in the future (such as Ember+) giving developers the option what to use instead of having one.

a config option for either using OSC or any other protocol, or any combination would be great. Only downside will be to maintain multiple protocols at the same time, as they are identical in their usecase.

Regarding AMCP:

I think something worth discussing for some distant future release is could ember+ (or something else) replace amcp too?

I dont think that Ember+ can be used as a way to control the server, but using json within AMCP might be interesting as @Julusian suggested. Maybe worth a closer look.

dotarmin commented 5 years ago

Only downside will be to maintain multiple protocols at the same time, as they are identical in their usecase.

This has to be down in a smart way meaning minimal effort to maintain both.

themormansound commented 1 year ago

Status on this?