Wirecast 10 - Rendezvous Bug - Can others confirm?
Using Wirecast 10 release for the first time in a show today. I was firing up Rendezvous. I have re-created my show template and reset preferences, so 100% clean starting point with Wirecast 10.
I sent a shot live... (no stream output or recording yet), and it all worked as expected. I then went to the rendezvous dashboard... and set the video input to rendezvous to be live output. My CPU load immediately doubled... and the fans started spinning up and preparing for take-off.
Can anyone else test this - and confirm if you get the same result?
Please find below full details on this bug.
- MAC, running OSX High Sierra
- Wirecast 10.0 Release version
Instructions to replicate:
- Start wirecast
- Reset preferences (to eliminate variables)
- Restart wirecast
- Open "Activity Monitor" and make a note of baseline CPU load and GPU usage
- Start with a new document
- Create a single shot with an input media file.
- Send the shot "live"
- Make a note of updated CPU usage and GPU usage.
- Open the "Rendezvous dashboard", and set the dashboard input to "Live output from untitled"
- 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.
I am tracking this bug here. Note: This portal is not officially endorsed by Telestream. However, there is no public facing portal that tracks known bugs. It is tracked here in the absence of anything more appropriate.Reply
Greg Kuhnert Perhaps you have a config specific issue. Or perhaps you're looking at single core use which can go from 30% to 50% or so in my tests. That's very low use when looking at 4 cores and up which is 400% and higher. If the file is H.264 it's certainly going to use resources to decode and that seems to go up when you're sending that to Rendezvous but overall it's low unless you're on a very old i5 (especially dual core).Reply
I have a single shot that has 150% CPU if you take into account the Wirecast CPU plus the VT decoder service... (60 and 70 each). Then - if you turn on Rendezvous, those numbers double - bringing total CPU to around 300%. On a four core CPU, that does not leave enough headroom in my opinion.
I demonstrated this via a live screen share to someone in Support earlier today. It is my intent to make a decent video that documents it... but I've been doing some non tech work in my video room - will get back to it tomorrow my time.
Hmm, I don't get numbers anywhere near that.
Craig... Here is a copy of a video that clearly demonstrates the problem. Note: There is extra load as a result of screen recording - but the results even without screen recording are almost identical.Reply
Greg Kuhnert You're adding to the CPU workload on the decode side. I'd say that's probably expected behavior. Complexity of the source is probably going to increase the resources needed for decode to Rendezvous. My numbers double too but my 2017 8 core (16 virtual) is certainly going to handle better than a 4 core i5 (especially if it's not the most recent vintage). The CPU capacity of the computer is certainly going to be a factor.
You can submit it but it's more likely a feature request for improved CPU efficiency when sending live output to Rendezvous.
Wirecast Feature RequestReply
My frustration here - is that I have not had this type of CPU workload before... even using the same document. Something has changed. I've eliminated all the variables I can. But lets take this another direction.
You asked earlier if I was using pro-res files? Will that essentially reduce or eliminate the CPU load because of how they are encoded at the expense of larger files? Is that what that VTDecoder process is doing?Reply
Greg Kuhnert said:
You asked earlier if I was using pro-res files? Will that essentially reduce or eliminate the CPU load
I believe the CPU load may be due to decoding H.264. ProRes should eliminate that. If it doesn't, at least that would verify that decoding specific codecs is not the issue. We can look at what else might be causing the CPU load increase with Rendezvous.
I"m not seeing any activity at all with VTDecoder.
An example how to find out what's initiating VTDecoder
Noting when feeding Wirecast Live Output to Rendezvous.Reply
I am 100% with you on the reboot thing - in fact, I have a "pre-flight checklist" that has that in there... Every time I stream. I am also very aware of startup items, and nothing in there related to this issue.
I am about to sleep. Tomorrow AM, I will package up something and send to you that might help nail this... west file and some media so you can replicate...
I did a little bit of research on this. I replicated my shot with ONE element only (a single video file). I tested it in two forms.
- I re-exported the video from FinalCut as H264
- I re-exported the video from FinalCut as ProRes 422
The interesting result was the results do not match what you said previously CraigS - The ProRes file you indicated would not require decoding, and therefore should be less CPU load. The reverse was true. The ProRes file is the only one that had any load on the VTDecoderXPCService. Looking at the three scenarios above:
- H264 = 15% - 20% wirecast, 0% VTDecoderXPCService = 15% - 20%
- ProRes = 10% - 15% wirecast, 20% VTDecoderXPCService = 30% - 35%
So. I did a bit more looking at the original scene. It had TWO ProRes elements in it. I tested (without Rendezvous), and got my high number of 60% in wirecast + more in XPCDecoderService.
Initially, I tested by turning off the display in the shot for those two elements. That should have removed the load from those elements. However, I had the same high CPU result.
I then tried removing removed those elements from the shot totally. And all of a sudden, the load was back to 15-20%.
For one more test, I tried ProRes 4444 instead of 422... That one had VTDecderXPCService load of 40%, and Wirecast load of 20%.
My composite shot uses two alpha channel movie files, which I have been using fr a long time. In earlier versions of Wirecast, the CPU load for this composite shot was significantly lower. I notice in another thread that there was discussion around this topic:
CineForm support was added in Wirecast 10, which we have a public beta for now. Please note that internally we saw that decoding CineForm is really expensive on macOS when compared to Windows, so I'd still recommend ProRes 4444 or QuickTime animation + alpha channel on macOS.
That tends to make me think that some work was done in this area, that is impacting us now... I dont even know what CineForm is - but I dont see it in the FinalCut export settings... All I know is that my existing scene that is UNCHANGED is now behaving badly... The only variable is the upgrade for Wirecast.
Even more research... My composite scene has three MOV file elements. One was H264, the other two were ProRes. I cannot convert the two ProRes files to H264 because they have alpha channels.
Those files are small logo elements that I loop. I thought I'd try one other radical approach. I converted them to animated gif's. Regretably, that was no good either. That took out the load from VTDecoderXPCService ... but wirecast went up to 150%
So essentially, I am screwed. My existing templates previously generated VERY low load of around 20%. After upgrade to Wirecast 10 - CPU is running so high that the stream was dropping frames last weekend.
As a workaround - I will do a local disk recording of that sequence - however there are parts of my show format where that cannot be avoided...