A YouTube Live format rejection cannot be diagnosed from the title alone: the exact error, FFmpeg command, playlist type and selected ingest protocol determine the fix. First establish whether the stream uses RTMP/RTMPS or HLS; they have different requirements, so there is no single conversion command that is right for both.
A file extension or playlist label does not tell you which codecs are inside the media. Gather the evidence below, then change only the part that fails: playlist interpretation, packaging, codec or encoder settings.
Start with the exact rejection
Copy the complete message from YouTube Live Control Room or FFmpeg, including any surrounding detail. Do not paraphrase it as “format not supported”: a message about a video format, an ingest connection, an unsupported codec, or a playlist that cannot be read points to different layers of the workflow. The precise text is not included in the question, so it would be guesswork to assign it a cause.
Record where the message appears and when. Does YouTube reject the stream key or ingest connection before media arrives? Does FFmpeg fail while reading an input playlist? Does the preview start and then report a problem after video or audio reaches YouTube? These observations help distinguish a connection or parsing problem from a media-format mismatch.
Keep the relevant inputs together. You will need the exact FFmpeg command, the first lines of the playlist, details of the media streams, and the protocol selected for the broadcast. Redact stream keys, tokens, private URLs and account identifiers before sharing anything. If a playlist contains signed links, redact those too, while leaving enough structure visible to show whether it lists segments, local files or another kind of input.
The word “playlist” is ambiguous. An .m3u8 file may be an HLS media playlist containing references to transport-stream segments. Alternatively, it may be a text list of files passed to FFmpeg through a concat demuxer or another input method. Those are not interchangeable. Do not convert a playlist merely because it has that name; first identify what FFmpeg is reading and what YouTube is receiving.
Confirm the selected ingest protocol
Open the stream’s settings in Live Control Room and verify the configured protocol and the corresponding ingest URL. YouTube’s ingestion protocol comparison distinguishes the available approaches; use the protocol the current stream is actually configured for, rather than inferring it from an old command or an .m3u8 extension.
| Check | RTMP or RTMPS | HLS |
|---|---|---|
| What is sent | A continuous encoded live stream to the ingest endpoint | A playlist and a sequence of media segments delivered to the HLS endpoint |
| Requirements highlighted here | H.264 video, AAC or MP3 audio, and CBR encoding in YouTube’s encoder guidance | TS segments, a rolling playlist, required segment duration and HTTPS POST or PUT delivery |
| Main diagnostic focus | Encoded stream properties, keyframes, bitrate and connection | Playlist structure, segment format and duration, upload method and accepted codecs |
| Latency consideration | A continuous ingest path; check the latency mode selected for the stream | HLS has higher latency; YouTube says ultra-low latency is unavailable when HLS is selected |
These are separate output paths, not two names for the same FFmpeg target. An RTMP/RTMPS stream does not become a valid HLS submission by adding a playlist, and an HLS playlist is not a substitute for an RTMP stream. YouTube’s HLS setup requirements apply when HLS is selected; its encoder guidance for a conventional live feed is a different reference point.
If your actual goal is to send prerecorded files continuously as one live programme, you may be using FFmpeg to read a list of files and send a continuous RTMP/RTMPS stream. That is distinct from creating an HLS live feed with segments and a rolling playlist. The distinction matters before you change the command: identify the endpoint and protocol in the current Live Control Room setup.
Inspect what the playlist actually contains
Look at the first several lines of the playlist, with private addresses and credentials removed. For an HLS playlist, check whether it identifies itself as an M3U playlist and whether it contains segment references and duration markers. Note whether those references point to .ts files, byte ranges within larger files, or a different format. Do not assume a particular playlist layout: it has not been provided here.
For a text list of source videos, inspect how FFmpeg is instructed to interpret it. A concat-style file list is input to FFmpeg; it is not necessarily the output playlist that YouTube receives. Confirm whether FFmpeg reads and combines those source files, re-encodes them, or copies their existing streams. The command’s input and output portions answer different questions, so keep both intact while diagnosing.
Check that referenced files exist and that FFmpeg can read them. A misspelt path, inaccessible segment or malformed list can stop playlist processing before YouTube gets a usable stream. If the input is an HLS playlist, verify that its segment URLs are reachable by the machine running FFmpeg and that the media files really match what the playlist declares. A parsing or missing-file error is not repaired by selecting a different video codec.
For an HLS output to YouTube, compare the playlist and segmenting behaviour with YouTube’s current official instructions. The HLS guidance requires TS segment format, segment duration between one and four seconds, no byte-range mode, and a rolling playlist with no more than five outstanding segments. These are HLS-specific requirements, not settings to apply to an RTMP/RTMPS output. In HLS, playlist entries also need to be delivered using the required HTTPS upload approach, rather than merely saved locally and assumed to have reached YouTube.
Match the output to the protocol
For RTMP/RTMPS, focus on the stream FFmpeg emits to the configured ingest address. YouTube’s encoder guidance lists H.264 video and AAC or MP3 audio for this protocol, along with constant bitrate encoding. If the source video is encoded with something else, changing the filename or wrapping the same compressed stream in another container will not turn it into H.264. Re-encode only when the source properties or desired output settings require it.
For HLS, configure an HLS output rather than a continuous RTMP target. The target is a rolling .m3u8 playlist with TS segments meeting the segment-duration and playlist constraints above, delivered to the HTTPS ingestion URL supplied for that broadcast. YouTube’s HLS instructions specify HTTPS POST or PUT. The URL is tied to the live setup; do not substitute the example URL in FFmpeg documentation or copy an endpoint from an unrelated session.
FFmpeg’s HLS muxer documentation describes options for producing playlists and segments and for uploading them using HTTP methods, including PUT. Its documentation also makes clear that the receiving server must accept the selected method. That explains what FFmpeg can be configured to send; it does not prove that an arbitrary URL accepts it. Use the actual YouTube HLS URL and method prescribed for the stream, and check the current YouTube instructions if the endpoint reports an upload failure.
If the broadcast is a prerecorded loop and you do not specifically need HLS, stay with the continuous RTMP/RTMPS route you configured and make its encoded stream compatible. Readers comparing file-based continuous playback and playlist behaviour may also find the practical discussion of delays between videos in a YouTube Live loop useful. It is a separate playback issue, not evidence that a particular protocol caused this rejection.
Check codecs, not just containers
Ask FFmpeg what streams are present in the source and output. Its probe output should identify the video codec, audio codec, frame size, frame rate and stream details; use that information to compare the file against the requirements for the configured protocol. If you only know that the file is MP4 or TS, you know the container, not the encoded video or audio format inside it.
A container holds encoded streams and related metadata. Repackaging can change how compatible streams are wrapped without changing their underlying codecs. Re-encoding creates new compressed streams and can change codec, bitrate, frame rate or other properties. Use stream copy only when the existing streams already meet the target requirements and the packaging path is appropriate. A copy operation cannot correct an incompatible codec or unsuitable encoding properties.
For RTMP/RTMPS, compare the video and audio codec names with YouTube’s encoder table. Its guidance lists H.264 video and AAC or MP3 audio. If a source file has a different video codec, such as HEVC, changing only the container does not make it H.264; you need a compatible encoded output. If the video is already suitable but the audio is not, address the audio stream without needlessly re-encoding the video where your workflow permits it.
For HLS, use the HLS-specific supported codec list rather than borrowing RTMP/RTMPS assumptions. YouTube’s HLS guidance supports H.264 and HEVC video and lists AAC, AC3 and EAC3 audio. Even when the codec is supported, a wrong segment format, byte-range playlist, upload method or playlist window can still prevent a valid HLS submission. Conversely, an HLS-compatible codec does not make the same output automatically appropriate for RTMP/RTMPS.
If you need to ask for help, share the exact error, the protocol, the command with credentials removed, the playlist’s opening lines, and the probe summary. That gives someone enough context to suggest a targeted change. A generic “convert this playlist” request leaves open whether the problem is a list of source files, an HLS playlist, the media codec, or delivery to the ingest endpoint.
Verify bitrate, keyframes and encoding mode
Once codec and packaging match the selected protocol, check the encoder properties. For RTMP/RTMPS, YouTube recommends CBR and a two-second keyframe interval; the keyframe interval should not exceed four seconds. A keyframe interval that is too long can make a stream harder to process as expected, but it does not establish the cause of a format rejection on its own. Check the setting in the actual output encoder, not just the source file’s metadata.
Choose bitrate using the current YouTube table for the output resolution, frame rate and codec. Do not copy a number from a different resolution or codec and treat it as universal. As one specific reference point, YouTube Help lists 5 Mbps minimum and 14 Mbps recommended for 1080p at 30 fps with H.264. That is a protocol- and configuration-specific recommendation, not proof that bitrate caused an individual format message. Check the current encoder settings table before setting your own target.
For HLS, do not transplant RTMP/RTMPS encoder rules without checking the HLS setup instructions. Confirm that the segment duration and playlist window meet the HLS requirements, then check codec support and the upload method. HLS introduces segment-based delivery and higher latency; YouTube notes that selecting it turns off the ultra-low-latency option. If low latency is essential to your channel, compare the trade-off before changing protocols just to work around an unexplained message.
A sensible order is to verify protocol, then playlist and packaging, then codecs, then encoder properties. This avoids changing several variables at once. If a test succeeds after changes to the container, codec, keyframe interval and bitrate all at once, you still will not know which adjustment mattered, and the next failure will be harder to diagnose.
Test briefly before restoring the full loop
Run a short private or unlisted test using the same protocol, endpoint type and representative media as the intended broadcast. Keep the test long enough to see whether the preview appears and whether audio and video continue, but do not assume that a successful connection alone proves that a long playlist will behave correctly. For HLS, check that new segments are accepted and the playlist rolls forward. For RTMP/RTMPS, look for a stable incoming stream and review the available stream-health feedback.
Change one relevant setting at a time and record what you changed. If the first test fails before media appears, return to the protocol, address and connection details. If it connects but reports a format or codec problem, review the actual output streams and protocol-specific requirements. If playback begins but stops later, check playlist references, segment delivery, input-file transitions and encoder logs rather than assuming that the initial format rejection remains the only issue.
Keep an untouched copy of the original files and playlist. A separate test output makes it easier to return to the source if a conversion loses audio, changes frame rate, or creates an unusable playlist. For a channel that needs prerecorded material to keep running while your own computer is off, StreamNeo removes the repeated local-machine and restart burden by turning an uploaded video into a YouTube live stream; you still need compatible source material and the correct YouTube setup.
If you are running FFmpeg yourself, the bitrate pre-flight checklist gives you a separate way to review connection capacity before committing to a long broadcast. For an FFmpeg-based continuous show, the guide to running a podcast stream with FFmpeg on YouTube is relevant to the broader workflow. Neither replaces this protocol check: first make sure you are solving the same kind of input and output problem.
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
What does YouTube mean when it rejects an FFmpeg video format?
The phrase alone does not identify one cause, and the exact rejection text has not been supplied here. Check whether the message concerns the input playlist, a codec, the ingest connection or the output format, then compare the relevant details with the requirements for the selected protocol.
Can I fix the rejection by changing an MP4 file to TS?
Not necessarily. Changing a container does not change the video or audio codecs inside it, and TS segments are an HLS requirement rather than a universal fix for RTMP/RTMPS. Confirm the protocol and stream details before repackaging or re-encoding.
Should I use RTMP/RTMPS or HLS for an FFmpeg playlist?
That depends on what you mean by playlist and what you need to send. A text list of prerecorded files can be an FFmpeg input for a continuous RTMP/RTMPS stream; an HLS feed sends a rolling playlist and segments to an HLS endpoint. Check the protocol selected in Live Control Room and account for HLS’s higher latency.
What should I provide to get a specific conversion command?
Provide the complete rejection message, the configured protocol, the FFmpeg command with secrets removed, the playlist’s first lines and a probe summary of the media streams. Those details show whether the needed change is to input parsing, packaging, codec settings or delivery. Without them, a command would be an unsupported guess.