rtpjitterbuffer segfault after repeated RTSP start/stop in same process

--00000000000067e7db0647bab185
Content-Type: text/plain; charset="UTF-8"

Hello,

I am experiencing a segmentation fault inside rtpjitterbuffer and wanted to
ask whether anyone has encountered a similar issue before.

The crash happens when I repeatedly start and stop an RTSP stream from the
same application/process. The first runs work fine, but after several RTSP
open/close cycles, a segfault occurs inside rtpjitterbuffer. This is not a
fork/exec case; the pipeline is created and torn down multiple times within
a single process.

The issue becomes more reproducible under unstable network conditions
(jitter, packet reordering, burst loss), but the repeated RTSP usage itself
seems to be a key factor.

I am trying to understand:

- Has anyone seen segfaults in rtpjitterbuffer related to repeated pipeline
setup/teardown?
- Are there known assumptions about jitterbuffer internal state (latency,
pt-map, reordering window, timers, etc.) that could be violated in this
scenario?
- Is there a recommended way to properly reset or flush rtpjitterbuffer
state when stopping an RTSP stream?
- Any advice on where to instrument or add sanity checks while debugging
this would be very helpful.

If needed, I can share a backtrace, pipeline description, or more details
about the RTP stream characteristics.

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

<div dir=3D"ltr">Hello,<br><br>I am experiencing a segmentation fault insid=
e rtpjitterbuffer and wanted to ask whether anyone has encountered a simila=
r issue before.<br><br>The crash happens when I repeatedly start and stop a=
n RTSP stream from the same application/process. The first runs work fine, =
but after several RTSP open/close cycles, a segfault occurs inside rtpjitte=
rbuffer. This is not a fork/exec case; the pipeline is created and torn dow=
n multiple times within a single process.<br><br>The issue becomes more rep=
roducible under unstable network conditions (jitter, packet reordering, bur=
st loss), but the repeated RTSP usage itself seems to be a key factor.<br><=
br>I am trying to understand:<br><br>- Has anyone seen segfaults in rtpjitt=
erbuffer related to repeated pipeline setup/teardown?<br>- Are there known =
assumptions about jitterbuffer internal state (latency, pt-map, reordering =
window, timers, etc.) that could be violated in this scenario?<br>- Is ther=
e a recommended way to properly reset or flush rtpjitterbuffer state when s=
topping an RTSP stream?<br>- Any advice on where to instrument or add sanit=
y checks while debugging this would be very helpful.<br><br>If needed, I ca=
n share a backtrace, pipeline description, or more details about the RTP st=
ream characteristics.<br></div>

--00000000000067e7db0647bab185--