OBS - Quality and Evaluation

OBS Studio was started in 2013 by Hugh “Jim” Bailey and quickly grew with the help of many online collaborators working to improve the software. In the present day, the software is community-driven with over 400 contributors. Because there is no real company, the autonomy must be very solid for the software development to run well

Software quality process

A method to ensure the development of OBS Studio is the use of software quality processes and how they are applied. This section will cover this concept.

Forking

For developers to contribute to the software, they need to fork the Github repository. Forking is creating a copy of a repository where you can freely experiment with changes without actually affecting the original project ¹. To add to the original project, the developer then has to create a branch from their fork and submit a pull request from that branch into the master branch of the original Github project. Such a pull request needs to be reviewed by other developers that in turn decide whether they accept, reject, or request changes for the pull request.

Pull request

In OBS Studio’s case, you also need to provide detailed information about the pull request together with a checklist that is checked off. The detailed information entails a description of the pull request, motivation, and context as to why the changes were made, the way the changes have been tested, and the types of changes that are made (e.g. Bug fix, documentation, etc.). The checklist consists of the following tasks:

• My code has been run through the clang-format
• I have read the contributing document
• My code is not in 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.

The clang-format is about the continuous integration that is applied, which will be addressed in the next section. The contributing document shows a list of coding conventions OBS Studio developers must abide by.

Coding

For coding these consist of using the kernel normal form which is a specific coding style, avoiding trailing spaces, tabs needing to be used for indentation, and a line of code not being longer than 80 columns.

Committing

For committing these changes are as follows; make use of the 50/72 standard for commits, which means 50 maximum of 50 characters for a commit message, and a full description afterward, wrapped to 72 columns. Titles should be in the present tense, prefix each commits title with the module name it addresses followed by a colon and a space ².

Continuous integration

Together with the aforementioned conditions that need to hold to contribute, there is also the continuous integration that is applied when making an addition. This section will cover the key elements of OBS Studio’s continuous integration processes.

The development team has decided that for each pull request that is made, there are 12 checks divided over 4 tools that are used for the CI. These parts are Flatpak, CI Multiplatform Build, Azure pipeline, and Clang-format.

Flatpak

Flatpak is a utility for software deployment and package management for Linux. It is advertised as offering a sandbox environment in which users can run application software in isolation from the rest of the system. This way OBS Studio can do some quick end-to-end testing when deploying their software on Linux³.

CI Multiplatform Build

They build the latest version on the possible platform OBS Studio is capable of running on. That is, they build the latest version on macOS 64-bit, Linux/Ubuntu 64-bit, Windows 32-bit, and Windows 64-bit. They do this by installing all parts needed to run the software on the specific platform which is specified in main.yml⁴.

Azure pipeline

Azure Pipelines automatically builds and tests code projects to make them available to others. Azure Pipelines combines continuous integration (CI) and continuous delivery (CD) to constantly and consistently test and build the code⁵.

Clang-format

Clang is a compiler front end for C, C++, and several other programming languages. It is mainly used to compile the code and run formatcode.sh using clang-format.yml which is a script that checks the code quality. That is, it looks at whether the code is in line with the coding conventions⁶.

Next to the checks there also other actions performed in the workflow. These are CI AppImage Build and Generate Documentation.

CI AppImage Build

AppImage allows users to download an application and run it on a Linux desktop system just like in Windows or Mac applications. So it is a check to see whether providing the packages for OBS Studio for Linux desktop systems will result in any errors. They do so by running build-appimage.yml⁷.

Generate Documentation

As the name suggests, it generates documentation for the specified places in the project. This is done running docs.yml⁸.

Testing

Unfortunately, in the development of OBS Studio, automated testing is not one of the priorities. The compiling and building of the software product is the main way of testing. There is also a test folder with several general tests. But these are not nearly enough to test the whole system. When submitting a pull request all changes are mainly manually tested by the contributor and the reviewer(s)⁶.

Hotspot components

This section will discuss the components that are involved in many code changes from the past and the potential future hotspot components.

We visualize the quality of OBS by the tool of CodeScene⁹. From the past code changes, the top three hotspot components are: plugins, UI, and libobs. plugins is the one that contains all the official plugins of OBS studio, thus it’s reasonable that plugins is one of the hotspots. The interface of OBS is supported by Qt, hence, the commits of UI contains the cleanups for new versions of the Qt framework. The components of libobs are the library of OBS, thus the commits contain a large number of code cleanups and minor fixes.

