If you see 直播? while streaming to YouTube with FFmpeg, that fragment alone does not identify a particular YouTube or FFmpeg error. Compare the complete FFmpeg stderr output with the timestamped message in YouTube Live Control Room before changing settings.
First, save the exact output and note when the failure occurred: before connecting, during startup, or after the stream had been running. Redact credentials before sharing logs, especially the stream key. The wording in the question is not enough to establish a cause or prescribe a fix.
What 直播? does and does not tell you
The characters 直播? are an ambiguous fragment, not a diagnosis. The available information does not establish that they are a YouTube error code, a standard FFmpeg message, or a reliable translation of a particular status. Do not choose a repair based on those characters alone.
Searches for “FFmpeg YouTube Live error”, “FFmpeg RTMP stream key error” or “YouTube Live encoder error” can help you find relevant troubleshooting material, but those phrases describe broad problem areas rather than evidence about your own stream. A failed login, incompatible settings, overloaded encoder and unstable upload can look similar from the outside, while their useful clues appear in different places.
Your goal is to match evidence from the time of the problem. FFmpeg reports what its process could see: for example, whether it reached a connection stage, whether an input failed to open, or whether it printed an error while sending output. Live Control Room reports YouTube’s view of the incoming stream and may attach a health message to a time. Neither view necessarily explains the other by itself.
Do not repeatedly alter bitrate, codec, URL and key at once. If the next attempt works, you will not know which change mattered; if it fails, you will have made the evidence harder to interpret. Keep an untouched copy of the original log and make one targeted change at a time.
Capture the complete FFmpeg error and its time
Capture standard error (stderr), not only the last line in a terminal. FFmpeg often prints useful context before a final failure summary: input details, output mapping, connection messages, stream metadata and warnings. Copy from the command’s start through its exit, preserving line order. A screenshot or a single clipped line can omit the reason that appeared earlier.
Record the local date and time, including your time zone, and describe the point in the run when the problem appeared. Was the process unable to start, did it stop while connecting, or did the stream run and then stall or exit? If you run FFmpeg under a service manager or a script, capture that process’s logs too, but keep the FFmpeg output distinct from wrapper messages.
A basic shell capture can save both normal output and errors to a file:
ffmpeg [your existing input and output options] 2> ffmpeg-stderr.log
This is only a logging example, not a complete streaming command. The options still need to match your source and YouTube’s current ingestion requirements. Check the saved file before sending it anywhere; commands and logs may expose credentials even if you have not pasted them deliberately.
If the process runs continuously, keep a small record of the last known-good time, the first visible problem, whether FFmpeg restarted, and whether the YouTube preview or health status changed. A local clock and Control Room timestamps may differ, so record their time zones and compare them carefully. YouTube’s live-stream troubleshooting guidance asks creators to inspect the health indicator and error messages as well as the encoder.
Match the log to Live Control Room health details
Open the correct scheduled stream in YouTube Studio’s Live Control Room and inspect its health indicator and timestamped messages around the incident. Confirm that you are looking at the same broadcast and time period as the FFmpeg process. A message from an earlier test or another scheduled event is not a match.
Make a short timeline rather than treating the two logs as competing verdicts. For example: FFmpeg started at 20:14 local time; YouTube’s health message appeared at 20:15; FFmpeg printed a connection or output error at 20:15. This sequence does not prove which side caused the failure, but it gives you a useful point to investigate. If Control Room received a stream before the local process exited, that is a different situation from an encoder that could not begin a connection at all.
Read the actual health text. A configuration or format message points you towards the outgoing video and audio settings; a connection-related warning makes network stability worth checking; a message about the video or audio quality calls for reviewing what the encoder is producing. These are directions for investigation, not proof that a single setting is wrong. Compare the wording with the exact FFmpeg lines at the same time.
YouTube’s official encoder settings and bitrate guide says to monitor stream health and review messages during the event. If you use API-based monitoring, Google’s LiveStreams resource documentation describes stream status and health-status configuration issues. Most small channel operators can begin with the Control Room rather than building API monitoring.
Follow the clues: connection, encoder and format
Use the signal you found to decide what to test. The table is a triage aid, not a list of guaranteed fixes. A message can point to a category without naming the underlying cause, so keep the change narrow and check the result on a fresh attempt.
| Evidence you have | What to inspect next | What that evidence does not prove |
|---|---|---|
| FFmpeg fails before a stream appears in Control Room | Connection messages, stream destination, key selection and whether the encoder’s YouTube workflow is current | That the key is invalid, unless the output or dashboard says so |
| Control Room shows a format or encoding warning | Output codec, audio format, frame rate, keyframe interval and the selected ingestion protocol | That changing every encoder setting will help |
| FFmpeg output looks normal, then the broadcast degrades or drops | Upload capacity and stability, concurrent network use, encoder CPU load and the time of the first health warning | That Wi-Fi alone is responsible |
| Local preview or archive has a problem | Source file, audio/video output, encoder errors and whether the local recording is also affected | That YouTube caused the fault |
| The stream reconnects or starts but then stops | Full reconnect messages, process restarts, source duration and whether the same event repeats | That a new key or protocol is needed |
Start-up clues and format clues call for different tests. YouTube’s troubleshooting page for live streams advises checking encoder errors and CPU load, looking at how the stream appears and sounds in the encoder, and reviewing a local archive where available. If the local output is already broken, fix or simplify that path before changing YouTube’s ingestion settings.
For a format warning, compare the actual output with YouTube’s current guide for the chosen resolution, frame rate and protocol. The guide lists H.264, H.265/HEVC and AV1 for RTMP/RTMPS video, AAC or MP3 audio, a recommended two-second keyframe interval that should not exceed four seconds, and frame rates up to 60 fps. These are published requirements and recommendations, not instructions to use every option. Choose the settings supported by your content, FFmpeg build and ingestion method.
Bitrate needs context too. YouTube’s H.264 settings table lists 6 Mbps as a minimum and 17 Mbps as recommended for 1080p at 60 fps. Those figures describe YouTube’s listed settings, not what your internet connection can sustain. Its network guidance recommends leaving 20% room above the stream’s demand, particularly when accounting for a backup stream. Check the current official table for your selected format and test actual upload capacity rather than treating a speed-test result as a promise of stable streaming.
If the encoder seems healthy but the incoming stream is inconsistent, test the outbound connection during a comparable load. Pause large uploads or other traffic for one test, and compare results; a wired connection can help isolate Wi-Fi as one variable, but it is not a universal cure. YouTube notes that connectivity disruption can break a live stream. If your stream uses a primary and backup feed, include both when thinking about network demand.
Protocol changes are not interchangeable repairs. YouTube recommends encrypted RTMPS where compatible and also documents HLS and DASH ingestion. The protocol affects supported formats and latency behaviour; HLS and DASH can support codecs that RTMP/RTMPS do not, while segment-based delivery usually adds latency. Only change protocol when the stream configuration, encoder and matching YouTube destination are all set up for it.
Check the destination and key privately
If FFmpeg cannot start sending, verify that the output destination is the one provided for the intended YouTube broadcast and that the selected stream key belongs to it. YouTube’s instructions for third-party encoders say to obtain the key in Live Control Room and update the encoder. If you sign into YouTube through a third-party encoder instead of entering a key, YouTube directs users to the software provider when compatibility may need an update.
Never put a stream key in a public issue, screenshot, chat, article comment or support request. Treat it like a password: redact it from the command, shell history, screenshots and logs before sharing. Also remove account tokens, private URLs and any other credentials. Do not send the key to someone who offers to diagnose the issue by logging in as you.
You can verify the destination locally without disclosing the secret. Compare the non-secret portion of the configured output URL with the current destination shown for the broadcast, then confirm privately that the selected key is the intended one. Avoid posting the full output line: some FFmpeg commands contain the stream key as part of the URL, so a log-sharing checklist is not safe merely because you removed a separate “key” field.
If you suspect a key was exposed, use YouTube’s current account and live-stream controls to manage it, rather than leaving a shared credential in place. Follow the instructions in YouTube Help and check the channel’s access state. Replacing a key is a security step when it has been disclosed; it is not a general fix for an unrelated format or network message.
Test a minimal reproducible command
A minimal test helps separate the source file from the YouTube connection, but it should be a controlled test rather than a new pile of settings. First preserve the original command, stderr and timestamp. Then use a short, non-sensitive test source or a local test output to establish whether FFmpeg can read the input and produce the expected audio and video. This step avoids changing the live broadcast while you investigate basic input or encoder issues.
Next, if you need to test YouTube ingestion, make a temporary private or otherwise suitable test broadcast using the correct destination and key kept out of any material you share. Keep the output settings close to YouTube’s current guidance and change only what the health message or log supports. Do not reuse a public command example without checking its placeholders, codecs, protocol and current requirements.
Record the exact FFmpeg version, operating system, input type, output options with credentials replaced by [REDACTED], and whether the local test succeeded. A useful minimal reproduction lets another person understand the media path and output format without needing access to your channel. If your normal command is wrapped in a script, reduce it carefully and explain what was removed, such as looping, a filter or a service restart.
For a stream that stops at the end of a file, the end-of-input behaviour may be more relevant than ingestion. The blog’s guide to FFmpeg streams that stop after one loop covers that distinct failure pattern. If your goal is a continuous recorded programme, the article on streaming recorded Marathi sermons with FFmpeg is useful for thinking about the media loop, but it does not diagnose an ambiguous error fragment.
Share evidence without sharing credentials
A good troubleshooting request gives readers enough context to compare the two timelines while keeping the channel secure. Before posting, search the command and every attached log for the stream key, full ingest URL, access tokens, account email and private identifiers. Replace secrets with a consistent marker such as [REDACTED]; check screenshots as well as text. Do not ask another person to reveal a key, and do not include it to “prove” which destination you used.
Include the exact fragment as seen, including 直播?, but state that you do not know what it identifies. Provide the complete relevant stderr section with timestamps, FFmpeg version and operating system. Describe whether failure happened before connection, during startup or after the stream had run. Include the exact Live Control Room health message and its timestamp, with the time zone for both sources if known.
Summarise the non-secret command options that affect the media: input type, video and audio codecs, frame rate, resolution, bitrate mode and value, keyframe interval, and ingestion protocol. If you cannot safely redact the command, describe those settings in prose instead. Mention whether a local recording or preview looked and sounded correct, whether CPU load was high, and whether the outbound connection was stable at the same time. Do not claim a result from an upload speed test as proof of sustained capacity.
State what you already changed and what happened after each change. “I changed the key, codec and bitrate” is hard to diagnose; “I changed only the audio codec, then Control Room displayed the same message” is more useful. If an error disappears, say which attempt changed and how long it ran rather than promising that the problem is solved for future broadcasts.
For adjacent operational questions, keep the investigation specific. A reconnect-error checklist for FFmpeg and YouTube Live may help when the log clearly shows reconnect behaviour. If you are setting up a long-running host rather than diagnosing one event, the guide to installing FFmpeg on an Indian VPS addresses a different part of the workflow. Those references are not substitutes for the redacted log and timestamped Control Room message.
When the repeated task is keeping a prepared file on air while your own computer is off, StreamNeo can remove the need to leave a local FFmpeg process running and to troubleshoot that process after a local machine interruption; it does not determine what 直播? means or change YouTube’s format and channel requirements.
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
Is 直播? a YouTube Live error code?
The fragment alone does not establish that. It is not enough to identify a specific YouTube or FFmpeg error, so use the complete stderr output and the timestamped Control Room health message instead.
What should I check first if FFmpeg will not connect?
Capture the whole stderr output and compare its time with the relevant broadcast’s Live Control Room messages. Then privately verify that the destination and selected key match the intended broadcast; never share the key in a troubleshooting post.
Should I change the codec or bitrate to fix the error?
Only when the log, health message or settings comparison gives you a reason to do so. Check the current YouTube guidance for the chosen resolution, frame rate and protocol, and test one justified change at a time.
Can I send someone my FFmpeg command for help?
Yes, if you first redact the stream key, full ingest URL, tokens and other private details from the command, logs and screenshots. If you cannot confirm that the credentials are removed, share the relevant settings in prose instead.