libobs: Fix obs_canvas_reset_video when other canvas is active

[exeldro]

Description

Fix obs_canvas_reset_video when other canvas is active
obs_video_active call is replaced by the new obs_canvas_video_active

Motivation and Context

Want to initialize extra canvas while the main canvas is active.

How Has This Been Tested?

On windows 11 by starting output of main canvas before calling obs_canvas_reset_video on an extra canvas

Types of changes

• Bug fix (non-breaking change which fixes an issue)

Checklist:

• My code has been run through clang-format.
• I have read the contributing document.
• My code is not on the master branch.
• The code has been tested.
• All commit messages are properly formatted and commits squashed where appropriate.
• I have included updates to all appropriate documentation.

[derrod]

I suppose this is less of a fix and more of a "what do we want the behaviour to be" question. Right now we don't allow reconfiguring many things if any video output is active, and canvasses replicate that behaviour. Should it be different? Perhaps. Arguably OBS is currently overzealous with blocking configuration changes.

[exeldro]

At the moment when OBS starts and for example decklink starts output of the main canvas on startup all other canvases can't load. They are not initialized (fix in #13102) and can't be changed ( fixed in this PR). So it leaves OBS in a broken state that the plugins providing extra canvas can't fix without force stopping outputs created by others

[PatTheMav]

At the moment when OBS starts and for example decklink starts output of the main canvas on startup all other canvases can't load. They are not initialized (fix in #13102) and can't be changed ( fixed in this PR). So it leaves OBS in a broken state that the plugins providing extra canvas can't fix without force stopping outputs created by others

I think the main issue (and this also applies to #13102) is that we give the main canvas special treatment on an API level. It would be more consistent if any interaction with the main canvas requires use of the "normal" canvas API methods and it's only scaffolding around that API that treats a canvas with of the MAIN type differently.

That means that using obs_video_active to check if the "main" output is active is conceptually wrong. Instead the code needs to find (or has retained) a reference to the "main" canvas and call obs_canvas_video_active with the main canvas to figure out if that is the case.

So this PR is the necessary building block to move to that refactoring that would make our internal canvas handling more consistent as well.