These fundamental changes were necessary to achieve the goals of lower overhead, faster performance, and to better represent the way that modern GPUs actually work, particularly when the GPU is used for more than just 3D rendering. Yet other changes were also necessary due to the way Metal was specifically designed to fit into Apple's operating systems.

Due to the sheer amount of information around this topic, it made sense to split it into separate posts:

• The first post (this one) will go into specific challenges and insights from writing the Metal backend for OBS Studio.
• The second post will look at the history of 3D graphics APIs, their core differences, and how the design of the new generation creates challenges for existing renderers like the one in OBS Studio.

The Metal backend is explicitly marked as "Experimental" in the application because it has some known quirks (for which no good solutions have been found yet, more about that below) but also because it has not yet been tested by a larger user audience. The OpenGL renderer is still the default choice offered to users and will be available for the foreseeable future, but we still would like to invite users to try out the Metal backend for themselves, and report any critical bugs they might encounter.

Better yet, if you happen to have prior experience working with Metal on Apple Silicon platforms (including iPhones), we'd be happy to hear feedback about specific aspects of the current implementation or even review pull-requests with improvements to it.

Part 1.1: The Why Of Metal

In June 2014 Apple announced (and - more importantly - also released to developers) the first version of Metal for iPhones with Apple's A7 SOC, extending its support to current Macs of the time in 2015. Thus Metal was not only available on what became later known as "Apple Silicon" GPUs, but also Intel, AMD, and NVIDIA GPUs, being the first "next generation" graphics API to support all mainstream GPUs of the time.

Metal combined many benefits to Apple specifically: The API was based on concepts and ideas that not only already found their way into AMD's "Mantle" API (which was announced in September 2013) but had also been discussed for and adopted to some degree in the existing graphics APIs (OpenGL and Direct3D) at the time. But as a new API written from scratch it had the chance to omit all the legacy aspects of existing APIs and fully lean into these new concepts. It was able to provide the performance gains unlocked by this different approach and as it was originally designed for iOS and macOS, an entirely new API implemented in Objective-C and Swift (the latter of which was also introduced in 2014).

While OpenGL did (and still does) provide a well-established C-based API, it incorporates a binding model that is considered inelegant by many. Direct3D to this day uses a C++-based object-oriented API design (primarily via the COM binary interface), making it easier for developers to keep track of state and objects in their application code. Notably existing APIs in COM-based systems are not allowed to change, instead new variants have to be introduced, providing a decent amount of backwards-compatibility for applications originally written for older versions of Direct3D.

Metal takes Direct3D's object-oriented approach one step further by combining it with the more "verbal" API design common in Objective-C and Swift in an attempt to provide a more intuitive and easier API for app developers to use (and not just game developers) and to further motivate those to integrate more 3D and general GPU functionality into their apps. This lower barrier of entry was very much the point of earlier Metal versions, which combined the comparatively easier API with extensive graphics debugging capabilities built right into Xcode, providing developers with in-depth insights into every detail of their GPU processing (including built-in debugging of shader code) in the same IDE used for the rest of their application development.

Part 1.2: Differences In API Design

All modern APIs share the same concepts and approaches in their designs, which attempt to solve a major design issue of OpenGL and Direct3D:

• The old APIs took care of a lot of resource management and synchronization for the developer, "hiding" much of the actual complexity involved in preparing the GPU for workloads.
• The old APIs presented the GPU as a big state machine (particularly OpenGL) where the developer can change bits and pieces between issuing draw calls.
• Due to the possibility to change bits and pieces of a pipeline at will, the old APIs had to check if the current "state" of the API is valid before issuing any work to the GPU, adding considerable overhead to the API "driver".

• The new APIs removed most of that and now require developers to manage their resources and synchronization themselves, only providing methods to communicate their intent to the API and thus the GPU.
• The new APIs present the GPU as a highly parallelized processing unit that can be issued a list of commands that will be added to a queue and are then picked up by the GPU, "drawing" just being one of many operations.
• To avoid having to re-validate the pipeline state before each draw call, pipelines have become immutable objects, whose validity is checked once during their creation, removing the overhead from draw commands using the pipeline, leaving some overhead whenever the pipelines themselves are switched.

Of course there are many other differences (large and small) but those are the ones that had the most impact on the attempt to write a "next generation" graphics API backend for OBS Studio. The current renderer is obviously built around the way the old APIs work (particularly Direct3D) and thus makes certain assumptions about the state the APIs will be in at any given point in time. The issue is that those assumptions are not correct as soon as any of those new APIs are used and a lot of the work that the APIs used to do for OBS Studio now has to be taken care of by the application itself.

So a decision had to be made: Either the core renderer can be updated or even rewritten to take care of the responsibilities expected by the modern APIs, adapting more modern "indirect drawing" techniques in Direct3D and OpenGL to make them more compatible with that approach (making those renderers potentially more performant as well), or put this additional work entirely into the backend for one of the new APIs, leaving the core renderer as-is. At least for the Metal backend, the second path was chosen.

Part 1.3: The Expectations Of OBS Studio's Renderer

Before the new release, OBS Studio shipped with two graphics APIs: Direct3D on Windows and OpenGL on Linux and macOS. This is achieved by having a core rendering subsystem that is (for the most part) API-independent and requires an API-specific backend to be loaded at runtime. This backend then implements a generic set of render commands issued by the core renderer and translates those into the actual commands and operations required by its API. That said, the core renderer has some quirks that become apparent once one tries to add support for an API that works slightly different than it might expect:

• As OBS Studio's shader files are effectively written in an older dialect of Microsoft's High Level Shader Language (HLSL), every shader needs to be analyzed and translated into a valid variant for the modern API at runtime.
• Shaders are expected to use the same data structure as input and output type, as well as support global variables.
• The application expects all operations made by the graphics API to be strictly sequential, and to always execute operations involving the same resources strictly in order of submission to the API.
• OBS Studio's texture operations (creating textures from data loaded by the application, updating textures, reading from textures, and more) are directly modelled after Direct3D's API design. Any other API needs to work around this expectation and do housekeeping "behind the scenes" to meet it.
• OBS Studio also expects to be able to render previews (such as the program view, the main preview, the multi-view, and others) directly at its own pace (and framerate), expecting every platform to effectively behave like Windows and provide "swapchains" with the "discard model" used by DXGI, and thus is not decoupled from the render loop for the video output.

Most of these issues either fall into the realm of shaders or the API design itself, all of which had to be overcome by the Metal backend.

Part 1.3.1: Transpiling Shaders

