OpenVINO AI plugins for OBS Studio

[vandah]

This PR adds OpenVINO AI plugins as a component to the core24 OBS Studio snap. It extends #220.

Since OBS Studio currently only supports one non-standard path for plugins, the plugins path is set to $SNAP_DATA/obs-plugins/ and plugins data path to $SNAP_DATA/obs-plugins-data/. The component makes symlinks into theses folders on every install or refresh to make sure the symlinks are up to date (the path to component changes when the component is refreshed). This means other plugins can be included in the same way as a separate component.

[frenchwr]

@vandah LGTM! Great work. I think you can convert to a non-draft now and we can invite others to review.

[soumyaDghosh]

I looked into this matter during my earlier suggestion about OBS packaging, and I believe that content snaps are a better solution for plugins than components, unless there is a strong requirement to do otherwise (which I’m happy to discuss).

Here are the key reasons for my recommendation:

1. Portability and Decentralization: Content snaps don’t need to be built within the consuming snap. With proper documentation and a consistent API/ABI-compliant environment, we can ensure reproducible builds. This enables third parties to independently build plugins, which the OBS snap can then consume. Moreover, if a plugin is meant to work with other snaps as well, they too can consume the same content snap.
2. Customization: As the packaging team, we won’t be able to ship every plugin users might need—especially considering the large ecosystem of OBS plugins, both well-known and obscure. Shipping them all ourselves isn’t feasible, partly due to security concerns. If we opt for components, the burden of inclusion and maintenance lies solely with us, increasing our responsibility and limiting user flexibility.
3. Maintainability: Not all plugins are built the same way. For example, Intel-specific plugins like OpenVINO are best maintained by Intel or contributors familiar with that ecosystem. Similarly, ffmpeg-related plugins would benefit from specialized maintainers. This modularity improves long-term maintenance and plugin quality.

My proposal is similar to how icon themes are currently handled in snaps. Any number of content snaps can be mounted into a consumer snap via specific mount points. The OBS snap can then consume multiple plugin snaps using simple interface connections:

In the OBS snap:

plugs:
  obs-plugins:
    interface: content
    target: $SNAP/usr/share/obs-plugins

In a plugin snap (e.g., OpenVINO plugins):

slots:
  obs-plugins:
    interface: content
    read:
      - /

Multiple provider content snaps can expose the same interface. With store-approved auto-connections for trusted plugins, users would only need to install the plugin snap for it to be available in OBS—no additional configuration required.

[soumyaDghosh]

Could you kindly remove the *-dev packages from the stage-packages list? These development packages are not needed at runtime and should not be staged in the final snap.

[soumyaDghosh]

Would it be possible to add a cleanup part after all other parts to ensure that we're not shipping any redundant libraries or unnecessary files in the final snap? This will help reduce the snap size and avoid bundling unused content.

[vandah]

@soumyaDghosh

I looked into this matter during my earlier suggestion about OBS packaging, and I believe that content snaps are a better solution for plugins than components, unless there is a strong requirement to do otherwise (which I’m happy to discuss).

