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

--0000000000005fb962063379e9cf
Content-Type: text/plain; charset="UTF-8"

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]

--0000000000005fb962063379e9cf
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div><=
div dir=3D"auto">Hi GStreamer Developers,</div><div dir=3D"auto"><br></div>=
<div dir=3D"auto">We are working with an application (Enigma2 STB software)=
 that implements live DVB timeshifting, buffering the incoming Transport St=
ream to disk (or potentially RAM) and allowing delayed playback.</div><div =
dir=3D"auto"><br></div><div dir=3D"auto">We face a recurring challenge: whe=
n the live DVB source is temporarily interrupted (e.g., signal loss) and th=
en resumes, playing back from the timeshift buffer *at a fixed delay* becom=
es unstable.</div><div dir=3D"auto"><br></div><div dir=3D"auto">**Scenario:=
**</div><div dir=3D"auto">1. Live DVB stream is being buffered.</div><div d=
ir=3D"auto">2. User is watching with a fixed delay (e.g., 30 seconds behind=
 live) by reading from the buffer. Playback is smooth.</div><div dir=3D"aut=
o">3. The DVB signal input is temporarily lost (e.g., 5 seconds). Buffering=
 stops receiving data. Playback likely pauses or freezes.</div><div dir=3D"=
auto">4. The DVB signal returns. Buffering resumes, writing new data with c=
urrent PTS timestamps. A significant PTS gap now exists in the buffer.</div=
><div dir=3D"auto">5. The application calculates the correct target playbac=
k position: `[current_buffer_end_pts] - [desired_delay]` or equivalent seek=
 target based on byte position/time.</div><div dir=3D"auto">6. The applicat=
ion issues a `seek()` operation to this target position.</div><div dir=3D"a=
uto"><br></div><div dir=3D"auto">**The Problem:**</div><div dir=3D"auto">Of=
ten, despite the application issuing a precise `seek()` command to the corr=
ect delayed position after the signal returns, the GStreamer pipeline seems=
 to perform an aggressive resynchronization. Instead of resuming smoothly a=
t the target seek point (which might be just before the large PTS gap), the=
 playback often &quot;jumps&quot; much further forward, closer to the live =
point (end of the buffer), effectively losing the user&#39;s desired timesh=
ift delay.</div><div dir=3D"auto"><br></div><div dir=3D"auto">**Our Underst=
anding:**</div><div dir=3D"auto">We believe this jump is GStreamer&#39;s de=
fault behavior when encountering a large PTS discontinuity during seek/play=
back in what is essentially a growing file/buffer scenario, prioritizing re=
gaining sync with the newest data over strictly honoring the seek target ne=
ar the discontinuity.</div><div dir=3D"auto"><br></div><div dir=3D"auto">**=
Seeking Guidance:**</div><div dir=3D"auto">Are there recommended GStreamer =
pipeline configurations, specific elements (queues with certain properties,=
 identity, custom buffers?), flags, or best practices for handling this spe=
cific scenario?</div><div dir=3D"auto"><br></div><div dir=3D"auto">Specific=
ally, 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 in=
terruption?</div><div dir=3D"auto"><br></div><div dir=3D"auto">Is there a w=
ay to configure the pipeline or specific elements (like decoders, sinks, or=
 demuxers) to be more tolerant of these gaps during seeks, or to better han=
dle the resumption logic to respect the application&#39;s seek target?</div=
><div dir=3D"auto"><br></div><div dir=3D"auto">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.</div=
><div dir=3D"auto"><br></div><div dir=3D"auto">Thank you for your time and =
the excellent framework.</div><div dir=3D"auto"><br></div><div dir=3D"auto"=
>Best regards,</div><div dir=3D"auto">[Mohamed, e.g., Enigma2 Community Mem=
ber]</div></div>

--0000000000005fb962063379e9cf--