Based on your UI, it seems reasonable to assume you are piping camera feed separately to each preset and therefore, causing a great deal of extra work. Manycam should NOT be as taxing as it is - I am on a 8 core i9 Mac and you’re killing the machine.
You should rearchitect Manycam to abstract cameras - perhaps into “looks”
one place to grab the image
one place to implement the chromakey
THEN fed as input to any presets that want that camera look.
I have N presets all using chromakeying - the key should be implemented just once, not N time as it appears to be now.
Thanks
p.s. I do have some track record designing video / imaging software and UIs. At least the Academy of Motion Picture Arts and Sciences thought so as did the Academy of Television Arts and Sciences. I’d like to help you step up ManyCam’s game.
Thank you for the feedback, will need to discuss with the team as I’m not 100% sure on the architectural details here but I do know we are making many optimizations/changes related to sources and layers in upcoming releases.
@ieo Please check this out, and ping me once you do.
Thank you. Rearchitecting would undoubtedly be a big job. Perhaps the most difficult thing to do in software development is to predict future needs and design in such a way as to support them.
I’ve looked at about a dozen applications similar to ManyCam. ManyCam seems to have the most promising basis upon which to move forward.
Chroma Key is indeed applied twice (green arrows) if you use it in two places. One of the main idea of manycam is that you can reuse your sources (Web-Cameras, IP-Cameras, Desktops) as many times as you want meaning in an arbitrary number of layers and several presets (preset is just the stack of the layers). This allows you to apply different transformations to any layer, for instance on one you want to zoom your camera and show your hands, on another layer you want to use the same camera feed but show your face and flip the image so text on your cap is readable.
As you wrote predicting future is hard and architecture reflects expectation of developers, but not customers. Per our view the customers should have 1 maybe 2 chroma keys, say desktop capture + camera with removed background on one preset and something else on another (meaning w/o chroma key). It looks like it is a wrong assumption. BTW what is your use case? How do you use Chroma Key? Is it Chroma Key option or Replace/Blur option?
One possible option for optimization is not applying Chroma Key for non active presets. Since only one preset is “live” at the moment (goes to say Zoom) other presets do nothing usefull except rendering for previews. In the latest update of ManyCam (v7.4 for mac and v7.5 for win) we render non-live presets with lower FPS, but in fact we can think about stopping to render it at all or render at 1 FPS. This way we will apply chroma key only once.
Your suggestion to put chroma key right after the camera feed (noted as green box at the scheme above) may be a good solution, but what if you don’t want to apply chroma key to your camera in all places? Maybe we should consider this option with @Chris_MC, but it may be confusing for some users.
The 3rd option is caching the results of Chroma Key, but the things are more complicated that they seem at first: we have playlists, different transforms per each layer, different layers size etc.
The same I say anytime I see RAM consumption of Chrome . Please share your CPU usage, normally ManyCam is limited to 2 cores (of course it is still high). Please make sure that you have enabled Hardware Acceleration (on by default).
Yours is probably the best response from a company on a technical suggestion I’ve made ever. As one might guess, the most common response is no response. This is followed by “Thank you”. Rarely does a company respond with a forthright contemplative answer that seeks to encourage dialog. Thank you.
Borrowing from the example of node-based compositing systems (and what is ManyCam but a compositing system?), could be extremely useful to you in order to a) increase generality of architecture b) increase user flexibility c) decrease computation. Another informative example might be found by considering the command line “make” and “makefile”. In both cases, the leaves pull from the nodes above them stopping if either they hit a) a source node or b) a node that has already been computed.
This (b) part is most germane to the topic at hand.
The above picture, if it shows up at all, shows how any subtree can be labeled as a terminus. Then, the terminus can be fed into the input of any number of other subtrees.
I’ll pause here and post to see if the picture works.
camera -> chromakey over clock over background - call this “MAIN”
camera-> chromakey scaled down left composite with clock and Visual Studio Code - call this “CODE”
camera-> chromakey scaled down left composite with clock and iPad - call this “WHITEBOARD”
camera-> chromakey scaled down left composite with clock and Browser - call this “BROWSER”
camera-> chromakey scaled down left composite with clock and Terminal- call this “SHELL”
camera-> chromakey scaled down left composite with clock and Video- call this “VIDEO”
clock is a Mac Desktop App rendering a nice wall clock.
This shows the typical use case of what I want to do every day. Notice here the need for copy / paste of presets. The position of the scaled down / positioned camera and the clock must be the same on every preset to be seamless.
I agree with Perry that creating “Sources” from camera and then reusing those across presets would be much better. I believe OBS does this.
I run regular webinars that are news or talkshow formats. In some cases, we’ll have 2 speakers in others we’ll have 5-6. In the case with 2 speakers (News format), we have different presets (Just the Speaker, Speaker with quarter screen slides, Full screen slides with small speaker, Moderator only, Moderator and Speaker, etc…) See my preset setup:
In this case, with only 2 camera, there are 7 unique streams coming into the presets. This wastes a lot of bandwidth and really taxes the CPU. (Also running a Mac with an 8 core i9)
I’ve tried to run a talk show format with 5-6 remote panelists. In one preset, I would have 1 speaker. (A) In some I would have all 6. In another, I would have 2 speakers. (A & B) In another, I would have 3 speakers. (A, C & D) etc… This caused 20+ separate streams and caused Manycam to become unresponsive. We had to use a different tool.
I really like Manycam would like to see this changed.
Thanks for your scheme. @Extreme-John, just in case we reuse “sources” from camera meaning it is decoded only once, but as the “A” terminus, not “B”. Regarding your suggestion we discused very similar approach yesterday (internally) and I think we may go with it for the Virtual Background feature. I hope you understand that we can’t change it quickly, but we will put it into our roadmap. However we may also try other optimization options.
Thank you for providing your case (unfortunatly I was unable to open your screenshot). Can you confirm that you use Chroma Key (Green Screen) option, but not Blur or Replace:
Anyway, I think that the main CPU consumer in your case is not Chroma Key, but Application Window Capturer. In short, capturing app window in ManyCam is extremely slow, while capturing fullscreen is much faster (macOS provides gpu-accelerated API for fullscreen capturing, but not for app windows capturing). If I correctly understood, you have 6 app window capturing presets and I beleive disabling Chroma key for them will not drop CPU usage significantly (could you try please?). Right now we capture all windows with the same FPS set in manycam (30 by default), but we could optimize it by capturing non-live windows with much lower FPS. If you can confirm that window capturing consumes a lot of resources that would be great.
BTW @Chris_MC I think that we should implement copying chroma key options from one layer to another, what do you think?
Thank you for your work!
I apologize for delay in getting back to you - I am on Zoom for EIGHT HOURS on Thursdays spread over twelve. I hate Thursdays.
Yes - confirm chromakey - not blur.
Your idea of reducing frame rate for non-active streams has a great deal of merit - elegant.
I will check the CPU impact of capture when next I am on that machine.
Also with regard to window capture (as well as camera identification but enough different that I’ll not consider it here), every time ManyCam starts up, I have to reset all my window captures as you seem to be identifying windows based on their full window title. I might have selected window “Code - foo.cpp” yesterday but I have “Code - bar.cpp” today. I have to reset manually. Perhaps allow users to enter a simple regex?
Wow Perry_Kivolowitz. So glad you are on board. I think I remember you from the late Amiga days. I had an Atari fully populated into external chroma-keyer, etc., but you guys went so far beyond everything. Amazing. I also have the MBpro 16 i9, and it gets hot with ManyCam. This discussion is very helpful.
. Please share your CPU usage, normally ManyCam is limited to 2 cores (of course it is still high). Please make sure that you have enabled Hardware Acceleration (on by default).
How about a zoom call? AH - Got it to work!
