Yes. YouTube Live lists AV1 as an accepted video codec for live ingestion, including frame rates up to 60 fps. For 4K at 60 fps, YouTube’s listed AV1/H.265 bitrate range is 10–40 Mbps.
That answer applies to SDR streaming, not HDR. YouTube explicitly says AV1 is not supported for HDR, so you need to check both the codec and the dynamic-range requirement before choosing an encoder or an always-on workflow.
YouTube Live does list AV1
YouTube’s official live encoder settings include AV1 among the supported video codecs. The same guidance lists frame rates up to 60 fps, so AV1 at 4K60 is within the platform’s documented live-ingest settings for SDR.
There are several separate checks hidden inside that simple answer:
- The stream must be sent using a supported live-ingest protocol, such as RTMP or RTMPS.
- The encoder must actually be capable of producing AV1 at 3840 × 2160 and 60 fps.
- The encoder must expose suitable bitrate, keyframe and, for 4K AV1, tiling controls.
- Your upload connection must sustain the selected bitrate while the stream is running.
- The content must be SDR if you are using AV1.
YouTube accepting AV1 does not mean that every application, graphics card, hardware encoder or cloud workflow can send it. Platform acceptance is one part of the chain. The source file, encoder, transport path and YouTube settings still need to agree.
It is also worth separating playback from ingestion. YouTube may deliver a video to viewers using codecs and resolutions chosen by its own processing system. That does not tell you which codec your encoder should send to YouTube. This article is about the codec used for the live feed entering YouTube.
For a pre-recorded devotional loop, study channel, ambience station or local news rotation, AV1 may therefore be a valid ingest choice when your encoding path supports it. If you are deciding how to keep the channel running overnight, first confirm the complete sending path rather than selecting AV1 because it appears in a general codec list.
The 4K60 bitrate range
For 4K, also shown as 2160p, at 60 fps, YouTube’s table gives AV1/H.265 a range of 10 Mbps to 40 Mbps. These are the values currently shown on YouTube’s encoder settings page, which you should recheck before a major broadcast because platform requirements can change.
The table must be read carefully. It groups AV1 and H.265 together for this range, while the H.264 column separately shows 35 Mbps as its recommendation for 4K60. The 35 Mbps figure should not be described as YouTube’s AV1 recommendation.
| Live video setting | YouTube-listed AV1/H.265 guidance | What to check in practice |
|---|---|---|
| Resolution | 3840 × 2160, or 2160p | Confirm the encoder is producing the intended canvas and output size |
| Frame rate | 60 fps maximum in the listed settings | Make sure the source and output are actually 60 fps if that is your aim |
| Video bitrate | 10–40 Mbps | Select a value your upload connection can sustain continuously |
| Rate control | CBR | Avoid a mode that regularly exceeds the selected ceiling |
| Keyframes | Two seconds recommended, four seconds maximum | Set the encoder deliberately rather than relying on its default |
| AV1 tiling at 3840 × 2160 and above | At least two tile columns | Check whether the encoder exposes this control |
The lower end of a published range is not automatically the right setting for every picture. A mostly static prayer slide, a slow lofi loop and a detailed weather map have different amounts of movement and fine texture. Rapid camera movement, film grain, tree leaves, water and scrolling text can all make compression more visible.
The opposite mistake is to choose the top of the range without checking the connection. A 40 Mbps video bitrate is not the entire network requirement. Transport overhead, other traffic and short-term variation need room as well. If a household connection is being used for uploads, cloud backups or other streams, those activities can interfere with an otherwise correct encoder setting.
For a 24/7 channel, consistency is more useful than chasing a setting that only works during a short test. A stable lower setting within YouTube’s stated range is preferable to a nominally higher setting that causes repeated upload congestion. You should still inspect the picture at the intended resolution and frame rate, especially where the programme contains small text or moving detail.
Do not confuse the AV1/H.265 range with a universal quality promise. YouTube’s table gives an ingestion range, not a guarantee that two different encoders will produce identical pictures at the same bitrate. The encoder implementation, source material and rate-control behaviour matter.
If your content is a long loop, the guide to loop file size can help you think about source quality and storage separately from the live bitrate. A large source file does not by itself require the same bitrate during live encoding, and a small source file cannot create detail that was never present.
Verify the encoder and ingest path
The next question is not simply whether YouTube accepts AV1. It is whether your chosen setup can create and send the required AV1 signal.
A software encoder may depend on the processor, graphics hardware, driver and application version. A standalone hardware encoder may support AV1 at some resolutions but not at 4K60, or may expose only a narrower set of rate-control and keyframe options. A capture or production application may accept an AV1 source while sending another codec to YouTube. The product name alone does not settle the matter.
Check the encoder’s own documentation for all of these points:
- AV1 video encoding, rather than AV1 decoding or playback.
- 3840 × 2160 output at 60 fps.
- CBR or an equivalent mode that keeps the live bitrate under control.
- A bitrate range that includes your selected YouTube setting.
- A two-second keyframe interval, with no interval above YouTube’s four-second maximum.
- At least two tile columns for AV1 output at 3840 × 2160 and above.
- RTMP or RTMPS output and a field for the YouTube stream key.
- SDR output if you are using AV1.
The tiling requirement is easy to miss. YouTube’s settings specify at least two tile columns for AV1-encoded streams at 3840 × 2160 and above. If your encoder has a tile-columns control, check its meaning and value in the manual. Do not assume that a setting called tiles, slices or threads means the same thing.
The transport path matters too. YouTube lists RTMP and RTMPS, and recommends RTMPS for secure transport. The protocol does not add AV1 capability to an encoder that cannot generate AV1, but an incorrect protocol, server address or stream key can prevent an otherwise suitable encoder from reaching YouTube.
YouTube’s encoder overview explains that an encoder may be software or standalone hardware. Its examples do not establish AV1 4K60 support for every named product. Treat an example encoder’s published 4K or HEVC capability as evidence only for that documented capability, not as proof that the same device supports AV1 at 4K60.
If you are running a continuous pre-recorded stream with FFmpeg, the FFmpeg YouTube loop walkthrough is relevant to the workflow, but its existence does not remove the need to verify your installed FFmpeg build and hardware encoder. Command-line flags can vary with the available codec libraries and hardware acceleration.
The same distinction applies to a spare computer. A machine that can play a 4K video smoothly may still be unable to encode AV1 at 4K60 in real time. Playback asks the machine to decode; live streaming asks it to process the source, encode each frame, maintain the selected rate control and deliver the result continuously.
AV1 is an SDR choice, not an HDR choice
The most important qualification is dynamic range. YouTube’s encoder settings state that AV1 is not supported for HDR. In other words, the documented answer is not “AV1 works for every 4K60 stream”. It is “AV1 is listed for 4K60 live ingestion when the stream is SDR”.
This matters because resolution and dynamic range are independent settings. A stream can be 3840 × 2160 and 60 fps while still being SDR. Adding HDR metadata or choosing an HDR colour workflow does not turn it into a supported AV1 HDR feed.
Check the source before you configure the output. If your programme was created in HDR, decide whether an SDR version is acceptable. Converting the content to SDR is a production decision, not merely a codec checkbox. Brightness, contrast, colour saturation and highlight detail may change during the conversion, so inspect the result before using it for a long broadcast.
For a devotional channel, the issue might appear in lamp flames, bright text or colourful artwork. For a local traffic loop, it may affect map colours and daytime footage. For an ambience stream, it may show in sunlight, skies or neon signs. These examples are not reasons to avoid AV1; they are reasons to view the actual SDR output rather than relying on the file label.
Do not infer HDR support from a device that advertises AV1 encoding. A hardware encoder can support AV1 for SDR and still not provide the HDR signalling or workflow that YouTube requires. The codec’s presence in a specification sheet is not enough.
If you are building a channel around a repeated programme, keep an SDR master and an HDR master separate where both are needed. Label the exports clearly. That reduces the chance of sending an HDR source through an AV1 preset and discovering the mismatch only after the broadcast has started.
If HDR matters, review HEVC requirements
YouTube’s HDR guidance says HDR streaming is currently supported with H.265, also known as HEVC. The official HDR requirements should be your reference when HDR is part of the plan, because the required colour settings and delivery details sit alongside the codec requirement.
This creates a practical choice rather than a universal winner:
| Your delivery requirement | Codec direction to investigate | Main check |
|---|---|---|
| 4K60 SDR live stream | AV1 or H.265, within YouTube’s listed settings | Confirm the encoder can produce the selected codec and bitrate |
| 4K60 HDR live stream | H.265/HEVC | Follow YouTube’s current HDR requirements and verify the encoder’s HDR output |
| Existing H.264 workflow | H.264 may be simpler if already validated | Check the separate H.264 bitrate guidance rather than borrowing AV1 figures |
| Pre-recorded loop with no HDR requirement | AV1 can be considered if the full path supports it | Test the overnight workflow, not only a short local encode |
HEVC is not automatically the better option for every channel. It may be the correct direction for HDR, but your encoder, operating system, application and licensing arrangements still need checking. You should also confirm that the intended YouTube ingest settings match the codec and colour workflow you have actually configured.
Conversely, AV1 is not automatically the better option simply because it is newer or appears alongside H.265 in a bitrate table. The relevant question is whether it works for your source, your required dynamic range, your encoder and your connection. For a practical operator, a verified path matters more than a codec label.
If your channel is a news or traffic loop, the rolling weather and traffic loop guide covers the programming side of keeping information current. Codec selection should remain a separate technical decision: first define what viewers must see, then choose an output path that YouTube documents for that requirement.
Test stream health before the event
Do not make the first overnight run your compatibility test. Create an unlisted or private broadcast and send the real resolution, frame rate, codec, bitrate, keyframe interval and colour mode that you intend to use. A short test can reveal configuration errors, but it cannot prove that a long stream will remain stable.
During the test, check the encoder locally and the YouTube control room separately. On the encoder side, watch for dropped frames, encoding overload, queue growth, clock drift and unexpected bitrate changes. On YouTube’s side, inspect the stream health messages, incoming resolution, frame rate and any warnings about the connection or video settings.
Use a checklist such as this:
- Confirm the YouTube stream key belongs to the intended channel and event.
- Use RTMPS if your encoder supports the recommended secure transport.
- Set the output to 3840 × 2160 and 60 fps only if the source and encoder can sustain it.
- Select AV1 for an SDR stream, not an HDR stream.
- Set CBR and choose a bitrate between 10 Mbps and 40 Mbps for AV1/H.265 at 4K60.
- Set a two-second keyframe interval and ensure it does not exceed four seconds.
- Confirm at least two AV1 tile columns at 3840 × 2160 and above.
- Check that the actual incoming stream matches the intended settings.
- Watch the upload connection while other household or office traffic is active.
- Leave enough time to stop, change one setting and test again.
Change one variable at a time. If you change the codec, bitrate, output resolution and transport together, you will not know which change fixed the problem. Record the working settings in a plain text note so that a restart does not depend on memory.
For a 24/7 channel, include recovery in the test. Stop the encoder and start it again. Check what happens after a brief network interruption. Confirm that the source loop resumes at the expected point and that the YouTube event does not require manual intervention that you will not be available to provide overnight.
A cloud workflow can remove the need to leave your personal computer running, but it does not remove the need to validate the stream key, source file, codec and YouTube event. StreamNeo is useful when you want to upload the file once, connect the YouTube stream key and have the broadcast continue while your own computer is switched off, with automatic monitoring and restart for drops.
If you prefer to operate locally, compare the practical limits of a spare machine with the VPS and spare-computer comparison. The relevant questions are whether the machine can encode the chosen format continuously, whether the connection is dependable and whether someone can respond when the stream needs attention.
Choose from the requirement, not the codec name
The decision can be reduced to a few questions. Is the programme SDR or HDR? Does the encoder document AV1 at 4K60, or only AV1 playback? Can the selected path expose CBR, keyframes and the AV1 tile setting? Can the upload connection carry the bitrate without competing traffic causing trouble?
If the answers are clear, AV1 is a documented option for a 4K60 SDR YouTube Live stream. If HDR is essential, investigate HEVC against YouTube’s current HDR requirements instead. If the encoder cannot confirm AV1 4K60 support, select a documented workflow rather than assuming that a general AV1 label covers the missing details.
Keep YouTube’s official settings page open when you configure the broadcast. The figures and codec rules are platform requirements, not permanent hardware facts. Before a public event, recheck the official page and run the complete path with the actual programme material.
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 YouTube Live accept AV1 at 4K60?
Yes. YouTube’s encoder settings list AV1 as a supported video codec and allow frame rates up to 60 fps. For 4K60, the documented AV1/H.265 bitrate range is 10–40 Mbps, provided the encoder and ingest path can produce those settings.
Can I use AV1 for YouTube Live HDR?
No. YouTube’s encoder guidance says AV1 is not supported for HDR. YouTube’s HDR requirements currently point to H.265/HEVC, so check the official HDR page before configuring an HDR broadcast.
Is 35 Mbps the AV1 recommendation for 4K60?
No. YouTube’s table shows 35 Mbps in the H.264 column. For AV1/H.265 at 4K60, the listed range is 10–40 Mbps.
Does an AV1-capable computer automatically support AV1 4K60 streaming?
No. AV1 playback or lower-resolution encoding does not prove that the system can encode 3840 × 2160 at 60 fps for live delivery. Check the encoder documentation for resolution, frame rate, CBR, keyframes, tiling, transport and SDR/HDR behaviour, then test the complete stream.