Plugin development: canvas API over obs-websocket, vendor requests, and ISO recording plans

[mauro.ahumada]

Hi all,
I'm working on a third-party plugin and I'd rather ask before building than duplicate something the project already has in flight. Five questions, all about extension points and direction — I've tried to check the public sources first and I'll say what I found so you don't have to repeat it.
1 · Canvas API over obs-websocket. OBS 31.1 added support for additional canvases in core, and obs-websocket exposes GetCanvasList plus canvas events, but as far as I can tell there is no request to create, modify or record to a canvas — the changelog describes it as partial support. Is write access to canvases planned over the websocket, or is in-process the intended path for anything that creates a canvas?
2 · Vendor requests as an extension point. Is CallVendorRequest considered a supported and reasonably stable way for an external application to drive a third-party plugin, or is it intended only for a plugin talking to its own companion app? Concretely: is it acceptable practice to build on another plugin's vendor requests, assuming its author agrees?
3 · Per-source / ISO recording in core. The feature request for multiple video outputs has been marked Planned since April 2018 and has around 368 votes. The last statements I can find are Lain's in 2018 and Joel Bethke's in 2019, both saying it's wanted but not soon. Is there any current intent to land it? I don't want to invest in something that's about to arrive in core.
4 · The scene timeline of a recording. obs-websocket already emits scene change events while recording, and Hybrid MP4 supports chapters. Is there any core intent to persist the scene timeline alongside the recording — which scene was active when, and for how long — or is that squarely third-party territory? To my knowledge no plugin writes it today, which is why I ask.
5 · Which base to build against. For a new plugin I assume the answer is upstream releases and the documented plugin template. Is there any guidance for developers whose existing code depends on obs-studio-node rather than on upstream libobs, when they move to writing a plugin proper?

Happy to be pointed at existing threads or docs if any of this is already answered — and happy to write up whatever I learn if it helps the next person.

Thanks for OBS.

 

[mauro.ahumada]

Two follow-ups I should have asked in the same post, both about listing and distribution rather than code. Sorry for the split.

6 · Listing a plugin that pairs with a paid app. I've read the resource and IP policy — source available, and avoid the acronym. Does a plugin whose full usefulness depends on a separate paid application meet the listing criteria? There look to be existing resources in that shape, so I'd rather have it confirmed by you than inferred by me. The plugin itself would be GPL with its source published, and useful on its own for what it does; it's the other half that's commercial.

7 · Naming. I understand the policy asks contributors to avoid the OBS acronym in their own product names. Could you confirm what's acceptable regarding the OBS name and logo in a plugin's name, its description and its resource page — for instance whether "for OBS" or "OBS plugin" is fine in a description even if it can't be in a title?

8 · Installing the plugin from our own installer. Would the project object to a third-party application's installer offering to install its plugin into an existing OBS installation, with the user's explicit consent? If that's unwelcome I'd rather know now and distribute only through the directory. If there's an expected way to do it — a path convention, checking for a running instance, anything — I'd follow it.

Thanks again.