Window capturу source for skype, chrome or any window - has very overload CPU
I tested and in Three Up layer, Split Screen and in One Placer layer in any crop parameters
https://yadi.sk/i/TCkLDwxT3MExz2
I have macbook pro 2016, 2,6 Ghz, i7, 16 GB RAM, Radeon Pro 450
tested on sierra 10.12.6 on two different macbook air and pro
I have also noticed very high CPU usage with a similar setup. I am also chromakeying my window capture which seems to exacerbate the issue even more.
up, very often bug with overheat any layers with windows capture source (chrome, skype, safari, any)
test on split, interview, three up layers
@Stimpy @did Thanks for the comments. We’re using macOS APIs to capture a window and unfortunately, that is very CPU intensive as the way this works means that the application that the window belongs to needs to draw the content twice. It is much more economical (but also less convenient) to use a cropped screen source that can work with the pixels that are already on the screen.
Out of curiosity, what are you capturing? We try to work around that by eliminating the need for window capture. For example, we introduced mimoCall so that you can bring in outside callers without the need to capture a Skype window.
im captured:
sometimes when i change x/y/h/w of window it could work norm, but sometimes is not
its depend on crop parameters, some x/y/h/w - with cpu overhead, different - without. dont know why
We tried today mimolive reporter as mimocall partner, but user cant hear studio sound via app and via chrome macos. thats why continue use windows capture from skype
@did that is very strange. We’ve recently used mimoCall in the mimoLive Reporter launch event live with no issues. Maybe it isn’t obvious how to set it up. The mimoCaller is sent the Programm out audio minus their own audio. If the studio/host audio can be heard in the recodrding/stream it also will be sent to the mimoCall client. Can you send me the document that isn’t working so we can take a look?
waiting an beta update because window capture bug is frequent
some notes, even without stream and rec:
window capture in placer layer show 45-50 ms in render performance monitor (just static page chrome or statiс page safari)
when i open crop settings of window capture source (WCS) - the level of placer with WCS fall always to normal 10-14ms
when i close crop settings of WCS - the level rises again to 40-50 ms
but if i changed any crop parameter x/y/h/w even on 1 px - level could raise or could normal unpredictably (i dont know why)
video format of template: h264, 720p, 30fps
top macbook pro 2016, 16gb, i7, radeon
@did From your first screen shot I understand that you are running mimoLive in debug mode. Please do not use this configuration for production because this mode generates log output and measure rendering times that will influence the overall performance of mimoLive!
Regarding the Window Capture Source: Please note that the window capture process in macOS requires the window owning app to render this window twice: first for the screen, second for the window capturing. This is because the window could be in the background or parts of it could be offscreen and therefor this second rendering is necessary to have a clean view of the window itself. But this means that the window owning app is responsible for the CPU load it generated when rendering the window a second time. In case of a web page this may cause high CPU load because the rendering of a complex webpages costs some calculations. If you have a secondary monitor and lots of screen space you should consider to place the window here and just use the screen capture source which doesn’t require the extra rendering of the window. Downside of cause is that it is a “screen capture” and it will certainly capture overlapping windows etc.
The time difference in the render performance monitor when opening the the crop settings can be explained with the following: The image we are getting from the window capturing seems not to be optimised for our video rendering pipeline. Once the video rendering pipeline is using the window image in any way then it will get converted. This process takes some time and will be reflected in the layer that first uses this image. Now if you open the crop settings for the window capturing this conversion will happen earlier and not in the video pipeline anymore. Thus the video pipeline can work faster. But this is by chance because it might be that the video pipeline uses the image earlier than the cropping settings on screen.
Another thing to consider: When capturing a window it will get rendered in retina solution. This resolution results in four times more pixels than in normal screen resolution. Those pixels need to be shuffled around in memory and processed. But if you aren’t using this high resolution in your video production anyways you should consider to move the window to a screen with normal resolution.
To switch off debug mode in mimoLive, please hold down the alt key and open the mimoLive Preference Window in the mimoLive menu. You will get an additional “Debug” panel in the Preferences window. Here you can switch off debugging with the “Enable Debug Mode” check box. Restart mimoLive. The “Debug” menu should be gone.
Please consider to switch from Window Capturing to Screen capturing because of the mentioned reasons.
As mentioned in the window capture process there isn’t only mimoLive causing high CPU usage. Please can you check with “Activity Monitor” app by Apple which processes are the once with the most CPU usage? You will see that the WindowServer process also have to do a lot of work.
Also: While in Activity Monitor can you do a “Process Sample” of mimoLive while the Window Capturing is on?
Dear Achim
i took screenshots with activity monitor.
https://yadi.sk/d/j7vaDYw53Mw8LR
As you see - my cpu/gpu was not overload and have capacity even split layer with windows capture sourses was in red line
Sometimes windows capture work ok, sometimes work red line. it depends on the coordinates x/y/h/w, and the red line’s load can decrease or increase!!! after any of the coordinates by one pixel. That is retina there is nothing to do with
Very interesting bug
Windows Capture Source with facetracking has 4-7 ms rendering in monitor
https://yadi.sk/d/H3GKP7Uy3MwQQs
Windows Capture Source without facetracking has 17-30 ms rendering in monitor
https://yadi.sk/i/JkeRrEdI3MwQRS
@did This is not a bug, its the way the rendering pipeline works as I described earlier in this post:
“The time difference in the render performance monitor when opening the the crop settings [or adding a filter to a source] can be explained with the following: The image we are getting from the window capturing seems not to be optimised for our video rendering pipeline. Once the video rendering pipeline is using the window image in any way then it will get converted. This process takes some time and will be reflected in the layer that first uses this image. Now if you open the crop settings for the window capturing [or add a filter to it] this conversion will happen earlier and not in the video pipeline anymore. Thus the video pipeline can work faster. But this is by chance because it might be that the video pipeline uses the image earlier than the cropping settings on screen.”
Dear Achim
Did you see my screebshots with activity monitor?
https://yadi.sk/d/j7vaDYw53Mw8LR
Any ideas how does it depend on x/y/h/w?
Yes, its just the same: cropping means that we need to touch the pixels of the window capture before it goes in the video pipeline and then this cropped images don’t need to be processed anymore. The processing time just happens outside of the performance measurement of the video pipeline. It has to be done anyways but in this case not in the video pipeline.
But why in some cases, after closing crop settings, general pipeline had red line ?
@“Oliver (Boinx)” I am using Window Capture for several things but the primary of which is to capture a browser window then chromakey the background out for on stream alerts via services like StreamLabs and various others. There are numerous tools for Twitch streamers that rely on browser source type functionality to add additional interaction and engagement with viewers.
Tested all day.
Mimolive reporter (on iphone 6s, and chrome on macbook) incoming audio is not working.
Sound from reporter in mimolive - ok
Mic and Audio in mimolive program and in monitor headphones - ok.
Audio from mimo to reporter - no ok.
not in chrome macbook, no in iphone
As idea: Probably you make spec button for fix window x and y in settings for windows capture? Probably some concrete resolution and aspect ratio will help mimolive and CPU: perhaps this will facilitate the calculation of data?
How to facilitate window capture for less CPU?
I can not abandon this tool, since alternatives do not work
I tried minimize setting window crop for skype as posible
But sometimes, when i change layers (start video, o titles) - window capture layers do overhead for mimolive render performance monitors oк sometimes just drop fps
we use window capture sources in SPLIT, THREE UP layers (maybe it’s important)