Skip to main content
RTMP and SRT ingest require a continuous, monotonic timestamp timeline. When the encoder sends frames with timestamps that move backward, reset mid-stream, or repeat unexpectedly, the Gcore transcoder and downstream components — CDN, packager, and end players — can produce damaged segments, audio/video drift, or reject the stream entirely. PTS (Presentation Timestamp) controls when a frame is displayed; DTS (Decoding Timestamp) controls when it is decoded. When frames arrive and decode in display order, PTS and DTS are equal.
The recommended RTMP and SRT low-latency configurations disable B-frames, which eliminates frame reordering and keeps PTS and DTS equal throughout the session.

​
Timestamp problems

An encoder that produces any of these patterns creates an unrecoverable or difficult-to-recover ingest condition: The correct behavior is a strictly increasing sequence with a consistent increment:
These timestamp errors affect different stages of the transcoding and delivery pipeline.

​
Gcore transcoder behavior

When PTS/DTS timestamps arrive damaged or inconsistent, the transcoder attempts several forms of recovery. It may drop frames or introduce momentary visual artifacts while trying to reconstruct the correct order. If timestamps jump backward or become impossible to interpret, the decoder can trigger a full reset, causing brief interruptions in the output. Incorrect PTS values can also produce segments that are too short, too long, or overlapping. This breaks the timing model required for HLS and DASH. Low-latency variants — LL-HLS and LL-DASH — can become unsynchronized because their chunk boundaries no longer match real frame timing. As the transcoder attempts to normalize the timeline, A/V alignment may shift across renditions. Players often compensate by dropping or repeating frames, which can result in noticeable sync errors. To rebuild a usable timestamp sequence, the transcoder may buffer additional frames internally. This buffering pushes the entire pipeline further from real time, degrading low-latency performance. If timestamps are severely corrupted and cannot be repaired, the ingest layer or the transcoder may reject the stream entirely to prevent downstream delivery failures. The combined effect on playback includes buffering, stalled video, audio ahead or behind video, abrupt quality switches from ABR logic errors, and complete playback failure on Smart TVs and mobile players. If these symptoms appear during playback, inspect the encoder output to determine whether the source timestamps are the cause.

​
Diagnose timestamp issues

Use ffprobe (part of the FFmpeg package) to inspect PTS and DTS values in a recorded encoder output. Most encoders support local recording alongside active streaming — record a short segment, then analyze it:
Output shows one line per video packet with pts_time, dts_time, and packet flags (K_ marks a keyframe):
A non-monotonic PTS appears as a line where pts_time is lower than the previous value:
Look for repeated PTS values or sudden large jumps as well. Any of these patterns indicate an encoder configuration or source issue that must be corrected before the stream reaches the ingest point. For SRT ingest, also monitor sender-side SRT statistics — rising pktLoss and pktRetrans values indicate network conditions that can produce late or dropped packets at the ingest boundary, contributing to timestamp instability.

​
Fix encoder settings

Encoder-side B-frames and lookahead buffers are the most common sources of timestamp instability in live ingest. Disabling them produces a monotonic, gapless PTS/DTS stream compatible with Gcore ingest:
  • Disable B-frames: bframes=0
  • Disable scene cuts: scenecut=0
  • Disable deep lookahead: rc-lookahead=0
  • Use fixed GOP intervals — keyframe every 1–2 seconds
  • Use low-latency presets: -preset veryfast -tune zerolatency
The RTMP and SRT low-latency configurations apply all of these settings, with complete encoder commands for FFmpeg, OBS, GStreamer, and vMix.