rtspsrc resets the timestamp

[Baby Octopus]

Hi,

I'm trying to restream rtsp video coming from a IP camera. I see that rtspsrc resets the timestamp after first 5 seconds due to state change dynamically. This is causing issues in playback

This is the print that I see

gst-launch-1.0 rtspsrc location=rtsp://admin:admin@192.168.2.87:550 ! rtph264depay ! fakesink silent=0 -v -m

/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain   ******* (fakesink0:sink) (20394 bytes, dts: 0:00:04.734, pts: 0:00:04.719, duration: none, offset: -1, offset_end: -1, flags: 00002000 delta-unit ) 0x7fbbb4025cf0
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain   ******* (fakesink0:sink) (22388 bytes, dts: 0:00:04.792, pts: 0:00:04.789, duration: none, offset: -1, offset_end: -1, flags: 00002000 delta-unit ) 0x7fbbb4024130
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain   ******* (fakesink0:sink) (20210 bytes, dts: 0:00:04.802, pts: 0:00:04.789, duration: none, offset: -1, offset_end: -1, flags: 00002000 delta-unit ) 0x7fbbb4024df0
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain   ******* (fakesink0:sink) (21287 bytes, dts: 0:00:04.863, pts: 0:00:04.859, duration: none, offset: -1, offset_end: -1, flags: 00002000 delta-unit ) 0x7fbbb40248a0
Got message #216 from element "rtpsession0" (element): /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0/GstRtpBin:manager/GstRtpSsrcDemux:rtpssrcdemux0.GstPad:rtcp_src_4294961314: caps = "application/x-rtcp\,\ ssrc\=\(uint\)4294961314"
application/x-rtp-source-sdes, cname=(string)Private;
/GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0/GstRtpBin:manager/GstRtpJitterBuffer:rtpjitterbuffer0.GstPad:sink_rtcp: caps = "application/x-rtcp\,\ ssrc\=\(uint\)4294961314"
Got message #220 from element "rtpsession1" (element): application/x-rtp-source-sdes, cname=(string)Private;
Got message #227 from element "rtpptdemux1" (state-changed): GstMessageStateChanged, old-state=(GstState)GST_STATE_NULL, new-state=(GstState)GST_STATE_READY, pending-state=(GstState)GST_STATE_PLAYING;
Got message #228 from element "rtpptdemux1" (state-changed): GstMessageStateChanged, old-state=(GstState)GST_STATE_READY, new-state=(GstState)GST_STATE_PAUSED, pending-state=(GstState)GST_STATE_PLAYING;
Got message #229 from element "rtpptdemux1" (state-changed): GstMessageStateChanged, old-state=(GstState)GST_STATE_PAUSED, new-state=(GstState)GST_STATE_PLAYING, pending-state=(GstState)GST_STATE_VOID_PENDING;
/GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0/GstRtpBin:manager/GstRtpJitterBuffer:rtpjitterbuffer1.GstPad:sink_rtcp: caps = "application/x-rtcp\,\ ssrc\=\(uint\)3663668030"
Got message #230 from element "rtpjitterbuffer1" (state-changed): GstMessageStateChanged, old-state=(GstState)GST_STATE_NULL, new-state=(GstState)GST_STATE_READY, pending-state=(GstState)GST_STATE_PLAYING;
Got message #231 from pad "rtpjitterbuffer1:src" (stream-status): GstMessageStreamStatus, type=(GstStreamStatusType)GST_STREAM_STATUS_TYPE_CREATE, owner=(GstElement)"\(GstRtpJitterBuffer\)\ rtpjitterbuffer1", object=(GstTask)"\(GstTask\)\ rtpjitterbuffer1:src";
Got message #232 from element "rtpjitterbuffer1" (state-changed): GstMessageStateChanged, old-state=(GstState)GST_STATE_READY, new-state=(GstState)GST_STATE_PAUSED, pending-state=(GstState)GST_STATE_PLAYING;
Got message #233 from element "rtpjitterbuffer1" (state-changed): GstMessageStateChanged, old-state=(GstState)GST_STATE_PAUSED, new-state=(GstState)GST_STATE_PLAYING, pending-state=(GstState)GST_STATE_VOID_PENDING;
Got message #237 from pad "rtpjitterbuffer1:src" (stream-status): GstMessageStreamStatus, type=(GstStreamStatusType)GST_STREAM_STATUS_TYPE_ENTER, owner=(GstElement)"\(GstRtpJitterBuffer\)\ rtpjitterbuffer1", object=(GstTask)"\(GstTask\)\ rtpjitterbuffer1:src";
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain   ******* (fakesink0:sink) (22258 bytes, dts: 0:00:00.024, pts: 0:00:00.022, duration: none, offset: -1, offset_end: -1, flags: 00002000 delta-unit ) 0x7fbbb4024df0
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain   ******* (fakesink0:sink) (22823 bytes, dts: 0:00:00.028, pts: 0:00:00.022, duration: none, offset: -1, offset_end: -1, flags: 00002000 delta-unit ) 0x7fbbb40248a0
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain   ******* (fakesink0:sink) (22268 bytes, dts: 0:00:00.085, pts: 0:00:00.092, duration: none, offset: -1, offset_end: -1, flags: 00002000 delta-unit ) 0x7fbbb4024ac0
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain   ******* (fakesink0:sink) (23612 bytes, dts: 0:00:00.096, pts: 0:00:00.092, duration: none, offset: -1, offset_end: -1, flags: 00002000 delta-unit ) 0x7fbbb4023120
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain   ******* (fakesink0:sink) (23390 bytes, dts: 0:00:00.154, pts: 0:00:00.162, duration: none, offset: -1, offset_end: -1, flags: 00002000 delta-unit ) 0x7fbbb4023230
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain   ******* (fakesink0:sink) (20201 bytes, dts: 0:00:00.220, pts: 0:00:00.221, duration: none, offset: -1, offset_end: -1, flags: 00002000 delta-unit ) 0x7fbbb4023bc0
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain   ******* (fakesink0:sink) (20105 bytes, dts: 0:00:00.224, pts: 0:00:00.221, duration: none, offset: -1, offset_end: -1, flags: 00002000 delta-unit ) 0x7fbbb40239a0
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain   ******* (fakesink0:sink) (20951 bytes, dts: 0:00:00.294, pts: 0:00:00.291, duration: none, offset: -1, offset_end: -1, flags: 00002000 delta-unit ) 0x7fbbb4026040

