174 lines
8.6 KiB
Text
174 lines
8.6 KiB
Text
|
|
What is OBS?
|
|
|
|
This project is a rewrite of what was formerly known as "Open Broadcaster
|
|
Software", software originally designed for recording and streaming live
|
|
video content, efficiently.
|
|
|
|
Bug Tracker: https://obsproject.com/mantis/
|
|
|
|
We are no longer using GitHub issues! Please use Mantis, and only report
|
|
bugs and major issues. Do NOT use mantis to ask questions or request
|
|
features, please keep that to the forums.
|
|
|
|
Forum accounts are now linked to Mantis Bug Tracker. To use the bug
|
|
tracker, simply log in to the forums and then go to the bug tracker link
|
|
above.
|
|
|
|
What's the goal of rewriting OBS?
|
|
|
|
- Make it multiplatform. Use multiplatform libraries/functions/classes where
|
|
possible to allow this. Multi-platform support was one of the primary
|
|
reasons for the rewrite. This also means using a UI toolkit will be
|
|
necessary for user interface. It also means allowing the use of OpenGL as
|
|
well as Direct3D.
|
|
|
|
- Separate the application from the core, allowing custom application of
|
|
the core if desired, and easier extending of the user interface.
|
|
|
|
- Simplify complex systems to not only make it easier to use, but easier to
|
|
maintain.
|
|
|
|
- Write a better core API, and design the entire system to be modular.
|
|
|
|
- Now that we have much more experience, improve the overall design of all
|
|
the subsystems/API, and minimize/eliminate design flaws. Make it so we can
|
|
do all the things we've had trouble with before, such as custom outputs,
|
|
multiple outputs at once, better handling of inputs, custom services.
|
|
|
|
- Make a better/cleaner code base, use better coding standards, use standard
|
|
libraries where possible (not just STL and C standard library, but also
|
|
things like ffmpeg as well), and improve maintainability of the project as a
|
|
whole.
|
|
|
|
- Implement a new API-independent shader/effect system allowing better and
|
|
easier shaders usage and customization without having to duplicate shader
|
|
code.
|
|
|
|
- Better device support. Again, I didn't know what I was getting into when
|
|
I originally started writing code for devices. It evolved into a totally
|
|
convoluted mess. I would have improved the existing device plugin code, but
|
|
it was just all so fundamentally bad and flawed that it would have been
|
|
detrimental to progression to continue working on it rather than rewrite it.
|
|
|
|
|
|
What was wrong with the original OBS?
|
|
|
|
The original OBS was rewritten not because it was bad, at least in terms of
|
|
optimization. Optimization and graphics are things I love. However, there
|
|
were some serious problems with the code and design that were deep and
|
|
fundamental, which prevented myself and other developers from being able to
|
|
improve/extend the application or add new features very easily.
|
|
|
|
First, the design flaws:
|
|
|
|
- The original OBS was completely and hopelessly hard-coded for windows,
|
|
and only windows. It was just totally impossible to use it on other
|
|
systems.
|
|
|
|
- All the sub-systems were written before I really knew what I was getting
|
|
into. When I started the project, I didn't really fully comprehend the
|
|
scope of what I would need or how to properly design the project. My
|
|
design and plans for the application were just to write something that
|
|
would "stream games and a webcam, with things like overlays and such."
|
|
This turned out fine for most casual gamers and streamers (and very
|
|
successful), but left anyone wanting to do anything more advanced left
|
|
massively wanting.
|
|
|
|
- Subsystems and core functionalities intermingled in such a way that it
|
|
was a nightmare to get proper custom functionality out of it. Things
|
|
like QSV had to be meshed in with the main encoding loop, and it just
|
|
made things a nightmare to deal with. Custom outputs were nigh
|
|
impossible.
|
|
|
|
- The API was poorly designed because most of it came after I originally
|
|
wrote the application, it was more of an afterthought, and plugin API
|
|
would routinely break for plugin developers due to changing C++
|
|
interfaces (one of the reasons the core is now C).
|
|
|
|
- API was intermeshed with the main executable. The OBSApi DLL was
|
|
nothing more than basically this mutant growth upon OBS.exe that allowed
|
|
plugin developers to barely write plugins, but all the important API
|
|
code was actually stored in the executable. Navigation was a total mess.
|
|
|
|
- The graphics subsystem, while not bad, was incomplete, and though far
|
|
easier to use than bare D3D, wasn't ideal, and was hard-coded for D3D
|
|
specifically.
|
|
|
|
- The devices and audio code was poor, I had no idea what I was getting into
|
|
when I started writing them in. I did not realize beforehand all the
|
|
device-specific quirks that each device/system could have. Some devices
|
|
had bad timing and quirks that I never anticipated while writing them.
|
|
I struggled with devices, and my original design for the audio subsystem
|
|
for example morphed over and over into an abomination that, though works,
|
|
is basically this giant duct-taped zombie monster.
|
|
|
|
- Shaders were difficult to customize because they had to be duplicated if
|
|
you wanted slightly different functionality that required more than just
|
|
changing shader constants.
|
|
|
|
- Orientation of sources was fixed, and required special code for each
|
|
source to do any custom modification of rotation/position/scale/etc.
|
|
This is one of those fundamental flaws that I look back on and regret, as
|
|
it was a stupid idea from the beginning. I originally thought I could
|
|
get more accurate source position/sizes, but it just turned out to be
|
|
totally bad. Should have been matrices from the beginning just like with
|
|
a regular 3D engine.
|
|
|
|
Second, the coding flaws:
|
|
|
|
- The coding style was inconsistent.
|
|
|
|
- C++98, C-Style C++, there was no exception usage, no STL. C++ used
|
|
poorly.
|
|
|
|
- Not Invented Here Syndrome everywhere. Custom string functions/classes,
|
|
custom templates, custom everything everywhere. To be fair, it was all
|
|
hand-me-down code from the early 2000s that I had become used to, but
|
|
that was no excuse -- C-standard libraries and the STL should have been
|
|
used from the beginning over anything else. That doesn't mean to say
|
|
that using custom stuff is always bad, but doing it to the extent I did
|
|
definitely was. Made it horrible to maintain as well, required extra
|
|
knowledge for plugin developers and anyone messing with the code.
|
|
|
|
- Giant monolithic classes everywhere, the main OBS class was paricularly
|
|
bad in this regard. This meant navigation was a nightmare, and no one
|
|
really knew where to go or where to add/change things.
|
|
|
|
- Giant monolithic functions everywhere. This was particularly bad
|
|
because it meant that functions became harder to debug and harder to
|
|
keep track of what was going on in any particular function at any given
|
|
time. These large functions, though not inefficient, were delicate and
|
|
easily breakable. (See OBS::MainCaptureLoop for a nightmarish example,
|
|
or the listbox subclass window procedure in WindowStuff.cpp)
|
|
|
|
- Very large file sizes with everything clumped up into single files (for
|
|
another particularly nightmarish example, see WindowStuff.cpp)
|
|
|
|
- Bad formatting. Code could go beyond 200 columns in some cases, making
|
|
it very unpleasant to read with many editors. Spaces instead of tabs,
|
|
K&R mixed with allman (which was admittedly my fault).
|
|
|
|
|
|
New (actual) coding guidelines
|
|
|
|
- For the C code (especially in the core), guidelines are pretty strict K&R,
|
|
kernel style. See the linux kernel "CodingStyle" document for more
|
|
information. That particular coding style guideline is for more than just
|
|
style, it actually helps produce a better overall code base.
|
|
|
|
- For C++ code, I still use CamelCase instead of all_lowercase just because
|
|
I prefer it that way, it feels right with C++ for some reason. It also
|
|
helps make it distinguishable from C code.
|
|
|
|
- I've started using 8-column tabs for almost everything -- I really
|
|
personally like it over 4-column tabs. I feel that 8-column tabs are very
|
|
helpful in preventing large amounts of indentation. A self-imposed
|
|
limitation, if you will. I also use actual tabs now, instead of spaces.
|
|
Also, I feel that the K&R style looks much better/cleaner when viewed with
|
|
8-column tabs.
|
|
|
|
- Preferred maximum columns: 80. I've also been doing this because in
|
|
combination with 8-column tabs, it further prevents large/bad functions
|
|
with high indentation. Another self-imposed limitation. Also, it makes
|
|
for much cleaner viewing in certain editors that wrap (like vim).
|