First of all, including this component doesn't mean other plugins can't be included as content producer snaps. In the past, content snaps have indeed been the only option to optionally include plugins. Components are optional parts of a snap and as such are perfectly suited for plugins. Building and uploading plugins together with the snap helps ensure binary compatibility (OBS plugins for example have a build and runtime dependency on libobs, so building in a component means we're using the same libobs version for OBS Studio and plugins).

Components are expected to become a more standard design pattern, especially around enabling AI features within snaps where models are often only supported on certain hardware. Since many in the community refer to Snapcrafters for their work, it's important we begin leveraging these features and understanding their use, limitations, etc. so we can document and recommend best practices. So far, components are not used in any Snapcrafterts snaps, but @frenchwr has extended the CI to support components to enable their use and I think these plugins could be a good opportunity to explore it. If there are significant problems or the plugins result in a significant maintenance impact, they can be relatively easily moved to being a content snap. However, I suspect that the maintenance would be actually larger for a content snap to ensure version compatibility...

Maintainability: Not all plugins are built the same way. For example, Intel-specific plugins like OpenVINO are best maintained by Intel or contributors familiar with that ecosystem. Similarly, ffmpeg-related plugins would benefit from specialized maintainers. This modularity improves long-term maintenance and plugin quality.

Canonical has a close partnership with Intel and even a dedicated squad of engineers to help package and integrate their software within Ubuntu. That squad can assume responsibility for the OpenVINO component (as we do for other software components within Ubuntu).

Moreover, if a plugin is meant to work with other snaps as well, they too can consume the same content snap.

Plugins are usually working with only one application and I don't think there are OBS plugins that would work with other snaps too, but if that's the case then those plugins could definitely be added as content snaps.

[jnsgruk]

+1 - I think this is a textbook use for components, and doesn't preclude the use of content snaps for other things.

[soumyaDghosh]

Hi @vandah,

Building and uploading plugins together with the snap helps ensure binary compatibility (OBS plugins for example have a build and runtime dependency on libobs, so building in a component means we're using the same libobs version for OBS Studio and plugins).

While binary compatibility is a valid concern, this isn’t a blocker in practice. Plugins can be built in a compatible and reproducible way by leveraging the OBS snap as a build-snaps dependency. For example:

  some-part:
    plugin: nil
    build-snaps:
      - obs-studio
    build-environment:
      - LD_LIBRARY_PATH: /snap/obs-studio/current/<path-to-libobs>:$LD_LIBRARY_PATH

This ensures that the plugin is compiled against the same version of libobs used by the OBS snap, maintaining ABI compatibility without requiring plugin components to be built directly within the OBS snap itself.

Components are expected to become a more standard design pattern, especially around enabling AI features within snaps where models are often only supported on certain hardware. Since many in the community refer to Snapcrafters for their work, it's important we begin leveraging these features and understanding their use, limitations, etc. so we can document and recommend best practices. So far, components are not used in any Snapcrafters snaps, but @frenchwr has snapcrafters/ci#51 to enable their use and I think these plugins could be a good opportunity to explore it. If there are significant problems or the plugins result in a significant maintenance impact, they can be relatively easily moved to being a content snap. However, I suspect that the maintenance would be actually larger for a content snap to ensure version compatibility...

According to the definition:

Snap components are parts of a snap that can be built and uploaded in conjunction with a host snap and later optionally installed beside it.

In this case, however, the plugins (especially third-party ones like OpenVINO) are not truly a part of the OBS snap. Users don’t expect additional plugins to be bundled by default when they install OBS. This aligns with feedback from other upstreams, such as GIMP.

Previously, the content interface was the recommended way to ship optional files (e.g., translations, man pages). Maintaining separate content snaps for such things made less sense for a single publisher, but components simplify that use case considerably.

So, while I understand @jnsgruk’s comment:

+1 - I think this is a textbook use for components, and doesn't preclude the use of content snaps for other things.

I would respectfully disagree that this is a textbook use of components in the context of OBS. A more appropriate use might be for packaging optional translations or locale data under the same publisher, not large third-party plugin ecosystems that are independently maintained.

Canonical has a close partnership with Intel and even a dedicated squad of engineers to help package and integrate their software within Ubuntu. That squad can assume responsibility for the OpenVINO component (as we do for other software components within Ubuntu).

That’s exactly what I’m advocating. Intel’s work on OpenVINO plugins should ideally reside in their own repositories and be built as standalone snaps. This avoids duplicating maintenance efforts across multiple repositories and keeps responsibilities well-scoped.

Plugins are usually working with only one application and I don't think there are OBS plugins that would work with other snaps too, but if that's the case then those plugins could definitely be added as content snaps.

Absolutely, I only meant that if a plugin were useful to more than one snap, content snaps would naturally facilitate that reuse. Even when that’s not the case, content snaps offer better separation of responsibility, modularity, and maintainability in the long run.

[merlijn-sebrechts]

I think this is a difficult one. While components are great for first-party variation between installs, (think different drivers for different hardware), I'm questioning whether they're the right approach for third-party variation.

Yes, in this specific case, we're currently maintainers of both, but I hope at some point we can transition this snap to OBS upstream without having to do the untangling work were doing now for gimp.

I'm leaning more towards shipping these plugins as content snaps instead of components, unless these plugins are actually part of the upstream obs studio project.

Inside of that content snap, however, I would expect to use plugins for the backend drivers or hardware-specific models. Is there anything that makes using content snaps impossible?

[merlijn-sebrechts]

I appreciate Canonical might be the correct publisher of the content snap given their relationship with Intel, but that doesn't mean Canonical might be the correct publisher of the OBS studio snap. From an ecosystem perspective, components don't seem to be the right fit. This is very different from the Ubuntu archive where we expect the entire archive is always maintained by Canonical, all the time.

[frenchwr]

I would respectfully disagree that this is a textbook use of components in the context of OBS. A more appropriate use might be for packaging optional translations or locale data under the same publisher, not large third-party plugin ecosystems that are independently maintained.

IMO, excluding third-party plugins is unnecessarily restrictive. Snap components are meant for optional features but they can include whatever the snap maintainers are willing and able to support, first-party or otherwise. Yes, there is added effort for reviewing and validating the component, but the same is also true for a content snap.

Is there anything that makes using content snaps impossible?

Content snaps would work fine, but they come with a lot of overhead for snap package developers/maintainers [1], especially if the goal is for upstream/partners to own the snap. Snap components were created (based on my understanding) to overcome some of these challenges, and we should be lowering the bar for snap developers, not raising the bar. I can appreciate that content snaps provide cleaner separation of ownership, but I feel somewhat strongly that a content snap would require more maintenance.

[1] Added maintenance burden for content snaps:

• Request and publish a new snap in the store
• Perform some CICD gymnastics to trigger a build for the plugins when the consumer snap (obs-studio) has a new candidate release, and coordinating the release schedule to ensure compatibility
• Define the plug for obs-studio in its snapcraft.yaml and perhaps include some command-chain parts to set environment variables and the like
• Request an auto-connection in the store for the new plug (and potentially other forum requests for the content producer snap itself)
• In the case of OpenVINO, it only supports Intel hardware, so there are additional checks and validation required to ensure you are only shipping the content snaps to Intel hardware (and not AMD CPUs). This means you cannot just blindly rely on default-providerand most likely need to ask a user to install the content snap manually, much like you would need to do for snap components.

[jnsgruk]

I do think using components here sort of enforces closer collaboration with the publisher which is likely to result in a more seamless experience - and without relying on lots o f external interactions for auto connections etc.

We don't yet have snaps with components in snapcrafters - perhaps this could be an interesting place to trial this model?

[vandah]

While binary compatibility is a valid concern, this isn’t a blocker in practice. Plugins can be built in a compatible and reproducible way by leveraging the OBS snap as a build-snaps dependency.

Yes, but this means exactly that the OBS snap first has to be published and only after that can the plugins be rebuilt. This introduces a gap in which the plugins are only available as built against an older version of OBS and not for the newer version.

In this case, however, the plugins (especially third-party ones like OpenVINO) are not truly a part of the OBS snap. Users don’t expect additional plugins to be bundled by default when they install OBS.

I'm not sure I understand what you mean here. When a user installs the OBS snap it comes without any components so I think this expectation is fulfilled. It is only at build and upload time that the snap has to be handled together with the components, but this is a matter for maintainers, not users.

[soumyaDghosh]

IMO, excluding third-party plugins is unnecessarily restrictive. Snap components are meant for optional features but they can include whatever the snap maintainers are willing and able to support, first-party or otherwise. Yes, there is added effort for reviewing and validating the component, but the same is also true for a content snap.

@frenchwr I’d like to clarify that the approach I’m suggesting does not restrict third-party plugins. On the contrary, the current implementation—by tightly coupling plugins as components—effectively restricts broader third-party contributions. The additional overhead is not on plugin authors, but rather falls on us as Snapcrafters and the upstream maintainers. I believe this isn't a responsibility we should be taking on for external third-party components.

Content snaps would work fine, but they come with a lot of overhead for snap package developers/maintainers [1], especially if the goal is for upstream/partners to own the snap.

In fact, I would argue that components introduce more overhead for maintainers (us) and for upstream developers. Maintaining third-party plugins shouldn't be our responsibility—it should rest with the plugin developers or respective stakeholders (e.g., Intel for OpenVINO).

Snap components were created (based on my understanding) to overcome some of these challenges, and we should be lowering the bar for snap developers, not raising the bar. I can appreciate that content snaps provide cleaner separation of ownership, but I feel somewhat strongly that a content snap would require more maintenance.

According to the documentation:

Components are useful for distributing optional resources for a snap, such as debug symbols alongside snap binaries, and kernel modules alongside a kernel snap.

Components are ideal for optional resources maintained by the same publisher. In the case of OBS or similar desktop applications, debug symbols or translations are good use cases. However, packaging third-party plugins as components—especially when they’re not maintained by us—goes against this design principle.

In other packaging models, third-party plugins are maintained separately and not bundled as first-party packages. The same should apply here.

[1] Added maintenance burden for content snaps:

* Request and publish a new snap in the store

* Perform some CICD gymnastics to trigger a build for the plugins when the consumer snap (`obs-studio`) has a new candidate release, and coordinating the release schedule to ensure compatibility

* Define the plug for `obs-studio` in its `snapcraft.yaml` and perhaps include some `command-chain` parts to set environment variables and the like

* Request an auto-connection in the store for the new plug (and potentially other forum requests for the content producer snap itself)

* In the case of OpenVINO, it only supports Intel hardware, so there are additional checks and validation required to ensure you are only shipping the content snaps to Intel hardware (and not AMD CPUs). This means you cannot just blindly rely on `default-provider`and most likely need to ask a user to install the content snap manually, much like you would need to do for snap components.

Let me respond to each of these:

• Publishing a new snap is expected because these plugins are, by nature, separate software components—not part of OBS itself. This separation of responsibility is aligned with best practices.

• Triggering plugin builds can be automated via CI/CD. Maintaining API compatibility checks is the responsibility of the plugin authors—not us. OBS and the plugins generally maintain ABI compatibility across versions.

• Plug definition and environment setup are relatively minor steps and quite manageable in practice and are a one time thing. No command-chain is typically required.

• Auto-connection requests are indeed necessary but should be handled by the content snap publishers and is also a one time thing.

• Hardware-specific constraints should be managed by the plugin publishers. In fact, in a content snap model, there is no need to define a default-provider because obs-studio will consume multiple plugin snaps via a single content plug.

I do think using components here sort of enforces closer collaboration with the publisher which is likely to result in a more seamless experience - and without relying on lots o f external interactions for auto connections etc.

@jnsgruk Closer collaboration is valuable, but I don’t think that justifies taking on third-party maintenance burden. Snapcrafters shouldn't be gatekeepers for hundreds of OBS plugins. According to the OBS plugin directory, there are over 250 third-party plugins—many of which are popular, officially recommended, or community-endorsed. Supporting all of them within a single snap or component system would be unmanageable.

We don't yet have snaps with components in snapcrafters - perhaps this could be an interesting place to trial this model?

I don’t believe components should be used here simply for the sake of experimentation. If needed, we can still leverage components in OBS—for example, by shipping debug symbols, which are extremely useful for upstream maintainers, as illustrated in this Telegram bug.

Yes, but this means exactly that the OBS snap first has to be published and only after that can the plugins be rebuilt. This introduces a gap in which the plugins are only available as built against an older version of OBS and not for the newer version.

That’s correct, but it refers to the candidate channel. Users should not expect production-ready compatibility from candidate releases. Additionally, as noted earlier, the responsibility for ABI compatibility and build timing lies with the plugin maintainers—not us.

I'm not sure I understand what you mean here. When a user installs the OBS snap it comes without any components so I think this expectation is fulfilled. It is only at build and upload time that the snap has to be handled together with the components, but this is a matter for maintainers, not users.

Yes, and to clarify my earlier point (which had a typo), my concern is more about auditing and maintenance. Developers and maintainers of OBS generally do not expect third-party plugins to be embedded or managed alongside the main application. In fact, as noted in a previous PR discussion, OBS upstream isn’t inclined to engage in discussions unless we’re using their official build environment (e.g., their PPA). It’s even more unlikely they’ll support an approach where third-party plugins are tightly coupled into the same build/repo.

[merlijn-sebrechts]

Snap components are meant for optional features but they can include whatever the snap maintainers are willing and able to support, first-party or otherwise.

It honestly feels like this comment from @frenchwr is arguing against including these plugins as components.

I think my main concern remains the following:

OBS studio maintainers will not want to maintain plugins as part of their package. We should not bundle things as part of this snap that they will likely want to remove. Therefor, we should use content snaps so that we can easily transfer this snap to them once they want to take ownership. Then we keep maintaining the openvino plugin snaps afterwards.

Canonical appears interested in maintaining both openvino plugin and OBS studio, so if you only look at the current situation, it might make sense to use components. However, our goal remains to eventually upstream these packages, like we're doing now with Gimp, and have done so with many other packages in the past. With that goal in mind, components are not the right approach.

This is very different from the Ubuntu archive, where the goal remains to indefinitely maintain all packages ourselves.

[frenchwr]

Hi @merlijn-sebrechts and @soumyaDghosh , I understand your position. At the risk of beating a dead horse, I'll just raise a few more points and then concede. 😃 I don't want to keep pushing and will respect what you decide.

It honestly feels like this comment from @frenchwr is arguing against including these plugins as components.

My point was that I am in a position to support the OpenVINO component given my role and involvement with both snapcrafters and Intel (my role at Canonical is to support Intel).

OBS studio maintainers will not want to maintain plugins as part of their package. We should not bundle things as part of this snap that they will likely want to remove. Therefor, we should use content snaps so that we can easily transfer this snap to them once they want to take ownership. Then we keep maintaining the openvino plugin snaps afterwards.

There is no guarantee that the OBS studio maintainers will agree to include even a plug for an OpenVINO content snap as it may imply some level of official support that is beyond their control. I wonder, therefore, if a future hypothetical transfer should be considered when deciding between components and a content snap.

One last point: I have more confidence in the reliability and quality of the plugins with components. A content snap will work, but there are more moving parts that could break: ensuring binary compatibility, coordinating the release/promotion schedule with obs-studio, problems with auto-connections, etc.

[soumyaDghosh]

There is no guarantee that the OBS studio maintainers will agree to include even a plug for an OpenVINO content snap as it may imply some level of official support that is beyond their control. I wonder, therefore, if a future hypothetical transfer should be considered when deciding between components and a content snap.

Just to clarify, there will not be individual content plugs for specific plugins like OpenVINO. As I explained earlier here, the OBS snap will define a single plug, which can consume content from multiple provider snaps. This avoids the perception that OBS officially supports any one plugin and keeps the architecture flexible and extensible.

One last point: I have more confidence in the reliability and quality of the plugins with components. A content snap will work, but there are more moving parts that could break: ensuring binary compatibility, coordinating the release/promotion schedule with obs-studio, problems with auto-connections, etc.

Respectfully, I believe the responsibility for ensuring binary compatibility should not fall on Snapcrafters or the OBS maintainers. Instead, it should lie with the publishers of the plugins—particularly for third-party components like OpenVINO.

That said, OBS has historically maintained ABI compatibility for libobs across releases. In addition, snapd offers mechanisms such as epochs that can be leveraged to ensure compatibility. We can also implement version checks within OBS itself if needed.

There are multiple mechanisms available to address compatibility concerns robustly—without tightly coupling plugin components inside the main snap.

If needed, I’d be happy to assist in setting up the full ecosystem around content snaps for plugins like OpenVINO, including compatibility enforcement, documentation, and auto-connection handling.

[merlijn-sebrechts]

I see Soumya sniped my comment 😅 most of it is just a repeat of his.

@frenchwr

There is no guarantee that the OBS studio maintainers will agree to include even a plug for an OpenVINO content snap as it may imply some level of official support that is beyond their control. I wonder, therefore, if a future hypothetical transfer should be considered when deciding between components and a content snap.

I thought we could make a general "plugin" plug that is greedy, and use that for the OpenVINO content snap, and any other plugin that might want to use it. That way, it's not a modification for one specific snap. Is that not the case?

One last point: I have more confidence in the reliability and quality of the plugins with components.

I agree content snaps are a bit more tricky to get right compared to components.

A content snap will work, but there are more moving parts that could break: ensuring binary compatibility

For official plugin systems this is typically less of an issue because most of them can handle ABI conflicts. Even on Windows, plugins and applications often update independently of eachother. Worst case, the app will see the plugin is incompatible and warn the user. How does OBS normally handle this?

Another approach specific to snaps is to embed the ABI in the plug or snap name. Like what's done with the gnome platform snaps or ffmpeg.

coordinating the release/promotion schedule with obs-studio,

Has this not been solved when we patched our ci/cd for ffmpeg release? It has a similarly complex dependency.

problems with auto-connections, etc.

It is indeed very unfortunate that critical snap functionality that every desktop snap depends on still breaks in fun and complicated ways.

It's a good idea to use "the wrong" feature when "the right" feature is too broken to be useful, but I think we can make it work. If I'm mistaken, please let me know.

[jnsgruk]

So I think after a brief exchange with @frenchwr yesterday, the Canonical team who put this together will work up another PR that utilises content snaps, and we can assess them both side-by-side and make a decision - this likely won't happen immediately, but stay tuned! :)

Thank you @vandah for your work on this so far! Excited for this to land in one form or another!

[vandah]

@soumyaDghosh @merlijn-sebrechts I've created a PR #228 which uses content-producer snaps. I have to say because of the directory structure expected by OBS this was a bit more effort than it would be for icon themes but finally it seems to be working.