CasparCG
AMCP v3
What's our wish list? @jesperstarkar @hummelstrand @dotarmin @TomKaltz @5opr4ni
- [ ] Asynchronous commands
- [ ] Possible preparation of commands to make sure they start at the same frame
- [ ] Command delay
- [ ] Composite commands
- [ ] Remove CG commands
- [ ] Don't touch casing of arguments
- [ ] Simplify and close to "hardware". Move abstractions to clients.
- [ ] Alternative transport protocols e.g. websocket, http?
- [ ] ...
- [ ] Possible preparation of commands (starting block with "CUE") finished by "TAKE" to make shure they start at the same frame
- [ ] "DELAY ms" command to pause AMCP command execution for specified time on server side (only for this AMCP connection/macro of course).
- [ ] "MACRO file" command to run prepared commands from file on server
- [ ] native serial AMCP interface
- [ ] find a better ADD command
- [ ] make shure clients can pull all necessary informations what is cued and playing on which layer by AMCP
- [ ] allow clients to pull durations and positions with AMCP command
- [ ] drop special flash layers
Correlation ID’s are very useful. My private 2.0.7 fork has something like this hacked into AMCP and the ffmpeg producer. I provide a UUID in the AMCP command and the producer gets marked with that ID when broadcasting playback status via OSC. Ideally this could be a core option where a producer can be fed a UUID via AMCP or the server can generate one, attach it to the producer and return it via AMCP response so clients can track playback status more accurately.
Separately I know the protocol is currently broken where AMCP responses come out of order and can not be properly tracked by clients if multiple commands are issued. How should this be fixed in next protocol? Could a correlation ID for the request also be injected by client?
I provide a UUID in the AMCP command and the producer gets marked with that ID when broadcasting playback status via OSC.
I like this idea. I have had difficulty making clients track playback videos when they reuse the same filename in a layer. If we serverside generated each producer an id upon construction, then that could be broadcast over osc and perhaps returned as part of the 200 PLAY OK response.
