Seeking Guidance: Handling PTS Discontinuities in Live Timeshift Playback After Source Interruption

[Mohamed Elnajar]

Hi GStreamer Developers,

We are working with an application (Enigma2 STB software) that implements
live DVB timeshifting, buffering the incoming Transport Stream to disk (or
potentially RAM) and allowing delayed playback.

We face a recurring challenge: when the live DVB source is temporarily
interrupted (e.g., signal loss) and then resumes, playing back from the
timeshift buffer *at a fixed delay* becomes unstable.

**Scenario:**
1. Live DVB stream is being buffered.
2. User is watching with a fixed delay (e.g., 30 seconds behind live) by
reading from the buffer. Playback is smooth.
3. The DVB signal input is temporarily lost (e.g., 5 seconds). Buffering
stops receiving data. Playback likely pauses or freezes.
4. The DVB signal returns. Buffering resumes, writing new data with current
PTS timestamps. A significant PTS gap now exists in the buffer.
5. The application calculates the correct target playback position:
`[current_buffer_end_pts] - [desired_delay]` or equivalent seek target
based on byte position/time.
6. The application issues a `seek()` operation to this target position.

**The Problem:**
Often, despite the application issuing a precise `seek()` command to the
correct delayed position after the signal returns, the GStreamer pipeline
seems to perform an aggressive resynchronization. Instead of resuming
smoothly at the target seek point (which might be just before the large PTS
gap), the playback often "jumps" much further forward, closer to the live
point (end of the buffer), effectively losing the user's desired timeshift
delay.

**Our Understanding:**
We believe this jump is GStreamer's default behavior when encountering a
large PTS discontinuity during seek/playback in what is essentially a
growing file/buffer scenario, prioritizing regaining sync with the newest
data over strictly honoring the seek target near the discontinuity.

**Seeking Guidance:**
Are there recommended GStreamer pipeline configurations, specific elements
(queues with certain properties, identity, custom buffers?), flags, or best
practices for handling this specific scenario?

Specifically, how can an application using GStreamer best achieve **stable,
delayed playback from a live-buffered stream that is prone to source
interruptions and resulting PTS discontinuities**, prioritizing the
*maintenance of the delay offset* over immediate resynchronization to the
live edge after an interruption?

Is there a way to configure the pipeline or specific elements (like
decoders, sinks, or demuxers) to be more tolerant of these gaps during
seeks, or to better handle the resumption logic to respect the
application's seek target?

Any pointers, documentation references, or examples would be greatly
appreciated. We want to ensure we are using GStreamer correctly for this
challenging timeshift use case.

Thank you for your time and the excellent framework.

Best regards,
[Mohamed, e.g., Enigma2 Community Member]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20250424/f6a3c3c0/attachment.htm>