Event live streaming: preparation, testing and operation

Assign responsibilities along the signal path

List cameras, presentations, videos and remote guests. Assign someone to each task: switching pictures, mixing audio, operating the encoder, and monitoring the platform and playback. Use the same names and numbers on the plan, inputs and crew communications so everyone requests the same signal.

For a remote participant, also prepare a return feed with the other participants' voices, presentation and stage. Check the audio so they do not hear their own voice as an echo. Rehearse a contribution, a question and a handoff between speakers before going live.

Use the table to plan the tasks each program requires. Camera counts, operators and destinations depend on what you want to show and on the tests; attendance alone does not determine the production system.

Test the link the audience will use

Choose where the stream will appear and how people will access it: public, private or restricted, depending on the platform and account. Check who administers the event, whether streaming is enabled, the schedule and the final link. Give the audience that viewing link, never the stream key.

Open it as a guest on a device outside the venue. Check permissions and playback, and prepare what viewers will see before the start, during a pause and after the event. Make the holding scene easy to select: it is useful if the stage is running late or a source needs recovery.

Maximum resolution, features and automatic archiving depend on the account and configuration. Check the documentation and test the configured event. For delivery afterward, follow the event recording guide.

Configure the encoder for the platform

Whether hardware or software, the encoder converts program into the stream accepted by the destination. Check inputs, resolution, frame rate, codec, bitrate, audio and protocol. Save the event profile and test it with every source active.

For H.264 ingest, YouTube's encoder table lists 14 Mb/s for 1080p30 and 17 Mb/s for 1080p60, with minimums of 5 and 6 Mb/s respectively. It specifies CBR and recommends a keyframe interval of 2 seconds, not exceeding 4 seconds. Recheck the settings before the show: these values apply to that destination and codec. YouTube: encoder settings.

Vimeo uses a different table: for 1080p30, it recommends 4000 kb/s or up to 5000 kb/s depending on the available upload bandwidth. Its guide limits 1080p60 to Enterprise accounts and lists a maximum recommended 9000 kb/s. If the platform changes, check the account and settings again. Vimeo: network and encoder configuration.

Listen at the receiving end

Prepare a streaming mix with speech, videos, presentations and remote guests. At a music event, the room contributes sounds the remote viewer cannot hear; you may need ambient microphones and a different balance. Identify the channels and who adjusts that mix.

Listen to the platform over an external connection. Test speech, applause, music and source changes. Adjust synchronization by checking the complete path: audio and video can arrive at different times even when they seem aligned inside the mixer.

For multiple languages, separate the original audio, interpretation, returns and destinations. Before adding sources, check what each mix contains to avoid doubling voices. See the simultaneous interpretation guide (Spanish guide).

Scenes and load: test the system under show conditions

The OBS wizard considers hardware and network conditions and provides a starting point. Then add sources, check audio devices and test recording or streaming. Until you rehearse the actual load, that setting does not establish what the computer can sustain. OBS: Quick Start Guide.

Prepare the opening, program, presentation, remote guest, pause and closing scenes you will use. Check proportions, names, lower thirds and space for captions. If there are multiple outputs, decide which share program and which need a different composition.

Run capture, videos, graphics, streaming and recording at the same time. Make changes and use movement similar to the event. A static scene can work while hiding a limit that appears when playing a video or covering a concert.

Prepare connectivity, local recording and recovery

Request the connection assigned to the encoder and a venue technical contact. Review sustained upload and the network using the event internet guide. Audio, protocol overhead and other tasks add to the video bitrate; a single speed test does not measure the complete path.

Test local recording alongside streaming and with the files you need to deliver. It may preserve material if the remote destination fails, provided the recording system itself keeps working. Check storage space, audio and copies separately.

Rehearse what happens if a camera, encoder or connection fails: what picture remains, who reports the problem and who restores service. A second device or connection helps when you have tested how to switch to it and what it needs. Keeping it nearby without testing the changeover leaves that part of the plan unfinished.

The full rehearsal and going live

Run a test with pictures, movement and audio similar to the event. Once live, monitor the platform's status and viewer playback: preview may represent a different stage of the process.

