RTSP replay streaming from ONVIF NVR

Application Development
1

I am trying to replay archived video from a Hanwha(Samsung) NVR via RTSP and using the onvif extensions (i.e. onvif-mode on rtspsrc) for doing trickplay commands for things like seeking or speed changes. It’s largely been going quite well with things working as expected, but after some time has elapsed I noticed that the stream can become frozen for a long period of time when doing seeks.

After digging around a little I have realised the source of the problem but am not experienced enough wtih gstreamer to know how to proceed with a hack or something to work around the issue.

What happens is after the stream has been playing for a while, and the RTP stream has progressed to a point where the SEQ num is > 32768 if I perform a trick play seek, the rtpjitterbuffer gobbles all of the RTP packets up and does not push any buffers until the SEQ number wraps back around from 65535 to 0 again in the stream, and then the jitterbuffer emits data once more.

Setting the GST_DEBUG=rtpjitterbuffer:5 I can see that it’s dropping packets because it’s treating any seq number of 32768 or higher as being less than the seq base of due to the way function gst_rtp_buffer_compare_seqnum casts the difference to a signed gint16. For example I will just get this in the debug output:

packet seqnum #46223 before seqnum-base #0
packet seqnum #46224 before seqnum-base #0
packet seqnum #46225 before seqnum-base #0
…
packet seqnum #65535 before seqnum-base #0
And then the stream resumes as it wraps back to 0.

Everything works fine in the stream so long as the SEQ number isn’t in the region 32768-65535 and a seek is performed which seems to cause the upset.

Any ideas of what I could do to remedy this issue would be greatly appreciated, for example if there’s a way anybody knows of how to disable reordering in the jitterbuffer as my application will always be tunneling the RTP over RTSP anyway so never out of order, or maybe some way I can prevent the seq base from being reset to 0, or maybe force it to -1 or something so it rebases on the following packet.

Thanks in advance,

Adam

1 Like
2

What GStreamer version is this with?

3

This is with version 1.24.5

EDIT: I’ve just upgrade to 1.26.0 for convenience. Unfortunately, still have the same issue.

4

I’ve narrowed this down further, and believe the root cause is that the RTSP PLAY rseponse from the NVR reports a seq=0 in the RTP-Info header even though the RTP seq numbers just continue where they last were. I’ll try to get them to patch the firmware but the chances are slim, so I am still a bit stuck on where I could fudge this if I have no joy with the vendor. I suppose intercepting the play response to modify the RTP-Info would be maybe a good start?