A YouTube live stream that freezes after FFmpeg changes resolution between playlist videos may be encountering an output-format transition, but the timing alone does not prove that is the cause. Check what FFmpeg sends at the boundary, whether timestamps continue, and what YouTube reports before changing encoder settings.
The safest first test is a short private or unlisted stream using representative playlist items, with output dimensions and frame rate held constant. Compare FFmpeg’s log at the freeze with YouTube Live Control Room’s stream-health messages; do not set manual YouTube options that disagree with the outgoing stream.
Why a playlist boundary may matter
A playlist can join files that look similar to a viewer but differ in the details of their encoded streams. One clip may be 1920×1080 and another 1280×720; they may also differ in frame rate, codec profile, pixel format, audio layout, or timestamp behaviour. If the broadcast appears to freeze at the join, those differences give you something specific to inspect.
They are not proof of a YouTube defect or even proof that resolution is the cause. A boundary is also a moment when FFmpeg opens a new input, changes packet flow, or encounters a damaged or unusual frame. Network interruption, encoder overload, malformed media, discontinuous timestamps, or an audio-stream change could coincide with it. Keep the diagnosis conditional until you have the command, file metadata and logs.
Start by recording the exact time the picture stops moving, whether audio continues, and whether the stream recovers without intervention. Note the playlist item that was ending and the one that was starting. Those observations help you correlate the symptom with FFmpeg output and YouTube’s messages rather than relying on a viewer’s impression alone.
If you change clips on a schedule, the transition itself is worth testing separately from the playback arrangement. The guide to scheduling video changes on an always-on stream is relevant to how items are handed off, but this diagnosis still depends on the actual encoded output.
Check stream-copy and output behaviour
Find the video output options in your FFmpeg command. If you see -c:v copy (or an equivalent stream-copy setting), FFmpeg passes compressed video packets through rather than decoding, filtering and encoding them. Copying can reduce processing work, but it cannot apply a scale filter to make differently sized inputs uniform.
That distinction matters when the playlist contains mixed dimensions. A command that copies each file’s video does not, merely by copying, turn every input into one stable output size. FFmpeg’s documentation describes -s as inserting a scale filter at the end of the filtergraph; a filtered and re-encoded test is therefore a more suitable way to check whether normalised output changes the symptom. See the FFmpeg documentation for the behaviour of stream-copy and output sizing options.
Do not replace a working command blindly. Save it, save the complete log, and make a copy for a controlled test. Change one relevant thing at a time: for example, first test a single item, then two items with different dimensions, then the same pair through an explicit scale and encode path. If you change filtering, codec, bitrate and playlist logic together, a better result will not tell you which change mattered.
The command is only part of the evidence. Check which input and output streams FFmpeg maps, whether it reports decoder or filter errors, and whether the output encoder remains active around the transition. A process that still exists is not necessarily producing healthy video packets. For a longer discussion of the constraints involved in running FFmpeg continuously, see Raspberry Pi FFmpeg settings for continuous YouTube streaming.
Compare dimensions and codec parameters
Inspect both the playlist files and the outgoing stream. For each item, note video codec, profile if shown, width and height, pixel format, frame rate, audio codec and channel layout. Then compare those values with what FFmpeg says it is producing. The key question is whether an output property changes where the freeze occurs, not simply whether the source files differ.
A differing input size is less informative if FFmpeg is decoding and scaling both clips into one output format. Conversely, stream-copying can preserve differences from one input to the next. Other codec parameters may matter too: a profile or pixel-format change, a new audio stream configuration, or a change in frame rate can be a clue even if dimensions appear stable. Treat each as a possible lead, not as a guaranteed trigger.
| What to compare | Why it is useful | What to test if it changes |
|---|---|---|
| Input and output width and height | Shows whether the outgoing picture changes size at the boundary | Scale and re-encode to one chosen output size |
| Video codec, profile and pixel format | Shows whether the stream’s coded representation changes | Use a consistent encoder configuration and inspect its output |
| Frame rate | A change may accompany a resolution transition or a cadence shift | Test one fixed output frame rate across representative clips |
| Audio codec, sample rate and layout | Audio can change independently of the picture | Check stream mapping and normalise only if evidence points here |
| Timestamps and keyframe cadence | Helps distinguish a format change from a timing or join problem | Inspect the log and test a controlled re-encode |
Do not assume a particular codec or pixel format from the file extension. A .mp4 suffix does not tell you the encoded stream properties. If you have a known-good item and a problem item, compare their metadata and then compare the outgoing stream at the transition; the latter is what YouTube receives.
Verify timestamp continuity
A boundary can be visually plausible as a format transition while actually being a timing problem. Look at FFmpeg’s log around the join for timestamp warnings, non-monotonic timestamps, large gaps, dropped or duplicated frames, and muxer or decoder errors. Compare the timestamps immediately before and after the boundary rather than only noting that the process did not exit.
A timestamp gap can leave a receiver waiting for the next expected media time; a reset or jump may be handled differently depending on the pipeline. The available evidence from your own logs is what determines whether this is relevant. Do not infer timestamp trouble just because a picture froze, and do not add timestamp flags at random: an attempted correction can change timing behaviour without fixing the underlying file or input sequence.
If the playlist is assembled from separately encoded files, test the two boundary items in isolation using the same command and output settings. Then test a normalised re-encode of those items. If one isolated file already shows warnings, investigate that file; if each works alone but the join fails, focus on how the pipeline transitions between them and what the log reports there.
Keep a small record of test conditions: command, FFmpeg version/build, input filenames, ingest method, start time, and any YouTube health message. This makes it possible to compare runs and ask for useful help. A cropped screenshot of a frozen player is less informative than the command and a few dozen log lines around the event, after removing stream keys or other secrets.
Review YouTube ingest and stream health
Confirm whether the broadcast reaches YouTube over RTMP/RTMPS or HLS. The protocols have different ingest requirements, so do not apply HLS segment rules to an RTMP diagnosis. YouTube’s Live Streaming API documentation describes stream configuration and status fields; status can help distinguish a running local process from a stream YouTube considers active, ready, inactive or in error.
In Live Control Room, compare the time of the freeze with the stream-health indicator and any messages. Check whether the ingest appears healthy, whether YouTube reports missing or unstable data, and whether the preview freezes in the same way as the public player. A healthy process on your machine does not establish that YouTube is receiving usable media; equally, a player-side freeze does not establish an ingest failure.
For RTMP/RTMPS, YouTube’s encoder guidance lists supported video codecs and recommends constant bitrate, a two-second keyframe interval and not exceeding four seconds. Its bitrate guidance depends on codec, resolution and frame rate, so use the current table for the mode you are actually sending rather than borrowing a setting from a different resolution. See YouTube’s live encoder settings guidance. Test and monitor; these recommendations are not a guarantee that a particular stream will be accepted or remain uninterrupted.
If you use HLS ingest, consult YouTube’s separate HLS ingest guidance. It calls for TS segments of 1–4 seconds, a rolling playlist with no more than five outstanding segments, HTTPS POST/PUT, and no byte ranges. HLS has higher latency than RTMP because it sends segments rather than a continuous stream. Those requirements matter only to an HLS workflow, not to a typical RTMP sender.
Test stable dimensions and frame rate
Create a test that makes the transition repeatable. Choose a pair of playlist items with different source dimensions if that matches the affected sequence, and include representative sound and motion. First run them with the existing command so you have a baseline. Then make a copy of the command that decodes, filters and re-encodes the video to one chosen output size and frame rate.
The purpose is not to claim that every YouTube stream must use one resolution. It is to test whether stable outgoing properties remove the symptom in your case. Keep the codec configuration, audio handling and playlist order unchanged where possible. Review the output stream and logs, then compare the same boundary in Live Control Room. If the freeze remains, the result narrows the question but does not rule out timestamps, connectivity, source damage or another issue.
YouTube recommends automatic resolution and frame-rate detection by default for Live Control Room streams. Its help page says, “By default (recommended), YouTube will automatically detect your resolution and frame rate.” If you use API stream configuration, the documentation says the resolution and frameRate settings must be set to variable together for automatic detection. With manual settings, select values that agree with the actual outgoing video; do not set a resolution or frame rate that FFmpeg is not sending.
Test before an important broadcast rather than discovering the transition during an overnight devotional loop or a scheduled local news replay. YouTube recommends testing with representative sound and movement, then monitoring stream health and messages. A short test is useful only if it includes the conditions that produce the boundary: the same files, command, ingest route and relevant settings.
Match manual settings to the outgoing stream
If your stream key or workflow uses manual resolution and frame-rate settings, compare them with the measured output, not with the source files’ labels or the resolution you intended to produce. For example, if FFmpeg scales all items to a 1280×720 output at a fixed frame rate, manual settings should describe that outgoing mode. If FFmpeg is copying inputs that vary in size, a single manual declaration may not represent what the sender actually emits.
For the API configuration, automatic detection is represented by variable for both resolution and frame rate; do not configure one as variable while forcing the other. For ordinary Live Control Room use, follow YouTube’s current encoder page and let the platform detect automatically unless you have a reason and a verified outgoing mode for manual selection. Guidance can change, so check the official page before a live event.
Stable output should be treated as a practical diagnostic preference, not as a universal requirement that YouTube rejects all midstream changes. If the fixed-size test does not help, take the next step from the evidence: investigate timestamp continuity, connection interruptions, encoder load, problematic media, or audio/video stream changes when the log or health messages support those avenues.
If keeping your own machine awake and watching a long-running FFmpeg process is the pain point, StreamNeo can remove that specific operational burden by turning an uploaded video into a YouTube live stream that continues with your computer switched off. It does not establish the cause of this freeze, and it is YouTube-only; verify the file and channel behaviour with a test before relying on any always-on arrangement.
If the workflow includes replacing or refreshing playlist material, the guide to updating a YouTube radio playlist without stopping the stream covers that separate operational question. Keep that change process distinct from a format-transition test so you can tell whether a freeze follows the media boundary, the update procedure, or neither.
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
Does a resolution change definitely cause the freeze?
No. A freeze at the same time as a resolution change makes the output transition worth investigating, but timing alone does not establish cause. Compare FFmpeg’s output and warnings, timestamps, and YouTube stream-health messages before settling on an explanation.
Can I use -c:v copy with files of different dimensions?
Stream copy passes compressed packets through and does not decode or scale them. If you need a consistent output size, test a decode, filter and re-encode path with a chosen scale rather than expecting copy mode to normalise the inputs.
Should I set YouTube to the resolution of the first playlist video?
Only if that is the actual outgoing resolution throughout the stream and the rest of the manual settings also match. Otherwise, use automatic detection as YouTube recommends by default, or first make the FFmpeg output stable and verify what it sends.
What evidence should I collect before asking for help?
Keep the full FFmpeg command and version, metadata for the playlist files, ingest protocol, relevant key settings, and logs around the freeze. Record the matching Live Control Room health messages as well, and redact stream keys before sharing anything.