1. Prepare the destination and access

   Check the platform, account, event, viewer link, languages and who administers each part.

2. Test sources and mixes

   Go through cameras, presentations, videos and remote guests; listen to what each destination receives.

3. Prepare the encoder profile

   Apply the platform's current requirements and test resolution, frame rate, codec and bitrate.

4. Run the whole system

   Send a test with movement, audio, scene changes and local recording active.

5. Watch from outside the venue

   Open the link over another connection. Check access, picture, sound and synchronization.

6. Test recovery

   Rehearse the planned failures and changeovers using test material, including who operates them.

7. Monitor the stream and its ending

   Assign status and playback monitoring. At the end, check that the stream has closed and that the agreed archive is available.

What to tell us when planning the stream

Send the date, schedule, venue, program, platform and access requirements. Include cameras, videos, remote guests, languages and recording. Describe the available connection and who manages the network. If there is an audience in the room, also identify who handles remote questions.

The proposal should address program, audio, encoder, connectivity, operation, monitoring and testing. Define recording and delivery. Confirm available models with the provider, and have the administrator review the permissions and features of the account that will stream the event.

OBS drops network frames: compare connection and system load

If OBS drops frames while sending, compare the local recording with platform playback. Record the OBS indicators and the time of the fault: this helps direct connection and load tests without changing several settings at once.

Compare IPv4 Only when the connection fails

If the local recording is good but network frames are dropped during transmission, record the ingest server, time, bitrate and result. Save the log and the remote viewer's observations. A speed test uses a different connection; it does not establish that the route to the server can sustain the event. Start by comparing a conservative bitrate and note whether failure occurs immediately or later.

OBS suggests testing Settings → Advanced → Network → IP Family → IPv4 Only. Save the previous value and repeat the scene and destination for comparison. If it does not help, the guide recommends returning to the default IPv4/IPv6 setting.

During rehearsal, monitor over another connection for the planned duration and assign responsibility for the return feed and backup changeover. Increasing bitrate while frames are already being dropped does not fix the fault.

The test and how to reverse it are described in OBS: Stream Connection Troubleshooting, IP Family.

OBS: rehearse for the planned program duration

Build a rehearsal with cameras, guests, videos, graphics and recording as they will be used at the event. Check the local file, OBS indicators and remote playback; note the time of each loss and what the system was doing. A short test can pass without exposing a problem that appears during a long program.

OBS documents H.264 streaming through VideoToolbox on Apple Silicon. Compare that encoder with x264 using the same computer, sources and load. Record changes in playback and logs; changing several parameters together makes it harder to tell which affected the result.

Save a working profile and change one variable per comparison. If you test dynamic bitrate, also inspect quality: it reduces the outgoing rate under congestion without fixing the cause. Extend rehearsal to the planned duration, including changes and actual guests, and define when to switch to backup.

The features and limits are described in OBS: Apple VideoToolbox and OBS: dynamic bitrate and dropped frames.

Test holding graphics when sending SRT

If the show opens with a still graphic, keep it on screen during rehearsal and observe the receiver. Then alternate with a camera and movement to see whether the defect follows one kind of content or persists throughout the stream.

The vMix 29 manual suggests at least four times the ping as a starting point. Haivision limits that guidance to networks with low loss and no significant bursts. Measure the path while sending and test the receiver with the show scenes; the calculation alone does not explain a fault or guarantee a clean picture.

If the issue is stuttering or a setting that seems not to apply, follow the comparison of Latency and Decoder Delay. Record transport, reception and the file separately.

1. Compare still and moving content

   Alternate holding graphics, camera pictures and cuts during rehearsal. In Statistics, monitor SRT RTT and loss and note when the defect appears. This lets you compare the picture with transport conditions.

2. Allow time for recovery

   Coordinate Latency with the receiver operator and repeat the test while changing one variable. If both ends use vMix, its guide requires the same value. More recovery time adds delay; check whether it suits the event's conversation.

3. Check how the holding graphic is sent

   If your version offers CBR and the receiver needs a constant rate, test it separately. In vMix 29, this option pads the SRT stream when it falls below the target rate, for example during a still graphic. The guide warns of approximately 10% higher total bitrate; measure the outgoing stream and watch the return to see whether it helps your path.

