A prerecorded stream that lags or freezes in StreamYard is often a source-video problem, so check the file and re-encode it before changing your internet setup. StreamYard’s guidance points to HandBrake, MP4 with H.264 video, and a maximum prerecorded-upload bitrate of 10 Mbps.
First work out whether the trouble is happening while the file uploads or while viewers watch the broadcast. A wired connection may help an unreliable upload, but it cannot repair the encoding or playback of a video that has already uploaded.
Identify when the buffering happens
“Buffering” can describe several different things: an upload that stalls, a video that pauses during playback, a stream that looks choppy, or an audio and picture mismatch. StreamYard’s prerecorded-stream help page uses the question “Why is my pre-recorded stream lagging?” and recommends re-encoding the video. That is a useful first distinction: a symptom visible during the scheduled broadcast deserves a source-file check, not an automatic assumption that your connection is too slow.
Note when the problem starts and who can see it. If the upload progress stops or fails on your computer, the immediate issue may be the connection or the upload process. If the upload completed but viewers report freezes once the prerecorded broadcast is playing, focus first on the source video’s format, bitrate, and encoding. If you can, watch the broadcast yourself and note whether the picture, sound, or both pause.
Also separate buffering from a low-resolution or blurry picture. A stream can appear soft without actually stopping, and a playback pause is not the same as an audio sync issue. These clues do not prove a cause, but they help avoid applying a fix to the wrong stage. StreamYard’s separate live-stream health checks for blurry or laggy video are useful context, but prerecorded uploads have their own file optimisation guidance.
Make a short note before changing anything: the file type, any bitrate information shown by your media software, whether the upload completed, and the point in the programme where viewers noticed trouble. Keep the original file untouched. If re-encoding improves the result, you will want to know which version went into the broadcast; if it does not, you can return to the original and test a different cause.
Check the source video
Start with the file you supplied to StreamYard, not a cable, router, or playback device. Check that it is an MP4 and that its video encoding is H.264, the combination identified in StreamYard’s prerecorded streaming requirements. A filename ending in .mp4 alone does not tell you everything about the contents, so inspect the file with a media-information tool if you are unsure.
Look at the bitrate, which describes how much data the video uses each second. StreamYard’s stated ceiling for prerecorded uploads is 10 Mbps. Its optimisation help advises reducing a file above that ceiling because a high bitrate may lead to lagging or freezing. Do not confuse this with your internet upload speed: one is a property of the encoded video file, while the other describes how quickly your connection can send data.
If you are working with a long music, devotional, news, or study programme, the file may have been exported using settings intended for a high-quality master rather than a web upload. That can leave it larger or more demanding than necessary. Check whether the source also has unusual dimensions, variable frame behaviour, or separate audio timing, but do not make unsupported changes simply because a setting looks unfamiliar. Begin with the supported format and bitrate, then re-encode using the recommended options.
Check the current plan’s upload size and duration rules before retrying a large file. StreamYard lists plan-dependent limits on its prerecorded-stream page, and these can change. Because the limits vary by plan, confirm them on the current help page rather than relying on an old screenshot or another creator’s account details. A file-size restriction can prevent a complete upload; it is not evidence that the already-playing video’s bitrate is acceptable.
A source inspection is especially useful if the original was assembled from several clips, rendered by an older editor, or downloaded from another platform. The edit may play correctly on your own computer yet still benefit from a clean, consistent export. If you are building a continuous YouTube loop from repeated footage, our guide to streaming prerecorded video around the clock with FFmpeg covers a different workflow; here, the aim is to prepare a compatible file for StreamYard’s prerecorded broadcast.
Re-encode the video with HandBrake
StreamYard points people with a lagging prerecorded stream towards re-encoding with HandBrake. Re-encoding means decoding the existing video and exporting a new copy using settings better suited to the destination. It does not change the internet connection and it cannot retroactively alter the file already uploaded; you need to upload the new copy and use it for a fresh test or broadcast.
Keep the original as a fallback, then open a copy in HandBrake. Choose an MP4 output and H.264 video encoding, and follow StreamYard’s video optimisation steps. The help page recommends enabling Web Optimized, also described as fast-start, and Align A/V Start. Those options prepare the file for web delivery and align the starting points of audio and video.
The exact HandBrake screen can vary with version and operating system, so follow the current instructions rather than matching an old screenshot pixel for pixel. Before exporting, verify that the output is MP4, the video codec is H.264, Web Optimized is enabled, and Align A/V Start is selected. If the source bitrate exceeds StreamYard’s 10 Mbps prerecorded ceiling, choose an output that brings it below that ceiling. Avoid inventing a target based on a rule of thumb: StreamYard documents the ceiling, not one universal ideal setting for every picture.
Re-encoding can make a file smaller and more suitable for upload, but it is not a way to improve a poor source. If the original is already visibly blocky or noisy, a new encode cannot restore detail that is not there. It may also take time to process, so allow the export to finish and check that the resulting file plays from beginning to end before uploading it.
Give the new file a clear name, such as evening-programme-web.mp4, rather than overwriting the master. That makes it easier to choose the correct upload in a channel workflow with recurring programmes. If a programme runs for hours, check the exported duration and sound near the start and end as well as a middle section. A successful export indicator is not a substitute for a quick playback check.
Review bitrate and file settings
The principal numeric setting in this diagnosis is StreamYard’s 10 Mbps maximum prerecorded-upload bitrate. Treat it as a file requirement, not a promise that any file just below the ceiling will play perfectly in every circumstance. A complex image can need more data than a still image at a similar visual quality, and no single number guarantees smooth playback for every viewer or network.
Keep these measurements separate:
| What you are checking | What it describes | How to use it |
|---|---|---|
| Video bitrate | Data encoded into each second of the source video | Compare with StreamYard’s 10 Mbps prerecorded ceiling and re-encode if higher |
| Upload speed | How quickly your connection sends the file from your device | Consider it when an upload is slow or fails, not as a substitute for checking the file |
| File size and duration | Total amount and running time of the prerecorded upload | Compare with the current limit for your StreamYard plan |
Audio and video settings need to work together. StreamYard’s optimisation guidance calls out Align A/V Start, which is worth enabling when exporting. After re-encoding, listen for sound that starts late or drifts relative to the picture. If the file has a sync problem, that is distinct from buffering, though the same fresh export may be a sensible test.
Do not change several unrelated settings at once. If you lower the bitrate, change resolution, alter frame rate, and convert audio in the same export, a better or worse result will not tell you which change mattered. Start by matching the documented format and ceiling, plus the recommended fast-start and alignment options. Make further changes only when you have a specific reason, such as a source setting that the editor reports as unsupported.
For a programme made from recorded sessions, check that the joins between segments are clean and that the audio track does not have gaps or unexpected silence. A pause at a predictable edit point may be in the source itself rather than a streaming failure. If the stream is a conference replay rather than a single continuous file, the recorded-session YouTube marathon workflow can help you think through sequencing separately from file playback quality.
Distinguish upload connectivity from playback
The upload stage is the point at which your computer sends the video file to StreamYard. An unstable Wi-Fi connection can interrupt or slow that transfer. StreamYard’s requirements page recommends Ethernet when possible for connection consistency, while noting that Wi-Fi works in most cases but can cause issues. In this context, a cable is a practical test if the upload keeps failing, stalls, or takes an unexpectedly long time.
That advice has a boundary. If the file finished uploading and the broadcast later freezes for viewers, plugging in Ethernet does not change the file’s codec, bitrate, or audio/video alignment. It may make your own connection more stable while you manage the studio, but do not present it as a repair for the already-uploaded programme. Re-encode and upload a corrected file when evidence points to the source.
StreamYard’s speed-testing article gives general live-broadcast guidance of at least 5 Mbps upload, with 7 Mbps or higher preferred. Those figures concern live streaming from your connection; they are not a prerecorded video bitrate rule and do not replace the 10 Mbps ceiling for the uploaded file. If you are uploading a large file, the connection affects how long the transfer takes, but a speed test alone cannot certify that the resulting video is encoded appropriately.
A practical split is to ask whether the file reaches StreamYard intact. If an upload is repeatedly interrupted, try a stable network, pause other large transfers if you can, and use Ethernet as a consistency measure. If it completes, then viewers report lag during playback, concentrate on format, bitrate, and a re-encoded test copy. If both happen, address the failed upload first so you can then make a meaningful playback test.
For a continuous channel that you need to keep running while your own computer is off, a different operating arrangement may address the burden of keeping a local playback computer available. StreamNeo turns an uploaded video into a YouTube-only 24/7 live stream and monitors and restarts the broadcast if it drops, removing the need to leave your computer running; the source file still needs to be prepared correctly. If you are planning a loop from a home Windows machine instead, the Windows PC looping guide is relevant to that separate setup decision.
Test the updated video
After HandBrake finishes, play the new file locally from the beginning, a middle point, and near the end. Listen for audio, check that the picture moves, and confirm that the programme has the duration you expect. This quick check can catch a wrong export, a truncated file, or an obvious sync issue before you spend time uploading it.
Upload the re-encoded copy as a new file rather than assuming the original has changed. Use a distinct name in StreamYard’s file selection so there is no ambiguity about which version you scheduled. If the file is rejected, consult the current upload requirements and plan limits. If upload succeeds, arrange a controlled test before relying on the file for a long unattended programme.
During the test, look for the symptom you originally recorded. A viewer pausing at the same spot each time may point towards the file or a specific segment; a problem that only occurs for one viewer could involve that viewer’s connection or device. Neither clue alone proves the cause, but repeating the test with the old and new versions can show whether re-encoding changed the behaviour.
Change one thing at a time and keep a simple record: original filename, exported filename, whether the upload completed, and what happened in playback. If the new file still lags, confirm again that it is H.264 in an MP4 container and that its bitrate is within the stated maximum. Then check the current StreamYard troubleshooting material and seek support with the file details and the point at which the problem occurs, rather than only reporting “it buffers”.
If your content is music-led, also listen for the sort of audio issue that can be mistaken for buffering: clipping, a loudness jump, or silence at a track boundary. The audio checks for a 24/7 music channel address those checks. They complement, rather than replace, the file-format and bitrate tests here.
When the file is ready, choose the operating arrangement that suits how often you need to publish and how much of the process you want to manage yourself.
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
Why is my pre-recorded stream lagging?
StreamYard’s help guidance recommends re-encoding a lagging prerecorded video with HandBrake. Check the output is MP4 with H.264 video, enable Web Optimized and Align A/V Start, and make sure the bitrate does not exceed the documented 10 Mbps ceiling.
Will Ethernet stop viewers seeing buffering?
Ethernet may help make an unreliable upload connection more consistent, especially if Wi-Fi interrupts the file transfer. It does not fix encoding or playback problems in a file that has already been uploaded and is being broadcast.
Is my internet upload speed the same as the video bitrate?
No. Upload speed describes how quickly your connection transfers data, while video bitrate describes the data encoded into each second of the source file. StreamYard’s live-stream speed guidance and prerecorded-file bitrate ceiling refer to different things.
Should I upload the re-encoded file over the original?
Keep the original and export a separately named copy so you can tell which version you tested and return to the source if needed. Upload the new copy, confirm the correct file is selected, then test playback before using it for a long scheduled broadcast.