To check FFmpeg stream bitrate and frame rate for YouTube Live, use ffprobe to inspect the stream fields, then compare those fields with encoder reporting and YouTube’s live stream-health information. Treat avg_frame_rate as an average and r_frame_rate as a guessed base rate, not as interchangeable answers or proof of the intended playback rate.
A probe of a file can tell you what that file contains; it cannot by itself measure changing network throughput during a live broadcast. For a useful diagnosis, check the encoder configuration, observe output over time, and compare what you send with what YouTube reports receiving.
Inspect stream fields with ffprobe
ffprobe is FFmpeg’s inspection tool. For a local file or a probeable input URL, this command asks it to report the first video stream’s codec, bitrate field and two common frame-rate fields:
ffprobe -v error -select_streams v:0 \
-show_entries stream=codec_name,bit_rate,r_frame_rate,avg_frame_rate \
-of default=noprint_wrappers=1 INPUT
Replace INPUT with the path or URL you can inspect. -select_streams v:0 selects the first video stream, while -show_entries limits the output to the fields you asked for. The default writer presents a compact report, useful for checking a single file without parsing it in another program.
For scripts or repeatable comparisons, request JSON instead:
ffprobe -v error -select_streams v:0 \
-show_entries stream=codec_name,bit_rate,r_frame_rate,avg_frame_rate \
-of json INPUT
JSON is easier to store and compare between runs, but the format does not make a field more authoritative. A missing or surprising bit_rate value still needs interpretation. If you want to understand the whole programme’s transport demand, do not forget audio: the first-video-stream selection deliberately excludes it. Omit -select_streams v:0 to inspect all streams, and identify audio and video separately before adding their contributions.
A probe should be part of a small record, not a one-time verdict. Keep the command, the input identity, the time of capture, and your relevant encoder settings together. If you have two candidate files, probe both in the same way. That helps distinguish a real change in the encoded stream from a changed command, input, or FFmpeg build. For a broader explanation of how stream quality is evaluated, see the key live video quality metrics.
For a live URL, whether probing works depends on the protocol, access and FFmpeg build. There is no single universal probe command for every RTMP or RTMPS session. If you cannot safely or reliably probe the live endpoint, inspect the encoder’s own output and YouTube’s stream-health view instead of treating a short local sample as a live network measurement. FFprobe’s documentation describes stream, packet and frame inspection options in more detail in the FFprobe documentation.
Read avg_frame_rate and r_frame_rate correctly
The two fields answer related but different questions. FFmpeg defines avg_frame_rate as the average frame rate. Its r_frame_rate value is a guessed base rate: it may represent the lowest rate at which timestamps can be expressed accurately, rather than the rate you meant viewers to see. FFmpeg explicitly cautions that this value is a guess in its AVStream reference.
This distinction matters when a report seems to say that a stream has a higher rate than you configured. Do not read r_frame_rate alone as the intended playback frame rate. Compare it with avg_frame_rate, the encoder’s configured output rate, and—if the mismatch affects your diagnosis—the actual frame timestamps. A guessed base rate can be higher without establishing that the video is being displayed at that rate.
For example, suppose your FFmpeg command is configured for a particular frame rate but the probe shows different values in the two fields. That is a reason to investigate, not a reason to pick whichever number seems more familiar. Check that you are probing the intended video stream, confirm that the file or endpoint is the output you meant to inspect, and compare its timestamps or decoded frames. FFprobe can show packet-level details with -show_packets and decoded frame details with -show_frames; choose the view that answers the question you have.
For constant-frame-rate encoding, FFmpeg’s documentation describes a time base of 1 / frame_rate and identical timestamp increments of one. In practical terms, consistency in timestamps is more informative than treating a metadata label as a guarantee. If the source is variable-rate, a short clip covers a transition, or timestamps are unusual, an average can conceal local variation. Record what you find and inspect a representative span rather than inferring the behaviour of a whole broadcast from one field.
A useful comparison note might include the configured rate, both reported fields, and whether timestamps are regular in the part you checked. This gives you a way to compare a preflight encode with a later version without turning one ambiguous number into a conclusion. It is especially useful for a devotional loop or ambience stream, where a static scene and a clip with movement can place different demands on encoding even when their nominal frame-rate settings match.
Interpret reported bitrate cautiously
The bit_rate shown by ffprobe is a stream field, not a live meter. It may be unavailable or unhelpful for a particular input. Even when a file reports a bitrate, that value does not establish what a changing live output sends in every moment or what YouTube receives over the network.
Keep three quantities separate: the encoder’s configured target, the encoder’s reported output over an interval, and the data observed at the transport or receiver side. They can differ. A target is a setting; an average is a summary over its measurement window; and a received rate can change as packets are sent, network conditions vary, or the stream has bursts. None can be substituted automatically for the others.
To examine a completed encode, use FFmpeg’s progress output or its documented -vstats reporting, when appropriate for your command. The output includes bitrate statistics such as br and avg_br, reported in Kbits/s. Read them as encoder statistics for the output and interval shown, not as a guarantee that every short interval matched the target. Check FFmpeg’s command-line documentation for the reporting options and their meaning.
If you need to understand packet behaviour, FFprobe’s packet inspection can show packet-level information for material it can access. But packet inspection of a file is still inspection of that file, not a direct measure of the live path from your encoder to YouTube. For a running broadcast, put encoder reports beside YouTube’s health information and note when each observation was made. Avoid claiming a transport problem solely because a file probe gives a different bitrate from your configured target.
The total programme rate also includes audio, so a video-only report should not be compared casually with a total upload figure. If you are diagnosing a constrained connection, consider the audio stream and any other data sent as part of the output. Compare like with like: a video stream field against video output reporting, or total output against total observed traffic. A codec comparison for live streaming can help frame codec choices, but it does not remove the need to measure your own output.
Check encoder configuration against YouTube guidance
YouTube’s live ingest recommendations depend on codec, resolution and frame rate. Its current encoder guidance reviewed on 3 October 2026 lists RTMP/RTMPS, H.264, H.265/HEVC or AV1 video, frame rates up to 60 fps, CBR encoding, and a recommended two-second keyframe interval that must not exceed four seconds. These are YouTube recommendations, not evidence that FFmpeg actually emitted the settings you intended. Recheck the YouTube live encoder settings page before a broadcast because guidance may change.
The following examples are from YouTube’s live ingest table, not its separate upload-video recommendations. Values are listed as minimum and recommended bitrate, in Mbps, for the named codec and format; as listed on YouTube Help’s live encoder page in October 2026:
| Ingest format | Codec | Minimum | Recommended |
|---|---|---|---|
| 1080p60 | H.264 | 6 Mbps | 17 Mbps |
| 1080p60 | AV1 or H.265 | 4 Mbps | 12 Mbps |
| 1080p30 | H.264 | 5 Mbps | 14 Mbps |
| 1080p30 | AV1 or H.265 | 4 Mbps | 10 Mbps |
| 720p60 | H.264 | 3 Mbps | 8 Mbps |
| 720p60 | AV1 or H.265 | 2 Mbps | 6 Mbps |
Use the row that matches the codec, ingest resolution and frame rate you are sending. A recommended value for H.264 at 1080p60 is not a target for H.265 at 1080p30, nor does an upload-encoding table describe live ingest. The point is not to chase the largest figure. Select a suitable format, then confirm that your actual encoder output and connection can sustain it.
Compare the output configuration against the guidance field by field: codec, resolution, configured frame rate, bitrate mode and keyframe interval. Then compare those settings with the probe and encoder reports. If the command requests CBR but output statistics vary, remember that the configured mode and observed short-interval behaviour are different checks. If FFmpeg reports an unexpected codec or the wrong video stream is selected, first verify the output you are probing.
For a 24/7 channel, these checks belong in preflight as well as during diagnosis. A static lofi screen may encode differently from a moving music visual, while a local news loop may have frequent cuts. Use audio and movement representative of the planned stream when testing; a quiet sample may not reveal what happens during a more demanding segment. Keep a record of the exact encode and settings that you tested. YouTube’s recommendations provide a comparison point, not a guarantee of acceptance or stable delivery.
Observe live output over time
A single snapshot is weak evidence about a stream that changes continuously. Capture encoder reports repeatedly over a meaningful span, and compare those with YouTube Live Control Room’s stream-health information during the same period. Note when the stream starts, when an issue appears, and whether the change coincides with a scene transition, a network change, or an encoder adjustment.
The exact way to collect FFmpeg output depends on the output protocol and how you launch the process. You can enable periodic progress reporting in the FFmpeg command or review its documented statistics, but do not copy a supposed universal command for all live setups. Match the method to your FFmpeg build and output. For packet or frame examination, work from an accessible capture or endpoint that represents the relevant part of the stream; do not assume a short recording is a faithful account of moment-to-moment throughput.
Keep the observations easy to interpret. Record configured target and mode, the time window, encoder-reported average, any visible interruptions, and YouTube’s health messages. If the encoder’s rate stays near its intended behaviour while YouTube reports delivery trouble, look beyond the metadata field to the connection and receiver-side information. If YouTube health appears normal but your local rate report is surprising, verify that you are reading the correct output and statistic before changing the encode.
Network capacity is part of the comparison. YouTube’s network tips recommend leaving 20% upload bandwidth headroom and state that total stream bitrate must fit the available upload bandwidth. The advice is to leave room rather than run a connection at its limit; actual usable upload capacity can vary. See YouTube’s streaming tips and test on the connection you will use for the broadcast.
This is particularly important when a channel must continue overnight. A laptop test on a quiet network does not prove that a home or shop connection will behave the same way at another time. If keeping a dedicated computer powered and connected through the night is the pain point, StreamNeo removes that specific burden: you upload the video and provide your YouTube stream key, then the broadcast can continue with your computer switched off. The stream still needs a sound source file, appropriate settings, and ongoing attention to channel health.
Compare settings with YouTube stream health
Treat stream health as a second observation, not a substitute for your encoder’s own evidence. The encoder tells you what it is configured to produce and what its reports say; YouTube’s Live Control Room indicates how the platform sees the incoming stream and surfaces health information. Looking at both can help locate which side of the path deserves attention, but neither a recommendation table nor a single report proves the entire session behaved consistently.
Use a repeatable comparison. First, write down the outgoing codec, resolution, frame-rate configuration, bitrate mode and keyframe interval. Next, confirm the fields in an output probe or encoder report. Then note the relevant YouTube health status and messages during the same interval. If the figures disagree, check that the reports refer to the same stream, time window and units before drawing a conclusion.
For example, if your configured video target is compared with YouTube’s total received rate, remember that the latter can include audio and can vary over time. If a probe’s average rate is compared with a brief health alert, the time windows differ. If your FFmpeg process is restarted, make a note of the new session rather than combining values from before and after the restart. These simple boundaries prevent an apparent mismatch from becoming an unnecessary bitrate change.
The same method helps you compare two settings fairly. Change one thing at a time where practical, then use similar content and observation periods. Compare codec, ingest resolution, target and observed bitrate, both frame-rate fields plus timestamps, keyframe interval and network headroom. Do not compare recommendations across different rows and conclude that one encoder is failing solely because its nominal number is lower.
YouTube advises testing with audio and movement similar to the planned event, then monitoring health and messages while live. That is more useful than a synthetic still image if your actual programme contains motion or frequent cuts. For a channel that relies on a repeatable loop, verify that the part with the most movement is included in the test. Keep the notes so a later change can be assessed against the same conditions. If you are planning content and presentation as well as the technical setup, the guide to scheduling pre-recorded videos on YouTube is relevant to the operational side, while the checks here remain about the stream you actually send.
Troubleshoot mismatched rate or frame reports
When a value looks wrong, begin with scope. Confirm you are probing the intended input or output, selected the correct video stream, and are not confusing the source file with the encoded live output. Check whether audio was included in one rate but not the other. Verify the units and the time interval attached to each report; bit_rate, encoder statistics and observed transport values need not describe the same thing.
If frame-rate fields disagree, compare the configured output rate with avg_frame_rate, then inspect timestamps or decoded frames for a representative interval. Do not use r_frame_rate as the final answer. If the stream has irregular timestamps or is variable-rate, the average and guessed base rate can diverge for legitimate reasons. If the mismatch appears only around a cut or transition, inspect more than that brief segment before changing settings.
If bitrate reporting differs, check whether the statistic describes video alone or the whole programme, whether it is an average or a target, and whether it came from a completed file or a live session. Re-run the same probe on the actual output if possible and compare with encoder output over time. If a direct probe is unavailable for the live protocol, avoid fabricating precision: use the encoder reporting available to you alongside YouTube’s health view.
If YouTube reports a problem, verify codec, resolution, frame rate, CBR configuration and keyframe interval against its current live page. Then consider whether your available upload capacity has the recommended headroom, and whether the test included representative content. Change one setting at a time when possible, so you can tell whether the adjustment made a difference. For a long-running channel, log when you make that change and what health information follows.
A clean diagnosis may end with the conclusion that metadata alone cannot answer the question. That is useful: it keeps you from treating a guessed frame-rate base or one bitrate field as proof of a transmission failure. Keep the evidence separate, compare equivalent quantities, and use the platform’s current guidance as a reference rather than a promise.
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
How do I check the bitrate of an FFmpeg stream?
Use ffprobe to inspect a probeable input or output, including its bit_rate field, and use FFmpeg’s encoder progress or statistics to observe output over time. A reported field is not automatically a reliable measurement of changing live throughput, so compare it with YouTube’s stream-health information for the same period.
Why does ffprobe show a different frame rate?
avg_frame_rate reports an average, while r_frame_rate is FFmpeg’s guessed base rate and can reflect timestamp representation. Compare both with your configured rate and inspect timestamps or frames if the difference matters; do not treat r_frame_rate alone as the intended playback rate.
Does matching YouTube’s recommended bitrate guarantee a healthy stream?
No. The recommendation is a reference for a codec, resolution and frame-rate combination, not proof that your encoder produced that output or your connection delivered it consistently. Test representative content and monitor YouTube Live Control Room during the broadcast.
Should I use YouTube’s upload bitrate table for a live stream?
No. Live ingest and uploaded video are different workflows with separate guidance. Use the current live encoder settings page for a live broadcast and confirm the relevant codec and format row before setting a target.