Green frames in a gaming rerun do not point to one cause by themselves. Find the first stage where they appear—the recording, local playback, FFmpeg output or YouTube playback—before changing settings.
Keep the original file untouched, note the timestamp of a bad frame, and compare the same moment at each available stage. That gives you evidence for a focused test instead of a guessed repair command.
Pinpoint where green frames first appear
Treat the workflow as a sequence: capture or recording, source-file playback, FFmpeg processing, local playback of the result, upload, then YouTube playback. Your first task is to locate the earliest stage at which the picture turns green. If the original is already affected, changing the output pixel format cannot restore image information that was not recorded correctly.
Write down one or more timestamps where the defect is easy to recognise. Check whether the entire frame is green, a block of it is corrupted, or the problem looks more like a colour cast. These appearances are clues, not diagnoses. A colour shift can involve colour metadata, while a wholly corrupted frame may point elsewhere; neither observation alone proves the cause.
Use this comparison to choose the next branch:
| What you observe | Where to investigate next |
|---|---|
| The original recording is green at the same timestamp in more than one player | Recording, capture, or source-file integrity |
| One player shows green, another does not | Playback or decoder behaviour before assuming the file is damaged |
| The original is clean but the FFmpeg output is not | FFmpeg command, build, decoding, conversion, and encoder support |
| Local files look clean but the YouTube rendition does not | Upload compatibility, processing, or playback on YouTube |
| The problem moves or changes between tests | Compare exact timestamps and settings before drawing a conclusion |
The table narrows the investigation; it does not identify a root cause. Preserve the original and note the result for each stage. If you are sending prerecorded gameplay into a continuing channel, the broader workflow in how to keep a YouTube gaming stream live overnight with prerecorded videos can help separate file preparation from the live-broadcast side.
Compare the original recording and local playback
Start with a copy of the original, not a file that has already been converted. Play the affected timestamp locally and note the player, operating system, and whether the same section looks normal when played in another application. A difference between players is meaningful: it means you should check the playback path before treating the video as conclusively damaged.
If two players show the same green frames in the original, preserve that observation and move upstream to the capture or recording process. If only one does, do not overwrite the original with a new transcode as a first response. A conversion can conceal a playback-specific symptom, create a new one, or make it harder to compare the original evidence.
Compare the exact moment, not just a nearby scene. Use the same start point and inspect a short interval around the first visible defect. Record whether the picture is green in the original, a copy, and any FFmpeg output. If audio is also missing or the file stops at the same point, note that too, but do not assume it shares a cause with the green image.
For a suspected playback issue, try a second player or decoder before changing encoding settings. If you use FFmpeg's ffplay, its documentation describes an output_corrupt option related to displaying potentially corrupt frames. That option changes playback behaviour; it does not reconstruct missing picture data or repair a file. See the FFplay documentation before using playback options as a diagnostic tool.
Inspect the FFmpeg command and logs
Keep the exact command that produced the output, along with the complete relevant console log. Also record the output filename, the timestamp where the problem first appears, and the FFmpeg version and build details shown by ffmpeg -version. Without the command and log, it is easy to blame a setting that was never applied or miss a warning about a different part of the process.
Read the log for decoder errors, conversion warnings, pixel-format messages, and encoder failures. Note whether FFmpeg reports that it is using a hardware decoder or encoder, if that information appears. Hardware acceleration is a variable to document, not a proven cause; avoid switching it on or off until you can compare a controlled test.
The command can request a format without the encoder actually supporting it. FFmpeg's documentation says that an unsupported requested pixel format may lead to a warning and selection of the best format the encoder supports. Therefore, seeing a format option in your command is not evidence that the resulting stream uses that format. Check the log and inspect the output stream rather than relying on the text of the command alone. The FFmpeg command-line documentation explains how its options are applied.
Before experimenting, save the original command and make a copy of the input. Change one relevant variable at a time, and give each output a distinct filename. If you alter the pixel format, encoder, filtergraph, or acceleration path together, a clean result will not tell you which change mattered. A failed test is useful when its inputs, command, and result are preserved.
If you do not know which encoder was selected, do not copy a command from a forum and assume it fits your build. FFmpeg builds and available encoders differ. The FFmpeg codec documentation is a starting point for checking encoder options; use the documentation relevant to the version you have installed, since the online documentation may describe a newer revision.
Check input and output streams
Inspect both the source and the resulting file. ffprobe -hide_banner -show_streams -show_format input.mp4 is one way to print stream and container details; replace the filename with the file you are examining. Save the output rather than paraphrasing it, so you can compare input and output properties side by side.
For the video stream, note the codec, pixel format, dimensions, frame rate, and any colour metadata that is reported. Also record whether the file contains more than one video stream or an unexpected stream layout. For the container, note its format and any relevant duration or time-base details. These properties help identify what changed during conversion; no single field proves why a frame is green.
Check that the output is the file you intended to create and that its stream is readable. A command can complete with a file on disk even when the result is not what you meant to encode. Compare the source and output around the same timestamp, and include any decoder or encoder messages from that interval in your notes.
For a looping prerecorded channel, output consistency matters beyond one test file: the file you plan to reuse should be checked before it enters the loop. The instructions in how to create a looping video playlist for a YouTube livestream with FFmpeg cover the playlist workflow, but a loop does not fix a damaged source. Validate the individual video first.
Verify pixel format and encoder support
Pixel format describes how picture samples are arranged and represented. A requested format is only a request; the encoder must support it, and filters in the chain can affect conversion. Look for the format FFmpeg selected in its output messages, then confirm the resulting stream with ffprobe. If they do not match your expectation, investigate the encoder's supported formats and any filtergraph conversions before trying another option.
FFmpeg documents a leading + on a requested pixel format as stricter behaviour: if that format cannot be selected, the operation can fail, and automatic conversion in filtergraphs is disabled. This can be useful as a diagnostic constraint when you understand the implications, but it is not a universal fix. It changes how conversion is handled and can make a previously working command fail. Consult the FFmpeg documentation on pixel-format selection and check your encoder's supported formats before using it.
Do not confuse a colour-metadata mismatch with proof of green-frame corruption. Record the reported primaries, transfer characteristics, and matrix if available, and compare them between source and output. Correcting metadata may address interpretation of colour, but it cannot recover missing or corrupted pixel data. Keep that distinction in mind when deciding whether a test should change colour tags or the encoding path.
Test a short SDR output
Only make a new test after confirming that the source decodes cleanly at the affected timestamp, or after documenting that it does not. Use a short section containing the problem area and a normal section for comparison. Keep the same input and change a single variable so you can tell whether the result improved, stayed the same, or changed in a different way.
For a new standard dynamic range (SDR) upload, YouTube's published baseline is a useful compatibility target: MP4 container, H.264 video, progressive scan, 4:2:0 chroma subsampling, and the frame rate used when recording. YouTube recommends BT.709 for SDR. These recommendations are for upload compatibility, not a promise to repair green frames, and they cannot make an already damaged source clean. Check the current YouTube upload encoding recommendations when preparing the export.
Do not force a setting just because it is common in an example command. First confirm which encoder your FFmpeg build uses and what formats it supports, then check the log and probe the test output. If the source uses a frame rate or colour path that differs from your intended output, document it rather than silently changing several settings at once.
Play the test file locally at the recorded timestamp. If it remains green, the upload stage has not yet been tested; return to the source, command, logs, and stream comparison. If it is clean locally, keep that exact file and its settings for the upload comparison. Do not discard the failed test: it is evidence about the effect of the single change you made.
Upload and compare playback
If the short output plays cleanly locally, upload that file and wait for YouTube playback to become available. Compare the same timestamp in the uploaded rendition, and keep the local test file unchanged. A difference between local playback and YouTube playback points the next investigation towards the uploaded rendition or playback path; it does not, by itself, establish a YouTube processing fault.
Check playback in another browser or device if practical, and note whether the green frames recur at precisely the same moment. Make sure you are looking at the uploaded test and not the original video or a cached version. If the local file and YouTube playback both show the defect, return to the file and encoding evidence rather than attributing it to upload processing.
For a continuous channel, a bad source can repeat each time the playlist returns to it. Validate the test export before adding it to an overnight loop, and monitor the first playback rather than waiting for a viewer report. If the recurring work is keeping a process alive rather than repairing a video, how to use systemd to restart an FFmpeg YouTube stream automatically addresses that separate operational problem. A restart mechanism cannot correct green frames embedded in a file.
If your pain is keeping a prepared rerun broadcasting while your own computer is off, StreamNeo can take an uploaded video and run it as a 24/7 YouTube live stream; it does not diagnose or repair a damaged source file, so establish that the video is clean first.
When you have the source and channel ready, use the operating-option details to decide what fits your workflow.
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
Should I change -pix_fmt as soon as I see a green frame?
No. First find out whether the source itself is affected and whether the problem appears in more than one player. Then compare the requested and selected pixel formats in the FFmpeg log and probe the output; the option in a command does not prove it was used.
Does an H.264 MP4 export guarantee YouTube will remove the green frames?
No. YouTube's SDR upload recommendations offer a compatibility baseline, not a repair guarantee. If the green frames are already present in the source, or the local output is damaged, changing the container and codec will not restore the missing image data.
What should I include when asking for help with my command?
Share the exact FFmpeg command, ffmpeg -version output, relevant log messages, and stream details for both input and output. Include the earliest affected timestamp and whether it is green in the original, local output, another player, and YouTube playback. Keep private stream keys and other credentials out of anything you share.
Is a green preview proof that the uploaded video is corrupt?
No. A playback application can render a file differently from another player, so compare the same timestamp with a second playback path and inspect the local file. If only YouTube shows the problem, record that distinction and investigate the uploaded rendition without assuming a cause.