Please find below full details on this bug.

Environment:

• MAC, running OSX High Sierra
• Wirecast 10.0 Release version

Instructions to replicate:

1. Start wirecast
2. Reset preferences (to eliminate variables)
3. Restart wirecast
4. Open "Activity Monitor" and make a note of baseline CPU load and GPU usage
5. Start with a new document
6. Create a single shot with an input media file.
7. Send the shot "live"
8. Make a note of updated CPU usage and GPU usage.
9. Open the "Rendezvous dashboard", and set the dashboard input to "Live output from untitled"
10. Make a note of the updated CPU usage and GPU usage.

My results: Wirecast behaved as expected up to step 8. When reviewing the CPU/GPU usage after opening the Rendezvous dashboard, it was noted that there was no increase in GPU usage, but the CPU usage doubled. Close the Rendezvous dashboard, and CPU usage returns to expected levels, and GPU usage is unchanged. Note: This was with a single simple source. When using more complex sources, the load and impact is much higher. 

My conclusions: The display of the program out in the Rendezvous dashboard on screen is CPU bound without using GPU, and using significant resources to display on screen. There are valid reasons to have the Rendezvous window open during broadcast. If there is no way to offload this to GPU, we should at least be able to disable the program display to save CPU cycles, since we can see it elsewhere on our screen in the main Wirecast application.

Please find below full details on this bug.

Environment:

• MAC, running OSX High Sierra
• Wirecast 10.0 Release version

Instructions to replicate:

1. Start wirecast
2. Reset preferences (to eliminate variables)
3. Restart wirecast
4. Open "Activity Monitor" and make a note of baseline CPU load and GPU usage
5. Start with a new document
6. Create a single shot with an input media file.
7. Send the shot "live"
8. Make a note of updated CPU usage and GPU usage.
9. Open the "Rendezvous dashboard", and set the dashboard input to "Live output from untitled"
10. Make a note of the updated CPU usage and GPU usage.

My results: Wirecast behaved as expected up to step 8. When reviewing the CPU/GPU usage after opening the Rendezvous dashboard, it was noted that there was no increase in GPU usage, but the CPU usage doubled. Close the Rendezvous dashboard, and CPU usage returns to expected levels, and GPU usage is unchanged. Note: This was with a single simple source. When using more complex sources, the load and impact is much higher. 

My conclusions: The display of the program out in the Rendezvous dashboard on screen is CPU bound without using GPU, and using significant resources to display on screen. There are valid reasons to have the Rendezvous window open during broadcast. If there is no way to offload this to GPU, we should at least be able to disable the program display to save CPU cycles, since we can see it elsewhere on our screen in the main Wirecast application.