OBS - Variability Analysis
Galster first introduced “software variability” in 2015 1 Later on, Meinicke et al. divided it into two types, functional and non-functional variations2. Functional variations can be shown as functional enhancements which are good for users, while non-functional variations are the same set of functions realized on different hardware platforms. So we will discuss the variability of OBS Studio from the above two forms.
Non-functional variations
Different platforms
As a software, the variability in platforms of OBS reflects on offering software based on different operating systems. Since the code base rework in 2016, OBS Studio supports Windows 8/8.1/10, macOS High Sierra (10.13) or later, Linux and Unix-like system FreeBSD. The OBS team provides instructions for installing OBS Studio on all of the four operating systems, users can follow the installation guide on installation instruction to install this software or build it from the source code3. Among all the operating systems, OBS requires either OpenGL or DirectX if you are on windows, and a compatible GPU4. However, the compatible system does not guarantee that it is capable of streaming or recording using OBS, CPU requirements vary considerably depending on the chosen encoder, resolution, FPS, and your scene complexity, which can be automatically set by the Auto Configuration Wizard
during the installation or found in the settings. But they can also be manually edited.
Hardware encoders are mostly used for local recordings, and for live streaming, they are the last resort if software encoding is not possible, thus OBS Studio also requires users to provide the latest drivers for their GPU. So far, all the consumer-level hardware encoders are provided by certain GPUs like NVIDIA, AMD, and Intel GPU4.
Rendering graphics
One of the core processes of OBS is video rendering since all of the videos or streaming need to be rendered before output. For graphics rendering, OBS Studio provides two computer graphic APIs: OpenGL and Direct3D, in which OpenGL is multi-platform supported, and Direct3D is Windows embedded. The default for Windows is to use Direct3D for rendering, which is more compatible with different Windows graphics cards.
To accommodate custom capture features available on specific operating systems, OBS Studio wraps both OpenGL and Direct3D into a programmable graphics subsystem5. Both of the two computer graphic APIs are capsuled in subsystems as libobs-opengl
and libobs-d3d11
, while libobs-d3d11
is mainly used in Windows systems, libobs-opengl
basically used in Linux/Unix systems.
Functional variations
Configuration
When users start up OBS Studio for the first time an Auto-Configuration Wizard will be run to test your system and to choose the best settings depending on whether you want to stream or record more. Of course, if users want to change these later on they can do so in the settings. They can even add multiple profiles which each have their own configuration of settings, so they can more easily switch between for example a configuration for streaming to one for recording. The settings menu has seven categories;
- The general settings are checkboxes for how you want OBS Studio to behave.
- The stream tab is for setting up your connection to a streaming service.
- The output tab has two different modes. A simple mode where you can select your bitrate, encoder for streaming, or your quality, format, and encoder for your recordings. In the advanced mode, you get more options to tweak especially for the audio settings.
- The audio and video settings are for their respective quality.
- The hotkeys make navigating OBS a lot easier since you can switch scenes, pause, or mute without having to first go to your OBS application.
- The advanced tab has some extra settings, such as how you want your filenames to be formatted, a stream delay, and even some network options.
So as you can see OBS Studio offers quite a selection of options which are just the more general settings. Because you also have a lot of variability in the types of sources you can use. As well as many filters for both the audio and video sources to optimize your output. Next to the default settings of OBS Studio, there are also other specific additions. That is, additions that are not made for the general product but for specific users are also possible with the use of plugins, the API reference or the use of scripting support.
Plugins
As aforementioned almost all custom functionality is added through plugin modules, which are typically dynamic libraries or scripts6. This is because the settings we looked at in the previous sections are also implemented as plugins, yet they are by default available when you install OB Studio. In the documentation, these are also linked as examples for implementation6. The kind of plugins can be divided into four different categories, which generally overlap with the standard settings tabs; sources, outputs, encoders, and services.
- Sources – Sources are used to render video and/or audio while recording or streaming. Standard sources include capturing an entire display, just one specific application or game, and even capturing only one specific audio channel such as a microphone or desktop audio. Sources can also be implemented as audio and video filters.
- Outputs – Outputs are used to output the currently rendering audio and/or video, which is generally recording or streaming. Yet this can also include the receiving of raw or encoded data.
- Encoders – Encoders are OBS-specific implementations of video/audio encoders, which are used with outputs that use encoders. x264, NVENC, Quicksync are examples of encoder implementations.6
- Services – Services are custom implementations of streaming services, which are used with outputs that stream. For example, you could have a custom implementation for streaming to Twitch, and another for YouTube to allow the ability to log in and use their APIs to do things such as get the RTMP servers or control the channel.6
So it is clear to see that most variability comes from the plugin system, that it is all very well documented, and hat it has numerous implementation examples 6. This of course greatly benefits the end-user who can configure their OBS exactly how they need it, and if a feature is not there could in theory even implement it themself.
API reference
If the basic version of OBS Studio and all its plugins are still not enough for a user, there is a possibility to create your additions with the help of a powerful API to provide the user with further customization and functionality specific to the users' needs. There is a API reference present for;
- The source: as mentioned earlier, the source is used to render video/or audio while recording or streaming. The
libobs/obs-source.h
file is the dedicated header for implementing sources7. - A scene: a source which contains and renders other sources using specific transforms and/or filtering 8.
- An output: as mentioned before, the output is used to output the currently rendering audio and/or video. The
libobs/obs-output.h
file is the dedicated header for implementing outputs9. - An encoder: as mentioned before, the encoder is an OBS-specific implementation of video/audio encoders. The
libobs/obs-encoder.h
file is the dedicated header for implementing encoders 10. - Service: as mentioned before, services are custom implementations of streaming services. The
libobs/obs-service.h
file is the dedicated header for implementing services11. - Data Settings: reference-counted objects that store values in a string-table or array. They’re similar to JSON objects, but additionally, allow additional functionality such as default or auto-selection values. Data is saved/loaded to/from JSON text and JSON text files12.
- Properties: used to enumerate available settings for a libobs object. Typically this is used to automatically generate user interface widgets, though can be used to enumerate available and/or valid values for specific settings as well13.
Scripting
There is also a possibility to create scripts that automate part of the functionality provided by OBS Studio. These scripts can be written in both Python or Lua. These scripts can interface with existing sources and make the life of a user easier. For the people that are not as proficient in writing the scripts, they can look at the scripts page to find scripts that have been created and freely distributed by the community. In the case the page does not have the envisioned script, there is always the possibility to ask the community directly for creating such a script. These scrips provide the user with potentially infinite options for their configurations.
Feature model
After identifying the features of the OBS Studio and their relationship, we produce a feature model diagram shown in Figure 1. Plugins and scripts can be seen as optional features and other features are mandatory. And the children features of the mandatory ones are in alternative relationship to each other.
Binding time
Before the rework in 2016, there was not any flexibility in the system and that is why the developers decided to rework it. During the rework, they made some major decisions but did not make anything fixed, except the UI layout. They changed the core structure so it would work across multiple platforms. The modular plugin system was also adopted during the rework. This adoption allows for more scalability and extensibility in the future. Furthermore, they improved their entire API so it would be usable and has as much if not more functionality than the main application.
There is no indication as to whether developers will make some definitive decisions in the future either. Seeing that the main focus lies on adding small features and quality of life changes. Additionally, they always have focused heavily on their modular plugin system and this has made OBS such a good application. Therefore, there is no clear reason to believe why they would change anything about that in the future.
Reference
-
Galster, M. (2015, September). Architecting for variability in quality attributes of software systems. In Proceedings of the 2015 European Conference on Software Architecture Workshops (pp. 1-4). ↩︎
-
Meinicke, J., Thüm, T., Schröter, R., Benduhn, F., Leich, T., & Saake, G. (2017). Mastering software variability with FeatureIDE. Cham: Springer International Publishing. ↩︎