A YouTube gaming “replay” can mean rewind during a live broadcast or a recording people watch afterwards. Neither requires a timestamp flag by itself: start with FFmpeg’s normal handling, then change timestamp behaviour only if the source timeline gives you a reason.
Use -copyts when retaining the input timeline matters, and consider -start_at_zero if that retained timeline should begin at zero. For variable-frame-rate video being stream-copied, test -copytb 1 only when you have a timestamp problem to solve. Check the output and YouTube’s stream health rather than assuming a flag guarantees identical timestamps or a successful archive.
First decide what “replay” means
There are two separate replay goals. DVR lets someone pause, rewind and resume while the live broadcast is still running. An archive is a recording available after the broadcast ends. FFmpeg timestamps can affect how media is timed on its way to YouTube, but they do not turn on DVR or guarantee that YouTube will keep an archive.
If you want viewers to rewind a match while it is still live, check the DVR setting in YouTube Studio. YouTube notes that DVR may be limited or unavailable for very long streams, and viewers cannot seek to a point before the stream began. If DVR is disabled, viewers may still be able to watch a recording after the stream; that is a separate outcome. See YouTube’s DVR guidance for the current behaviour.
If you mean a saved replay of a completed gaming session, plan for a local recording as well as YouTube’s archive. YouTube says streams under 12 hours can be automatically archived, while streams longer than 12 hours may not be captured; it recommends keeping a local backup. That is a platform archive caveat, not a reason to add -copyts. Consult YouTube’s archive instructions before relying on a particular recording being available.
A third use of “replay” is rebroadcasting a file as a new live event. In that case the file’s timeline and the new broadcast’s timeline are not automatically the same thing. A game recording may have a non-zero start time or variable frame rate because of how it was captured or edited. Decide whether that original timing is meaningful before you pass it through unchanged.
Begin with FFmpeg’s normal handling
For a typical live transcode, begin without -copyts or -copytb. FFmpeg normally sanitises input timestamps rather than simply retaining every input timestamp value as-is. This is usually the sensible starting point for a regular gaming feed or a replay file that should behave like a new stream from its beginning.
The default-first approach matters because source timestamps are not always a useful clock for the destination. A file can start at an offset, contain gaps, or carry timing decisions from an earlier edit. Preserving those values without knowing what they mean can create confusing output timing rather than fix it. Conversely, if the source’s timing carries required relationships, default sanitisation may not match your intended timeline. The right choice depends on the source and the goal, not on a universal YouTube setting.
Separate timestamp handling from other encoder settings. YouTube’s live encoder guidance describes supported ingest choices including RTMP/RTMPS, supported video and audio codecs, frame rates up to 60 fps, and a recommended two-second keyframe interval that should not exceed four seconds. Match the current guidance to your chosen codec, resolution and frame rate; bitrate recommendations vary, so use the relevant row in YouTube’s table rather than copying a number from a different format.
A timestamp flag does not set codec, bitrate, keyframe interval, audio format, DVR, or the stream key. Keep those decisions separate. If you are already diagnosing output quality, the practical CBR versus VBR comparison helps frame bitrate behaviour; it does not replace inspecting timestamps.
When retaining the input timeline makes sense
FFmpeg’s -copyts tells it to retain input timestamp values instead of applying its usual sanitising behaviour. It is worth considering when an input timeline has a specific meaning you need to carry into the output, for example when the source’s timestamp offsets or timing relationships are part of the material you are processing. It is not a general-purpose way to make a live stream more reliable, and it does not enable viewer rewind.
Use it conditionally, in the global options position appropriate for your installed FFmpeg version and command. The FFmpeg documentation describes -copyts and its interactions with timestamp handling. Read the documentation for the version you actually run, since command details and behaviour should be checked against that build rather than inferred from an example elsewhere.
For example, the decision can be expressed as a small comparison rather than a fixed command recipe:
| Situation | Starting choice | What to check |
|---|---|---|
| Regular live gaming transcode, no known source offset problem | Normal FFmpeg handling | Stream health and audio/video sync |
| Replay file where existing input timestamps carry meaningful timing | Test -copyts |
Whether output timing retains the relationships you need |
| Retain source timing but make the output start at zero | Test -copyts with -start_at_zero |
Output start time and packet/frame timing |
| Variable-frame-rate video being stream-copied with non-monotonic timestamps | Test -copytb 1 |
Whether output packet timestamps are monotonic |
These are investigations, not promises. FFmpeg warns that output timestamps may still be changed by frame synchronisation and muxer processing, so -copyts does not mean byte-for-byte identity of timestamps. If the source and output need to be understood precisely, save the exact command and inspect both files rather than assuming what an option did.
Shift the retained timeline to zero when appropriate
Sometimes you need to preserve relative timing but do not want output to begin at the source’s original offset. In that case, -start_at_zero is used together with -copyts to shift the retained timeline so it starts at zero. It is not a standalone switch that preserves timestamps, and it is not something to add merely because the destination is YouTube.
The combination is a useful hypothesis when a source begins at a non-zero time and that offset is not wanted in the outgoing stream, but its timing relationships still matter. After applying it, inspect the output start time and the timestamps of representative packets or frames. FFmpeg’s synchronisation and muxer stages can still affect what is written, so verify rather than infer that every value has been preserved exactly.
For a stream-copy rebroadcast of a file, ask first whether the input offset is deliberate. If the video begins at a meaningful timestamp because of an edit or source workflow, shifting it may be wrong. If the file should simply begin as a fresh programme, normal handling may be adequate, or the combined options may be worth testing if you need the original relative timing. In either case, test on a representative segment before scheduling a public session.
DVR is a separate control. When a viewer wants to jump backwards during the ongoing stream, change or confirm the DVR setting in Studio and test the actual event path. Do not add -copyts as a substitute. For the wider operational question of running a loop continuously, the guide to building a 24/7 Marathi music channel covers channel planning, while the timestamp choice remains specific to your media source.
Treat -copytb 1 as a targeted stream-copy test
-copytb 1 selects the demuxer timebase. FFmpeg identifies it as a possible aid for variable-frame-rate video being stream-copied, where it may avoid non-monotonic timestamps. That is a narrow use case: it is not a default setting for live streaming, and it is not a general replacement for diagnosing timestamps.
First establish that you are stream-copying video rather than re-encoding it. Then establish that the source is variable frame rate and that the output actually shows non-monotonic timestamps or a related muxing issue. If those conditions apply, test -copytb 1 against the same source and inspect output packet timing. If the problem persists, collect the FFmpeg version, full command, input probe and output probe before changing more options.
A transcode and a stream copy have different processing paths. In a transcode, frames are decoded and encoded again, so rate control, frame synchronisation and encoder settings are also relevant. In a stream copy, compressed packets are passed through, and timebase representation can matter differently. Do not conflate “timestamp issue” with dropped frames, upload congestion, unsupported encoding settings, or a bad capture file.
For a planned stream of a local replay, a short private or unlisted test with the actual file is more useful than trying a handful of flags in a long public session. The YouTube Live Control Room preview and stream-health checks let you check what YouTube is receiving. For a continuous playlist workflow, replacing a video in a running OBS playlist is a separate operational concern from the timestamps of the individual file.
Inspect the output and check synchronisation
A useful diagnosis starts with evidence from the exact source and output. Keep the FFmpeg command, the output of ffmpeg -version, and probes of both input and output. Compare stream start times, packet or frame presentation timestamps (PTS), decoding timestamps (DTS), and time bases. Look for missing timestamps, discontinuities, or values that move backwards where the muxer expects increasing timing.
A probe can show whether the streams start at different times or whether the source itself has gaps. A packet or frame inspection can help establish whether the output timing changed during processing. If only the video stream is being copied and the audio is encoded, inspect both: apparent lip-sync drift may involve the relation between tracks rather than a single video timestamp. No one option should be assumed to repair that without identifying where the mismatch begins.
Compare a few points across the clip, including the beginning and a later section with representative gameplay motion and audio. Confirm that playback remains in sync, that motion is not visibly uneven, and that the output file can be played locally. If YouTube reports stream health problems, use its feedback alongside the local checks; a valid local file does not prove the ingest is healthy, and a healthy ingest does not prove that YouTube will retain an archive.
YouTube recommends testing with representative content and checking the Live Control Room preview and stream health before relying on a live session. Keep a local recording and confirm that it is growing and playable while the broadcast runs. If a replay matters, that independent copy is useful even when the platform archive is expected. The bandwidth guide for live streaming can help with a separate network diagnosis, but bandwidth is not a reason to change timestamp flags without evidence.
Prepare the broadcast around the file
Before a public stream, identify whether the video is being re-encoded or copied, whether its frame rate is constant or variable, and whether its starting offset is intentional. Write down the outcome you want: a fresh timeline, retained source timing, or retained relative timing beginning at zero. That short decision record helps you avoid changing several options at once and losing track of what resolved a symptom.
Then match ingest settings to YouTube’s current encoder table for the actual resolution and frame rate. YouTube’s general guidance includes a two-second keyframe interval recommendation, a maximum interval of four seconds, and supported codecs and protocols; those are encoder constraints, not timestamp-preservation instructions. If using RTMPS, obtain the ingest URL and stream key from Live Control Room, and treat the key as a credential. Do not put a real key in a sample command, screenshot or shared log.
For a rebroadcast file, test the actual opening and a representative later scene. Watch the preview, listen for audio alignment, and confirm the local archive file is usable. If you run the channel from a computer that must stay powered on, plan for restart and monitoring behaviour separately from FFmpeg timestamp configuration. When that is the operational pain point, StreamNeo can take an uploaded video and run it as a YouTube live stream without keeping your computer on, so you are not relying on a home machine staying awake through the night.
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
Should I use -copyts for every YouTube gaming replay?
No. Start with normal FFmpeg timestamp handling for a typical live transcode or a file that should begin as a fresh stream. Test -copyts only when the input timeline has timing information you need to retain, and inspect what the output actually contains.
Does -start_at_zero turn on DVR?
No. It shifts the retained timestamp timeline when used with -copyts; it does not change YouTube’s DVR setting. Enable and test DVR in YouTube Studio if viewers should rewind during the live broadcast.
When should I try -copytb 1?
Try it as a targeted test when you are stream-copying variable-frame-rate video and have evidence of non-monotonic timestamps. It is not a universal live-stream setting, and you should compare packet timing before and after against the same source.
Can timestamp flags guarantee that YouTube archives my stream?
No. YouTube’s archive guidance says streams under 12 hours can be automatically archived and warns that longer streams may not be captured. Keep a local recording when the replay matters, and check the current official guidance for the stream you plan to run.