OBS Studio is a production and encoding application. It combines sources into scenes, mixes audio, records locally, and sends an encoded output toward another system. It is not the audience destination, CDN, account system, or viewer player.
Use this map to understand OBS, not to configure a show
This page explains responsibility boundaries. Build a first working production with the OBS tutorial. Detailed output settings, recording presets, RTMP, SRT, plugins, and destination interfaces require their own procedures. One OBS setup cannot be promised to fit every computer, source, network, or service.
Scenes are saved compositions
A scene tells OBS which visual and audio sources should be active and how they are arranged. A production might have a camera scene, a screen-share scene, a holding slate, and an ending card. Switching scenes changes the composition; it does not move media through a CDN or create a viewer account.
Sources bring material into a scene
Sources can include a display, application window, camera, media file, image, browser surface, text, or audio device. Availability and capture behavior vary by operating system and source type, so current project documentation matters. The official OBS Studio overview is the reference point for the application’s main areas.
Each source has a local responsibility: capture the intended material, use the correct device, maintain expected dimensions, and avoid exposing private content. Whether the audience later receives that material belongs to the downstream path.
Composition layer
Scenes, source ordering, transforms, cropping, filters, transitions, and Studio Mode determine what the programme looks like before encoding.
Audio layer
Device selection, mixer levels, monitoring, filters, sync observations, and track routing determine what OBS captures and places into its outputs.
Output layer
Encoder choice, recording container, stream service fields, reconnect behavior, and the application’s local statistics shape what OBS produces.
Settings and observations OBS owns locally
Visibility, dimensions, capture state, device errors, render timing.
Meter activity, clipping, monitoring, track assignment, sync at local output.
Encoder load, skipped frames, output bitrate observation, recording state, reconnect attempts.
These observations are valuable because they describe the sender. They should be joined with destination ingest logs, delivery telemetry, and player behavior before drawing an end-to-end conclusion. A green local status cannot prove public playback; a viewer error cannot prove OBS caused it.
Profiles and scene collections store different things
A profile groups output-related settings, while a scene collection stores scenes and sources. Teams often need both named deliberately—for example, one collection for a programme and separate profiles for rehearsal and approved output. Export or back them up according to the current OBS workflow, then test restoration on a non-critical machine. Avoid treating the two menus as interchangeable backups.
Device names can change when a camera, interface, driver, or USB connection changes. After restoration, inspect every source and audio device instead of assuming the saved label reconnected to the same hardware. Record missing fonts, browser-source dependencies, media paths, plugins, and credentials separately; the collection alone may not contain everything needed to reproduce a production.
Recording and streaming share a programme, not every setting
OBS can record and stream at the same time, but those outputs may have different requirements. Local recording can preserve quality for editing, while a streaming destination constrains codecs, packaging, authentication, and network behavior. Use OBS recording settings for the file job and OBS streaming for output planning. Keep the two results distinct when troubleshooting.
Where OBS hands off the stream
When streaming starts, OBS encodes media and connects to a selected destination. An RTMP endpoint may be one kind of receiver; the RTMP server guide explains that server role. An SRT listener is another possible boundary; the SRT server guide covers it. After ingest, routing, transcoding, packaging, access, distribution, playback, and audience measurement belong to the chosen system.
Callaba can be one possible ingest destination after OBS output. That does not make Callaba a replacement for OBS, and it does not make OBS responsible for all later delivery stages.
Monitoring needs observations on both sides
On the OBS side, keep render and encode timing, dropped-frame counters, connection state, reconnect events, and the session log. On the receiving side, keep arrival time, format recognition, continuity, processing state, and a viewer probe. Align clocks and capture the moment of a planned scene change so the two records can be compared without guessing which event came first.
Where OBS responsibility ends when output fails
A viewer reports black video while the OBS preview moves. First create a short local recording from the same programme. If the recording is black, inspect the source and render path locally. If it is correct, check OBS output status and destination receipt. If ingest is healthy, continue through processing, access, delivery, and the player. The first boundary where the picture changes is more useful than restarting every component.
Choose the next guide by job
- Need a first scene, audio check, local recording, private output, and recovery rehearsal? Follow the OBS tutorial.
- Need a durable local master? Work through the recording-settings page.
- Need to understand a destination protocol? Move to its RTMP or SRT server guide.
- Need viewer playback or distribution? Diagnose the downstream product rather than searching for another OBS scene setting.
That division also clarifies support requests. Attach OBS observations when the sender misbehaves, destination observations when receipt fails, and player observations when delivery reaches the audience incorrectly.
