If Restreamer audio works but video is black on YouTube, treat audio and video as separate signal paths: sound reaching the viewer does not prove that video is being received, encoded or published correctly. Check the source and Restreamer’s local playback first, then follow the picture through encoding and YouTube’s live dashboard.
There is no reliable universal fix without knowing your Restreamer version, source, settings and stream-health messages. The useful question is where the moving picture disappears. Work through the checkpoints below and record what you see before changing settings.
Why audio can work while video is black
A live broadcast carries audio and video as distinct media streams. An encoder or relay may handle the audio track successfully while the video track is absent, unreadable, misconfigured or not accepted downstream. YouTube’s live encoder guidance specifies its requirements for audio and video separately. Hearing sound is therefore not a test of whether YouTube is receiving decodable picture frames.
Think of the route in stages: the camera or file supplies video; Restreamer receives and processes it; a player may show its output; and the publication connection delivers it to YouTube. Audio can pass through those stages even if the picture fails at one of them. Restreamer’s troubleshooting guide likewise breaks investigation into areas such as video input, player streaming and publication service, rather than treating a live audio signal as proof that all parts work.
Start by noting the first checkpoint where the image is black. If you can see movement in the source’s own preview but not in Restreamer’s player, investigate the input or Restreamer processing path. If Restreamer displays video but YouTube does not, concentrate on the selected destination, publishing configuration and YouTube’s stream-health feedback. This narrows the investigation; it does not, by itself, establish a cause.
Before testing, write down the Restreamer version, source type, destination protocol, and any encoder settings. Save the current configuration or take screenshots. Change one setting at a time so that a test result can tell you something. For a general explanation of what happens when video is passed through versus encoded again, see copy mode and re-encoding.
Check whether the source contains video
Begin before Restreamer. Confirm that the selected source actually supplies a video stream, not just audio. With a camera, check its own preview and make sure the intended camera or capture device is selected. With an incoming RTMP, SRT, HLS or RTSP feed, check the source player or sender’s status and whether its picture is moving. With a file, open the exact file you are using and check that it contains video as well as sound.
This matters with mixed playlists, scheduled files and remote feeds: a source may be valid for audio while a particular item or input has no picture. A camera can also be connected but not sending usable frames, or a sender can be publishing a different profile or stream than expected. Do not assume the source is healthy because another device or an earlier test showed an image.
Restreamer supports different input families, so the right check depends on how yours is configured. Note the precise source type and, where relevant, the device name or input URL. If another encoder such as OBS feeds Restreamer, check that encoder’s preview before changing Restreamer. The comparison in OBS versus FFmpeg for a 24/7 YouTube stream can help you identify which part of that kind of workflow you are testing.
Where possible, keep the source constant while checking downstream stages. If the source itself has no picture, there is little value in changing YouTube settings yet. If it does have a clear moving picture, note that as evidence and continue to Restreamer’s local view.
Test local Restreamer playback
Open the Restreamer player or local test view, if it is available in your setup, and check for moving video. Distinguish a frozen frame from a black screen, and allow time for the player to load before judging it. Record whether the sound is audible there too, but assess picture and sound independently.
Datarhei’s current Basic Troubleshooting guide recommends testing with a virtual source as an initial procedure and reviewing logs if the issue remains. A virtual-source or test transmission is useful because it gives you a comparison that does not depend on your production camera or incoming feed. Follow the steps for your installed version; interfaces and labels can differ.
If the test source shows video but the production source does not, the evidence points you back towards the production input, its selected profile, codec or connection. If both are black in the local view, keep investigating the Restreamer processing and player path. These outcomes help choose the next check; neither is a definitive diagnosis without the corresponding configuration and logs.
If local Restreamer playback shows a picture but YouTube is black, avoid changing the camera or source codec first. The video has reached at least the local playback checkpoint. Move on to the external publication path and compare what YouTube reports. If you are also trying to distinguish audio timing from missing picture, the separate guide to fixing audio delay on a YouTube radio stream covers a different symptom; a black image needs its own video checks.
Inspect video input and encoding
Check what video codec Restreamer receives and what it is set to send. In pass-through or “copy” mode, the source video is forwarded without being re-encoded. Datarhei’s older encoding guide describes copy as its default video codec setting for the version covered, and explains that choosing H.264 forces video encoding. That guide concerns older, version-specific behaviour, so confirm your installed version and current interface before relying on its labels or defaults.
The key diagnostic question is whether the incoming video can be passed through to the configured destination. If the source codec or format is not compatible with the path you are using, a controlled encoding test may help isolate the issue. H.264 is an available compatibility option to consider, not a guaranteed remedy for every black picture. Record the original setting, change only the video mode, and test again. If the picture does not change, restore the setting before trying another branch.
Re-encoding has a cost: it uses processing capacity that pass-through may not need. If you are running your own host or encoder, check resource use and the process logs while testing. A CPU bottleneck or processing error may affect video even when audio continues. Do not infer that more powerful hardware is required from the symptom alone; first establish whether the source, local player or publication stage is where video disappears.
For YouTube ingestion, use its current requirements as the reference rather than copying a bitrate or codec value from an unrelated setup. The official encoder page lists H.264, H.265 and AV1 video for live ingestion and describes settings including CBR and keyframe intervals. It recommends a two-second keyframe interval and says not to exceed four seconds. Its bitrate guidance depends on codec, resolution and frame rate, so select the applicable row for your actual output instead of applying one number to every stream.
If OBS is the encoder feeding Restreamer, distinguish OBS-to-Restreamer settings from Restreamer-to-YouTube settings. Restream’s OBS setup guidance recommends settings for that connection path, including CBR, a two-second keyframe interval, Main profile, NV12 and 709. Those recommendations are specific to the documented OBS workflow; they are not universal requirements for every datarhei Restreamer input. Use the OBS Analyzer where applicable to review the OBS output, connection and stream-health findings.
Check the YouTube publishing path
When Restreamer’s local view has video but YouTube remains black, confirm that Restreamer is publishing to the intended YouTube event and destination. Check the selected RTMP or RTMPS endpoint and verify that the current stream key belongs to that event. A valid key or an audible broadcast does not prove that the video is reaching the intended event correctly. For help locating the right event details, use the guide to finding YouTube’s RTMP URL and stream key.
Open YouTube Studio’s Live Control Room and look at the incoming preview, stream health and any messages shown during the test. Compare the time at which Restreamer’s local player has a picture with what YouTube displays. If YouTube reports a video-format or ingestion problem, capture the exact wording and compare your output with the current YouTube requirements. If there is no clear message, preserve the uncertainty and continue collecting evidence rather than assuming the key, codec or network is at fault.
Check that the test is tied to the intended live event and that the destination details have not been copied from another event. If you edit a URL, key or encoder profile, note the old value privately and avoid sharing stream keys in support requests or screenshots. A key is a credential; redact it before sending logs or images to anyone.
Review stream-health messages and logs
Use the messages as evidence, not as a substitute for checking the path. Record the exact text from YouTube’s stream health and Restreamer’s process details, along with the time it appeared. A message about missing or unstable video is more useful than a general note that the stream is live, but it still needs to be interpreted alongside the source and local-player checks.
Datarhei’s troubleshooting documentation recommends reviewing logs and attaching a process report when seeking help. Look for errors related to the selected input, video processing or publication around the time of the test. Do not paste a whole log publicly without checking for secrets such as stream keys, private URLs or account information. Keep an unredacted copy for your own diagnosis and make a redacted copy for sharing.
If you are operating an FFmpeg-based sender or a VPS as part of the input chain, monitor the encoder and connection at the same time as the Restreamer and YouTube checkpoints. The guide to monitoring an FFmpeg YouTube stream on a VPS is relevant when that is your setup, not a generic instruction to add a VPS to every Restreamer workflow. Keep the scope clear: one process’s healthy status does not establish that the next stage is publishing picture.
What to gather if the picture remains black
If the checks do not isolate the failure, prepare a concise report rather than changing several settings at once. Include the Restreamer version; source type and a redacted source description; whether OBS or another encoder is involved; the incoming and outgoing video codec settings; the destination protocol; and whether the local Restreamer player showed moving video. Add the time of a test and the exact YouTube stream-health text or messages.
Attach a process report and relevant log excerpt if requested by the support channel you use. Include the result of the virtual-source test: whether it produced local video, whether the production source produced local video, and what YouTube showed in each case. That comparison helps someone see whether the evidence points towards source input, local processing/player streaming or publication. It does not justify a root-cause claim without the setup and corresponding details.
Describe what you changed and what happened after each change. For example: “The camera preview was moving; Restreamer local playback was black; a virtual-source test showed video; I have not changed the destination settings.” This is more actionable than “audio works, video does not” because it identifies checkpoints and preserves the distinction between observation and diagnosis.
For a channel built around a fixed video file rather than a live camera or incoming feed, keep a known-good copy of the source and test that exact file before changing the broadcast path. StreamNeo can remove the need to keep your own computer running for a file-based YouTube broadcast, but it will not diagnose a camera, encoder or Restreamer source failure; establish that the file and destination are ready first.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
Why does Restreamer audio work when the YouTube video is black?
Audio and video are separate parts of a broadcast, and success in one path does not prove success in the other. Check whether video is present at the source, visible in Restreamer’s local player and accepted at YouTube before deciding which stage needs attention.
Should I change the video codec to H.264?
Not automatically. Restreamer’s older encoding guide describes H.264 encoding as an option, but the right test depends on your version, incoming codec and destination. Record the current setting, check resource use, and try a controlled change only when the evidence points towards compatibility or encoding.
What if the local Restreamer player shows video but YouTube does not?
Check the selected YouTube event, destination URL and stream key, then review YouTube’s Live Control Room preview, stream health and messages. Capture the exact message and compare the outgoing video settings with YouTube’s current encoder requirements; do not assume the key is the cause merely because it is part of the publishing path.
What should I send when asking for help?
Provide the Restreamer version, source and encoder details, relevant video settings, a redacted process report or log excerpt, and the time of a test. State whether the production source and virtual source showed video locally, and include YouTube’s exact stream-health wording. Keep stream keys and private URLs out of anything you share.