OBS Studio makes extensive use of shader programs that run on the GPU to do efficient image processing. Both libobs (OBS Studio's main library that includes the core renderer) as well as plugins like the first-party obs-filters plugin provide their own "effect" files, which are implemented using the HLSL dialect mentioned above.

These effects files contain "techniques", each potentially made of up of a number of render passes (although all current OBS Studio effect files use a single pass) that provide a vertex and fragment shader pair. The vertex shader is the little program a GPU runs for every vertex (a "point" of a triangle) to calculate its actual position in a scene relative to a camera looking at it. The fragment shader (also called "pixel shader" in Direct3D) calculates the actual color value for each fragment (a visible pixel in the output image).

To make these files work with OpenGL and Direct3D, they need to be converted into bespoke shader source code for each "technique" first, which OBS Studio achieves through multiple steps:

• Each effect file is parsed in its entirety and converted into a data structure representing each "part" of the effect file:
  • The "uniforms", that is data (or a data structure) that is updated by application code at every rendered frame.
  • The "vertex" or "fragment" data (usually a data struct) that is kept in GPU memory.
  • Texture descriptions (textures can be 1-, 2-, or 3-dimensional) and sampler descriptions (samplers describe how a color value is read from a texture for use in a shader).
  • The shader functions, including their return type and argument types.
• Additionally each technique (and pass(es) within) are parsed into a nested data structure:
  • OBS Studio will then iterate over every technique and its passes to pick up the names of the vertex and fragment shader functions mentioned in each.
  • The uniforms, shader data, as well as the texture and sampler descriptions, are shared among each technique within the same file. The created data structures are used to re-create the (partial) HLSL source code that was parsed originally.
  • The shader functions and their content are then copied and a "main" function is generated (as the entry-point for the shader) calling the actual shader function. The generated final HLSL string is kept as the shader representation of each "technique".
• Each technique is sent in its HLSL form to each graphics API and is then transpiled into its API-specific form:
  • For Direct3D this means replacing text tokens with their more current variants.
  • For GLSL this means parsing the HLSL string back into structured data again, before iterating over this data and composing a GLSL shader string from it. As shader function code is not analyzed, it needs to be parsed word-for-word and translated into GLSL-specific variants if necessary.

UPDATE (January 2026): After this article was posted, we were informed that global variables were supported in the Metal Shading Language (MSL), starting with version 3.1.

While the workarounds documented below might still be necessary when using an older version of MSL, the UniformData in GPU buffer 30 can be assigned directly:

constant UniformData& constant uniforms [[buffer(30)]];

The view projection matrix could then be accessed in any scope via uniforms.ViewProj and would not need to be explicitly passed as a function argument through the different layers of the shader. The usual caveats of global variables apply, but in this case the global variable is strictly read-only by being a constant reference to data in the constant address space.

Adapting this process for Metal led to a few challenges, born out of the stricter shader language used by the API:

• MSL is stricter around types and semantics:
  • Direct3D uses "semantics" to mark parts of shader data structs and give them meaning, like TEXCOORD0, COLOR0, or SV_VertexID, while OpenGL uses global variables that shader code instead reads from or writes into.
  • Metal uses a similar semantics-based model as Direct3D via attributes, but their use is more strict. Some attributes are allowed for input data, but not for output data.
  • Thus the same struct definition cannot be used as input and output type definition, instead the single struct type used by HLSL needs to be split into two separate structs for MSL.
  • Every function's content then needs to be scanned for any use of the struct type and needs to be replaced with the appropriate input or output variant.
• MSL has no support for global variables:
  • This means that "uniforms" as used by Direct3D (and set up by OBS Studio's renderer) cannot be used by Metal - uniform data needs to be provided as a buffer of data in GPU memory.
  • This buffer of data can be referenced as an input parameter to a shader function, thus any use of the global variable (used by HLSL and GLSL) needs to be replaced with a use of the function argument.
  • However any other function called by the "main" shader function also accessing a global variable needs this local variable passed explicitly to it, thus - once again - every function's code needs to be parsed and analyzed.
  • Any time a function uses a global, it needs to have a new function argument added to its signature to accept the "global" data as an explicit function parameter.
  • Any time a function calls a function that uses a global, it also needs to have its signature changed to accept the data explicitly and also change the call signature to pass the data along.

And these are just two examples of major differences in the shader language that require the transpiler to almost rewrite every effect file used by libobs.

Here's a trivial example, OBS Studio's most basic vertex shader that simply multiplies each vertex position with a matrix to calculate the actual coordinates in "clip space" (coordinates that describe the position as a percentage of the width and height of the camera's view):

uniform float4x4 ViewProj;

struct VertInOut {
    float4 pos : POSITION;
    float2 uv : TEXCOORD0;
};

VertInOut VSDefault(VertInOut vert_in)
{
    VertInOut vert_out;
    vert_out.pos = mul(float4(vert_in.pos.xyz, 1.0), ViewProj);
    vert_out.uv  = vert_in.uv;
    return vert_out;
}

VertInOut main(VertInOut vert_in)
{
    return VSDefault(vert_in);
}

In this shader the view projection matrix is provided as a global variable called ViewProj and it's used by the VSDefault shader function. The Metal Shader variant needs to be a bit more explicit about the flow of data:

#include <metal_stdlib>
using namespace metal;

typedef struct {
    float4x4 ViewProj;
} UniformData;

typedef struct {
    float4 pos [[attribute(0)]];
    float2 uv [[attribute(1)]];
} VertInOut_In;

typedef struct {
    float4 pos [[position]];
    float2 uv;
} VertInOut_Out;

VertInOut_Out VSDefault(VertInOut_In vert_in, constant UniformData &uniforms) {
    VertInOut_Out vert_out;
    vert_out.pos = (float4(vert_in.pos.xyz, 1.0)) * (uniforms.ViewProj);
    vert_out.uv  = vert_in.uv;
    return vert_out;
}

[[vertex]] VertInOut_Out _main(VertInOut_In vert_in [[stage_in]], constant UniformData &uniforms [[buffer(30)]]) {
    return VSDefault(vert_in, uniforms);
}

As explained above, the single VertInOut struct had to be split into two separate variants for input and output, as the attribute(n) mapping is only valid for input data. It uses a pattern more common in modern APIs where memory is typically organized in larger heaps into which all other data (buffers, textures, etc.) is placed and referenced. In this case the stage_in decoration allows the developer to access vertex or fragment data for which a vertex descriptor had been set up and is used for convenience. Otherwise the variable would just represent a buffer of GPU memory.

To tell Metal which part of the output structure contains the calculated vertex positions, the corresponding field has to be decorated with [[position]] or return a float4 explicitly. Every vertex shader has to do one or the other, as it would otherwise fail shader compilation.

The uniform global used by HLSL is transformed into a buffer variable: The uniform data is uploaded into the buffer in slot 30 and referenced by the [[buffer(30)]] decorator and uses the ampersand (&) to make it a C++ reference using the constant address space attribute, which marks this reference to be read-only. The uniforms reference is also passed into the VSDefault function, as the transpiler detected that the function accesses ViewProj within its function body, and thus adds it as an argument to the function signature and converts the reference of ViewProj into the correct form uniforms.ViewProj.

Similar work has to be done for all those cases where GLSL or HLSL will opportunistically accept data with the "wrong" types and alias or convert them into the correct one. Metal does not allow this, the developer has to put any such conversion into code explicitly and also requires any function call to match the function signature. Here is one such example:

float PS_Y(FragPos frag_in)
{
    float3 rgb = image.Load(int3(frag_in.pos.xy, 0)).rgb;
    float y = dot(color_vec0.xyz, rgb) + color_vec0.w;
    return y;
}

In this example the HLSL shader uses the Load function to load color values from a texture and passes in a vector of 3 signed integer values. A valid Metal Shader variant would look like this:

float PS_Y(FragPos frag_in, constant UniformData &uniforms, texture2d<float> image) {
    float3 rgb = image.read(uint2(int2(frag_in.pos.xy)), uint( int( 0))).rgb;
    float y = dot(uniforms.color_vec0.xyz, rgb) + uniforms.color_vec0.w;
    return y;
}

The signature of the corresponding read function in MSL requires a vector of 2 unsigned integer values and a single unsigned integer. Thus the transpiler needs to detect any (known) invocation of a function that uses type aliasing or other kinds of type punning and explicitly convert the provided function arguments into the types required by the MSL shader function, in this case converting a single int3 into a pair of uint2 and uint and ensuring that the data passed into the uint constructor is actually of a specific type that can be converted.

These and many other changes are necessary because MSL is effectively C++14 code and thus requires the same adherence to type safety and function signatures as any other application code written in C++. This allows sharing header files of data type and structure definitions between application and shader code, but also requires shader code to be more correct than it had to be for HLSL or GLSL in the past. And in the case of OBS Studio, the transpiler has to partially "rewrite" the HLSL shader code into more compliant MSL code at runtime.

Part 1.3.2: Pretending To Be Direct3D

The next hurdle was to simulate the behavior of Direct3D inside the Metal API implementation. As it was deemed infeasible to rewrite the core renderer itself, it must be "kept in the dark" about what actually happens behind the scenes.

One of the main jobs OBS Studio has to do for every video frame is convert images (or "frames") provided by the CPU into textures on the GPU, and - depending on the video encoder used - convert the final output texture back into a frame in CPU memory that can be sent to the encoder. In Direct3D this involves the "mapping" and "unmapping" of a texture:

• When a texture is "mapped" it is made available for the application code in CPU memory.
• When the texture is mapped for writing, Direct3D will provide a pointer to some CPU memory that it has either allocated directly or had been "lying around" from an earlier map operation. OBS Studio can then copy its frame data into the location.
• When the texture is mapped for reading, Direct3D will provide a pointer to CPU memory that contains a copy of the texture data from GPU memory. OBS Studio can copy this data into its own "cache" of frames.
• When OBS Studio is done with either operation, it has to "unmap" the texture. The provided pointer is then invalidated and any data pointed to it can and will be changed randomly.

By itself a naïve implementation of this operation can have severe consequences: When a texture is mapped for writing, any pending GPU operation (e.g., a shader's sampler reading color data from it) might be blocked from being executed as the texture is still being written to. Likewise when a texture is mapped for reading, any pending CPU operation (e.g., copying the frame data into a cache for the video encoder) might have to wait for any GPU operation that currently uses that texture.

As part of its resource tracking behind the scenes, Direct3D 11 keeps track of texture access operations and will try to keep any such interruptions to a minimum, which leads specifically to the kind of overhead the modern APIs try to avoid:

• When a texture is mapped for writing, Direct3D will keep track of the mapping request and provide a pointer to get the data copied into, even while the texture is in use, and schedule a synchronization of the texture data.
• Once the texture is unmapped, Direct3D will upload the data to GPU memory and once this has taken place, schedule an update of the texture with the new image data.
• If any consecutive draw call that uses the same texture was issued by the application code after the unmapping, Direct3D will implicitly ensure that all pending GPU commands are scheduled and thus the texture update will take place before any consecutive GPU command might access the same texture.
• When a texture is mapped for reading, Direct3D will also ensure that all pending GPU commands writing to that texture are executed first to ensure that the copy it will provide will represent the result of any draw commands issued by the application before that.
• These are just examples of what might happen, as the specifics are highly dependent on the current state of the pipelines, the internal caches of the API's "driver" and other heuristics.

OBS Studio's entire render pipeline is designed around the characteristics of the map and unmap commands in Direct3D 11 and expect any other graphics API to behave in a similar way. Metal (as other modern APIs) does not do all of this work (Metal 3 will indeed still do hazard tracking of resources, but developers can opt-out of this behavior, and Metal 4 removed it entirely) and thus the API-specific backend has to simulate the behavior of Direct3D 11 in its own implementation:

• When a texture is mapped for writing, a GPU buffer is opportunistically set up to hold the image data.
• As the Metal backend is only supported on Apple Silicon devices, GPU and CPU share the same memory. This means that a pointer to the buffer's memory can be directly shared with the renderer,
• When the texture is "unmapped", a simple block transfer (or blit) operation is scheduled on the GPU to copy the contents of the GPU buffer into the GPU texture. The unmap operation will "wait" until the blit operation has been scheduled on the GPU to prohibit the renderer from issuing any new render commands which would potentially run in parallel.
• When a texture is mapped for reading, the same pointer to the GPU buffer is shared with application code. As the buffers are never used by any render command directly, no hazard tracking is necessary. An "unmapping" thus does nothing.
• "Staging" a texture for reading thus only requires scheduling a blit from the source texture into its associated staging buffer (as buffers and textures are effectively the same thing and differ only by their API). To ensure that no further render commands are issued by the application, the copy operation is made to wait until it is completed by the GPU, but also has to ensure that if the source texture has any pending render commands, that those are scheduled to be run on the GPU explicitly.

The same applies to other operations closely following Direct3D's design: To ensure that the Metal backend reacts in a way that meets the way OBS Studio's renderer expects, it had the "hidden" functionality of Direct3D implemented explicitly, particularly the tracking of texture use by prior render commands before any staging takes place.

Part 1.4: But Wait, There's More (Issues)

One major reason why the backend is considered "experimental" is due to the way its preview rendering had to be implemented for now. To understand the core reason for those issues, it is important to first understand how OBS Studio expects preview rendering to work, which closely shaped by the way DXGI (DirectX Graphics Infrastructure) allows applications to present 3D content on Windows. DXGI swapchains hold a number of buffers with image data created by the application, one of which the application can ask to be "presented" by the operating system.

To avoid an application potentially generating too many frames than can be presented (and thus potentially blocking the application), DXGI swapchains can be set to have a "discard" mode and a synchronization interval of 0, which effectively allows an application to force the presentation of a back buffer immediately (without waiting for the operating system's own screen refresh interval) and because the contents of the buffer are discarded, it becomes available to be overwritten by the application with the the next frame's data.

Unfortunately this is the opposite of how Metal (or more precisely Metal Layers) allows one to render 3D contents into application windows: With the introduction of ProMotion on iPhones and Macbooks, macOS controls the effective frame rates used by devices to provide fluid motion during interaction, but potentially throttle the desktop rendering to single digit framerates when no interaction or updates happen. This allows iOS and macOS to limit the operating system framerate (and the framerate of all applications within it) when the device is set to "low power" mode and is thus not designed to be "overruled" by an application (as it would allow such an application to violate the "low power" decision made by the user).

Thus applications cannot just render frames to be presented by the OS at their own pace, instead they have to ask for a surface to render to and the number of surfaces an application can be provided with is limited. This means that if OBS Studio is running at twice the frame rate of the operating system, it would exhaust its allowance of surfaces to render into. And because OBS Studio renders previews as part of its single render loop, any delay introduced by a preview render operation also stalls or delays the generation of new frames for video encoders.

The solution (at least for this first experimental release) was for OBS Studio to always render into a texture that "pretends" to be the window surface to allow the renderer to finish all its work in its required frame time. Then a different thread (running globally for the entire app with a fixed screen refresh interval) will pick up this texture, request a window surface to render into, and then schedule a block transfer (blit) to copy the contents into the surface. This also requires explicit synchronization of the textures' use on the GPU to ensure that the "pretender" texture is fully rendered to by OBS before the copy to the surface is executed.

In a nutshell: Whenever the operating system compositor requires a refresh, a separate thread will wait for OBS Studio to render a new frame of the associated preview texture and only once that has happened, the texture data is copied into the surface provided by the compositor. But as the preview rendering is now decoupled from the main render loop, framerate inconsistencies are inevitable. The kernel-level timer provided by the operating system will not align with OBS Studio's render loop (which requires the render thread to be woken up when it's calculated "time for the next frame" has been reached) and thus either a new frame might have been rendered in time or an old frame could not be copied in time.

Starting with macOS 14, the approach suggested by Apple would require OBS Studio to decouple these intervals even further, as every window (and thus potentially every preview) will have its own independent timer at which the application will receive a call from the operating system with a surface ready to be rendered into, which would bring a whole new set of potential challenges as it's even further removed from how OBS Studio expects to be able to render previews in the application.

Part 1.5: The Hidden Costs Of Modern Graphics APIs

The complexity of the endeavor was high and took several months of research, trial and error, bugfixing, multiple redesigns of specific aspects, and many long weekends. During the course of development it also became clear why some applications that simply switched from OpenGL to Vulkan or Direct3D 11 to Direct3D 12 might have potentially faced worse performance than before, seemingly contradicting those API's promise of improved performance.

Part of the reason is that a lot of the work that had been taken care of the by API's drivers are now application responsibilities and thus need to be taken care of by developers themselves. This however requires a more intimate understanding of "how the GPU works" and familiarization with those parts of Direct3D or OpenGL that were purposefully hidden from developers up to this point. And it also requires a more in-depth understanding of how the render commands interact with each other, what their dependencies are, and similarly how to encode and communicate these dependencies to the GPU to ensure that render commands are executed in the right order.

In the case of the Metal backend, this means that a certain amount of overhead that was removed from the API itself had to be reintroduced into the backend again, as even though it would be in a far better position for adoption, the core renderer was not available for a rewrite. Nevertheless even with this overhead, the Metal backend provides multiple benefits:

• In Release configuration and even in its non-optimized current form, it performs as well or even better as the OpenGL renderer.
• In Debug configuration it provides an amazing set of capabilities to analyze render passes in all their detail, including shader debugging, texture lookups, and so much more.
• As it's written in Swift, it uses a safer programming language than the OpenGL renderer, one that is at the same time easier and less time consuming to work with.
• Because preview rendering is effectively handled separately from the main render loop, the Metal renderer enables EDR previews on macOS for high-bitrate video setups.

As far as maintenance of the macOS version of OBS Studio is concerned, the Metal backend brings considerable benefits as Xcode can now provide insights that haven't been available to developers since the deprecation of OpenGL on all Apple platforms in 2018. But it is due to these complexities that the project would like to extend an invitation to all developers (and users that might be so inclined) to provide feedback and suggestions for changes to improve the design and implementation of the Metal backend to first move it out of the "experimental" stage and later make it the default graphics backend on macOS.

• Added a basic plugin manager [FiniteSingularity/PatTheMav/Warchamp7]
• Added opt-in automatic crash log upload for Windows and macOS [PatTheMav/Warchamp7]
• Added Voice Activity Detection (VAD) to NVIDIA RTX Audio Effects, which improves noise suppression for speech, as well as several optimizations to NVIDIA Effects [pkviet]
• Added chair removal option for NVIDIA RTX Background Removal, allowing removal of chairs [pkviet]
• Added experimental Metal renderer for Apple Silicon Macs [PatTheMav]
• Added Hybrid MOV support [derrod]
  • Brings ProRes support on macOS and a more widely supported HEVC/H.264 + PCM audio option to all platforms

General Changes

• OBS Studio will no longer load plugins built for a newer release of OBS to prevent future compatibility issues [norihiro]
• Added custom OBS widgets in preparation for larger UI updates [derrod/gxalpha/Warchamp7]
• Added preparations for Metal renderer (stay tuned!) [PatTheMav]
• Changed default bitrate from 2500 to 6000 Kbps [notr1ch]
• Changed Hybrid MP4/MOV to be the default containers [derrod]
• Changed the crash sentinel file location to its own subdirectory [PatTheMav]
• Improved audio deduplication logic to cover more cases of nested scenes, groups, and multiple canvases [pkviet]
• Prevent audio duplication when sources are set to "Monitor and Output" while the monitoring device is also being captured [pkviet]
• Updated the default settings for AMD encoders [rhutsAMD]
• Improved accuracy of chapter markers in Hybrid MP4/MOV [derrod]
• Re-hid the cursor in edit fields on macOS [gxalpha]
• Improved format selection for PipeWire video capture [tytan652]
• Removed workarounds to prevent loading Qt 5 based plugins [RytoEX]
• Removed the --disable-shutdown-check launch flag [PatTheMav]
• Hybrid MP4/MOV is now out of beta and has been made the default output format for new profiles [derrod]

Bug Fixes

• Potentially fixed a rare crash on macOS when moving or resizing the OBS window [PatTheMav]
• Fixed a crash with SRT when using an invalid URL [pkviet]
• Fixed a crash when setting non-default pkt_size with SRT [pkviet]
• Fixed a crash in Media Source when playback starts with certain video files [howellrl]
• Fixed a UI deadlock when opening source properties from the Sources list when the Windows setting 'Snap mouse to default button in dialog boxes' was enabled by adding a 200ms delay before creating the properties window [Warchamp7]
• Fixed a memory leak when trying to output Hybrid MP4 to a non-writeable location [norihiro]
• Fixed rare occurrence of multiview becoming blank [norihiro]
• Fixed SRT reconnection failures [pkviet]
• Fixed overflow texture rendering sRGB-awareness [PatTheMav]
• Fixed incorrect color range property setting for AMD AV1 encoder [rhutsAMD]
• Fixed Hybrid MP4 file splitting not working correctly in some cases [derrod]
• Fixed not being able to capture higher than 60fps with macOS Screen Capture [jcm93]
• Fixed focus not displaying properly in hotkey settings on macOS [gxalpha]
• Fixed the scrollbar appearing invisible in Light and Rachni themes [shiina424]
• Fixed HEVC frame priority not being set correctly in some cases, potentially causing playback errors when dropping frames [dsaedtler]
• Fixed an issue that could result in increases to output latency after temporary encoder stalls [dsaedtler]
• Fixed an issue where Multitrack Video could still be enabled after switching from a service that supports it to one that does not [Penwy]
• Fixed an issue where GetGroupList with obs-websocket would return nothing [gxalpha]
• Removed a workaround for older Qt versions that prevented docks from loading correctly while OBS is maximized [RytoEX]

Note: The code signing certificate for OBS has been updated. This may impact game capture compatibility with some anti-cheat solutions with this OBS update. If you are a game or anti-cheat developer please see obsproject.com/kb/capture-hook-certificate-update on our knowledge base for more information.

New Features

• Added NVIDIA Blur Filter and Background Blur [pkviet]
• Added preview scrollbars and zoom/scale indicator [cg2121/Warchamp7]
• Added v210 format support for AJA device capture [paulh-aja]
• Added Amazon IVS service integration [palana]
• Added QSV AV1 Screen Content Coding [thyintel]
• Enabled first-party YouTube Chat features [msuman-google]

General Changes

• Updated the browser source/docks CEF (Chromium) to version 127 (6533) on all platforms [reitowo/WizardCM/PatTheMav/tytan652/pkviet/kkartaltepe/Lain-B]
• Changed scene items to use relative coordinates [derrod]
  • Existing scene collections will be automatically converted to use relative coordinates if the scene collection has a known output resolution set.
• Split NVIDIA Audio Effects from Noise Suppression [pkviet]
  • Existing filters will be automatically migrated.
• Changed the Image Slideshow's Playback Mode property from radio buttons to a dropdown [derrod]
• Disabled the (currently unsupported) built-in Automatic Scene Switcher when using Wayland on Linux [tytan652]
• Improved error messages for macOS Virtual Camera [jcm93]
• Changed Display and Window capture on Windows to not capture the first found display or window [Lain-B]
• Changed display and window capture on Linux to not capture implicitly [Lain-B]
• Added a warning to Window Capture when trying to capture WinUI 3 applications with BitBlt [qhy040404]
• Refactored the NVENC implementation with various improvements [derrod]
  • SDK 12.2 features, such as split encoding, are now supported.
  • Additional features from old SDKs are supported:
    • B-Frames as reference
    • Target Quality VBR mode (CQVBR)
  • A custom options field has been added to allow setting more options that don't warrant their own UI elements.
• Improved screensaver inhibit functions on Linux in Flatpak [tytan652]
• Changed scripts to correctly pass settings to modified callbacks on reload [Penwy]
• Removed legacy QSV code for old devices (Haswell or older) [RytoEX]
• Removed legacy QSV code for Windows 7 [RytoEX]
• Removed default desktop audio device on macOS 13+ [jcm93]
• Removed NVIDIA Kepler GPU support for NVENC [derrod]
• Removed FTL support [derrod]
• Removed legacy migrations from OBS Studio 28.1 and earlier [derrod]
  • If updating from these older versions, you may wish to update to OBS Studio 30.2 first, and then update to OBS Studio 31.
• Removed support for Ubuntu 22.04 [derrod]
• Removed legacy YouTube chat [gxalpha]
• Blocked TikTok Virtual Camera from loading in OBS due to known issues [notr1ch]
• Application settings have been split into "app" configuration and "user" configuration, rather than storing everything in global.ini [PatTheMav]

Bug Fixes

• Fixed two crashes with the QSV encoder on Linux [kkartaltepe]
• Fixed a crash with a race condition involving multitrack video output reconnect [dsaedtler]
• Fixed two potential crashes in Linux Window Capture [Lain-B]
• Fixed a crash on macOS that could occur if an audio device was disconnected [jcm93]
• Fixed a crash on Windows when capturing D3D12 games [confusionattack/Lain-B]
• Fixed a crash on Linux when importing a scene collection created on Windows [SarenDev]
• Fixed a crash on Windows when capturing a Vulkan application [Charlese2]
• Fixed a deadlock in MP4 muxer [derrod/notr1ch]
• Fixed a deadlock when shutting down muxer [exeldro]
• Fixed a potential deadlock when stopping an encoder [derrod]
• Fixed a potential memory error and crash in text parser [fzwoch]
• Fixed a couple minor memory leaks [pkviet]
• Fixed a memory leak in PipeWire plugin [dimtpap]
• Fixed a memory leak when playing an HDR media file [tt2468]
• Fixed an issue on FreeBSD with handling SSL certificates [emaste]
• Fixed an issue with pressed button color in the Rachni theme [shiina424]
• Fixed an issue with some missing icons in the System theme [shiina424]
• Fixed an SRT listener bug where the socket was not closed properly [pkviet]
• Fixed an issue where the current scene collection could be erased to default when trying to switch to a different scene collection that's corrupted or invalid [derrod]
• Fixed a buffer overrun in UTF-8 text conversion [derrod]
• Fixed an issue that could cause bitrate spikes in QSV CBR [thyintel]
  • Note: This fix only applies to Lunar Lake or newer except Alder Lake N.
• Fixed an issue where the Auto Configuration Wizard could unintentionally enable Enhanced Broadcasting [lexano-ivs]
• Fixed issues with the audio clipping indicators displaying incorrectly on volume meters [norihiro]
• Fixed an issue causing hotkeys to register inconsistently on macOS [jcm93]
• Fixed an issue causing multitrack video output to fail if color format was set to I444 [dsaedtler]
• Fixed an issue where Custom CSS in browser sources no longer worked with certain websites (namely YouTube chat) [vvto33]
• Restored STUN support for WHIP output [mondain]

A Decade of Growth

OBS has been around for over ten years now, and in that time, it has grown significantly in terms of functionality, code complexity, and community size. With this growth came challenges, both in development and organization. While it’s a great problem to have, figuring out how to manage these growing pains hasn’t always been easy.

One of the areas that needed attention was our release process and versioning methods. Up until recently, we lacked a clear, consistent approach to how we numbered our releases. But with version 30, we’ve started to follow proper Semantic Versioning (SemVer) a lot more strictly.

What Is Semantic Versioning?

Semantic Versioning is a system for labeling software versions in a logical, consistent way. It communicates the significance of changes so users and developers know what to expect from an update.

MAJOR.MINOR.PATCH
Ex. 30.0.1

• MAJOR: Big, breaking changes that may affect how you interact with the software or require developers to adjust their code.
• MINOR: New features and improvements that don’t break anything but add something new.
• PATCH: Hotfixes and other bugs that need attention before other releases

Our Journey with Versioning

In the past, our versioning was a bit… loose. We didn’t have a strict structure or consistency in deciding when to release a new version or how to label it. Releases would come when we felt there were enough new features or fixes to warrant one, and we’d assign a version number based on how significant we thought the changes were.

Sometimes a MAJOR version would include breaking changes, and other times it was simply a feature-packed release we wanted to highlight. This inconsistency could be confusing, and moving forward, we’ve committed to using MAJOR version numbers strictly for updates that fundamentally change how you use OBS or affect developers by modifying the API or dependencies.

A great example of why this change was needed is OBS 28.0. That release included an update to the UI framework we use, which broke compatibility with several plugins. In hindsight, our inconsistent use of MAJOR version bumps muddied the significance of this update, causing frustration among both users and developers. By sticking more closely to Semantic Versioning, we hope to avoid these kinds of issues in the future.

What This Means for You

Going forward, you can expect MINOR version bumps to be more common. We’re aiming to limit MAJOR breaking updates to about once a year, though that timeline could shift to be more or less depending on the needs of the project.

To be clear, this doesn’t mean the project is slowing down. In fact, it’s quite the opposite. With clearer planning and more predictable versioning, we’ll be able to manage releases more efficiently. In the past 10 years, we’ve reached version 30, but over the next decade, we may not even hit version 40, simply because MAJOR releases will be less frequent. This is just a visual change to how we label updates, not a reflection of the pace or size of our changes.

Our Release Schedule

Alongside our commitment to more structured versioning, we’re also working toward a more predictable release schedule. While we’re not enforcing strict deadlines for features or updates yet, we’re aiming for new releases roughly every 4 months. This loose schedule gives contributors and users a better idea of when to expect new features and fixes, without sacrificing quality by rushing development.

As we move forward, we’re excited to bring more structure to the OBS Studio release process, giving you clearer communication on what’s coming and when. By adopting a more standardized approach to versioning and scheduling, we hope to make OBS even better for both everyday users and developers who rely on it. We’re thrilled about what’s coming in version 31 and beyond—stay tuned!

Note: NVIDIA users may need to update their GPU drivers to 531.61 (Windows) / 530.41.03 (Linux) or newer.

Note: The code signing certificate for OBS is being updated. This may impact game capture compatibility with some anti-cheat solutions starting with the next major OBS update. If you are a game or anti-cheat developer please see https://obsproject.com/kb/capture-hook-certificate-update for more information.

New Features

• Added support for Multitrack Video streaming [palana]
  • On Twitch, this is known as Enhanced Broadcasting. For more information, see: https://help.twitch.tv/s/article/multiple-encodes
  • The supported audio channel configurations are stereo or mono.
  • This feature is currently only available on Windows and requires an NVIDIA GTX 900, GTX 10, or RTX 20 series GPU or newer or an AMD RX 6000 series GPU or newer. Support for other operating systems and GPU vendors is planned.
  • When this feature is enabled, the following data about your system will be sent to the streaming service when starting a stream:
    • OBS version and audio/video settings (resolution, framerate, audio channels/tracks)
    • CPU info (name, speed, core counts)
    • GPU info (model, memory, driver version, device ID, vendor ID)
    • Memory info (free, total)
    • OS info (name, version, arch, emulation)
      • Windows info (gaming feature status: Game Bar, Game DVR, Game Mode, Hardware-accelerated GPU Scheduling)
    • Multitrack Video settings (maximum streaming bandwidth, maximum video tracks)
• Added support for Enhanced RTMP/FLV multi-track audio and video [palana/kc5nra]
  • Replaces the old metadata-based "VOD Track"
• Added "Hybrid MP4" output format (BETA) [derrod]
  • Combines fault-tolerance of fragmented MP4 with wide compatibility and faster access times of regular MP4. For more information, see: https://obsproject.com/kb/hybrid-mp4
  • Supports inserting chapter markers into the file via a hotkey or API. These markers are supported by most video players and editing software, such as DaVinci Resolve
• Added Linux support to the native NVENC encoder [derrod]
  • NVENC AV1 is now supported on Linux
• Added Linux shared texture support to the NVENC encoder [derrod]
• Added Linux shared texture support to the QuickSync encoder [kkartaltepe]
• Added Linux shared texture support to the VA-API encoder [nowrep]
• Added HEVC support to WebRTC output [murillo128]
• Added Composable Themes system to simplify theme creation, maintenance, and enable future customization options [derrod/Warchamp7]
  • Themes now consist of a base theme and variants that can be switched between in the new "Appearance" settings tab
  • Old themes will no longer work and will need to be updated to the new system. See the wiki page for details: https://github.com/obsproject/obs-studio/wiki/OBS-Studio-Theme-System
  • The legacy System theme is no longer available. If it was used for accessibility reasons with high contrast, enable high contrast in your operating system settings to re-enable the OBS System Theme. OBS can only detect high contrast on Windows and macOS at this time.

General Changes

• Various UI and Theme tweaks [Warchamp7]
• Audio of multiple instances of a source in a scene/group is now deduplicated [derrod]
  • Deduplication is recursive, but does not apply on groups or nested scenes that are currently playing show/hide transitions, this may be fixed in the future
• Scene Collection specific plugin data is now retained for plugins that are not currently loaded [derrod]
• Closed-captions are now supported for HEVC and AV1 [jhnbwrs]
• Qt Fusion style is now always enforced on Linux [tytan652]
• Combined PipeWire window/display capture into unified "Screen Capture" source to align with other platforms [tytan652]
  • Renamed "Screen Capture (XSHM)" as "Display Capture (XSHM)" for consistency with other capture sources [tytan652]
• Set default recording format on macOS to fragmented MOV [gxalpha]
• Improved freetype2 text source performance [kkartaltepe]
• File open dialogs now start in the directory of the currently selected file, rather than the default [Warchamp7]
• Moved warnings in advanced output to bottom of settings window for better visibility [GPattenden]
• Various performance improvements for texture encoding [kkartaltepe]
• Prioritize NVDEC decoder on NVIDIA systems [moocowsheep]
• Support NVDEC decoder for encoded DirectShow sources [moocowsheep]
• Replaced non-texture NVENC FFmpeg fallback with native implementation [derrod]
• Log now includes all available encoders [Penwy]
• Reset duration of scene item show/hide transitions when removing the transitions [Warchamp7]
• Adjusted appearance of volume meters [Warchamp7]
• Adjusted appearance of multiview borders and labels [Warchamp7]
• Added support for audio-only and video-only WHIP outputs [tt2468]
• Changed default container in non-macOS OBS Beta builds from Fragmented MP4 to Hybrid MP4 [derrod]

Bug Fixes

• Fixed packet priority not being set for some AV1 encoders, resulting in outputs never recovering from dropping frames [derrod]
• Fixed various issues with audio channel layouts in (remuxed) recordings [pkv/derrod]
• Fixed various issues with the native FLV muxer [palana]
• Fixed various issues with the RTMP protocol implementation [palana]
• Fixed minor errors in HEVC and AVC decoder configuration records [derrod]
• Fixed change discard confirmation dialog popping up twice when closing source properties [tytan652]
• Fixed QSV AV1 on multi-GPU systems [thyintel/derrod]
• Fixed FFmpeg output erroneously checking disk space when not writing to a file [RytoEX]
• Fixed auto-config wizard not working without a stream key [mar10iana]
• Fixed text alignment with extents [exeldro]
• Fixed encoder properties having nested scroll areas in output settings [derrod]
• Fixed crash if input video resolution changes when using hardware-accelerated decoding [tt2468]
• Fixed button text being cut off in controls dock [powersagitar]
• Fixed undo action for filters showing UUID instead of name [derrod]
• Fixed not all eligible Patreon supporters being shown in the "About" dialogue [Warchamp7]
• Fixed copy-pasting show/hide transitions not including duration [Warchamp7]
• Fixed settings dialog being cut off on low-resolution screens [tytan652/Warchamp7/derrod/RytoEX] (yes, this one took four people to figure out)
• Fixed paused indicator text stacking [Aleksbgbg]
• Fixed disabled audio sources showing up in advanced audio properties [Penwy]
• Fixed Grid Mode setting not being persisted when enabled through the View menu [RytoEX]
• Fixed CoreAudio not handling encoder delay, resulting in audio being 44-48 ms late [derrod]
• Fixed OBS not handling negative audio timestamps at the start of an output correctly, resulting in Opus and CoreAudio AAC audio being delayed by a few ms [derrod]
• Fixed VA-API AV1 encoder being unavailable if H.264 is unsupported [kkartaltepe]
• Fixed WebRTC buffer size being too small for recovery with high-bitrate video [Sean-Der]
• Fixed renaming multiple scenes when hitting Tab key while renaming [howellrl]

In OBS 30.2 I introduced the new "Hybrid MP4" output format which solves a number of complaints our users have had for pretty much all of OBS's existence; It's resilient against data loss like MKV, but widely compatible like regular MP4.

Getting here was quite a journey, and involved fixing several other bugs in OBS that were only apparent once diving this deep into how the audio and video data is stored.

In this post I'll try to explain how MP4 works, what the drawbacks were to regular/fragmented MP4, and how I tried to solve them with a hybrid approach.

QTFF, BMFF, WTF

The MP4 file format we all know and love today is based on Apple's "QuickTime File Format" (QTFF) - mostly just known as "MOV" - which was originally created in the 90s. It was adapted by the International Organization for Standardization (ISO) to create the MP4 File Format in 2001, then later split up into the more generic "Base Media File Format" (ISO BMFF) and an MP4 extension containing MPEG-specific features.

Since then, MP4 has undergone numerous updates and extensions over the years to support new codecs and more specialised use cases. The extensible nature of the base format also means that various users of MP4, such as Apple, have added extensions to support various other features such as DRM, 3D video and more.

The Trouble with Tribbles MP4

While MP4 is very widespread and supported by almost anything under the sun, there are some issues specific to the use case of recording live video to disk. To explain those, let's first go over the basic structure of an MP4 file, as that will help make sense of what was required to make Hybrid MP4 work.

At its core an MP4 file is made up of objects known as "Boxes" in ISO, or "Atoms" in Apple terminology. Each box consists of a header containing its size and a four-letter name/type, followed by its data. Most boxes contain data structures defined in ISO/Apple specifications, but some are containers for other boxes. This allows for a hierarchical structure of the file and makes it easy to extend the format by introducing new boxes containing additional information without breaking backwards compatibility with existing software. For the purposes of this blog post, however, we'll only be looking at what are known as "top-level boxes", i.e. boxes that are written directly into the file and are not contained within other boxes.

A typical MP4 file produced by OBS or FFmpeg will contain four top-level boxes:

• ftyp - File Type Box: Contains information about the the standard version(s) used in the file
• free - Free Space Box: Placeholder that should be ignored/skipped over
• mdat - Media Data Box: Contains data for media tracks (audio, video, etc.)
• moov - Movie Box: Contains other boxes with metadata for the file and media tracks

There are two things here that create the main problem we have with MP4: The moov sits at the end and is written when finalising the file, and it is required to be able to make sense of the data contained in the mdat box. This means that if the writing of the file gets interrupted for any reason (BSOD, disk full, power loss, etc.) and the moov box is not written, the file is extremely difficult - if not impossible - to recover. This is obviously very bad™ if you just recorded your best ever clutch in Counter-Strike but then your disk space ran out and now you don't have any proof of it ever happening!

Note about the free box since it will become important later: The size field in the box header is limited to 4 GiB. In order to have an mdat box larger than that, an extended size field needs to be used, which increases the size of the header. FFmpeg and OBS will write the placeholder so that it can be overwritten to writer a longer mdat header should it become necessary.

This leads us into the next part, which details the first attempt at solving this problem...

Fragmented Frustration

Some time ago the ISO format was extended with support for splitting media data into "Fragments", this is commonly referred to as "Fragmented MP4". These fragments can be split out into separate files as well, which is mainly used when streaming video over the internet, whether live on Twitch¹ or films on Netflix. The details of that are beyond the scope of this post, but you can learn more about why this is done and its advantages for streaming use cases by reading more about HLS and DASH.

What's relevant for us is that a fragmented file has an "incomplete" moov that only contains the basic information necessary for decoding each track, with the information about specific samples (video frames, audio segments) contained in a fragment being stored in the moof (Movie Fragment Box) at the start of each fragment.

This is useful for the OBS recording use case because it means that a file no longer relies on a single moov containing all the information about the media data in the file. Each fragment only needs it's own moof box + the incomplete moov at the beginning to be played back correctly. This means that if the writing of the file is interrupted (e.g. due to a power failure), everything up to the last fragment will still be readable, solving the data loss problem of regular MP4 files.

Sounds too good to be true, doesn't it? Well, there are some significant downsides that ultimately caused us to stop using fragmented MP4 as the default pretty quickly:

1. Fragmented files are still not well supported in various applications, including editors and players
2. They are slow to access on HDD or network drives, as each fragment's header needs to be read to get the complete metadata of the file and start playback
3. File browsers such as the Windows explorer do not show the file duration due to 2.
4. Some players (e.g. the default Windows Media Player) do not allow seeking in the file due to 2. and will instead play it back like a livestream

Of course this can be fixed by remuxing the file, but that just brings us right back to where we started with MKV. There has to be a better way...

Hybrid Harmony

Quite a while ago I had a simple though: What if we just "finalise" a fragmented file with a full moov so that it behaves like a regular MP4? Then finally a few months ago I started to actually explore this idea which evolved into what we now know as "Hybrid MP4".

While the recording is running, a hybrid file is really just a fragmented MP4, retaining the resilience against data loss, but when the recording stops, it is quickly modified to appear like a normal MP4. I called this process a "soft remux" because it only needs to overwrite a small part of the file to achieve similar results to fully remuxing a file.

To do this, a full moov is written at the very end of the file that indexes the media data exactly like a normal MP4 would, and the placeholder free box at the start is overwritten with an mdat header that turns the entire file up to the newly written moov box into one giant Media Data box, thus effectively hiding the fragments from a reading application. This means we're now left with a file that appears to be a regular MP4, when it's actually fragmented inside!

The hybrid approach ultimately addresses all the problems we had by combining the best of both worlds. If a file is not finalised you still have a valid fragmented MP4 that can be remuxed if necessary, and if it is finalised, well, for all intents and purposes it's just a regular old MP4.

And that's pretty much it. This idea went through a few rounds of iteration and improvement, this post only details the final version that has shipped in OBS. It kind of hurts that several days of work and research can be summed up in a couple paragraphs, but that's what the "pain" part in the subtitle is for.

Big Buck Bunny Holes

The process of building this implementation took me down quite a few rabbit holes, as it required me to learn a lot of low-level details about how audio and video data is stored in files, and sometimes left me wondering why my results were different from the references I was using. This section contains some fun and some not so fun examples of things I encountered while working on the Hybrid MP4 output.

Chapter Markers

Markers are one of the headline features that Hybrid MP4 adds over the existing FFmpeg-based output. Don't get me wrong, FFmpeg does support these as well, but we never implemented it. But while I was doing this I figured this might be a good time to get it done, and will give users a nice incentive to actually use and test it.

The MP4 standard itself actually does not define anything for chapter markers, they are entirely based on Apple's QuickTime specification, and even then it seems to be only mostly documented. The implementation in OBS is directly adapted from FFmpeg, and should work in all the same software that it does like video players and some editing suites such as DaVinci Resolve. Sadly this does not include Adobe Premiere or Final Cut Pro, but there may be tools coming to make it a bit easier for those users!

Additional Metadata

While I was at it I figured I can add some additional metadata to each media track and the file itself, such as the encoder configuration², so I did! This is particularly useful when you're testing different settings and want to compare them later, but don't want to have to rename the file after every test. Files now also contain a correct creation/encoding date so even if you rename them you can still track when a file was originally recorded.

Multi-Track Video

The new MP4 output now also supports multiple video tracks alongside multiple audio tracks, this is great for debugging features such as Twitch's Enhanced Broadcasting by having a single file with all the video streams that can be easily switched between in players such as MPC-HC.

So it's not super useful for the average user yet, but hopefully we can make use of it in the future for things such as ISO recording (well, if we can also convince video editors to support it...).

Audio Encoder Delay and why your audio might've been out of sync for the last few years

AAC and Opus audio both have something called "priming" samples, this is a few milliseconds of silence at the start of an audio stream used to "warm up" the encoder, which should be skipped when playing back the file. Audio packets containing priming samples have a negative timestamp, indicating (part of) the audio they contain should be skipped during playback. There were two separate issues in OBS related to this:

1. Audio packets with timestamp < 0 would be discarded until the one with a closest timestamp <= 0 is found, which would then have its timestamp "corrected" so that the stream always starts at 0, thus including the delay in the output and causing it to be slightly out of sync
2. The CoreAudio AAC encoder implementation did not subtract the delay from timestamps at all, thus audio always being delayed by 40-44 ms (at 48/44.1 kHz)

Issue 1. happened to not affect the default audio encoder (FFmpeg AAC), as it uses a delay equivalent to packet duration, meaning the first packet with actual audio already starts at 0. Opus on the other hand would produce a first packet with a timestamp of -312 with the next one being 648, OBS would then "correct" the packets to 0 and 960 respectively and would result in the 312 samples of silence being included and the audio being ~6.5 ms late.

Coincidental Collaboration

Just a few days after we merged the Hybrid MP4 feature into OBS the FFmpeg maintainer Martin submitted a patch that adds a similar feature to FFmpeg's MOV/MP4 muxer. This was entirely coincidental, and includes a note that Apple apparently did something like this already, which just proves that great minds do indeed think alike 😛.

This has now also been merged into FFmpeg as well, meaning it's already available in git builds and will hopefully soon make it's way into a stable release!

Note: The FFmpeg implementation is slightly different, and the OBS version has a few more safety nets just in case. It's still great to have though!

MOV-ing Forward

While MP4 is great for many things, it lacks some of the features and codec support available in it's ancestor QTFF (or MOV). Adding a "Hybrid MOV" mode is the next step to truly making it the new default in OBS. This primarily requires dealing with some of the differences between MOV and MP4 with things like PCM audio, differently implemented metadata structures, and also support for the ProRes codec. I'm hoping this can be done in time for OBS 31.0 if everything goes well!

A few other things that I'd like to work on for future improvements:

1. Better accuracy for chapter marker timestamps (needs OBS backend updates)
2. Support for writing a timecode (tmcd) track (requires the same backend updates as 1.)
3. Support for configurable fragment duration, rather than always fragmenting on keyframes (particularly important for intra-only codecs such as ProRes)
4. (Maybe) Built-in utility for exporting chapter markers in different formats for easier use in Premiere, etc.
5. (Big Maybe) Support for embedded XMP metadata for markers in Premiere

Thanks & Acknowledgements

• FFmpeg and its contributors for documenting the undocumented
• GPAC for mp4box.js, which has been invaluable for debugging my muxer and inspecting its output
• Apple's old QTFF documentation for actually being really good and having great explanations for concepts such as priming samples
• NOT the ISO for paywalling these specs and making it a god damn paperchase where every time you get one document it references three others that are also paywalled

We're excited to announce that YouTube has renewed their premier sponsorship of the OBS Project! Since they first partnered with us back in 2020, we've made some incredible progress together, both for the betterment of OBS, and the streaming community as a whole. Let's go over a few highlights from the past year that they have helped us accomplish to celebrate our continued partnership.

We partnered with YouTube to add support for streaming HEVC and AV1-encoded video over e-RTMP, the first update to the widely used protocol RTMP in over a decade. With the release of OBS 29.1 in May 2023, creators could use modern codecs to stream higher-quality video to YouTube using less bandwidth. To kick off 2024, we've added more e-RTMP features in OBS 30.1 (out now!), enabling creators to stream HDR content to YouTube using HEVC over e-RTMP.

We also collaborated with YouTube to embed a streamlined version of their Live Control Room panel as a dock within OBS. Released with OBS 30.0 in November 2023, this let creators monitor CCV and stream health, manage ads, insert stream markers, and more from OBS without the need to visit YouTube. Real-time content creation and streaming can be overwhelming, and we're happy that we can provide tools to ease the burden right in OBS. We're actively working with them and providing feedback to make this feature even better!

YouTube is a pillar of creativity in the internet community, serving as a nexus for people to share all kinds of content, including live performances, live streams of video game content, educational resources, product reviews, comedy sketches, and much more. It pioneered a new generation of video content across TV, computer and mobile devices, while also providing a platform that allows anyone to create and grow a career out of video content creation.

The OBS Project team is proud to have a role in serving content creators on YouTube with free and open source tools, and are incredibly grateful to YouTube for supporting us as we continue to meet those needs!

30.1 New Features

• Enabled HDR for HEVC over RTMP [nquah]
  • AV1 HDR is not currently supported by YouTube.
• Reworked the Image Slideshow source [Lain-B]
  • The reworked Image Slideshow source loads files asynchronously and fixes an issue where the slideshow would loop before showing all images. To change existing Image Slideshow sources to the new version, you must recreate them. Existing Image Slideshow sources will continue functioning as before.
• Added Capture Audio option to window/game capture on Windows [derrod]
• Added Premultiplied Alpha option for game capture on Windows [jpark37]
• Added option for automatic cropping to bounding box [derrod]
• Added maxRGB tonemapper for SDR in HDR Tone Mapping filter [jpark37]
• Added GPU rescaling options for streaming and recording outputs [derrod]
• Added channel selection for CoreAudio input devices [PatTheMav]
• Added Capture Card Device source type on macOS [PatTheMav]
• Enabled multi-track audio support for mpegts [pkviet]
• Added AV1 support for VA-API [nowrep]
• Added AV1 support for WebRTC/WHIP output [Sean-Der]
• Added Video Capture Device (PipeWire) source type [GeorgesStavracas]

30.1 Changes

• Added HDR support for the Elgato HD60 X Rev.2 [FBirth]
• Added theme data search paths [derrod]
• Added Lua script location to search path for Lua native libraries [Smartkin]
• Added Python 3.11 support for macOS [PatTheMav]
• Updated obs-websocket to version 5.4.2 [tt2468/Lain-B]
  • Release notes for addition in 5.4.0 are here: https://github.com/obsproject/obs-websocket/releases/tag/5.4.0
• Improved simple mode replay buffer settings [gxalpha]
• Switched to bigger units in the UI for high bitrate/large recordings [derrod]
• Disabled Paste Transform on locked scene items [cg2121]
• Disabled Edit Transform if scene item is locked [cg2121]
• Removed Windows 7 and Ubuntu 20.04 NVENC fallbacks [derrod]
• PCM audio in (fragmented) MP4/MOV is now supported [derrod]
• Changed default recording format to fMP4/fMOV for stable releases [derrod]

30.1 Bug Fixes

• Fixed crashes with the Virtual Camera on Windows when apps consumed it as YUY2 [vico-shang]
• Fixed crash when loading Python at runtime on Windows [PatTheMav]
• Fixed crash in Image Slideshow when adding a directory with no files in it [notr1ch]
• Fixed crash on macOS when attempting to stream to a WHIP servers with certain configurations [RytoEX/Sean-Der]
• Fixed crash when trying to stream with WebRTC/WHIP [CrackThrough]
• Fixed a possible crash in Lua scripts when switching scene collections [exeldro]
• Fixed a possible crash with WHIP output [Aleksbgbg]
• Fixed deadlock when adding a macOS Screen Capture source [PatTheMav]
• Fixed issue where OBS could be closed by docked browser panels [WizardCM]
• Fixed high CPU usage with Virtual Camera on macOS [jcm93]
• Fixed checkbox misalignment on macOS in properties view [nikola3211]
• Fixed audio track 1 audio being offset/desynced with other tracks [derrod]
• Fixed incorrect VST window size on HiDPI display [xlinshan]
• Fixed editable list UI element having incorrect background-color [tuduweb]
• Fixed the resize cursor with respecting the item transformation [BGM99]
• Fixed disk space reporting for attached network drives on macOS [PatTheMav]
• Fixed Safe Mode removing third-party transitions from scene collection [derrod]
• Fixed being unable to use QSV in the Flatpak package [twelho]
• Fixed audio track titles not being set in Custom FFmpeg Output [tuduweb]
• Fixed an issue with free disk space calculation on ExFAT and FAT32 volumes on macOS [PatTheMav]
• Fixed an issue with free disk space calculation on macOS not matching values in Finder [jcm]
• Fixed an issue where a removed source's scene would not be correctly logged [exeldro]
• Clarified the macOS microphone permissions prompt [jcm]
• Fixed a regression causing a missing tooltip for Fragmented MOV/MP4 [shiina424]
• Fixed an issue with the background of audio meters being transparent causing visual artifacts [fzwoch]
• Fixed an issue with Yes/No buttons on the Reset Docks confirmation message box not being translated [shiina424]
• Fixed an issue preventing the Remux dialog from being used multiple times [RytoEX]

New Features and Additions

• Added support for streaming AV1/HEVC over Enhanced RTMP [YouTube/yuriy-chunak/derrod]
  • Enhanced RTMP V1 extends the RTMP protocol to support newer video codecs and HDR. More info at: https://github.com/veovera/enhanced-rtmp
  • Currently only supported by/enabled for YouTube as a beta feature
  • HDR is not yet implemented
• Added support for multiple audio tracks in Simple output recording [pkv]
• Added a DLL blocking feature for Windows. This allows OBS to block problematic DLLs from attaching to OBS and causing freezing or crashes, for example 3rd party overlay hooks and outdated video capture devices. [notr1ch]
  • This blocks old versions of popular VTubing software virtual cameras that are known to cause freezes when accessing video capture device properties. If you are affected, please update to the latest version of your VTubing software.
• Added settings to select the audio encoder for streaming and recording [tytan652]
• Added an option to preload media sources used in Stingers to memory, to avoid frame skips during transitions [Lain]
• Added Update Channels on macOS and updated Sparkle for smaller and faster updates going forward [derrod]
• Added compatibility notices in the Window and Game Capture sources for Windows [derrod]
• Added the ability to zoom browser docks with Ctrl - and + and the right click menu [WizardCM]
• Added a setting to record in fragmented MP4 and MOV formats [derrod]
  • These offer greater compatibility than MKV while providing similar resilience against data loss due to crashes, running out of space, etc.
  • Fragmented MP4 and MOV files can be remuxed to regular MP4/MOV in cases where the former may not be read correctly (e.g. in older editing software)
• Added support for surround sound for AJA capture cards [paulh-aja]
• Added ProRes 4444 (XQ) support for VideoToolbox encoder on macOS [jpark37]
• Added lossless audio recording options (FLAC/ALAC/PCM including 32-bit float) [derrod]
• Added indicator if an audio source is unmuted, but not assigned to any audio tracks [derrod]
• Added AMD AV1 encoder to simple output mode [notr1ch]

General Changes

• Increased the minimum macOS version to macOS 11.0 [PatTheMav]
• Output rescaling is ignored if the scaled resolution matches the current video output resolution [notr1ch]
• NVENC error messages now include more details [notr1ch]
• Changed the default FFmpeg AAC encoder to twoloop which has higher quality [norihiro]
• Allow symbolic links for VST paths [tuduweb]
• Implemented QVBR for AMF encoders [flaeri]
• Expanded support for subtitle tracks in VLC source (up to 1000) [jjm2473]
• The Hotkeys tab in settings is no longer loaded until switched to, resulting in the Settings window opening much faster for large scene collections [derrod]
• Switched various internal data structures to use hash tables for lookups, resulting in significant performance and loading/saving time improvements with large scene collections [derrod]
• Exported scene collection JSON is now pretty-printed and sorted, allowing for easier tracking via git or other versioning mechanisms [derrod]
• Added a "What's New" entry in the help menu to manually open the post-update changelog dialog [derrod]
• Clicking the "Defaults" button in properties will now ask for confirmation before resetting [derrod]
• Improved Windows OBS updater speed and reduced download size by using Zstandard compression [derrod]
• Added platform-specific "What's New" notifications to better communicate changes or issues not affecting all operating systems [derrod]
• Added option to force SDR Window Capture capture in Windows 10+ mode [jpark37]
• Improved YouTube thumbnail preview by using bilinear scaling [derrod]
• Incompatible audio/video encoders will now be disabled based on the selected format [derrod]
• Added HEVC and HDR support to VA-API encoder [yuriy-chunak]
• Added HDR capture support for DeckLink sources [jpark37]
• Video-related items in the right click menu of audio sources in the Sources list will no longer appear [cg2121]
• Native macOS dialogs now respect OBS being set to dark themes [gxalpha]
• Significantly improve screen capture performance on Intel dedicated GPUs on Linux [kkartaltepe]
• JACK inputs on Linux will now display "OBS Studio" in their name to clarify their origin. This may cause existing configured devices to stop working until updated by the user [univrsal]
• The system color selection dialog is now used on macOS [gxalpha]
• Various improvements to the t-bar for a more predictable user experience [gxalpha]
• Plugins installed system-wide are no longer loaded when OBS is run in Portable Mode [gxalpha]
• Hardware Decoding of Media Sources can now use CUDA [rjgtav]
• Improved DeckLink performance [jpark37]
• Python 3.11 is now supported in Scripting [RytoEX]
• Added FDK AAC support on Flatpak [tytan652]
• Browser docks now provide a "Copy page address" option [WizardCM]
• Increased the maximum resolution of browser sources to 8192x8192 [fungiboletus]
• OBS Websocket has been updated to 5.2 [RytoEX]
• Changed Add Source menu to sort case-insensitively [gxalpha]
• Improved default buffering behavior for most Elgato video capture devices on Windows [FBirth]
• Added codec logging for the QSV encoder [RytoEX]
• Made hotkey edit layout margins symmetrical [gxalpha]
• Added logging if the active encoder is incompatible with dynamic bitrate [pkv]

Bug Fixes

• Fixed output silently not starting when using multi-track audio at higher frame rates [kkartaltepe]
• Fixed dynamic bitrate changes not working when using NVENC presets p6 or p7 [pkv]
• Fixed encoder settings not being updated if the encoder is changed in settings [tytan652]
• Fixed a crash that could occur when using a video source that frequently changed its resolution (e.g. a VLC playlist) [notr1ch]
• Fixed a crash that could occur when using streams in the media source (introduced in v29) [notr1ch]
• Fixed an issue with negative gain in upward compressor [pkv]
• Fixed several bugs in FFmpeg custom output related to color conversion [flaeri]
• Fixed UI unresponsiveness when searching for hotkeys and duplicate key assignments in large collections [derrod]
• Fixed an issue with RTMP timeouts that could cause a server to think OBS has cleanly ended the connection instead of it disconnecting due to an error, and not activating features like "disconnect protection" [notr1ch]
• Fixed properties being cut off until window is resized [derrod]
• Fixed portable Windows versions not restarting in portable mode after an update [derrod]
• Fixed updating of an install being blocked by unrelated OBS instances running [derrod]
• Fixed excessive config reads when sources are selected in the preview [derrod]
• Fixed audio track assignments of sources provided by third-party plugins being reset when the plugin could not be loaded [derrod]
• Fixed invalid rescaled resolutions being allowed when they shouldn't be [tuduweb]
• Fixed presets in the Expander filter not applying changes immediately [tuduweb]
• Fixed the virtual camera on Windows reporting the incorrect resolution to external apps, resulting in stretched images [exeldro]
• Fixed the ability to drag and drop scenes after clicking Rename and not changing the name of the Scene [cg2121]
• Fixed a crash on macOS that would occur when an external display with an active Projector was disconnected [PatTheMav]
• Fixed an issue where remuxing a .ts file would fail [tuduweb]
• Fixed an issue with the VLC source where large videos (e.g. 4K) would get squashed horizontally [CoalZombik]
• Fixed spacing helpers appearing incorrectly when a source is rotated and flipped [cg2121]
• Fixed an issue where the preview would display incorrectly when zoomed too far in either direction [cg2121]
• Fixed the macOS virtual camera potentially crashing external apps and recordings to be the wrong length [mac-cain13]
• Various fixes for monitoring when using PulseAudio [kkartaltepe]
• Fixed a crash on shutdown with virtual camera on Linux [kkartaltepe/norihiro]
• Fixed an issue in the V4L2 source on Linux where a capture device's frame rate could be invalid, resulting in incredibly large log files [9p4]
• Fixed the listing of PulseAudio monitoring devices incorrectly listing inputs [jp-bennett]
• Fixed the preview having the ability to scroll infinitely out of view when scaled manually [cg2121]
• Fixed the Async Filters list showing incompatible async filters for synchronous sources [gxalpha]
• Fixed an issue where the cursor would not properly disappear in certain games on Wayland [rmngr]
• Fixed an issue where certain filters would not properly update when clicking the Defaults button [gxalpha]
• Fixed an issue with FFmpeg NVENC producing invalid DTS when using b-frames [RytoEX/flaeri/derrod/tt2468]
• Fixed an issue where network sources in the Media Source could cause rendering/UI freezes when they reconnect [tt2468]
• Fixed AAC encoding of 2.1 audio [pkv]
• Fixed an issue where pressing Space would unexpectedly pause the active media source when the main window was focused [cg2121]
• Fixed an issue where duplicating scenes would lose colour coding on sources [cg2121]
• Browser dock Inspect will now remember settings and customizations [WizardCM]
• Fixed a case where HDR -> SDR might not tonemap correctly [jpark37]
• Fixed simple mode replay buffer maximum not being set [derrod]
• Fixed Windows-only RTMP options (e.g., Network Optimizations) causing issues if the profile was imported on non-Windows with those enabled [tytan652]
• Fixed security software status logs showing as blank when running on non-English locales [notr1ch]
• Fixed a bug where certain system localizations couldn't load Lua files on Windows [exeldro]
• Fixed Screen Capture crashing in the Flatpak with old versions of PipeWire server [tytan652]
• Fixed an issue where Push to Talk on Linux wouldn't work when assigned to secondary mouse buttons [KasinSparks]
• Fixed CBR padding when using NVENC AV1/HEVC [derrod]
• Fixed Auto Scene Switcher not saving settings correctly [PatTheMav]
• Fixed AMF encoder crashing when streaming by temporarily disabling dynamic bitrate when it is in use [derrod]
• Fixed recordings made with Apple VT Hardware encoders in CRF mode only having one initial keyframe [derrod]
• Various improvements and fixes to Decklink performance [jpark37]
• Fixed transparent windows capturing incorrectly on Wayland using PipeWire [asahilina]
• Fixed an issue with the source rotation handle when source is flipped [cg2121]
• Fixed a crash in Decklink Output when no Decklink device is available [jpark37]

OBS Studio 29.0.2

• Fixed a bug introduced in 29.0.1 which caused sources with an upward compressor filter to stop audio playback under certain circumstances [notr1ch/pkv]

OBS Studio 29.0.1

• Fixed the "NVIDIA AUDIO Effects SDK is outdated" message appearing on the noise reduction filter properties when the SDK wasn't installed [notr1ch]
• Fixed a crash that could happen if you use NVIDIA's audio effect filters and then later uninstall the SDK [pkv]
• Fixed the expander and upward compressor audio filters sounding distorted [pkv/norihiro]
• Added "Knee Width" option to the upward compressor audio filter to improve quality [pkv/norihiro]
• Fixed a bug where overriding the theme on Linux could cause the program not to start up [kkartaltepe]
• Fixed software rendering not working properly on Linux [columbarius]
• Fixed a bug where the Stats window/panel would show an incorrect disk space calculation when pausing recordings [notr1ch]
• Fixed a bug on Windows where the "Force SDR" setting in window capture wasn't showing up [jpark37]
• Fixed a bug on macOS where the virtual camera would show up red [PatTheMav]
• Fixed a bug where Linux captures would not work correctly on X11 [kkartaltepe]
• Fixed a crash on Linux when using Wayland and trying to use the automatic scene switcher [GeorgesStavracas]
• Fixed a bug where alpha wouldn't output properly when setting OBS to use BGRA color format [jpark37]
• Fixed a crash on startup when OBS was minimized [derrod]
• Fixed a bug where projectors could look washed out when projecting SDR content while using an HDR display [jpark37]
• Fixed a bug on Windows where secondary displays could sometimes not show up in the display capture properties [jpark37]
• Fixed a crash when using the virtual camera as an OBS source and changing the canvas resolution [notr1ch]
• Fixed a bug on macOS where the properties window would go behind the main window after opening a file selection dialog [gxalpha]
• Fixed a bug where profile encoder settings would not properly update when switching between services that require a different encoder [tytan652]
• Fixed a bug in custom ffmpeg output mode where RTMP would force certain encoders [flaeri]

OBS Studio 29.0

New Features and Additions

• Added support for the AMD AV1 Encoder for the RX7000 series GPUs on Windows [AMD/Lain]
• Added support for the Intel AV1 Encoder for Arc GPUs on Windows [Intel/Lain]
  • Note: CQP is available but not fully supported
• Added support for the Intel HEVC Encoder on Windows [yuriy-chumak/rcdrone/Lain]
• Added an upward compressor filter [pkv]
• Added a 3-band equalizer filter [Lain]
• Added support for native HEVC and ProRes encoders on macOS, including P010 and HDR [Developer-Ecosystem-Engineering/PatTheMav/gxalpha]
• Added support for macOS Desk View [Developer-Ecosystem-Engineering]
• Added update channels for opting into receiving beta/release-candidate builds to Windows [Rodney]
  • Work is still underway to get everything ready on the server side, updating via the built-in updater may not be available until later in the OBS 30.0 beta-testing period
• Websockets updated to 5.1.0, which has a number of bug fixes, UI improvements, and new stream reconnect events. [tt2468]

General Changes

• The Replay Buffer's memory limit is now set to 75% of installed system RAM rather than fixed to 8GB [Rodney]
• Added media key support in Linux [kkartaltepe]
• Various improvements to NVIDIA Video and Audio filters, including a Mask Refresh slider and support for temporal processing, which provides better quality masking [pkv]
• Improved Display Capture screen naming & saving on Windows; indexes should now match regardless of Mode, and reconnected displays should show the correct monitor [jpark37]
  • Note: This does mean existing Display Capture sources will be blank until manually configured, to avoid showing the wrong display
• Added support for encryption and authentication for SRT and RIST outputs [pkv]
• Disabled ScreenCaptureKit Display & App capture on macOS 12 due to various issues; users should either update to macOS 13 or use the existing Screen Capture source [PatTheMav]
• Removed the automatic numbering on Multiview labels [Warchamp7]
• Added the ability to mute individual browser docks [WizardCM]
• Added the ability to right click and 'Inspect' individual browser docks [WizardCM]
• Changed the default Simple Output NVENC preset to P5 for better compatibility & performance [RytoEX]
• Added support for higher refresh rates in the Video Capture Device source on Windows [WizardCM/EposVox]
• Added the Apple VT Hardware encoder to the Auto Configuration Wizard [gxalpha]
• Improved FFmpeg VA-API enablement by directly using Libva to check device capabilities [tytan652]
• Various minor UX/accessibility tweaks in the UI [Warchamp7/cg2121]
• Raised the speed at which dynamic bitrate recovers after a drop [Lain]
• Audio should now be automatically captured for most capture card brands using the Video Capture Device source on Windows [WizardCM/EposVox]
• Added a slide counter to the Source Toolbar when an Image Slide Show is selected [cg2121]

Bug Fixes

• Fixed issues with async filters (such as Delay) not rendering correctly [jpark37]
• Various performance improvements to Decklink preview output [jpark37]
• Fixed an issue where source Projector windows wouldn't close when a source was deleted [cg2121]
• Fixed an issue where cursors would disappear or display incorrectly on screen captures on Windows [caesay]
• Fixed issues with CQP rate control for SVT and AOM AV1 encoders [flaeri]
• Fixed an issue with CQP rate control for AMD HEVC and H264 [flaeri]
• Fixed Virtual Camera not working with Webex and GoToMeeting [Lain]
• Fixed capturing UHD/4K YUV on the AJA Kona HDMI [paulh-aja]
• Fixed a bug where slideshow sources wouldn't remove cleared files when removing missing files [gxalpha]
• Fixed slideshow counter on the source context toolbar showing "1/0" when empty, now shows "-/-" instead [cg2121]
• Fixed chroma location for VAAPI [jpark37]
• Fixed a case where macOS' VideoToolBox HEVC encoder would be parsed as AVC [jpark37]
• Allow SRT streams to disconnect after timeout [pkv]
• Fixed color space being incorrect for some video devices running in MJPEG video format on Windows [jpark37]
• Fixed monitor names in the Fullscreen Projector & Multiview menus on Windows [WizardCM]

While the release is a standalone plugin meant to be run with OBS Studio 27.2, we will be including version 5 with all downloads of OBS Studio starting with version 28.0.0. Including obs-websocket v5 by default will help drive adoption of the new protocol, and we expect it to benefit the third-party scripts and tools ecosystem long-term by bringing official support to the API that many of them depend on.

To install 5.0.1, check out the release available on GitHub. Please bear in mind that obs-websocket v5 uses a new protocol that not all tools support, so you may need to additionally install the 4.9.1-compat version to continue using those tools. For a list of software tools that already support the new protocol, see here.

Many existing tools will require the previous version of obs-websocket, 4.9.1-compat, in order to continue working until such time as those tools are updated. This version can be installed alongside v5 and will not conflict, and can safely be removed at a later date once any tools you may be using are updated to the new version. That version can be found alongside the download links for 5.0.1 on the release page.

We do have a Discord Server dedicated to obs-websocket where you can participate in discussions and get help for the plugin. If you'd like to contribute towards furthering obs-websocket development, we have a dedicated Open Collective page. Thank you to those who have faithfully contributed via Open Collective thus far!