Among all the files of OBS, the most frequently changed one is the window-basic-main.cpp from UI component, with a change frequency of 106 commits. Further analysis of the code quality will be discussed in the next section.

As for hotspots in the future, there’re no new big features planned for the next version, the future work will mainly be improving the system, thus hotspots will focus on the plugins components to add more features and fixing issues of other components.

Code quality

This section focus on the code quality of hotspot components discussed in the previous section.

Among all the hotspot components, the window-basic-main.cpp file of UI component is the one with the most defect commits, which has 47 commits that are defected and takes 44% of the total commits in this file.

According to the analysis of CodeScene⁹, the least healthy codes of all the files are all in the UI component, with the problems of a bumpy road and deeply nested complexity, which means this code has multiple nested conditional logic inside the same function. However, in the UI component, it’s essential to check the conditions of every setting and transmit these to back-end functions, hence, some of the functions in UI needs to check these conditions by if-statement in sequence. Therefore, the poor score of the UI component does not represent serious problems of source code.

The quality culture

The quality culture of OBS Studio is maintained by the entire community. Some useful guide documents² are provided on GitHub for contributors to follow. These documents describe some principles of coding and commit format.

In the issues and pull requests of OBS studio, there is a tag “code cleanup” which is specified for those contributions on structure refactoring and code cleaning. The fact that 160 “code cleanup” issues and pull requests accounted for a large proportion of the total reflects the community’s emphasis on code maintainability and quality. And we will take one of the pull requests as examples for specific analysis.

As described in this pull request¹⁰, the hotkey interface needs to be redesigned as a plugin rather than embedded in the core module and RFC is used to integrate all control plugin modules. The first reason for this refactoring is that the hotkey code is mixed with others in several files which are against maintainability. The other reason is that using RFC allows hotkeys to control and communicate with other input and output plugin modules¹¹.

This code refactoring is consistent with the design concept of the entire project, that is, modular plug-initiation. Through this plug-in idea, the entire project becomes very extensible and maintainable.

Besides, some comments under pull requests posted by developers also reflect their awareness of quality culture. One of the examples can be:

Technical debt

The current system has little technical debt, which is the consequence of a complete rework of the entire system and the emphasis on maintainability afterward. Like we discussed earlier there is a lot of focus on the code quality as seen from all the code cleanup PRs. As well as the maintenance of it by ensuring strict rules for all changes to the system. And even though there are no current plans for major new features this should not give too much of a hassle similar to how smaller features are also implemented fairly easily.

This was completely different back in 2016 when the developers wanted to add multi-platform support and realized that the system was completely hardcoded for windows and there was no way it would work on other systems¹². Furthermore, the developers also saw major technical and coding flaws that hindered the developers in maintaining the system and adding new features. They are all addressed in ¹² but we will take a look at the main ones.

The main design flaws were caused by either not planning well enough or hardcoding particular features/components. This was generally because the developer did not anticipate his project becoming so big and he just wanted to create a simple streaming software. Therefore he only added certain features later on such as the API, but these were generally hard to implement and were hacked into the project. With the rework, the core developer had way more experience with all the sub-systems and there was now also a community to help out. Thus he set out some of the main goals for the rework:

• Making it multi-platform since that was the feature they wanted to add before realizing how bad their system was designed.
• Separating the components more and simplifying the particular complex ones. This would make them easier to use and more maintainable.
• Creating a new API and making it modular.
• Improving the overall design, minimizing the design flaws, and ensuring that certain features, which could not be added before, can now easily be added.

Furthermore were there also some major coding flaws, which the rework intended to resolve. The main problems were inconsistent style, too many custom classes that re-invented the wheel, and classes and methods that were too large and did too many things at once. That is why they introduced such strict guidelines which they still use currently and are already mentioned in this essay.

So it is clear to see that there was a lot of technical debt in the system and they decided that rewriting the entire system with clear guidelines and a strict code style in mind would repay the debt and give them a clean slate. So that is indeed what they did and the guidelines were already mentioned in the section about PR quality. And this has given the current system with very little debt remaining because you can never remove all of it for everyone at least.

Reference