A remote guest hears an echo: trace their audio return

If a remote guest hears repeated voices while the room sounds normal, draw two paths: what you send to Zoom and what you receive from Zoom for the speakers. Include support laptops. If they are only needed for viewing or sharing, disconnect them from meeting audio: muting their microphones leaves their speakers active.

Test one room microphone first, then one remote voice. Listen over another connection and open the other channels one at a time. When the echo returns, trace that path. This distinguishes a return sent back into Zoom from a speaker being picked up by a microphone.

Prepare a feed for the remote guest containing the in-room voices and planned content while excluding their own return: that is mix-minus. On a Qu-16, select that Mix and check that the return channel is unassigned. If the send is pre-fader, lowering its LR fader can leave the return active in that Mix. The AP10025 guide for V1.9 explains assignment; keep the remote voice in the room mix where it is needed.

If you use the original Roland VR-50HD over USB, check System → USB Streaming → Audio Bus: it supports MAIN or AUX. Selecting AUX is not enough; check its sends and the microphone device selected in Zoom. Finish by testing questions in both directions.

See the tests for echo in Zoom, the Qu V1.9 routing guide, pages 11 and 15 and the VR-50HD USB bus guide, page 11.

In OBS, a visible source may still be waiting in Preview

In OBS 32.1.0, the mixer can show audio from the scene being prepared in Preview. If a source carries that label, check which scene is in Program before changing the device. Seeing a channel on screen does not mean that voice or video is already live.

Compare off air: leave a test scene in Program and prepare another with a known video. Use Transition to take it to program, listen and check its audio state. Then return to the previous scene. Rehearse the change using the graphics, videos and microphones planned for the event.

Check mute, volume and monitoring separately. The Monitor button plays through the local device selected in Settings; hearing audio there does not confirm what the platform receives. Also open the viewer link and check the sound after the transition.

If you updated OBS, record the version and review the mixer during rehearsal: 32.1 also allows channels to be pinned and sources from other scenes to be shown. See the 32.1.0 release notes, the Studio Mode workflow and the audio guide. If a source remains silent in Program, save the log and note the failing source, scene and output device.

A microphone appears twice: check global and scene capture

If a voice sounds doubled or louder than expected, check which devices feed each OBS audio source. Similar names may refer to the same microphone or to different devices. Open their properties before deciding which to mute.

The OBS Audio Sources guide warns that capturing the same device in Settings > Audio and through Audio Input Capture in a scene can cause echo. These names apply to Windows and macOS; the guide describes ALSA/PulseAudio sources for Linux.

Choose the intended workflow: a global microphone available across scene changes, or scene capture to control where it is heard. For the second option, disable that same device in global settings. Prepare the change off air and check the speech, holding and video scenes.

Speak, mute each path separately and listen to a test recording; then check the platform return. The voice should arrive once and disappear where the program requires it. If echo remains, inspect the other paths too: removing this duplication does not prove that all audio is correct.

Define how each clip starts and ends in OBS

Before the stream, decide what should happen when you return to a scene: should the clip restart or continue another way? Open its Media Source properties and check Restart playback when source becomes active. OBS documents a restart when the source is in the current scene and visible.

Check Close file when inactive separately. Enabling it frees the file's memory while the source is hidden or outside the current scene. On return, there may be a blank interval during reload. Test that delay with the opening file and your usual transition.

Also review the ending: Loop repeats the file, while Show nothing when playback ends prevents its final frame from remaining visible indefinitely. Choose the behavior required by the running order. Then record a test entering, leaving and returning to the clip; check its start, ending and audio. Record the settings alongside the filename so another operator knows how it should play.

If the problem returns with the scene collection, test sources and filters separately

If OBS performs better with a simple scene collection but stalls after the show collection is imported, preserve both for comparison. Note the scene, time and source active when the fault occurred. The difference guides the review; it does not yet identify a particular filter as the cause.

The OBS performance guide explains that scene composition uses GPU resources. It recommends simplifying sources, reducing Browser Sources and comparing behavior with filters disabled. It also warns that many sources consume resources even when invisible: hiding an element does not prove it has stopped loading the system.

