Switch to being Client or let others talk

[BaddMann]

Ok I'm very excited at how this project is coming along. Did some initial tests on the rec-timecode and I couldn't have asked for more. Then I started testing if the clients could pass on information to each other as they already had a connection to each other and may need to exchange info.

Oh no. Every message that isn't directed at the server is interpreted as bad json and a message to that effect is shared. Now my future webpage/app could account for this and just ignore the messages, but that's a lot of useless chatter. Can we add an option to ignore other chatter?

Then I thought more about it and realized that maybe I'd want the websocket server to not be hosted by OBS itself and maybe just be another client on an existing websocket server. Then I realized I might want to have multiple obs websocket clients check in on that server and be individually commendable! So we have to name each OBS websocket instance and have them respond to that individual name or an "all" name.

This rabbit whole is getting big. Hopefully this all makes sense, I just woke from a hot sweat dreaming about the possibilitys.

Thank you for your brilliant tool and time.

[BaddMann]

Individually addressable

[Palakis]

What I'd rather suggest is adding a "broadcast" request type where a client could broadcast arbitrary messages to other clients connected. This would be simpler to implement in the plugin's code.

What could be interesting is WAMP client mode using the Autobahn C++ library.

[Palakis]

WAMP is interesting because Crossbar has access control and more authentication modes, whereas obs-websocket has no access control and simplistic authentication.

[Palakis]

@BaddMann For a better understanding of the request, can you formulate an existing or potential use case for this feature?

[BaddMann]

I'm in a situation where I have two computers. One records the Video camera of the event, the other computer records the slides presented at the event. The camera is unfortunately attached to a BlackMagic h.264 recorder. It's not compatible with OBS no matter what I do and always has 30 second lag thanks to the encoder being on the device. This situation can always be fixed with better hardware, but I'm not in charge of the purchasing and figured I should see how to solve this another way. Also gives me an excuse to experiment in automated video editing.

Up until you got the time-codes in your web-socket plugin I was using the info writer plugin to record the transitions of the powerpoint slides. I'd then try and start the recording on both PCs at the same time and end it at the same time. If that did not happen I used a python script that used sound analysis to sync the timing between the camera and presentation videos.

I spent a lot of time building up an automated effort of joining the footage together, normalizing the sound and adding a bug to all videos I produce via moviepy. It used the timing of the slide transitions to cut the footage into smaller palatable chunks that can then be re-broadcast on the CCTV station that my venue runs. I almost have it down to the point where it can do all of this without supervision. I'm looking forward to making it more stable and add bumper clips to the clips with some artistic flair then upload those to YouTube eventually.

I get paid to record the event, I do not get paid to do the editing. With all this automating, I've almost lose no time on the editing anymore. Now I lose it making the tools to do the editing. One day I'd like to actually release something useful from all of this.

The biggest issue I've had beyond the syncing is choosing the content that should be cut out. with your web-sockets plugin I can now use my phone to quickly mark the Cut points and add titles for the lower thirds of each clip while the event is still in progress. when the event ends, that should trigger the post processing stuff immediately and most of the pre-load video processing can occur while I collect equipment. Once I get back to the Nest, I should be able to quickly glance over the summary of planned edits and allow or make small changes. I then leave for the day while the computers do the trans-coding and uploading.

I'm going to have an electron app monitor the websocket feed and trigger info collection from me during the event. I'll only have access to the app via my phone while the event is in progress, so will probably have an http interface there. The app will also be monitoring the sound and will use the autosub python app to create subtitles that will help with my quick editing in place as I can then choose exactly what lines I can perform the cut on. I was hoping to re-inject the subtitles into the websocket feed as it would help with editing, I could then just have one websocket monitoring both the subtitle creation and the scene transitions from OBS.

I'm just pitching this as an option for future changes, I can always make other things happen on my electron app to accommodate my needs, but thought it would be awesome if the future GUI I make for your web sockets could also have timecoded sub-titles and maybe timecoded chat from my other helper apps I'm hoping to build along the way.

Thanks for the consideration

[haganbmj]

I don't envy you at all @BaddMann - dealing with that audio syncing method across devices sounds like a pain.

I could see a use case for identifiers on events as well if something along these lines happens.

"Scene was changed to Scene1, initiated by WebSocket Client 2" "Scene was changed to Scene2, initiated by Host Machine"

Event: SwitchScenes

• scene-name: The name of the scene.
• event-actor: The identifier/alias that initiated the event.
  • id: The identifier of the actor.
  • alias: The alias/name of the actor.

To do that though you'd need to track requests and know the difference between the host machine and socket connections?

Then if you really want to put some basic messaging into the socket, which I'm not entirely sure that's the place for this - you'd have identifiers per each connection and a basic means of relaying messages. With everything timecoded to the stream, and maybe timestamped against the host system you'd have a pretty good log to work with.

[tt2468]

Possible with BroadcastCustomEvent in 5.0.0. Implementing a client into obs-websocket is not planned.