Performance implications of addWatermark usage and alternative approach suggestion

We’re adding a watermark to videos that we get from auto highlight capture or manual capture, right after the video was created.

As far as I understand, it works in a way, that the video that you’re adding the watermark to is fully processed, and the watermark is added to each frame.

This uses the user’s CPU, which would not be desirable and can lead to lags in game.

My main question:

  1. is this assumption correct, or is overwolf doing anything special to be more performant when adding the watermark?

As a followup I have a suggestion for a “better” way to add the watermark:
When setting up recording, it could be possible to define the watermark (file and position).
This watermark is then visible only in recordings, so that it’s not visible for the user or on stream, but will end up naturally on all recordings done.
This way there would not be additional processing needed and therefore no extra video-file created just to add the watermark.

Cheers :slight_smile:

Hi and sorry for the delay.

The watermark location and size can be configured: API · Overwolf

The watermark is added once the capture file is created. You can add it even “offline” - to a file that is already created before. I’m not familiar with the internals of it more than that. I can open a request for investigation to the R&D, but to be honest - I can tell you that it will take time, as we will assign it as a low priority - we are focused on other issues, and there are no complaints about the watermark performance or similar problems.


The watermark is added once the capture file is created.

can you elaborate on that?
Currently afaik the process is:

  1. video file is created (highlight)
  2. watermark is added through the api, creating a new video file.

This creates a second file and naturally requires some form of processing of the file to get the watermark on there.
Am I missing an option to have it added right away without creating an additional file?

@Colorfulstan This is the way that the API is currently working. I’m not familiar with all the reasons why it’s working like that, but I can tell you that now enhancing this internal mechanism will not be a high priority. I will discuss that internally and update you.


Hey @Colorfulstan,

I checked it further, and it looks that your description of the process pretty much reflects the actual process. And you are right; it’s not implemented most efficiently. One of the reasons is that we need to decide - what happens if we add the watermark on the capture phase and two apps are capturing at the same time… If you have an idea, you are welcome to suggest it…

Anyway, I will discuss that with the team to check if it’s time to improve the watermarking process.


1 Like

Hey @Colorfulstan,

We added this task to one of the subsequent iterations.

I will keep you updated here. Thanks.

1 Like

Thanks for your updates, following them but not replying if not needed :slight_smile:

Looking forward for what you guys come up with here :+1: