Welcome to the first OBS Studio Progress Report. My name is Lain, the normally-silent author of OBS. Version 22.0 has finally come out, and I had a really great time writing it.

This is going to be a long post because I almost never normally speak, so get ready.

First, I want to say thank you

This month marks the sixth anniversary of the very first release of OBS back in August 2012. Back during those times I was able to answer every single post on the forum, interacted with almost every single person who came around the chat, and answered every email. Some time around 2014-2015, forum posts, emails, and chat became so active that it would take me 10 hours per day to answer everything. Eventually, I had to stop, delegate that task to others, and focus exclusively on working on the program.

As of today, 21.1.2, the previous release before 22.0, had nine million downloads in three months time.

This blows my mind.

The program has (along with its derivatives) arguably become the most widely used tool for live streaming and recording on Twitch, YouTube, and around the world. I can't stress enough how grateful I am for this opportunity. Before I made the program, I was in a pretty bad place. Now, I've had opportunities that I never thought I would ever have, and a unique, solid resume that will keep me fed for a long time. Hopefully, I can continue to do this as long as I can, because I am having a lot of fun doing it.

So again, to every one of you who use my program and find it useful: Thank you. You have changed my life; and I hope I have been able to change yours for the better as well. I know that many of you have become quite successful with the help of our humble tool, and I hope you continue to be successful.

Now, let's do a quick run over the biggest developments that happened since 21.1.

The browser source was majorly refactored, and is now hardware accelerated

The browser source is arguably one of the most complicated and vital plugins of the project. Packaging Chrome itself to be usable as a source that you can add to OBS is about as complicated as it sounds. Fortunately, thanks to the great developers and contributors over at the CEF project, we've been able to integrate the power of the browser in to the project for use as a compositing tool. And with version 22.0, we've finally achieved hardware accelerated off-screen browser surfaces thanks to the wonderful developers and contributors of the CEF project.

Before, the way the browser source worked was one of two ways:

• Chromium renders the browser surface with hardware rendering (GPU rendering) -> Chromium downloads the surface to RAM -> Surface is passed from Chromium to OBS with RAM -> We upload back to the GPU to be used as a source for OBS

• Chromium renders the browser surface with software rendering (CPU rendering) -> Surface is passed from Chromium to OBS with RAM -> We upload to the GPU to be used as a source for OBS

Unfortunately, for the longest time, the former case took more resources than the latter case, and would also have strange hiccups in rendering, so we were forced to use software rendering for the browser source. However, software rendering also had its own issues, such as obscure crashes and the inability to use WebGL for advanced overlays. In either case, we were forced to always upload every single frame back on to the GPU for compositing. So we've always been stuck between a rock and a hard place for the browser.

Today, there are proposed changes on CEF which would allow passing of a shared surface from the Chromium renderer directly to the program implementing CEF. What this means is the pipeline now looks like this:

• Chromium renders the browser surface with hardware rendering (GPU rendering) -> Chromium shares that surface with OBS to be used as a source without moving off of the GPU

The performance and resource benefits of this are astounding. You might initially think "but wait, isn't it using more GPU now that it has to render on the GPU?", but it turns out it's actually the opposite case: before, when we had to upload the browser surface to the GPU every browser frame, that action of uploading frames alone required more GPU usage than actually just rendering the browser surface with the GPU.

To give some perspective on how much data had to be transferred to the GPU, let's take the worst case scenario as an example: a 1920x1080 browser surface updating at 60 frames per second. A 1920x1080 RGBA frame is approximately eight megabytes, and transferring that to the GPU at 60 frames per seconds is almost 500 megabytes per second. What this means is not only do we reduce CPU and RAM usage due to the fact that we're no longer rendering the surfaces on CPU and to RAM, but we also reduce GPU usage because we're no longer transferring however many countless megabytes to VRAM!

This change to the browser source reduces its CPU usage, reduces its RAM usage, and reduces its GPU usage. This is one of the most significant optimizations the program has ever seen since game capture was created.

On top of all this, the browser source was always an incredibly complicated plugin. It had tens of thousands of lines by itself. With version 22.0, it's now completely refactored, and over 13,000 lines of code were pruned (you can see the commit here). Any experienced programmer can probably sense the joy I have when I say those words. The act of pruning massive amounts of unnecessary code is arguably more valuable to the overall health of a program than is adding new features. All the memory leaks were fixed, the design has been greatly simplified, and the code is much more readable. It was a monumental undertaking that was well overdue, and I'm proud to say that the code is now in the best place it's been in years.

It was absolutely worth it to finally tackle one of the biggest issues that we've had to face with the program.

Source Grouping

Source grouping has been a long-requested feature -- the ability to treat multiple sources as one. We originally added the ability to use scenes as sources which were an interim workaround to this problem (which you can still use). However, scenes are always the same size as the canvas, and to edit the sources, you have to switch to those scenes to edit the elements. It has its upsides and downsides, but it's always been a little bit awkward to use them that way.