Create a working copy and a short test with a known camera and audio source. Add the presentation, graphics and video one at a time. When stuttering returns, repeat that step and compare its filters separately. Keep a sample and a record of each comparison.

Before approving the reduced collection, run through the complete program: transitions, videos, guests and simultaneous recording. Also check playback over another connection. If a show function is missing, restore it and repeat rehearsal before using that collection.

Audio is out of sync: measure whether the difference changes

Before entering a delay value, record a visible and audible reference, such as a hand clap, near the beginning and later in rehearsal. Compare the picture's timing with the audio peak and note whether the separation stays constant or changes.

In OBS 32.1.0, Sync Offset applies a per-source offset in milliseconds. If audio leads by a stable amount, test a measured compensation and review another recording. A fixed value does not by itself correct separation that changes during the stream.

Compare the local file, platform reception and monitoring headphones separately. The OBS guide defines Monitor as listening to the source through the configured device; you also need to check what the audience receives.

If the mismatch returns after noise or a dropout, note when it happened and repeat checks along individual sections of the path. Save that sample with the settings used to continue diagnosis.

Select the camera and microphone separately in Zoom

If Zoom receives OBS video but voices are missing, check the audio input selected in Zoom. The OBS meters do not verify what the meeting receives.

In OBS 32.1 for Windows, Virtual Camera carries video. In its gear menu, select Program to send the show output; Preview shows preparation changes in Studio Mode.

In Zoom, open Settings → Audio and select the intended microphone. Use Test microphone and listen to playback. Then ask someone connected from outside the room to check each voice and the videos' audio. Record which device carries that mix.

On Twitch, listen to both the live stream and the replay

If the live stream contains voices and videos but the replay loses a source, check the mix sent to each destination. The replay may receive different audio.

With Twitch VOD Track enabled, OBS can send a separate mix to Twitch's archive. Its guide uses track 1 for live and track 2 for VOD by default. In Advanced Audio Properties, check which sources are assigned to each.

Test speech, video and another source separately. Listen to the live stream from a second device and check the replay afterward. If something is missing, compare assignments before adding another capture of the same device.

Streaming brief: audience, materials and responsibilities

Record which sessions will be streamed, their intended audience and how viewers will receive the link. Include languages and the requested availability afterward. Separate decisions already made from those still open.

List the presentations, videos, names and graphics that must be received. Assign a contact and delivery date to each item. Identify who approves what the audience will see.

Define who administers the account, shares the link and authorizes the start and end of the stream. If the platform is still undecided, identify who makes that decision and when it is needed.

ATEM Mini Pro: keep the voice audible when switching pictures

The ATEM Mini manual distinguishes ON, which keeps audio enabled, from AFV, which makes it audible when its source is on air.

Test speech in ON while alternating cameras and slides; use AFV for clips that should be heard only with their picture. Listen to program and the return to the speaker.

ATEM Mini Pro: set the production standard before loading graphics

On an ATEM Mini Pro, check the production standard before preparing still graphics. The June 2026 ATEM Mini manual states that automatic mode takes it from the first connected HDMI source. Compatible inputs are converted to the selected standard.

Changing the standard clears still images from the media pool. Set the format, load the graphics and test the outputs used by the recorder and encoder before considering the show ready.

Makito X4: check which audio channels you are encoding

The Makito X4 Encoder 1.8 guide distinguishes Input Interface, Input Channels and Channel Mode. Channel Mode also changes the range of channels processed: choosing Stereo or Mono is not enough.

During the conference rehearsal, identify the SDI input and speech or interpretation channels. Test the planned speech and interpretation signals separately, listen at the receiver and record the expected content.

P300: check the signal used for echo cancellation

If the system uses a P300, trace remote audio to the speakers. In the USB example with an analog output, select Analog - To Speaker as the AEC reference in Schematic; for Dante speakers, select the corresponding Dante output.

Check Reference Meter while the remote guest speaks, without clipping, and listen to a test call. The 8.4 guide states that choosing the reference in one AEC block changes the reference for all blocks.

