GNOME Bugzilla – Bug 739419
rtspsrc: not-linked after a while
Last modified: 2018-11-03 14:55:48 UTC
Created attachment 289691 [details] debug logs I have an rtspsrc stream that stop with this error: gstbasesrc.c(2932): gst_base_src_loop (): /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0/GstUDPSrc:udpsrc1: streaming task paused, reason not-linked (-1) after few minutes, attached the debug logs, please let me know if are enough to understand the problem
The video stream switches between payload 96 and 112, the seqnums are not continuous, seems like a broken stream.
yes I can see the payload change, however vlc can handle this, it probably ignore the packet with the new payload, can gstreamer do something like this?
here is a wireshark dump taken while vlc show the stream: http://195.250.34.59/temp/739419.pcapng
(In reply to comment #2) > yes I can see the payload change, however vlc can handle this, it probably > ignore the packet with the new payload, can gstreamer do something like this? not currently
Ok, If I'll do a patch to ignore packets with payload different from the one declared in the sdp (or the first received), will this be accepted?
Created attachment 291409 [details] [review] tentative patch this patch ignore rtp packets if their payload is different from the one in the caps, this way gstreamer can receive the rtsp stream from that rtsp server. The patch seems to work but I'm sure it needs a lot of improvements, please advice, thanks
ping
I retested and git master seems to handle this case properly, here are the logs: 1120:update_receiver_stats: unacceptable seqnum received 0:00:21.228405395 27403 0x143a4a0 WARN rtpsource rtpsource.c:1120:update_receiver_stats: unacceptable seqnum received 0:00:21.228476282 27403 0x143a4a0 WARN rtpsource rtpsource.c:950:calculate_jitter: cannot get clock-rate for pt 112 0:00:21.228814762 27403 0x143a4a0 WARN rtpsource rtpsource.c:1120:update_receiver_stats: unacceptable seqnum received 0:00:23.198049087 27403 0x143a4a0 WARN rtpsource rtpsource.c:1120:update_receiver_stats: unacceptable seqnum received 0:00:23.198115394 27403 0x143a4a0 WARN rtpsource rtpsource.c:950:calculate_jitter: cannot get clock-rate for pt 112 and the stream continue to play
however after a while new caps are received (on_pad_added callback) caps as string application/x-rtp, media=(string)video, payload=(int)112, clock-rate=(int)90000, encoding-name=(string)H264, profile-level-id=(string)4D0014, packetization-mode=(string)0, sprop-parameter-sets=(string)"Z00AH5pkAoAt2AtQUBBQIA\=\=\,aO48gA\=\=", a-Media_header=(string)"MEDIAINFO\=494D4B48010100000400000100000000000000000000000000000000000000000000000000000000\;", a-appversion=(string)1.0, ssrc=(uint)1795816497, npt-start=(guint64)0, play-speed=(double)1, play-scale=(double)1 and the pipeline error out with not-linked since payload 112 should be ignored (not in sdp). This happen randomically
So rtspsrc a) should ignore payloads that are not in the SDP and b) don't error out if only one (i.e. not all) streams are not-linked.
(In reply to Sebastian Dröge (slomo) from comment #10) > So rtspsrc a) should ignore payloads that are not in the SDP yes seems so > and b) don't > error out if only one (i.e. not all) streams are not-linked. I'm not sure about this. I think if we ignore media not in sdp and don't generate caps event for them the problem could be solved anyway (at least for this camera).
Want to provide a patch for that? Both seem like a good idea to do, b) also in general. In case you only link video and not audio of a stream for example.
I'm retesting the patch already attached, seems to work (case a), I'll let the pipeline run for an hour or so to confirm. However with this stream there is a bus message about every 2 seconds like this: 0:02:24.147087884 4182 0x1be70a0 WARN rtpjitterbuffer gstrtpjitterbuffer.c:2380:gst_rtp_jitter_buffer_chain:<rtpjitterbuffer1> buffer pt 112 caps pt 96, dropping buffer 0:02:24.147102497 4182 0x1be70a0 WARN rtpjitterbuffer gstrtpjitterbuffer.c:2751:gst_rtp_jitter_buffer_chain:<rtpjitterbuffer1> warning: Received invalid RTP payload, dropping WARNING: from element /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0/GstRtpBin:manager/GstRtpJitterBuffer:rtpjitterbuffer1: Could not decode stream. Additional debug info: gstrtpjitterbuffer.c(2751): gst_rtp_jitter_buffer_chain (): /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0/GstRtpBin:manager/GstRtpJitterBuffer:rtpjitterbuffer1: Received invalid RTP payload, dropping what do you think about this patch?
That patch will break other use cases. If anything, the filtering should happen in rtspsrc.
(In reply to Sebastian Dröge (slomo) from comment #14) > That patch will break other use cases. If anything, the filtering should > happen in rtspsrc. I suspected that, I'm looking at the code in gstrtspsrc.c
Here are some public test streams: rtsp://admin:12345@93.63.189.11:1554/Streaming/channels/601 rtsp://admin:12345@93.63.189.11:1554/Streaming/channels/401
Hi, is gst_rtp_session_chain_recv_rtp http://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/gst/rtpmanager/gstrtpsession.c#n1777 the right place to drop rtp packet with payload not in caps? I'm having some problems to fully understand rtpsrc code, can you give me some hints? thanks
No, the dropping should happen in gstrtspsrc.c somewhere IMHO. In rtpsession and rtpjitterbuffer there are cases when there are a) no payload type and other things in the caps and b) multiple payload types or ssrc in the same stream.
Created attachment 307213 [details] [review] tentative patch v2 Ok, take a look to this patch then, thanks!
(In reply to Nicola from comment #19) > Created attachment 307213 [details] [review] [review] > tentative patch v2 > > Ok, take a look to this patch then, thanks! This works for rtsp over tcp only, now I'll try to find where rtp over udp packets are processed too, maybe there is a common function ...
Ok, seems that rtp packet go to gst_rtp_session_chain_recv_rtp in gstrtpsession.c
Maybe needs a pad probe for UDP... or maybe rtpsession should have a way to let rtspsrc (or the application) decide which payloads to accept and which not.
a pad probe seems simpler to me, if you agree I can proceed this way
It's also more expensive :)
a new property for rtpbin then? Something like accept_paylod, unsigned integer, -1 mean any payload, a valid value mean that payload only
do you think my patch for tcp mode is correct? Maybe I need to loop over ptmap instead of use default_pt
I would've thought of a signal in rtpsession where the application (or rtspsrc here) can decide whether a new payload (payload type and ssrc) should be exposed or ignored.
Ignore that comment :) So what should happen is that rtspsrc should just not expose the pads from rtpbin that refer to a payload the SDP does not talk about. So in pad-added from the rtpbin you would filter things. And this should not cause not-linked errors, if it does something else is broken. Also as it is now it shouldn't really cause not-linked errors.
I don't fully understand you suggestion sorry :( suppose you have an rtsp media with audio + video (example here rtsp://admin:12345@93.63.189.11:1554/Streaming/channels/401) 1) new_manager_pad (http://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/gst/rtsp/gstrtspsrc.c#n2914) is called two time, video has pt 96 and audio has pt 0 2) about every two seconds on the rtp video session arrive an rtp packet with a wrong sequence number and payload set to 112 (so no new pad is added, is the same pad already created) 3) request_pt_map is called (http://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/gst/rtsp/gstrtspsrc.c#n3006) and return null caps since there is no stream with pt 112 4) the rtp buffer with pt 112 is passed to the next elements anyway. How we can instruct the manager to drop buffer when request-pt-map signal callback return null? (sorry for the probably trivial question)
2) sounds like the problem here. It should become a new pad, why doesn't it?
(In reply to Sebastian Dröge (slomo) from comment #30) > 2) sounds like the problem here. It should become a new pad, why doesn't it? probably because a new pad is created only if ssrc change: http://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/gst/rtpmanager/gstrtpssrcdemux.c#n627 buffer with pt 112 does not arrive in gst_rtp_pt_demux_chain, I'm trying to understand why
The ssrc stays the same but the pt changes?
(In reply to Sebastian Dröge (slomo) from comment #32) > The ssrc stays the same but the pt changes? exactly
What is this broken stream? ;) But if no new pad is created, what exactly is the problem and why?
(In reply to Sebastian Dröge (slomo) from comment #34) > What is this broken stream? ;) > only one of the broken streams I have to deal with ;) actually I receive it using the manufacter sdk, but I would like to remove this external lib and use gstreamer if possibile. > > But if no new pad is created, what exactly is the problem and why? with 1.4 version gst error out as soon as the first rtp buffer with payload 112 is received with no linked error (see initial logs) with gst-master the situation is a bit better, the stream seems to play fine, there are some warnings like the ones reported in comment 8, however the rtspreceiver error out at least one time for hour: video frames are not received anymore (I don't have specific logs for now) or on_pad_added is called with payload type 112 and after that I get not linked error. If I ignore rtp buffers with payload 112 using one of the proof of concepts patch posted the pipeline runs with no problems for several hours
ok, maybe I understood the code ... assuming that request_pt_map return NULL caps at least the second problem should not happen, and pt_maps are already created from sdp ... I launched a pipeline with log enabled to try to understand what happen after an hour or so ...
Created attachment 307239 [details] not linked after 43 minutes Here is the not linked error after 43 minutes, seems to happen after a gap
so usually rtp buffers with wrong payload are received from gstssrcdemux and dropped before rtpdemux, but after a gap if we have no luck and receive a buffer with wrong payload it go to rtpdemux new caps are emitted and so not linked error as you can see here: 0:43:04.843385004 14857 0x7f16c4002850 DEBUG rtpptdemux gstrtpptdemux.c:274:gst_rtp_pt_demux_get_caps: pt 112, got caps application/x-rtp, media=(string)video, payload=(int)96, clock-rate=(int)90000, encoding-name=(string)H264, profile-level-id=(string)4D0014, packetization-mode=(string)0, sprop-parameter-sets=(string)"Z01AKIuVAPAET8sIAABdwAAK/IQg\,aP44gA\=\=", ssrc=(uint)826811416, npt-start=(guint64)0, play-speed=(double)1, play-scale=(double)1 we are accepting caps with payload 96 for a buffer with payload 112, it is ok for you not emitting the new caps signal in this case and drop the buffer in the rtpdemux? Or have I to find another way?
this happen because we get the current caps http://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/gst/rtpmanager/gstrtpptdemux.c#n270 if request_pt_map return null caps, if we return null caps in gst_rtp_pt_demux_get_caps we get a flow error
Created attachment 307284 [details] [review] proposed fix v3 this patch should be what you asked for: now rtpptdemux drop buffers that have no payload mapping. For example rtpsrc return NULL caps in request_pt_map when the payload type is not inside sdp. I keep the fallback to the pad caps that was already there but the buffer is accepted only if its payload match the one on the pad caps. It works with both rtsp and rtspt, please review
the latest patch was tested for about 24 hours in udp and tcp mode in a mixed environment: - 1 camera that change payload type on same ssrc using rtspu - 1 camera that change payload type on same ssrc using rtspt - 4 camera that does not change payload type using rtspu - 2 camera that does not change payload type using rtspt seems to work fine
That's not what I asked for :) I think it would make more sense to have new pads created for new pt/ssrc combinations, and then let rtspsrc just ignore them if they're unknown. I thought that ignore-pt=FALSE does that already. It should in any case be controllable with a property.
Ok, but rtpptdemux seems to need a fix too, do you think it is ok to accept buffer with payload 112 with caps that have payload 96? Please see log in comment 38. Do you known use cases where this is ok? So maybe rtpptdemux should create a new pad in this case
please note that, in the specific case reported here, the buffers with wrong payload are generally already unconditionally dropped: 2:15:44.492169332 2044 0x1beae80 WARN rtpsource rtpsource.c:950:calculate_jitter: cannot get clock-rate for pt 112 2:15:44.492207441 2044 0x1beae80 WARN rtpsource rtpsource.c:1120:update_receiver_stats: unacceptable seqnum received 2:15:46.482012508 2044 0x1beae80 WARN they create problems only when for some reason (for example a gap) rtpsource pass them to the next elements, when they arrive to ptdemux new caps are generated and then the non-linked error
I think rtpptdemux should create a new pad here indeed, I thought that's what it does :) It demuxes based on the pt, while rtpssrcdemux demuxes based on the ssrc. rtpsource should indeed drop them unless there are two consecutive packets with the same pt, ssrc and consecutive seqnums.
Ok, I'll try as soon as I have some time, I thought that since ptdemux asked to the controlling element, in this case rtspsrc, for payload mapping and rtpsrc return NULL that mean it does not have a mapping for that payload (rtspsrc has mapping only for payloads declared inside sdp), this was enough to drop the buffer inside ptdemux
ignore-pt=FALSE does not add rtpptdemux to rtpbin, this does not seems a viable solution, without ptdemux the stream freeze (the pipeline show about one frame every 2 seconds) when a buffer with invalid payload is not dropped by rtpsource. Based on my tests the only viable solution is to drop the invalid buffer as the latest patch do. If you agree I can do the following: - add a new property to rtpbin, for example drop-unmapped-pt, default to FALSE, same behaviour as now - rtpbin set the property value on ptdemux (a new property for ptdemux too) - rtspsrc set drop-unmapped-pt on rtpbin to TRUE and so rtpbin set this on ptdemux - when ptdemux detect a new payload and the payload is not mapped (request_pt_map return NULL) it create a new pad if drop-unmapped-pt is FALSE otherwise the buffer is dropped and not pad is created another solution is to let ptdemux create the pad anyway and ignoring the pad in gstrtspsrc.c, for example I tryed to goto unknown_stream in new_manager_pad but this method does not produce the excepted result, the stream freeze the same way as ignore-pt=FALSE when ptdemux detect an unmapped payload thanks for your patience
Hi, Nicola! -I have the same problem but I try apply the fix in gstreamer 1.2.4 but don't work. Which is the version that you are using? -You know any public streaming to test? My test stream is not always available. Thanks!
(In reply to Alex from comment #48) > Hi, Nicola! > -I have the same problem but I try apply the fix in gstreamer > 1.2.4 but don't work. Which is the version that you are using? Please try git master or 1.5.90, probably the patch does not apply on holder versions and however it depends on post 1.4 modifications > -You know any public streaming to test? My test stream is not always > available. Please try the link posted above if it does not works I can restore it the next week when I'll return to office > > Thanks!
(In reply to Nicola from comment #49) > Please try git master or 1.5.90, probably the patch does not apply on holder > versions and however it depends on post 1.4 modifications Ok. I try with version 1.5.90. Thanks!! > Please try the link posted above if it does not works I can restore it the > next week when I'll return to office I try the link posted but is offline. If you can restore I would be grateful. Thanks!
(In reply to Alex from comment #50) > (In reply to Nicola from comment #49) > > > Please try git master or 1.5.90, probably the patch does not apply on holder > > versions and however it depends on post 1.4 modifications > > Ok. I try with version 1.5.90. Thanks!! to be more clear, you have to apply the patch here against 1.5.90 and recompile yourself, the patch it not included already > > > Please try the link posted above if it does not works I can restore it the > > next week when I'll return to office > > I try the link posted but is offline. If you can restore I would be grateful. > Thanks! ok, you have to wait the next week, I'm out of office now I tested this patch with several different hikvision dvr models and it works fine (and it does not introduce regressions for other rtsp stream), however actually I have no time to make it ready for upstream inclusion. Please let me know if it works as is for you too, thanks Nicola
(In reply to Alex from comment #50) > (In reply to Nicola from comment #49) > > > Please try git master or 1.5.90, probably the patch does not apply on holder > > versions and however it depends on post 1.4 modifications > > Ok. I try with version 1.5.90. Thanks!! > > > Please try the link posted above if it does not works I can restore it the > > next week when I'll return to office > > I try the link posted but is offline. If you can restore I would be grateful. > Thanks! here is a test rtsp url from my hikvision nvr rtsp://admin:12345@93.63.189.11:1554/Streaming/channels/601
Fwiw, I confirm I could reproduce this bug with git master. It took about 20 minutes. Will need further investigation of course.
(In reply to Nicolas Dufresne (stormer) from comment #53) > Fwiw, I confirm I could reproduce this bug with git master. It took about 20 > minutes. Will need further investigation of course. I think you get an error similar to the one posted in comment 37: - generally the packets with a payload not declared inside the sdp are dropped (with the logs posted in comment 8) - after some event such as a gap, you get new caps with payload 112 (not declared inside sdp) and you get a not linked error the attached patch fix the issue simply dropping payload not declared inside sdp inside ptdemux (tested for several days with no issue) but seems not good for inclusion, more work is needed based on Sebastian's comments
Hi Nico. I have test your fix with my system of cameras (Hikvision NVR,DS-7616NI-SP) but seem that isn't the same problem. Sometimes it is not even connect to the system I have to keep investigating... With your hikvision works fine. Good work Thanks so much for all. ;)
(In reply to Alex from comment #55) > Hi Nico. > I have test your fix with my system of cameras (Hikvision NVR,DS-7616NI-SP) > but seem that isn't the same problem. Sometimes it is not even connect to > the system > I have to keep investigating... > With your hikvision works fine. Good work > Thanks so much for all. ;) Hi Alex, can you please make your camera public? I'm interested to see what happen and if I can fix, thanks Nicola
I have same warnings with 1.10 and HiKVision cameras. Will apply the patches and see if it helps. Here is the logs: Setting pipeline to PAUSED ... Pipeline is live and does not need PREROLL ... Progress: (open) Opening Stream Progress: (connect) Connecting to rtsp://xxx:xxx@10.10.10.1:554/ISAPI/streaming/tracks/101?starttime=20161115T105041Z&endtime=20161201T160000Z RTSP request message 000000295BBFF9D0 Progress: (open) Retrieving server options request line: method: 'OPTIONS' uri: 'rtsp://10.10.10.1:554/ISAPI/streaming/tracks/101?starttime=20161115T105041Z&endtime=20161201T160000Z' version: '1.0' headers: key: 'User-Agent', value: 'GStreamer/1.10.1' key: 'User-Agent', value: 'RealMedia Player Version 6.0.9.1235 (linux-2.0-libc6-i386-gcc2.95)' key: 'ClientChallenge', value: '9e26d33f2984236010ef6253fb1887f7' key: 'CompanyID', value: 'KnKV4M4I/B2FjJ1TToLycw==' key: 'GUID', value: '00000000-0000-0000-0000-000000000000' key: 'RegionData', value: '0' key: 'PlayerStarttime', value: '[28/03/2003:22:50:23 00:00]' key: 'ClientID', value: 'Linux_2.4_6.0.9.1235_play32_RN01_EN_586' body: RTSP response message 000000295BBFFA30 status line: code: '401' reason: 'Unauthorized' version: '1.0' headers: key: 'CSeq', value: '1' key: 'WWW-Authenticate', value: 'Digest realm="Embedded Net DVR", nonce="159783995", algorithm="MD5"' key: 'WWW-Authenticate', value: 'Basic realm="/"' body: length 0 RTSP request message 000000295BBFF9D0 request line: method: 'OPTIONS' uri: 'rtsp://10.10.10.1:554/ISAPI/streaming/tracks/101?starttime=20161115T105041Z&endtime=20161201T160000Z' version: '1.0' headers: key: 'User-Agent', value: 'GStreamer/1.10.1' key: 'User-Agent', value: 'RealMedia Player Version 6.0.9.1235 (linux-2.0-libc6-i386-gcc2.95)' key: 'ClientChallenge', value: '9e26d33f2984236010ef6253fb1887f7' key: 'CompanyID', value: 'KnKV4M4I/B2FjJ1TToLycw==' key: 'GUID', value: '00000000-0000-0000-0000-000000000000' key: 'RegionData', value: '0' key: 'PlayerStarttime', value: '[28/03/2003:22:50:23 00:00]' key: 'ClientID', value: 'Linux_2.4_6.0.9.1235_play32_RN01_EN_586' key: 'Date', value: 'Fri, 09 Dec 2016 18:49:31 GMT' key: 'User-Agent', value: 'RealMedia Player Version 6.0.9.1235 (linux-2.0-libc6-i386-gcc2.95)' key: 'ClientChallenge', value: '9e26d33f2984236010ef6253fb1887f7' key: 'CompanyID', value: 'KnKV4M4I/B2FjJ1TToLycw==' key: 'GUID', value: '00000000-0000-0000-0000-000000000000' key: 'RegionData', value: '0' key: 'PlayerStarttime', value: '[28/03/2003:22:50:23 00:00]' key: 'ClientID', value: 'Linux_2.4_6.0.9.1235_play32_RN01_EN_586' body: RTSP response message 000000295BBFFA30 status line: code: '200' reason: 'OK' version: '1.0' headers: key: 'CSeq', value: '2' key: 'Public', value: 'OPTIONS' key: 'Public', value: 'DESCRIBE' key: 'Public', value: 'SETUP' key: 'Public', value: 'PLAY' key: 'Public', value: 'TEARDOWN' key: 'Public', value: 'PAUSE' key: 'Public', value: 'SET_PARAMETER' key: 'Public', value: 'GET_PARAMETER' key: 'Date', value: 'Fri, 09 Dec 2016 18:49:30 GMT' body: length 0 RTSP request message 000000295BBFF9D0 request line: method: 'DESCRIBE' uri: 'rtsp://10.10.10.1:554/ISAPI/streaming/tracks/101?starttime=20161115T105041Z&endtime=20161201T160000Z' Progress: (open) Retrieving media info version: '1.0' headers: key: 'User-Agent', value: 'GStreamer/1.10.1' key: 'Accept', value: 'application/sdp' body: RTSP response message 000000295BBFFA30 status line: code: '200' reason: 'OK' version: '1.0' headers: key: 'CSeq', value: '3' key: 'Content-Type', value: 'application/sdp' key: 'Content-Length', value: '507' key: 'Date', value: 'Fri, 09 Dec 2016 18:49:30 GMT' body: length 508 00000000 (000001BDA8C35030): 76 3d 30 0d 0a 6f 3d 2d 20 31 31 30 39 31 36 32 v=0..o=- 1109162 00000010 (000001BDA8C35040): 30 31 34 32 31 39 31 38 32 20 30 20 49 4e 20 49 014219182 0 IN I 00000020 (000001BDA8C35050): 50 34 20 30 2e 30 2e 30 2e 30 0d 0a 73 3d 48 49 P4 0.0.0.0..s=HI 00000030 (000001BDA8C35060): 4b 20 4d 65 64 69 61 20 53 65 72 76 65 72 20 56 K Media Server V 00000040 (000001BDA8C35070): 33 2e 34 2e 32 0d 0a 69 3d 48 49 4b 20 4d 65 64 3.4.2..i=HIK Med 00000050 (000001BDA8C35080): 69 61 20 53 65 72 76 65 72 20 53 65 73 73 69 6f ia Server Sessio 00000060 (000001BDA8C35090): 6e 20 44 65 73 63 72 69 70 74 69 6f 6e 20 3a 20 n Description : 00000070 (000001BDA8C350A0): 73 74 61 6e 64 61 72 64 0d 0a 65 3d 4e 4f 4e 45 standard..e=NONE 00000080 (000001BDA8C350B0): 0d 0a 63 3d 49 4e 20 49 50 34 20 30 2e 30 2e 30 ..c=IN IP4 0.0.0 00000090 (000001BDA8C350C0): 2e 30 0d 0a 74 3d 30 20 30 0d 0a 61 3d 63 6f 6e .0..t=0 0..a=con 000000a0 (000001BDA8C350D0): 74 72 6f 6c 3a 2a 0d 0a 62 3d 41 53 3a 34 31 30 trol:*..b=AS:410 000000b0 (000001BDA8C350E0): 36 0d 0a 61 3d 72 61 6e 67 65 3a 63 6c 6f 63 6b 6..a=range:clock 000000c0 (000001BDA8C350F0): 3d 32 30 31 36 31 31 31 35 54 31 30 35 30 34 31 =20161115T105041 000000d0 (000001BDA8C35100): 5a 2d 32 30 31 36 31 32 30 31 54 31 36 30 30 30 Z-20161201T16000 000000e0 (000001BDA8C35110): 30 5a 0d 0a 6d 3d 76 69 64 65 6f 20 30 20 52 54 0Z..m=video 0 RT 000000f0 (000001BDA8C35120): 50 2f 41 56 50 20 39 36 0d 0a 69 3d 56 69 64 65 P/AVP 96..i=Vide 00000100 (000001BDA8C35130): 6f 20 4d 65 64 69 61 0d 0a 61 3d 72 74 70 6d 61 o Media..a=rtpma 00000110 (000001BDA8C35140): 70 3a 39 36 20 48 32 36 34 2f 39 30 30 30 30 0d p:96 H264/90000. 00000120 (000001BDA8C35150): 0a 61 3d 66 6d 74 70 3a 39 36 20 70 72 6f 66 69 .a=fmtp:96 profi 00000130 (000001BDA8C35160): 6c 65 2d 6c 65 76 65 6c 2d 69 64 3d 34 44 30 30 le-level-id=4D00 00000140 (000001BDA8C35170): 31 34 3b 70 61 63 6b 65 74 69 7a 61 74 69 6f 6e 14;packetization 00000150 (000001BDA8C35180): 2d 6d 6f 64 65 3d 30 0d 0a 61 3d 63 6f 6e 74 72 -mode=0..a=contr 00000160 (000001BDA8C35190): 6f 6c 3a 74 72 61 63 6b 49 44 3d 76 69 64 65 6f ol:trackID=video 00000170 (000001BDA8C351A0): 0d 0a 62 3d 41 53 3a 34 30 39 36 0d 0a 61 3d 4d ..b=AS:4096..a=M 00000180 (000001BDA8C351B0): 65 64 69 61 5f 68 65 61 64 65 72 3a 4d 45 44 49 edia_header:MEDI 00000190 (000001BDA8C351C0): 41 49 4e 46 4f 3d 34 39 34 44 34 42 34 38 30 31 AINFO=494D4B4801 000001a0 (000001BDA8C351D0): 30 31 30 30 30 30 30 34 30 30 30 30 30 31 30 30 0100000400000100 000001b0 (000001BDA8C351E0): 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000 000001c0 (000001BDA8C351F0): 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000 000001d0 (000001BDA8C35200): 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000 000001e0 (000001BDA8C35210): 30 30 30 30 30 30 3b 0d 0a 61 3d 61 70 70 76 65 000000;..a=appve 000001f0 (000001BDA8C35220): 72 73 69 6f 6e 3a 31 2e 30 0d 0a 00 rsion:1.0... sdp packet 000001BDA8BD9EB0: version: '0' origin: username: '-' sess_id: '1109162014219182' sess_version: '0' nettype: 'IN' addrtype: 'IP4' addr: '0.0.0.0' session_name: 'HIK Media Server V3.4.2' information: 'HIK Media Server Session Description : standard' uri: '(NULL)' emails: email 'NONE' connection: nettype: 'IN' addrtype: 'IP4' address: '0.0.0.0' ttl: '0' addr_number: '0' bandwidths: type: 'AS' bandwidth: '4106' key: type: '(NULL)' data: '(NULL)' attributes: attribute 'control' : '*' attribute 'range' : 'clock=20161115T105041Z-20161201T160000Z' medias: media 0: media: 'video' port: '0' num_ports: '0' proto: 'RTP/AVP' formats: format '96' information: 'Video Media' bandwidths: type: 'AS' bandwidth: '4096' key: type: '(NULL)' data: '(NULL)' attributes: attribute 'rtpmap' : '96 H264/90000' attribute 'fmtp' : '96 profile-level-id=4D0014;packetization-mode=0' attribute 'control' : 'trackID=video' attribute 'Media_header' : 'MEDIAINFO=494D4B48010100000400000100000000000000000000000000000000000000000000000000000000;' attribute 'appversion' : '1.0' RTSP request message 000000295BBFF8F0 request line: Progress: (request) SETUP stream 0 method: 'SETUP' uri: 'rtsp://10.10.10.1:554/ISAPI/streaming/tracks/101?starttime=20161115T105041Z&endtime=20161201T160000Z/trackID=video' version: '1.0' headers: key: 'User-Agent', value: 'GStreamer/1.10.1' key: 'Transport', value: 'RTP/AVP;unicast;client_port=50760-50761' body: RTSP response message 000000295BBFF950 status line: code: '200' reason: 'OK' version: '1.0' headers: key: 'Session', value: '936414832;timeout=60' key: 'Transport', value: 'RTP/AVP;unicast;client_port=50760-50761;server_port=62964-62965;ssrc=37d08e70' key: 'CSeq', value: '4' key: 'Accept-Ranges', value: 'UTC' key: 'Media-Properties', value: 'Random-Access=1.0s, Unlimited, Immutable,Scales="-1, 0.5, 0.25, 0.125,:1, 2, 4"' key: 'Date', value: 'Fri, 09 Dec 2016 18:49:30 GMT' body: length 0 Progress: (open) Opened Stream Setting pipeline to PLAYING ... New clock: GstSystemClock Progress: (request) Sending PLAY request RTSP request message 000000295BBFFA40 request line: method: 'PLAY' Progress: (request) Sending PLAY request uri: 'rtsp://10.10.10.1:554/ISAPI/streaming/tracks/101?starttime=20161115T105041Z&endtime=20161201T160000Z' version: '1.0' headers: key: 'User-Agent', value: 'GStreamer/1.10.1' key: 'Range', value: 'npt=39041-' body: 0:00:00.156250000 2872 000001BDAB219D00 FIXME default gstutils.c:3826:gst_pad_create_stream_id_internal:<fakesrc0:src> Creating random stream-id, consider implementing a deterministic way of creating a stream-id RTSP response message 000000295BBFF9E0 status line: code: '200' reason: 'OK' version: '1.0' headers: key: 'Session', value: '936414832' key: 'CSeq', value: '5' key: 'Date', value: 'Fri, 09 Dec 2016 18:49:30 GMT' body: length 0 Progress: (request) Sent PLAY request 0:00:00.296884000 2872 000001BDAB2199C0 WARN rtpsource rtpsource.c:983:calculate_jitter: cannot get clock-rate for pt 112 0:00:00.296884000 2872 000001BDAB2199C0 ERROR rtpjitterbuffer gstrtpjitterbuffer.c:1372:gst_jitter_buffer_sink_parse_caps:<rtpjitterbuffer0> Got caps with wrong payload type (got 96, expected 112) 0:00:00.296884000 2872 000001BDAB2199C0 WARN rtpjitterbuffer gstrtpjitterbuffer.c:3133:gst_rtp_jitter_buffer_chain:<rtpjitterbuffer0> No clock-rate in caps!, dropping buffer 0:00:00.296884000 2872 000001BDAB2199C0 WARN rtpjitterbuffer gstrtpjitterbuffer.c:3133:gst_rtp_jitter_buffer_chain:<rtpjitterbuffer0> No clock-rate in caps!, dropping buffer 0:00:01.312092000 2872 000001BDAB2199C0 WARN rtpsource rtpsource.c:983:calculate_jitter: cannot get clock-rate for pt 112 0:00:01.312092000 2872 000001BDAB2199C0 ERROR rtpjitterbuffer gstrtpjitterbuffer.c:1372:gst_jitter_buffer_sink_parse_caps:<rtpjitterbuffer0> Got caps with wrong payload type (got 96, expected 112) 0:00:01.312092000 2872 000001BDAB2199C0 WARN rtpjitterbuffer gstrtpjitterbuffer.c:3133:gst_rtp_jitter_buffer_chain:<rtpjitterbuffer0> No clock-rate in caps!, dropping buffer 0:00:01.312092000 2872 000001BDAB2199C0 WARN rtpsource rtpsource.c:983:calculate_jitter: cannot get clock-rate for pt 112 0:00:01.312092000 2872 000001BDAB2199C0 WARN rtpjitterbuffer gstrtpjitterbuffer.c:3133:gst_rtp_jitter_buffer_chain:<rtpjitterbuffer0> No clock-rate in caps!, dropping buffer Redistribute latency... 0:00:02.299007000 2872 000001BDAB2199C0 WARN rtpsource rtpsource.c:1171:update_receiver_stats: unacceptable seqnum received (seqnr 4, delta -258, packet_rate: 89, max_dropout: 5340, max_misorder: 178) 0:00:02.299007000 2872 000001BDAB2199C0 WARN rtpsource rtpsource.c:983:calculate_jitter: cannot get clock-rate for pt 112 0:00:02.299007000 2872 000001BDAB2199C0 ERROR rtpjitterbuffer gstrtpjitterbuffer.c:1372:gst_jitter_buffer_sink_parse_caps:<rtpjitterbuffer0> Got caps with wrong payload type (got 96, expected 112) 0:00:02.314604000 2872 000001BDAB2199C0 WARN rtpjitterbuffer gstrtpjitterbuffer.c:3133:gst_rtp_jitter_buffer_chain:<rtpjitterbuffer0> No clock-rate in caps!, dropping buffer 0:00:02.314604000 2872 000001BDAB2199C0 WARN rtpjitterbuffer gstrtpjitterbuffer.c:3133:gst_rtp_jitter_buffer_chain:<rtpjitterbuffer0> No clock-rate in caps!, dropping buffer Redistribute latency... 0:00:03.310470000 2872 000001BDAB2199C0 WARN rtpsource rtpsource.c:1171:update_receiver_stats: unacceptable seqnum received (seqnr 6, delta -390, packet_rate: 89, max_dropout: 5340, max_misorder: 178) 0:00:03.310470000 2872 000001BDAB2199C0 WARN rtpsource rtpsource.c:983:calculate_jitter: cannot get clock-rate for pt 112 0:00:03.310470000 2872 000001BDAB2199C0 ERROR rtpjitterbuffer gstrtpjitterbuffer.c:1372:gst_jitter_buffer_sink_parse_caps:<rtpjitterbuffer0> Got caps with wrong payload type (got 96, expected 112) 0:00:03.310470000 2872 000001BDAB2199C0 WARN rtpjitterbuffer gstrtpjitterbuffer.c:3133:gst_rtp_jitter_buffer_chain:<rtpjitterbuffer0> No clock-rate in caps!, dropping buffer 0:00:03.310470000 2872 000001BDAB2199C0 WARN rtpjitterbuffer gstrtpjitterbuffer.c:3133:gst_rtp_jitter_buffer_chain:<rtpjitterbuffer0> No clock-rate in caps!, dropping buffer 0:00:04.313708000 2872 000001BDAB2199C0 WARN rtpsource rtpsource.c:1171:update_receiver_stats: unacceptable seqnum received (seqnr 8, delta -521, packet_rate: 89, max_dropout: 5340, max_misorder: 178) 0:00:04.313708000 2872 000001BDAB2199C0 WARN rtpsource rtpsource.c:983:calculate_jitter: cannot get clock-rate for pt 112 0:00:04.313708000 2872 000001BDAB2199C0 ERROR rtpjitterbuffer gstrtpjitterbuffer.c:1372:gst_jitter_buffer_sink_parse_caps:<rtpjitterbuffer0> Got caps with wrong payload type (got 96, expected 112) 0:00:04.313708000 2872 000001BDAB2199C0 WARN rtpjitterbuffer gstrtpjitterbuffer.c:3133:gst_rtp_jitter_buffer_chain:<rtpjitterbuffer0> No clock-rate in caps!, dropping buffer 0:00:04.313708000 2872 000001BDAB2199C0 WARN rtpjitterbuffer gstrtpjitterbuffer.c:3133:gst_rtp_jitter_buffer_chain:<rtpjitterbuffer0> No clock-rate in caps!, dropping buffer 0:00:05.313717000 2872 000001BDAB2199C0 WARN rtpsource rtpsource.c:1171:update_receiver_stats: unacceptable seqnum received (seqnr 10, delta -649, packet_rate: 88, max_dropout: 5280, max_misorder: 176) 0:00:05.313717000 2872 000001BDAB2199C0 WARN rtpsource rtpsource.c:983:calculate_jitter: cannot get clock-rate for pt 112 0:00:05.313717000 2872 000001BDAB2199C0 ERROR rtpjitterbuffer gstrtpjitterbuffer.c:1372:gst_jitter_buffer_sink_parse_caps:<rtpjitterbuffer0> Got caps with wrong payload type (got 96, expected 112) 0:00:05.313717000 2872 000001BDAB2199C0 WARN rtpjitterbuffer gstrtpjitterbuffer.c:3133:gst_rtp_jitter_buffer_chain:<rtpjitterbuffer0> No clock-rate in caps!, dropping buffer 0:00:05.313717000 2872 000001BDAB2199C0 WARN rtpjitterbuffer gstrtpjitterbuffer.c:3133:gst_rtp_jitter_buffer_chain:<rtpjitterbuffer0> No clock-rate in caps!, dropping buffer 0:00:05.532472000 2872 000001BDAAC92C80 WARN d3dvideosink d3dhelpers.c:1862:d3d_render_buffer:<fps-display-video_sink-actual-sink-d3dvideo> error: Output window was closed ERROR: from element /GstPipeline:pipeline0/GstFPSDisplaySink:fpsdisplaysink0/GstAutoVideoSink:fps-display-video_sink/GstD3DVideoSink:fps-display-video_sink-actual-sink-d3dvideo: Output window was closed Additional debug info: ../sys/d3dvideosink/d3dhelpers.c(1862): d3d_render_buffer (): /GstPipeline:pipeline0/GstFPSDisplaySink:fpsdisplaysink0/GstAutoVideoSink:fps-display-video_sink/GstD3DVideoSink:fps-display-video_sink-actual-sink-d3dvideo Execution ended after 0:00:05.376222000 Setting pipeline to PAUSED ... RTSP request message 000000295BBFFA30 request line: method: 'PAUSE' uri: 'rtsp://10.10.10.1:554/ISAPI/streaming/tracks/101?starttime=20161115T105041Z&endtime=20161201T160000Z' Setting pipeline to READY ... version: '1.0' headers: key: 'User-Agent', value: 'GStreamer/1.10.1' body: RTSP response message 000000295BBFFA90 status line: code: '200' reason: 'OK' version: '1.0' headers: key: 'CSeq', value: '6' key: 'Session', value: '936414832' key: 'Date', value: 'Fri, 09 Dec 2016 18:49:36 GMT' body: length 0 Setting pipeline to NULL ... 0:00:05.532472000 2872 000001BDAAD01690 WARN d3dvideosink d3dhelpers.c:1103:d3d_set_window_handle:<fps-display-video_sink-actual-sink-d3dvideo> Window HWND already set to: 0 Freeing pipeline ...
This patch now also needs some change in `gstrtpjitterbuffer.c` to work. Because this block changes the pt to the new *Wrong* pt: if (G_UNLIKELY (priv->last_pt != pt)) { GstCaps *caps; GST_DEBUG_OBJECT (jitterbuffer, "pt changed from %u to %u", priv->last_pt, pt); priv->last_pt = pt; /* reset clock-rate so that we get a new one */ priv->clock_rate = -1; /* Try to get the clock-rate from the caps first if we can. If there are no * caps we must fire the signal to get the clock-rate. */ if ((caps = gst_pad_get_current_caps (pad))) { gst_jitter_buffer_sink_parse_caps (jitterbuffer, caps, pt); gst_caps_unref (caps); } } Which results in this error: 0:00:00.358131000 2668 0000016BDADDD9C0 WARN rtpsource rtpsource.c:983:calculate_jitter: cannot get clock-rate for pt 112 0:00:00.359132000 2668 0000016BDADDD9C0 ERROR rtpjitterbuffer gstrtpjitterbuffer.c:1372:gst_jitter_buffer_sink_parse_caps:<rtpjitterbuffer0> Got caps with wrong payload type (got 96, expected 112) 0:00:00.359132000 2668 0000016BDADDD9C0 WARN rtpjitterbuffer gstrtpjitterbuffer.c:3133:gst_rtp_jitter_buffer_chain:<rtpjitterbuffer0> No clock-rate in caps!, dropping buffer 0:00:00.359132000 2668 0000016BDADDD9C0 WARN rtpjitterbuffer gstrtpjitterbuffer.c:3133:gst_rtp_jitter_buffer_chain:<rtpjitterbuffer0> No clock-rate in caps!, dropping buffer But If the above check would not change the last_pt to pt the patch in this bug will result in dropping the buffer in `gstrtpdemux.c`.
@Sebastian Where is the appropriate place to fix this? I will look at gstrtspsrc.c as you mentioned. That should perhaps prevent the wrong pt to go to rtpjitterbuffer in the first place.
I attached a patch to ignore pt change in the buffer. I understand there might be use-cases that changing pt may be valid, and probably there is a need to have a "ignore-pt-change" property that rtspsrc should have and set it also for the buffer/session/... (so buffer also needs to have same property, and so on) but wanted to get some feedback before changing many files. I would like to set this property for my rtspsrc because I am dealing with broken some streams with ONVIF playback that I try to fix gradually.
Created attachment 341700 [details] [review] Ignore payload change in jitter buffer
I still think what needs to happen here is that: 1) rtpptdemux creates a new pad for those spurious packets with a different pt (that's what rtpptdemux does in the end: demuxing based on the PT) 2) rtspsrc should ignore streams that have PT/SSRC that are not given in the SDP, i.e. just not link/expose pads from rtpptdemux/ssrdemux that it does not know anything about. In addition it could make sense for the demuxers to not expose pads for which no caps are known, but that seems like a separate issue. In this case, the buffers with the wrong PT should never end up in rtpjitterbuffer and not cause any confusion due to changes. Or am I missing anything here why all this can't work? Changing PT in general is something that should be supported, just not for RTSP
(In reply to Nicola from comment #47) > ignore-pt=FALSE does not add rtpptdemux to rtpbin, this does not seems a > viable solution, without ptdemux the stream freeze (the pipeline show about > one frame every 2 seconds) when a buffer with invalid payload is not dropped > by rtpsource. > > Based on my tests the only viable solution is to drop the invalid buffer as > the latest patch do. > > If you agree I can do the following: > > - add a new property to rtpbin, for example drop-unmapped-pt, default to > FALSE, same behaviour as now > - rtpbin set the property value on ptdemux (a new property for ptdemux too) > - rtspsrc set drop-unmapped-pt on rtpbin to TRUE and so rtpbin set this on > ptdemux > - when ptdemux detect a new payload and the payload is not mapped > (request_pt_map return NULL) it create a new pad if drop-unmapped-pt is > FALSE otherwise the buffer is dropped and not pad is created > > another solution is to let ptdemux create the pad anyway and ignoring the > pad in gstrtspsrc.c, > > for example I tryed to goto unknown_stream in new_manager_pad but this > method does not produce the excepted result, the stream freeze the same way > as ignore-pt=FALSE when ptdemux detect an unmapped payload > > thanks for your patience Hi Sebastian, what do you think about the solution proposed above? I still would like to send a proper patch but rtspsrc source code seems quite complex for an occasional contributor like me, I need some more detailed directions, thanks!
Adding new API for an transient solution until a full solution is implemented does not seem like a good idea. This needs to be properly analysed and then fixed accordingly. And what you propose sounds more difficult than just ignoring the pads inside rtspsrc. It should be a very local change without any API changes. The reason why it didn't work for you is maybe because ptdemux did not properly expose a *new* pad for the new stream but reused an old one? See 1) in what I wrote above.
As principle I agree but looking at the logs seems not so simple, please take a look here, this is what happen when a new payload type arrive on the same SSRC, the right payload is 112 the good one is 96 rtpsource rtpsource.c:1158:update_receiver_stats: seq 42118, PC: 1, OC: 0 rtpsource rtpsource.c:938:calculate_jitter: SSRC 75699a4c got payload 112 rtpsource rtpsource.c:898:get_clock_rate: new payload 112 rtpbin gstrtpbin.c:3232:pt_map_requested:<manager> payload map requested for pt 112 in session 0 rtpbin gstrtpbin.c:937:get_pt_map: searching pt 112 in cache rtpbin gstrtpbin.c:950:get_pt_map: emiting signal for pt 112 in session 0 rtspsrc gstrtspsrc.c:2645:request_pt_map:<rtspsrc0> getting pt map for pt 112 in session 0 rtpbin gstrtpbin.c:1915:_gst_caps_accumulator: got caps (NULL) rtpbin gstrtpbin.c:1915:_gst_caps_accumulator: got caps (NULL) rtpbin gstrtpbin.c:1001:get_pt_map: no pt map could be obtained rtpbin gstrtpbin.c:3243:pt_map_requested:<manager> could not get caps rtpsession gstrtpsession.c:1597:gst_rtp_session_get_caps_for_pt:<rtpsession0> could not get caps rtpsession rtpsession.c:1420:source_clock_rate: got clock-rate -1 for pt 112 rtpsource rtpsource.c:910:get_clock_rate: got clock-rate -1 rtpsource rtpsource.c:983:calculate_jitter: cannot get clock-rate for pt 112 rtpsource rtpsource.c:873:push_packet: pushing queued packet rtpsession rtpsession.c:1389:source_push_rtp: source 75699a4c pushed receiver RTP packet so in rtspsrc getting pt map return NULL caps (unknown_stream) but this rtp packet is pushed anyway, do you agree that this packet should be dropped? rtspsrc seems to do the right thing, it says "hey I don't know this rtp packet" but the buffer should be dropped elsewhere, probably in rtpsource, do you agree?
If buffer should drop the wrong pt, the jitterbuffer can easily drop it (the patch I sent). It is the only patch I apply and it drops the PT that is not in the caps, which fixes the problem for me.
Needless to say, `rtspsrc` sets the caps based on SDP
(In reply to Nicola from comment #65) > As principle I agree but looking at the logs seems not so simple, please > take a look here, this is what happen when a new payload type arrive on the > same SSRC, the right payload is 112 the good one is 96 > > [...] > > so in rtspsrc getting pt map return NULL caps (unknown_stream) but this rtp > packet is pushed anyway, do you agree that this packet should be dropped? > rtspsrc seems to do the right thing, it says "hey I don't know this rtp > packet" but the buffer should be dropped elsewhere, probably in rtpsource, > do you agree? Why is rtpptdemux not creating a new pad for it? The behaviour in rtpbin/rtpsource/etc seems not wrong, the packet comes through with a new pt and it just tries it best to handle that. It should've been demuxed into a different stream though. If there are caps or not seems secondary here. (In reply to dashesy from comment #66) > If buffer should drop the wrong pt, the jitterbuffer can easily drop it (the > patch I sent). It is the only patch I apply and it drops the PT that is not > in the caps, which fixes the problem for me. As mentioned a few times above, the different pt should be split off before the rtpjitterbuffer already. And then just be ignored at the rtspsrc level.
Created attachment 342545 [details] [review] new patch Sebastian, I think this is the patch you asked for, ptdemux already create a new src pad when pt change, now rtspsrc ignore this pad. This patch could be useful in general but does not change anything in this case, I'll summarize my findings later
Created attachment 342546 [details] [review] new patch in previous patch there was a ref instead of an unref
I'm planning to migrate my gst base from 1.6 to 1.12 so I'm doing some more accurate tests, this is what I see: - gstreamer 1.6 1) with no patch applied rtspsrc errors out after a while 2) with the patch here I see the logs in the patch and streaming continue - gstreamer 1.12 (git master) I'm unable to reproduce the error, there are a lot of warning when pt change but rtspsrc does not errors out, here are the warnings: 1) "rtpsource.c:983:calculate_jitter: cannot get clock-rate for pt 112", the buffer is pushed anyway 2) "rtpjitterbuffer gstrtpjitterbuffer.c:3133:gst_rtp_jitter_buffer_chain:<rtpjitterbuffer0> No clock-rate in caps!, dropping buffer", the buffer is dropped here and never arrive to ptdemux the relevant change between 1.6 and git master is this one: https://cgit.freedesktop.org/gstreamer/gst-plugins-good/commit/?id=608b4ee53c43c3dcbfee167349771eeffd92e071 if I apply this patch to 1.6 my old patch is not needed anymore, dashey, why your patch is needed? In my tests the buffers are dropped anyway since the caps refer to payload 96 and not 112 and so clock_rate is -1 and gst_rtp_jitter_buffer_get_clock_rate return -1 too (request_pt_map return null caps since pt 112 is not inside sdp). Is your stream different from the mine?
Created attachment 342556 [details] [review] new patch
@Nicola I only applied that patch (in the rtpjitterbuffer drop packet if pt changes). The stream I have sends an unwanted 112 before any 96 is seen, sigh. Caps are set by rtspsrc to pt=96 so next time rtpjitterbuffer sees 112 it will drop it instead of trying hard to use it and failing. If not dropped clock rate of 96 is reset any time a 112 is seen, it is pushed but apparently with negatively affecting the valid 96 stream.
(In reply to dashesy from comment #73) > @Nicola I only applied that patch (in the rtpjitterbuffer drop packet if pt > changes). The stream I have sends an unwanted 112 before any 96 is seen, > sigh. > Caps are set by rtspsrc to pt=96 so next time rtpjitterbuffer sees 112 it > will drop it instead of trying hard to use it and failing. how this fails? With not linked error? It works for me with current version, the buffers with payload 112 are dropped anyway > > If not dropped clock rate of 96 is reset any time a 112 is seen, it is > pushed but apparently with negatively affecting the valid 96 stream. do you have a chance to make your stream public available? I would like to do some more investigations, thanks!
The not-linked error happens after quite some time sporadically, the fix needs your original patch (that I double checked and was applied). My patch tries to fix this error: 0:00:00.296884000 2872 000001BDAB2199C0 ERROR rtpjitterbuffer gstrtpjitterbuffer.c:1372:gst_jitter_buffer_sink_parse_caps:<rtpjitterbuffer0> Got caps with wrong payload type (got 96, expected 112) 0:00:00.296884000 2872 000001BDAB2199C0 WARN rtpjitterbuffer gstrtpjitterbuffer.c:3133:gst_rtp_jitter_buffer_chain:<rtpjitterbuffer0> No clock-rate in caps!, dropping buffer Even though 96 is declared in SDP (is valid) and 112 is invalid, one with pt=112 results in one buffer with pt=96 to be dropped. I will try your new patch on top of 1.10 and report. The stream is private but I will gladly test.
(In reply to dashesy from comment #75) > The not-linked error happens after quite some time sporadically, the fix > needs your original patch (that I double checked and was applied). the not-linked error does not happen anymore for me with 1.10 and git master, while it happens with 1.6 if I don't apply my old patch > > My patch tries to fix this error: > > 0:00:00.296884000 2872 000001BDAB2199C0 ERROR rtpjitterbuffer > gstrtpjitterbuffer.c:1372:gst_jitter_buffer_sink_parse_caps: > <rtpjitterbuffer0> Got caps with wrong payload type (got 96, expected 112) > 0:00:00.296884000 2872 000001BDAB2199C0 WARN rtpjitterbuffer > gstrtpjitterbuffer.c:3133:gst_rtp_jitter_buffer_chain:<rtpjitterbuffer0> No > clock-rate in caps!, dropping buffer has you can see the buffer is dropped anyway > > > Even though 96 is declared in SDP (is valid) and 112 is invalid, one with > pt=112 results in one buffer with pt=96 to be dropped. > ok it is a bit late at my timezone, I'll check tomorrow > > I will try your new patch on top of 1.10 and report. in my test my patch is useless, the buffer is always dropped and so ptdemux has no chance to get a buffer with a different payload and so to emit a signal, I still think that if such buffer is not dropped inside ptdemux it will cause a not linked error (my old patch). The purpose of the latest patch is to do what Sebastian said and so to have another suggestion on how to proceed > The stream is private but I will gladly test.
> has you can see the buffer is dropped anyway A wrong buffer is dropped as well. cap is set to `pt=96` then this is the sequence of received packets: 112->112->96->96->...96->112->112->96->96 The transition from 96 to 112 sets `priv->last_pt = pt;` and the next 112->96 wrongly drops the 96 *valid* buffer. > the not-linked error does not happen anymore for me with 1.10 and git master You could be right! it takes a long time for it to happen and I have not see it with 1.10 either, I thought it is the patch that fixed it. Hard to debug infrequent problems.
Created attachment 342567 [details] [review] set last_pt only if the buffer is not dropped
(In reply to dashesy from comment #77) > > has you can see the buffer is dropped anyway > > A wrong buffer is dropped as well. cap is set to `pt=96` then this is the > sequence of received packets: > > 112->112->96->96->...96->112->112->96->96 > > The transition from 96 to 112 sets `priv->last_pt = pt;` and the next > 112->96 wrongly drops the 96 *valid* buffer. in my case I have 96->96 ... 96->112->96 and no buffer is dropped, anyway could you please test the latest patch? This should do the same thing of yours but hopefully in a way that could be accepted upstream > > > the not-linked error does not happen anymore for me with 1.10 and git master > > You could be right! it takes a long time for it to happen and I have not see > it with 1.10 either, I thought it is the patch that fixed it. Hard to debug > infrequent problems. my old patch make the things more solid anyway, if I manually change the buffer payload in ptdemux I get a non linked error, this patch https://cgit.freedesktop.org/gstreamer/gst-plugins-good/commit/?id=608b4ee53c43c3dcbfee167349771eeffd92e071 should make very hard or impossibile to forward a such buffer to ptdemux but the things can change in future, I wonder why jitterbuffer can request a pt map and drop the buffer if it return NULL and ptdemux cannot do the same thing
Yes the last patch works, and results in this benign error: rtpjitterbuffer gstrtpjitterbuffer.c:1372:gst_jitter_buffer_sink_parse_caps:<rtpjitterbuffer0> Got caps with wrong payload type (got 96, expected 112) But should change the comment: rtpjitterbuffer gstrtpjitterbuffer.c:2783:gst_rtp_jitter_buffer_chain:<rtpjitterbuffer0> pt changed from 96 to 112 It is no longer correct, pt did not change. Also, why should it reset the clock_rate now, it is the clock_rate of 96? i.e. priv->clock_rate = -1; should be moved to inside the if statement? Attached is the revised patch.
Created attachment 342588 [details] [review] change pt if in caps
opinions on the latest attachments? We posted several ways to handle with these rtsp camera and let gstreamer handle them as vlc/ffplay, is there an approach good for inclusion?
Review of attachment 342567 [details] [review]: I think this patch is good
Review of attachment 342556 [details] [review]: I think this is the right approach. But won't it just make it just return not linked though if the pad from ptdemux is not linked? Don't we need to add a pad probe to drop buffers/events/queries ? ::: gst/rtsp/gstrtspsrc.c @@ +5059,2 @@ /* our CMD_CLOSE might have interrutped CMD_LOOP. gst_rtspsrc_loop + * will send a CMD_WAIT which would cancel our pending CMD_CLOSE (if This re-indentation should be a separate patch.
Review of attachment 341700 [details] [review]: Ignoring all PT changes is wrong.. Mixing PTs is a used in many normal use-cases.
Review of attachment 307284 [details] [review]: I assume that the two other patches, this is not needed?
Created attachment 344384 [details] [review] new patch
Created attachment 344385 [details] [review] improve log when a buffer with wrong payload is dropped from the previous log seems that the right payload is the one of the dropped buffer
(In reply to Olivier Crête from comment #86) > Review of attachment 307284 [details] [review] [review]: > > I assume that the two other patches, this is not needed? please see comment 79
(In reply to Olivier Crête from comment #84) > Review of attachment 342556 [details] [review] [review]: > > I think this is the right approach. But won't it just make it just return > not linked though if the pad from ptdemux is not linked? Don't we need to > add a pad probe to drop buffers/events/queries ? > the camera manufacter sends metadata inside these buffers with payloads not declared inside the sdp, we want drop these buffers (as vlc and ffplay do) and continue to receive the buffers with payloads declared inside sdp that are the ones we are interested to so we don't want to return not-linked and stop the stream. Can you please elaborate regarding the pad probe? With the attached patch we already drop unwanted buffers, sorry if I missed something
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/139.