With 22.0, we now have source grouping. I contemplated implementing this by just automatically combining the selection rectangles for multiple sub-items and always treating them as "one", which would have been the most simple solution. However, if I implemented groups as resizable scenes internally, we'd be able to apply filters to the group and be able to more easily reference groups in other scenes. It was a bit more complicated, but I decided to go with the latter because that gave the users the most benefit and features.

I also wanted to make sure that you could see sub-items of groups in the list box, select/modify those sub-items, and expand and collapse that list, so the widget for the list of sources had to be completely rewritten.

What's next for the program

Making the program easier, and improving user experience

If recent events have taught us anything, it's that OBS isn't particularly the friendliest towards new users. The auto-configuration tool (which users can use on the first time they start the program, or access in the tools menu) helped a lot with this; it was a really good first step. It can get streamers started with their encoding settings and getting the program outputting to stream, but what it doesn't help them with is setting up other parts of their stream, like the captures, overlays, cameras, alerts, and all the things that are increasingly important to streamers these days.

One of the primary things being focused on for the next few versions will be making things easier for new users and getting people started more easily; being able to set up not just their encoding/video settings, but also to help them get started with overlays, captures, and other things as well.

User experience is also something that goes a long way: having a well designed user interface that has a smooth, intuitive flow and design. Sadly, the program isn't the most ideal in this area either. There are features that some people don't realize exist; some features which are hidden in menus. Or sometimes, users don't know what a feature means or what it does, so they never use it. The number of times users ask us why they're dropping frames is almost silly, and it's something that should probably be explained better in the program. The status bar doesn't convey information very well, the settings window could use a lot of work, the context menus have endless numbers of options -- the list goes on and on.

These are all things that can be improved to make the experience of the program better. Reducing any sort of "clunky" feeling in the interface and making things feel better and easier to grasp is another one of the things being focused on.

Another nice thing that I'm hoping to add will be the ability to log on to Twitch/Youtube from within the program, which leads me in to my next segment:

Access to service APIs from within the program

One of the things that we should have done from the beginning is implement service APIs within the program: APIs for Twitch, YouTube, and perhaps even the APIs for streaming alert services. This would be useful not only because we would like to avoid having to make the user copy and paste their stream keys, but because it would allow the program to add a wide variety of other features, such as being able to see viewer count, channel followers, channel subscribers, alerts for whatever alert services they use, and all sorts of things that are becoming an increasingly necessary part of streaming. This would all be optional of course -- if a user doesn't want to use this functionality, they should always be allowed to use the program the way they have been and just enter in a stream key instead.

When these APIs are implemented, not only will this help make the program easier to use for first time streamers, but also provide great new features that users can take advantage of, and provide tools to companies to improve the user flow and better accommodate their users.

I had originally intended to have it be a part of the 22.0 release, but our settings window needed a ton of work to accommodate this, so I decided to just make the 22.0 release instead as-is.

On forks and plugins

There has been some interesting developments around OBS recently. One of which is a fork of our own project by a certain company; it has our core, but different frontend. I think users having options is always a good thing; even if it's putting a lot of pressure on me to perform, and even if it is very stressful for me at times. It keeps the industry healthy and benefits the users the most because everyone is striving to improve and innovate.

However, despite its name, I want to be clear that this fork is not associated with myself or the OBS team. I want to state very clearly that I have not made any contractual agreements with any of the alert service companies. The only true requirement I have ever made is that people abide by the GPL.

I have never made nor will ever make any contractual agreement which would end up denying the users their freedom with the program. For me, the program is and always will be by the users, for the users. This is my personal ideal. Although there is a lot of zealotry around the GPL license at times, I fully believe in its intended ideals of freedom.

Fundamentally, if I am lacking something that the industry needs, then I want to strive to provide it to the industry. That is something I am focusing on; to make the program not only better for the users, but better for the industry, and help provide growth to the industry. Making the program easier to use for new users, improving user experience, and providing better tools for both users and companies in the industry.

However, I want to make sure that the users are always the ones who are in control.

Contribution, organizing, and moving forward

The program is quite a large project now. It now has a few hundred thousand lines of code, and approximately 30-50 pull requests per month. Meanwhile, I'm still adding improvements, fixes, and features of my own while managing all of this. At this point, organization and delegation is becoming increasingly necessary to accommodate everyone's needs. I realize now that this isn't something that I can do by myself, so there may be a time very soon when some sort of official organization needs to be made.

Fortunately, the wonderful contributors to the project have been adding requested features, improving the project, fixing bugs, making translations, tending the website, doing support on the forums and chat, and helping in so many ways that it just blows my mind.

I cannot emphasize enough how grateful I am to everyone who has been involved with the project; everyone who has contributed, everyone who has helped provide support, everyone who has helped manage the different aspects of the project, everyone who has donated, everyone who has reported a bug or feature request, and especially all of users who have used and enjoy our humble program.

This project has the best community anyone could have asked for.

I am by no means perfect, and not every decision I have made is perfect; but I will do what I can to make the program the best it can be.

If you would like to contribute to the project, please read my guide on how to contribute to open source projects.

Thank you for reading!