ATEM Mini Pro: separate Zoom from the HDMI output

The ATEM Mini Pro provides program as a webcam over USB-C. The June 2026 manual separates that Zoom path from VIDEO OUT, which selects the HDMI source.

To display program on an LED screen over HDMI, choose PGM. M/V is the initial selection and shows several sources together. Record the destination of that single HDMI output before rehearsal.

vMix 29: transfer preset media to the backup computer

Save As stores the preset in a different file. To include media, open its arrow and choose Save As Bundle: the .vmixZip contains much of the material, including video, audio and titles. It excludes replay files.

Copy it to the backup computer and rehearse playback. Check devices, local settings, audio and outputs on that computer. vMix: Preset Bundles.

vMix 29: locate dropped frames

In Statistics, check each input. Source Dropped indicates losses caused by slow camera or capture hardware; Renderer Dropped indicates losses associated with slow graphics processing. Encoders lists streams and recordings; Codec identifies CPU or GPU encoding. Save the readings and the time of the interruption.

ATEM Mini Pro: analog audio delay

In ATEM Software Control, open the delay indicator below Input Level for Mic1/Mic2. The manual adjusts it in frames; the ATEM Mini Pro specifications list up to 8 frames.

vMix 29: adjust an audio input's delay

In Audio Mixer, open the input's gear menu: General → Delay delays that source in milliseconds. If several cameras share the same voice, check every camera cut.

Receiving multilingual SRT: identify channels before mixing

SRT Input in vMix 29 combines received pairs into a multichannel stream controlled through the matrix and mixer. In Channel Matrix, columns are source channels and rows are destinations. Its three-pair example assigns 1–2 to Master/Headphones, 3–4 to A and 5–6 to B.

That example does not identify your languages. Send distinct phrases on each pair, listen separately and record channel, bus and content in the worksheet. Check the destination with the camera and streaming team. Also review the output tracks (Spanish guide).

Nimble receives several audio tracks, but only one reaches HLS

The WMSPanel reference allows audio for an MPEGTS output to be selected by PID. If omitted, it uses the first audio; with PID zero, it uses index. Check the effective selection before changing the sender.

Send a distinct phrase in each language. Listen at the input, outputs and final HLS destination; use the worksheet to record where the second audio disappears. Record the build and preserve the configuration so it can be restored.

Then review the HLS labels (Spanish guide). Coordinate rehearsal with the camera and streaming team.

The video starts with the wrong audio for a few seconds

If the menu displays one language but another is heard at startup, record the selected option and the first phrase played separately. Repeat startup before changing player settings.

In the hls.js v1.7.3 API, audioPreference looks for the best-matching track at startup. Without that preference, the player selects a default track. Record the version before comparing behavior.

Listen from the first instant, repeat startup and record the opening phrase in the worksheet. Compare the configured preference with the actual content. Also test switching audio tracks and switching back.

For multiple languages, share the track identities (Spanish guide) and startup record with the person responsible for cameras and streaming.

AirPlay sends audio, but the picture stays on the iPad

WebKit explains that an MSE/MMS blob is not a playable address outside the browser. Its example adds an alternative HLS URL that Safari can pass to AirPlay. Identify the path in use: native HLS or JavaScript with MSE/MMS.

Compare local playback, sending and returning on the intended receiver. Record the picture and phrase heard in the worksheet. Ask the player administrator to review its sources before modifying it, and save the previous configuration.

For multiple languages, check the selected audio (Spanish guide). Coordinate with the camera and streaming team.

The selector requests a track ID but plays another language

Compare ID, index and language in the current track list. If the selector returns different audio, check which track matches the requested identifier and listen to its content.

The HTML standard specifies that AudioTrack.id is read-only. getTrackById returns the first match, or null if none matches. Indexes may change when tracks are added or removed.

Record every track and its enabled state in the worksheet. If duplicate IDs appear, ask for the player selection to be reviewed; listen to the selected language and repeat after reloading.

If the language heard does not match, give the manifest (Spanish guide) and track list to the person responsible for cameras and streaming to continue the review.

vMix 29: an SRT input stutters—which setting should you compare?

