For a 24/7 YouTube news channel on Oracle Cloud, start by testing 720p at 30 fps with H.264 video, AAC stereo audio, constant bitrate and a two-second keyframe interval. Send the stream over RTMPS, then adjust the bitrate and workload only after testing representative footage on the actual VM.
This is a starting profile, not a tested or guaranteed configuration for any Oracle instance. YouTube’s H.264 guidance for 720p30 gives 3 Mbps as the minimum and 8 Mbps as the recommended video bitrate; the right operating point depends on motion, source quality and measured performance.
A starting profile for a news feed
Use the following as a checklist for the first end-to-end test, rather than as a command that is ready to paste into every installation.
| Setting | Starting point | What to verify |
|---|---|---|
| Resolution and frame rate | 1280×720 at 30 fps | The source is suitable for progressive 720p30, and the picture remains legible on mobile screens |
| Video codec | H.264 | The installed FFmpeg build has the chosen H.264 encoder available |
| Rate control | Constant bitrate (CBR) | The encoder’s output rate behaves as intended under both quiet and busy footage |
| Video bitrate | Choose within YouTube’s 720p30 guidance, which lists 3 Mbps minimum and 8 Mbps recommended | The picture and YouTube stream-health feedback are acceptable during representative motion |
| Keyframes | Two-second interval | At 30 fps, this corresponds to a 60-frame GOP; confirm the encoder applies the interval you intend |
| Audio | AAC stereo, 44.1 kHz, 128 kbps | Speech, studio audio and any background bed are clear and stay in sync |
| Transport | RTMPS | The destination is YouTube’s ingest endpoint and the stream key is kept private |
| Picture format | Square pixels, progressive scan, Rec. 709 for SDR | The source and output do not introduce unexpected scaling, interlacing or colour shifts |
These settings give you a coherent first test, but they do not settle how to loop a file, reconnect a live source, preserve timestamps, or handle input interruptions. Those depend on the feed and the way it is delivered to FFmpeg. If your source is a collection of clips rather than a continuous feed, the FFmpeg looping guide discusses that separate part of the problem.
For a local or regional news loop, check the material as viewers will see it. A fixed lower-third, a presenter speaking to camera, scrolling headlines, map animation and fast-moving field footage all put different demands on compression. A profile that looks adequate on a static studio shot may soften text or smear motion elsewhere.
Why begin with 720p30, H.264 and AAC stereo
720p30 is a useful first point because YouTube publishes a specific H.264 bitrate row for it, and the output is less demanding than moving immediately to a higher resolution or frame rate. It is not the right answer for every channel: if your source is interlaced, has a different frame rate, or is intended to preserve finer detail, first decide how it should be converted and whether the VM can encode that conversion continuously.
H.264 is a straightforward compatibility choice for a YouTube live encoder. YouTube also documents support for other codecs, including H.265 and AV1, but codec availability depends on the FFmpeg build and encoder in use. More importantly for a first Oracle Cloud test, selecting a codec that is supported by YouTube does not show whether your chosen VM can encode your actual input without falling behind.
AAC is suitable for stereo audio in this profile. YouTube’s advanced recommendations list 44.1 kHz and 128 kbps for stereo; treat these as output settings to verify, not a promise that every source will sound better after conversion. News speech needs intelligible, stable audio more than elaborate processing. Check levels, channel mapping and sync on the real programme material, including quiet sections and transitions.
Progressive scan, square pixels and Rec. 709 for SDR are useful details to preserve through the encode. If the input has a different pixel aspect ratio, interlacing or colour range, blindly labelling the output does not repair it. Inspect a short sample before the continuous run, and avoid adding filters unless you know what they do to both picture and processor load.
For a broader preflight beyond codec choices, the YouTube live checklist is useful for checking the channel and broadcast workflow around the encoder. Keep that separate from the FFmpeg profile itself: account setup, stream destination and content readiness are not solved by a bitrate flag.
Set the bitrate and two-second keyframes
YouTube’s published H.264 guidance for 720p30 is 3 Mbps minimum and 8 Mbps recommended. Start within that range, then compare image quality and encode behaviour using footage that represents the channel. Do not assume that the top of the range is automatically best for your VM, or that a lower target will cure a CPU-bound encode.
CBR is the practical starting rate-control mode for a live ingest profile. It makes the output rate more predictable than a quality-targeted mode whose bitrate can rise and fall with scene complexity. Constant bitrate does not mean every frame has identical size or that the network path is guaranteed; it describes how the encoder manages its output rate over time.
Set a two-second keyframe interval. At 30 frames per second, that means a keyframe every 60 frames. YouTube recommends two seconds and says not to exceed four seconds. The GOP setting should be expressed in a way your selected encoder understands, and then checked in output logs or a suitable stream inspection tool. An option that is syntactically accepted is not proof that the intended keyframe cadence was produced.
Keep video and audio bitrate concepts distinct. The listed 3 Mbps minimum and 8 Mbps recommended are YouTube’s H.264 video values for 720p30, while the stereo audio recommendation is separate. Your outbound stream therefore includes both video and audio, as well as protocol overhead. Leave practical headroom in the VM’s measured network path rather than treating a nominal link rate as available exclusively to the stream.
Changing resolution changes the relevant YouTube row. The 1080p30 H.264 guidance, for example, lists 5 Mbps minimum and 14 Mbps recommended. That is not an argument to move up: higher detail can cost more to encode and transport, and a channel with text overlays may benefit more from a cleaner source or better layout than a resolution increase. Compare resolution and bitrate together, not as independent quality switches.
Send the stream to YouTube over RTMPS
Use RTMPS for the ingest connection. YouTube recommends it and describes it as a secure extension to RTMP that encrypts the stream sent to Google’s servers. Read the current YouTube encoder settings guidance for the supported settings and ingest instructions before setting up a production channel.
The destination address and stream key are credentials for the broadcast. Put the actual key only in the configured RTMPS destination, protect configuration files and logs that may expose it, and do not paste a real key into an article, public issue, screenshot or shared terminal transcript. If it is accidentally disclosed, replace it through YouTube Studio rather than assuming that obscurity will protect it.
The source side of an FFmpeg command is just as important as the output flags. A live URL may time out or drop; a local file may need looping and timestamp handling; a playlist may have gaps or mismatched audio. Reconnection options that work for one input type may be wrong for another. Test the exact input and complete command with the intended output settings before leaving it unattended.
YouTube’s live streaming help covers the platform workflow, but it does not configure your Oracle instance or make a source resilient. If you are diagnosing drops, distinguish a failure to read the input, an FFmpeg process exit, a network interruption and an ingest-side warning. A symptom that looks like “YouTube stopped” can start much earlier in the pipeline.
Adapt the profile to motion and measured VM capacity
News footage varies. A static presenter, a slow studio pan, a map with moving markers and busy street footage do not compress equally. Fine text, tickers and sharp graphics can also expose softness even when the average scene appears still. Select a target by testing those segments, not by judging a single title card.
Start with the suggested 720p30 profile and a bitrate within YouTube’s documented range. If motion looks poor but the encoder has headroom, test a different point within the range against the same scenes. If the CPU is saturated or the output falls behind, increasing bitrate is unlikely to solve that bottleneck. Reduce unnecessary filters or scaling, reconsider the frame rate or resolution, or choose a VM with more measured encode capacity.
Oracle’s published VM resources need careful interpretation. Its Linux launch tutorial shows a sample A1 instance with one OCPU, 6 GB memory and 1 Gbps bandwidth; the OCI A1 resource page describes an Always Free entitlement equivalent to two OCPUs and 12 GB memory. Oracle’s compute shapes reference describes bandwidth scaling with A1 OCPUs. These are documented allocations, not evidence that a particular FFmpeg build, source and filter chain will encode continuously.
Check the limits, quotas and usage for your own tenancy before provisioning. Availability can depend on region and account conditions, and a published network figure is not an end-to-end guarantee. The encoder may be constrained by CPU, memory, input delivery, disk reads, filters, or a build that lacks the encoder you planned to use. Measure the real workload rather than inferring encode capacity from network bandwidth.
Oracle also documents a policy under which Always Free compute may be reclaimed as idle when CPU utilization at the 95th percentile, network utilization and, for A1, memory utilization are each below 20% over a seven-day period. Check the current policy and monitor the instance; a quiet or broken stream can create operational consequences beyond viewer interruption. The Oracle Cloud versus DigitalOcean comparison can help frame the hosting decision, but the choice should follow your account limits, workload and maintenance tolerance rather than a generic claim of capacity.
Test real footage and watch stream health
Before treating the setup as ready, run a test with movement and audio similar to the intended channel. YouTube specifically advises testing before an event with audio and movement like the planned stream, and monitoring stream health while it is live. For a news loop, include a presenter, scrolling text, an animated graphic, a transition and a busier field clip. Test the actual file or feed, not a synthetic still that barely exercises encoding.
During that run, observe both the encoder and YouTube’s ingest feedback. Look for an FFmpeg process that remains active, output timestamps that continue to advance, stable audio sync and no accumulating delay. In YouTube Studio, pay attention to stream health messages, incoming bitrate and any warnings about video or audio. Use the guide to fixing common YouTube live problems when symptoms appear, but first record what happened and when rather than changing several settings at once.
On Oracle Cloud, watch CPU, memory, network and disk behaviour for the same period. A successful short run is evidence about that test only, not proof of an uninterrupted service through every source change or future workload. Repeat with the busiest footage and the filters you actually intend to use. If the source is a live feed, test its failure and recovery behaviour as well as normal operation.
For a 24/7 channel, arrange process supervision and restart-on-failure behaviour, rotate logs, monitor disk and memory, and alert on loss of input or YouTube ingest. These are operational recommendations, not guarantees from Oracle or YouTube. Document the expected process, a safe way to restart it, and the steps to rotate a stream key if it is exposed. Check the source rights, feed terms and attribution requirements separately; an encoder setting does not settle whether a particular news feed may be rebroadcast.
Tune only after locating the bottleneck
When the stream has a problem, change one relevant variable at a time and repeat the same test clip or feed segment. Otherwise, a resolution change, a different filter and a new bitrate can make it impossible to tell which change helped. Keep a small record of the settings, VM shape, FFmpeg build, source and observed symptoms for each run.
If the encoder is falling behind while CPU remains heavily loaded, inspect scaling, deinterlacing, overlays and other filters before raising bitrate. If the encoder output is steady but YouTube reports network or ingest trouble, investigate the network path and ingest configuration rather than lowering image quality reflexively. If the picture is blocky during fast movement while resources and ingest are stable, test a bitrate adjustment within the applicable guidance or revisit source quality and resolution.
Do not treat a higher OCPU count as an automatic fix. More compute may provide useful room, but the result depends on the encoder, input, software build and concurrent work. Likewise, switching to hardware acceleration is only useful if the selected instance exposes a suitable encoder and FFmpeg can use it correctly; verify that path explicitly. A profile that works after changing input resolution or adding a filter must be re-measured, since the encode workload has changed.
If the recurring pain is keeping a personal computer powered and connected through the night, StreamNeo removes that particular burden by taking an uploaded video and running it as a YouTube live stream while your computer is off. That addresses a different operating model than configuring FFmpeg on an Oracle VM, so it does not replace the tests or source decisions in this guide.
Once the channel plan, file and operating approach are clear, compare the practical options and their trade-offs before committing.
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
Which FFmpeg settings should I try first for 720p30 news?
Begin with H.264, AAC stereo, CBR, a two-second keyframe interval and RTMPS, using 720p30 if the source and editorial need suit it. For bitrate, YouTube lists 3 Mbps minimum and 8 Mbps recommended for H.264 720p30; test the actual footage and VM rather than treating either value as a guarantee.
Will an Oracle Always Free A1 instance run this continuously?
Published OCPU, memory and bandwidth allocations do not establish that a particular instance can encode your input continuously. Check the current tenancy limits and regional availability, then measure CPU, memory, network and output behaviour with the complete FFmpeg pipeline. Oracle’s idle compute policy is another reason to monitor the instance and check current documentation.
Should I use 1080p for a news channel?
Only if the source and editorial need justify it and the VM can handle the full encode workload. YouTube’s H.264 1080p30 row lists 5 Mbps minimum and 14 Mbps recommended, but those figures do not show that a given VM or network path will sustain the stream. Compare it with a tested 720p30 output using the same representative footage.
Is RTMPS enough to make a stream reliable?
No. RTMPS is the recommended secure transport to YouTube, but it does not prevent input loss, encoder failure or network interruption. Test the complete path, keep the stream key private, supervise FFmpeg and monitor YouTube’s stream health while the channel is running.