Reconnect with srtsrc when ignore-pcr is true

Application Development
1

Hello hackers!

We have a srtsrc based SRT receiver that we want to be able to handle the sender going away and coming back, so we have the keep-listening property set to true.

However, we also had a tsdemux element after which had the ignore-pcr property set to true. This might be silly. We had it because we rewrite the timestamps of the incoming video ourselves using timestamps embedded in the SEI header of the h.264 frames.

So. When the sender attempts to connect again after dissapearing we get this splat on the receiver side:

WARN           srtsrc gstsrtsrc.c:226:gst_srt_src_fill:<src> discont detected 1745635056 (expected: 0)
FIXME      mpegtsbase mpegtsbase.c:1010:mpegts_base_activate_program: Refcounting issue. Setting twice a PID (0x0041) as known PES
FIXME      mpegtsbase mpegtsbase.c:1010:mpegts_base_activate_program: Refcounting issue. Setting twice a PID (0x0042) as known PES
WARN  rtpjitterbuffer rtpjitterbuffer.c:575:calculate_skew: delta - skew: 0:00:04.944996424 too big, reset skew
WARN          basesrc gstbasesrc.c:3132:gst_base_src_loop:<src> error: Internal data stream error.
WARN          basesrc gstbasesrc.c:3132:gst_base_src_loop:<src> error: streaming stopped, reason not-linked (-1)

When we remove ignore-pcr it works as expected. Is this something that is expected? The documentation of the ignore-pcr property only mentions timing, but it seems it makes us miss when there is a new “program” in the mpeg-ts stream which mess stuff up.

Is all well? Thanks!

2

Hi,

The ignore-pcr property is for coping with the insane amount of broken streams from hls (mainly).

If your stream is “broadcast-compliant” (which you’d expect with SRT) you can safely ignore that property and let it use PCR for timestamp calculation.

3

Hi,

thanks! yeah, we had it set because the mpeg-ts sender clock retrieval is not enough for us when syncing multiple different devices and we use timing embedded in the H.264 header instead. (We might have talked about this in A Coruña?)

But probably we do not need to set it and can just let it be(?). But. Is the effect on SRT re-connection expected or something that should be looked into?

4

I’m going to put aside the “multiple source” use-case for now, because that’s a Black Friday special offer on cans of worms.

  • The warning about srtsrc detecting a discont is slightly bogus (it’s not a real discont, it’s just the first packet).
  • The FIXME in tsdemux can be ignored
  • The jitterbuffer warnings makes … no sense ? Why are you using that element ?

With a single SRT Stream ( srtsrc <properties> ! video/mpegts,systreamstream=true ! decodebin3 ! queue ! autovideosink ), you should be able to have the same stream be disconnected and resuming and there should not be any timing issues.

  • Same stream => i.e. the sender isn’t switching streams, but you had a network issue of some sort
  • Timing issues => Except for that loss of signal, playback should resume at the same rate.
5

(The jitterbuffer is there, because the application this comes from relays the mpeg-ts muxed A/V stream to 2 RTP streams 1 video and 1 audio.)

So in your opinion the receiver should handle a srt disconnect / reconnect as long as the underlying mpeg-ts stream is the same?

6

I don’t see the point in using RTP in your scenario. SRT is pretty much covering the same needs (retransmission, etc…)

So yes. Start with a regular mpeg-ts over SRT and check that works fine first (it should).