To rotate a pre-recorded video on YouTube Live from a Raspberry Pi, first confirm how the video is oriented and whether that orientation is stored in its display metadata. Then decide whether to rotate the picture, fit it inside a target frame, or crop it, and test the resulting FFmpeg workflow on the Pi before relying on it for a long broadcast.
Rotation is a video-processing step, not just a YouTube setting. If a filter changes decoded frames, the output normally has to be encoded again; the board, FFmpeg build, input and intended output all affect whether that is practical. Treat any command as a candidate to adapt and test, not a hardware-independent recipe.
Check the source video's orientation and metadata
Start by inspecting the file rather than guessing from its filename or how a media player displays it. Record its coded width and height, frame rate, video and audio codecs, and any display-rotation metadata. A phone recording can have landscape-shaped coded frames while metadata tells a player to display them upright. Other files have already had their pixels rotated, so applying a second rotation would turn the picture sideways.
FFmpeg's ffprobe utility can report stream properties and side data, but the exact fields shown depend on the file and FFmpeg version. For example, try ffprobe -hide_banner -show_streams -show_format input.mp4 and inspect the video stream for dimensions, frame rate and any rotation-related side data. If the output is unfamiliar, check the installed tool's documentation and compare it with a frame extracted or played in a viewer that honours display metadata. Do not infer the visible orientation from width and height alone.
Also check the whole clip. A file can contain mixed shots, letterboxing, or a brief segment with a different orientation. Look at the beginning, middle and end, and listen for the audio track you intend to send. A worship recording might have been edited into a portrait canvas but have a landscape camera image placed within it; rotating the entire file would not fix that composition. A study video may have titles close to its edges, making an otherwise neat crop unreadable.
Keep an untouched copy of the source and note the facts you observed: displayed orientation, pixel dimensions, frame rate, and whether audio is present. These become the baseline for later tests. If the clip is important, render a short test output to a separate filename rather than overwriting the source. This makes it easier to compare the original and transformed frames and to back out a mistaken filter.
Choose portrait or landscape output
Choose the frame shape for the content and viewers before selecting filters or a bitrate. A vertical devotional clip intended for phone screens may suit portrait output. A landscape lecture, news loop or music visualiser may be better left wide. The shape of the source is evidence, not a requirement: decide what the intended audience should see and how much of the frame must remain visible.
YouTube receives one encoder output and transcodes it for viewers; you are not preparing a separate resolution for every viewer. Use YouTube's current encoder settings to choose a supported codec and output target, then compare the recommended ingest bitrate with the stable upload capacity at the Pi's location. A recommended bitrate is a platform target, not evidence that a particular Pi can encode the picture at that rate.
For H.264, YouTube lists recommended bitrates of 5 Mbps for 720p at 30 fps, 8 Mbps for 720p at 60 fps, 10 Mbps for 1080p at 30 fps, and 17 Mbps for 1080p at 60 fps. These are distinct output choices, not a ladder to combine. YouTube also recommends a two-second keyframe interval and says not to exceed four seconds. Check the current table before broadcasting because codec, resolution and frame rate change the relevant recommendation.
A higher frame rate or resolution can mean more work to encode and more upload capacity to sustain. When a clip is mostly a still background with gentle movement, a lower frame rate may be adequate; fast movement or scrolling text may expose judder. Use representative content to assess it rather than assuming that a nominal setting will look right. If you are comparing upload use over an always-on day, the guide to data use for an always-on YouTube radio stream helps frame the network side of that choice.
Decide whether to rotate, fit, or crop
Rotation changes the orientation of the image. Fitting changes its size and placement within a chosen canvas, usually leaving unused space where the source does not fill it. Cropping removes some of the source edges to fill the target frame. These operations solve different problems, and combining them blindly can cut off signs, faces, subtitles or instruments.
Suppose a portrait phone recording is intended for a landscape stream. You could rotate it, but that may leave the picture tall inside a wide canvas; fitting it preserves all content and adds side space. Cropping or enlarging to fill the width makes the output more immersive but loses top and bottom content. For a landscape source going to portrait, the same trade-off appears along the sides. If the important material is near an edge, fit is usually the safer first preview.
A plain rotation by a right angle can be handled with an FFmpeg transpose filter. A command fragment might use -vf transpose=1 for a clockwise transpose, but confirm the filter's direction and the actual source display orientation in your installed FFmpeg documentation. For a half-turn, a different filter or a pair of transformations may be needed. Do not paste a fragment into a production command without checking whether the file's display metadata would also cause a player or downstream stage to rotate it.
Fitting and cropping generally use scale and pad or crop filters, respectively. A conceptual fit chain could scale down to stay within a target width and height, then pad the remaining area; a crop chain scales to cover the target and cuts away the excess. Exact expressions depend on target dimensions, pixel aspect ratio, whether dimensions must be even for the chosen encoder, and the desired background. Preview a rendered frame and confirm it matches the live target rather than relying on the command's appearance.
Write down the intended result in plain terms before building the filter: for example, “upright portrait image centred in a landscape canvas, full frame retained, dark side bars acceptable.” That description provides a pass/fail test. If it instead says “fill every pixel,” explicitly identify which source area can be discarded. This is more useful than choosing a filter just because it is a familiar one.
Build the FFmpeg filter workflow
Build the video path in stages: read the file, correct orientation if needed, fit or crop to the output canvas, set an intentional frame rate if required, then encode. FFmpeg filters act on decoded frames. A simple filter fragment could be -vf "transpose=1,scale=...", but the ellipsis is deliberate: target dimensions and scaling expressions must come from your chosen canvas and the source's display geometry. Confirm filter names and options with ffmpeg -filters and the FFmpeg filter documentation for the build installed on your Pi.
Avoid doing several transformations at once until you know each stage's effect. First render a short local sample with only the orientation correction. Inspect that output. Then add the fit or crop stage, inspect again, and only then add output frame-rate and encoder settings. This catches a wrong transpose direction or unexpected crop before it becomes a long-running stream. Include a frame with movement and a frame with text or other edge-sensitive detail in the sample.
Keep audio separate in your reasoning. A video filter does not repair an absent or unsuitable audio track. Check whether the input has audio, whether it is in sync after processing, and whether the selected output codec is supported by YouTube. YouTube's encoder guide supports AAC or MP3 audio; use the current guide rather than assuming the source audio can be passed unchanged. If the source is silent by design, decide whether that is acceptable for the channel instead of adding an unrelated audio track by accident.
A sample command found online may use options that your package lacks, or an encoder that is unavailable on your Pi. Inspect ffmpeg -version and ffmpeg -encoders locally, and consult the package or OS documentation for how that build was configured. Hardware encoding support and filter availability vary; do not assume that an option valid on a desktop will be available on the board. The Raspberry Pi FFmpeg troubleshooting guide for limited RAM is relevant when a workflow fails before you even reach the network test.
Assess when video processing requires re-encoding
A stream-copy option such as -c:v copy tells FFmpeg to pass compressed video packets through rather than decode and encode the picture. That can be efficient when no pixel-level change is needed and the stream is compatible with the destination. It does not perform a transpose, scale, pad or crop on decoded frames. If the desired orientation correction must happen as a video filter, the filtered video must be encoded to a new video stream.
Some files carry display metadata that instructs compatible players how to present an image. Metadata handling is not interchangeable with filtering pixels, and support can differ across players and services. Do not assume that stream copy will preserve an arbitrary rotation operation or produce the orientation you want on YouTube. Check the displayed result through a private or unlisted test stream, and use a filter and re-encode when the image itself needs transformation.
Re-encoding adds processor work. It may also change image quality, output size and heat under sustained load. The result depends on the Pi model, cooling and power, OS, FFmpeg build, input format, filter chain, encoder and chosen frame rate and resolution. Research and documentation alone do not establish a reliable workload benchmark for your board. A YouTube bitrate recommendation does not establish one either.
If the clip already has the right pixels, aspect and supported codec, a less transformative path may avoid unnecessary encoding work. If you need to rotate or resize it, plan for encoding and measure the complete process on the actual setup. Record the board model, OS release, FFmpeg version and build, input codec, output target and stability observed during testing. If the CPU remains heavily loaded, frames are dropped, audio drifts or the device becomes hot, reduce the target workload or use a different operating arrangement rather than hoping a long broadcast will behave better.
This is where a Pi and a cloud workflow serve different priorities. A Pi gives you local control and can suit a short schedule or a project whose file and equipment you want to keep on-site, but the board, power, network and encoding process must all remain available. For a fixed prerecorded file that must keep broadcasting while your computer is off, StreamNeo removes the need to keep the Pi running and to manage its repeated local encoding; it is YouTube-only, so it is not a fit if you need another destination or a live camera contribution.
Configure repeat behaviour and YouTube output
Looping the source and connecting to YouTube are separate tasks. FFmpeg's input looping options and timestamp behaviour depend on the input and the exact command structure. A loop that seems to work in a short preview can still produce a pause, a jump in timestamps, an audio discontinuity or a restart at an unexpected point. Inspect the transition from the end of the clip back to the beginning, especially if the audio has a fade or the opening has a long silence.
Test the repeated file locally for longer than one pass and listen across the join. Check that motion and sound resume as expected and that the process does not exit at end-of-file. If the output should instead play once, do not add looping merely because a tutorial does. The article on fixing an FFmpeg YouTube loop that ends instead of repeating covers the loop-specific failure mode; use it alongside your own test, not as proof that the same flags suit your file.
For YouTube, create the live stream in Live Control Room and copy the current server URL and stream key into your encoder configuration. Prefer the RTMPS endpoint where available. Google's RTMPS ingestion documentation describes the secure transport and endpoint structure; in practice, copy the current endpoint offered in the live workflow rather than hard-coding an address from an old tutorial. Keep the stream key private. Do not paste it into a public command example, screenshot or support post.
YouTube's encoder workflow instructions explain entering the server URL and key. Use the current Live Control Room labels because its interface can change. Configure the encoder for the selected codec, frame size, frame rate, bitrate mode and keyframe interval, then verify that its output profile agrees with YouTube's current guidance. YouTube's encoder guidance calls for constant bitrate and supports H.264, H.265/HEVC and AV1 ingestion, but the available Pi encoder may not support every choice.
If you need a process supervisor to restart a failed local encoder, decide how it handles a lost network, a bad key and a deliberate stop. Automatic restart is not a substitute for checking the cause, and careless restart policies can create repeated connection attempts or obscure a broken configuration. Keep a private note of where the key is stored, restrict access to that file, and regenerate the key in YouTube if it is exposed.
Test on the target Raspberry Pi setup
A test should include the whole path, not just a successful local render. Use the actual file or a representative segment, the planned filters, encoder, network connection and YouTube destination. Test movement similar to the final channel: a static devotional image does not reveal the same encoding load as a moving camera clip or scrolling news ticker. Include the intended audio and listen through a loop boundary if the file repeats.
Watch YouTube's stream health and any status messages while the test is running. Check that the picture is upright, framing is intentional, audio is present and synchronised, and the stream does not stall or drop frames. A successful connection only confirms that a connection was made; it does not confirm a stable overnight broadcast. Run long enough to expose likely issues in your setup, including heat, storage, power and network changes, without treating one successful test as a promise of future uptime.
The Pi itself needs an OS boot medium, appropriate power and a network connection that remains available. Raspberry Pi's installation guide gives OS media recommendations, including at least 8 GB for Raspberry Pi OS Lite and at least 32 GB for desktop and Full images. Those figures concern the operating system medium, not a video archive; account separately for the space your files and logs need. Select a power supply suitable for the specific board and plan Ethernet or Wi-Fi according to the reliability of the location.
For a headless setup, Raspberry Pi OS Lite can avoid running a desktop, but remote access still needs to be configured. Make sure you can inspect logs and stop the broadcast without relying on a monitor beside the Pi. Before leaving it unattended, confirm that the process starts as intended after a restart, that the key remains private, and that you know how to recover if the stream or network fails. Avoid claiming a particular model can handle a target until you have measured that exact workload.
If you decide local encoding is more effort than the channel needs, compare alternatives on the basis of control, ongoing operation, destinations and file handling. YouTube's encoder directory includes cloud options for continuous prerecorded streaming; check the current listing and each provider's own terms before relying on one. If you want to compare a local software workflow with a computer-based one, the OBS or FFmpeg home-PC comparison can help organise that decision. Neither a Pi nor a cloud tool removes the need to verify the actual stream in YouTube.
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
Can I rotate a video in YouTube Live Control Room?
The rotation belongs in your video workflow before or during encoding; do not expect Live Control Room to apply a transpose filter to incoming frames. Prepare and inspect the output, then send that output to the live ingest. If the source's display metadata already makes it upright, verify the result before adding another rotation.
Can I use -c:v copy with a rotation filter?
No, not for a pixel-level filter such as transpose, scale, pad or crop: stream copy does not decode and transform the frames. You need an encoding stage for filtered video. A metadata-only situation is different, but player and platform handling can vary, so test the displayed output rather than assuming copy will achieve the desired orientation.
Will every Raspberry Pi run a rotated 1080p stream?
There is no safe answer from the model name alone. The filter workload, encoder support, FFmpeg build, thermal conditions and chosen frame rate all matter, and YouTube's bitrate table is not a Pi performance benchmark. Test your exact board and configuration with representative video and monitor the result.
How do I keep a prerecorded stream repeating?
Configure the file input to loop using syntax supported by your FFmpeg build, then test more than one pass for gaps, timestamp changes and audio discontinuities. Separately verify that the encoder remains connected to YouTube and that the stream health stays acceptable. The loop option does not create or protect the YouTube connection.