Before increasing a buffer, identify the fault: stuttering pictures, audio dropouts, a mismatch between voice and picture, or excessive return delay. Record the sender, vMix version, codec, resolution, frame rate, Latency and Decoder Delay. Save a sample with movement and a recognizable voice.

The vMix 29 SRT Input manual distinguishes Latency, which provides transport recovery time, from Decoder Delay, which compensates for uneven frame arrival or audio and video sent at different times by the encoder. Its example of 150 ms for frames arriving 100 ms apart illustrates the function; it is not a setting for every sender. Also check SRT Technical/System Requirements: vMix 29 supports progressive formats, H.264 or HEVC, and AAC-LC audio in a Transport Stream.

Compare the same input and content off air for the same duration. In Statistics, save RTT, loss and SRT data at the start and end. Also inspect the Video and Audio timing values available for that input. One counter alone does not identify an encoder, network or GPU fault.

If RTT or loss changes when the defect appears, investigate transport and coordinate a Latency comparison with the other end. If you suspect irregular delivery from the encoder, compare Decoder Delay while keeping Latency, format and load unchanged. In both cases, observe smoothness, synchronization and return delay; change one variable per attempt and restore the previous setting if the result worsens.

Complete the comparison worksheet with both samples and your observations. Smooth input during one part of a test does not prove the entire program: afterward, rehearse cameras, graphics, remote guests and recording together. Compare the file with the MultiCorder SRT guidance and coordinate the camera and streaming path.

Decoder Delay resets to zero or leaves the return unchanged: separate the symptoms

First check whether Decoder Delay loses its value or keeps it without producing the expected change in the return. Record the field and picture separately to distinguish those symptoms.

In a rehearsal configuration, record the value before the change and the value shown after reopening the input. If it returns to zero, record exactly when: closing the window, reconnecting or loading a preset. If the value stays but the return looks unchanged, record that result instead. These are different observations and need separate records.

Use Save As to save the rehearsal in a separate file: Save overwrites the open preset. Load that copy off air and inspect the value again. This checks whether the setting persists; if it resets, preserve the sequence and preset for further diagnosis.

For the picture test, follow camera → Nimble → SRT input → output → monitoring screen. The vMix 29 manual describes Decoder Delay as compensation for irregular arrival; it does not promise a visible shift identical to the number entered. Compare against a visible and audible reference and record the measurement point. Do not treat the field value as a measurement of total delay.

If the difference persists, keep versions, field screenshots, rehearsal preset, settings and samples for support without sharing connection keys. The worksheet includes space for the requested value, the value after reopening and the return result. Review the synchronization checkpoints and the camera and streaming service to prepare the comparison.

Latency at both ends: vMix instructions and the negotiated SRT value

To prepare a vMix 29 connection, its SRT Input manual, Latency section requires the same value at both ends. Coordinate with the other equipment operator and record the units: the vMix field is in milliseconds. Do not lower only one end expecting an equal reduction in return delay.

Haivision explains in SRT 1.5.4, Latency that the higher value is used. The API documentation for that version defines the scope more precisely: with timestamp-based delivery (TSBPD) enabled, negotiated receive latency is the maximum of the local receive value and the sender's requested minimum. Negotiation occurs when the connection is established. This describes the SRT library; it does not establish which version the application contains.

Caller and Listener describe how the connection is established. For this comparison, also record who sends video and who receives it. In versions that allow bidirectional transmission, each direction needs its own check; saying that Caller or Listener takes precedence is not enough.

Calculated example for that mechanism: if the receiver requests 120 ms and the sender sets a minimum of 250 ms, the negotiated receive buffer is 250 ms. This calculation excludes capture, encoding, decoding, mixing and display; it is not a camera-to-screen measurement.

For the proposed rehearsal, record values and versions on both devices. If the tool exposes negotiated latency, record it after connecting; otherwise mark it unavailable. Coordinate any reconnection off air and check smoothness, audio and the delay of the complete path.

Use the worksheet together with the network counters. The protocol example does not replace the settings prescribed by each application. When planning cameras and streaming, also explain how much delay the remote participant can tolerate in conversation.