Can someone tell why is the timestamp reset dynamically?

[Nicolas Dufresne-4]

Le mardi 29 mars 2016 à 05:41 -0700, Baby Octopus a écrit :
> I'm trying to restream rtsp video coming from a IP camera. I see that
> rtspsrc resets the timestamp after first 5 seconds due to state
> change
> dynamically. This is causing issues in playback

5 seconds sounds like the UDP transmission timeout. After that delay,
we fallback to TCP. Maybe you have one of those servers that advertise
audio and video, but sends only audio or video ? Or you have a network
firewall issue. That would result in a timeout, then a reset of the
timestamp (but with the segment it will be contiguous). Remember, the
timestamp alone does not mean much.

Nicolas
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Baby Octopus]

> 5 seconds sounds like the UDP transmission timeout. After that delay,
> we fallback to TCP
Doesn't look like UDP timeout. Media data is coming through UDP itself

> Maybe you have one of those servers that advertise
> audio and video, but sends only audio or video ?
Very much. The IP camera gives out only video and no audio. How to know if it advertises both audio as well as video?

> Or you have a network firewall issue. That would result in a timeout, then a reset of the
> timestamp (but with the segment it will be contiguous). Remember, the
> timestamp alone does not mean much.
Its a local network. No issue with firewall

[Chuck Crisler-3]

Check the SDP. It will have different sections for the different media. RTSPSRC debug level 6 (?) will log the SDP.

On Mar 29, 2016 10:32 AM, "Baby Octopus" <[hidden email]> wrote:

> 5 seconds sounds like the UDP transmission timeout. After that delay,
> we fallback to TCP
Doesn't look like UDP timeout. Media data is coming through UDP itself

> Maybe you have one of those servers that advertise
> audio and video, but sends only audio or video ?
Very much. The IP camera gives out only video and no audio. How to know if
it advertises both audio as well as video?

> Or you have a network firewall issue. That would result in a timeout, then
> a reset of the
> timestamp (but with the segment it will be contiguous). Remember, the
> timestamp alone does not mean much.
Its a local network. No issue with firewall



--
View this message in context: http://gstreamer-devel.966125.n4.nabble.com/rtspsrc-resets-the-timestamp-tp4676616p4676619.html
Sent from the GStreamer-devel mailing list archive at Nabble.com.
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Baby Octopus]

Yes, the SDP has both audio as well as video. But what should be the behaviour of rtspsrc if that's the case? Does it wait for audio and timeout, or something like that?

[Nicolas Dufresne-4]

Le mardi 29 mars 2016 à 08:07 -0700, Baby Octopus a écrit :
> Yes, the SDP has both audio as well as video. But what should be the
> behaviour of rtspsrc if that's the case? Does it wait for audio and
> timeout,
> or something like that?

As I said, it will timeout on the audio udpsrc, and will try and
fallback to TCP mode. Please, at least give it a try and disable the
timeout (set it to 0 to disable).

Nicolas
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Baby Octopus]

Hello Nicolas, thank you so much for your reply

I tried with disabling timeout property, still no luck. PTS resets and causes the video decoder to give same PTS for frames worth 5 seconds, causing playback issues on Linux :(

Interestingly, I do not see any such issues on Windows. Timestamp continuous flawlessly though state change messages are seen on windows as well after 5 seconds!!