Rendezvous panel offloaded to a second machine
If you're pushing rendezvous again and trying to improve the quality, allow it to be run on the local network in order to offload the CPU requirements that drive that page. This would allow another machine to use it's webcam as the control room camera or bring in the primary program view of the Wirecast instance it's being driven from. It would work via a port on the primary wirecast and be run from the browser. It would also enable a second control room person to do the back and forth along with on-boarding guests during a show without impacting the host directly.
Not enough info on how this might be done. An entirely separate application? NDI out or? A reason to duplicate Skype or Zoom which already exists (or browser-based equivalent? What would be the differentiator to go in this direction with development resources?
Developers will want a very thorough description.
Not enough info on how this might be done. An entirely separate application? NDI out or? A reason to duplicate Skype or Zoom which already exists (or browser-based equivalent?
Let me give you an example of how this might work. (and this is just my opinion). Imagine a peer to peer connection between two copies of Wirecast. One for broadcast, one for Rendezvous. Licensing would allow rendezvous only instances to start, without a license being installed. The rendezvous sources would be made available to the Wirecast instance possibly using NDI or whatever technology you like as discrete sources, and the broadcast Wirecast instance could send NDI back to the Rendezvous computer using NDI as well. This would imply this feature would be a Pro only feature - but you could change that if you like.
There is lots more to this that could be incorporated - and it doesn't have to be NDI. Thats just one possible solution. But I agree with Matthew. This type of flexibility as a strategy to offload resources elsewhere is just a smart thing to do.
Functionality overview: Allow the rendezvous dashboard, which is obviously a webview hosted within a system window within the Wirecast process, to be able to be run from a local network device.
The return video could then be able to be that new device's webcam, an NDI source (through virtual input even), or even the Wirecast program feed itself via WebRTC to that other local device.
The intent is to offload the processing requirements of running the dashboard to a different device entirely. Greg Kuhnert has been able to demonstrate on multiple occasions that having the dashboard up causes significant CPU loads. The added benefit also comes in where an assistant can run the instance in order to manage the connected guests.
Regarding your omment about "reason to duplicate Skype or Zoom", you're clearly trying to do that with Rendezvous. Wirecast is currently unusable to broadcasters who use those tools due to the scaling issues that have been well documented. If Telestream really wants to have Rendezvous be a competitor to what it was originally rushed out to compete with, find ways of being able to ensure best optimization of system resources. Currently, the forum has more posts about these issues with it than most other software Telestream distributes. It would have been great if there were a small team of dedicated users who were trying to use this feature when it first came out and were providing all these similar issues. Just imagine how valuable that information would have been over the last multiple years. WINK