GNOME Bugzilla – Bug 793715
rtspsrc: regression with streams marked as recvonly
Last modified: 2018-03-13 14:05:44 UTC
<mndar> Thanks for your tip yesterday about the GStreamer not detecting RTSP camera stream. Turns out this line is causing the problem. Disregarding that condition the camera stream works. In gstrtspsrc.c, "gst_sdp_media_get_attribute_val (media, "recvonly") != NULL" was causing that problem. I see that the 'if' condition has changed in git master https://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/gst/rtsp/gstrtspsrc.c#n1775 (log files were pasted to pastebin but pages expired now)
What is this camera? ONVIF, and following the wrong example in the specification and mixing up the sendonly/recvonly attributes and contradicting the RFCs that define the attributes? We might have to add some detection for ONVIF to rtspsrc for switching between both, or a property. Can you provide a dump of the RTSP stream with that camera?
Can/should we detect in advance if there are backchannels in the SDP and ignore recvonly/sendonly attributes if there's no mix?
Created attachment 368805 [details] Hikvision ONVIF IP Camera
The camera stream correctly in 1.12.4 GStreamer 1.13.1 does not have '!stream->is_backchannel' in that 'if' condition. I have attached the Wireshark dump of the IP camera. Here is the SDP received v=0 o=- 1519236923460104 1519236923460104 IN IP4 10.168.1.64 s=Media Presentation e=NONE b=AS:5050 t=0 0 a=control:rtsp://10.168.1.64:554/Streaming/Channels/101/?transportmode=unicast&profile=Profile_1 m=video 0 RTP/AVP 96 c=IN IP4 0.0.0.0 b=AS:5000 a=recvonly a=x-dimensions:1920,1080 a=control:rtsp://10.168.1.64:554/Streaming/Channels/101/trackID=1?transportmode=unicast&profile=Profile_1 a=rtpmap:96 H264/90000 a=fmtp:96 profile-level-id=420029; packetization-mode=1; sprop-parameter-sets=Z00AKpWoHgCJ+WEAAAcIAAFfkAQ=,aO48gA== a=Media_header:MEDIAINFO=494D4B48010200000400000100000000000000000000000000000000000000000000000000000000; a=appversion:1.0
Ok, so the camera is doing it exactly wrong. The way how it is wrongly given in the examples in the ONVIF spec. I guess we have to implement some kind of heuristic then. As a first step what Tim said, but for cases where there are both directions we need to be more clever. This also means that a property is needed in gst-rtsp-server to work with both kinds of ONVIF clients: broken like this one and correct like rtspsrc currently.
Another heuristic we can do: check what the video stream(s) are tagged with.
(In reply to Tim-Philipp Müller from comment #6) > Another heuristic we can do: check what the video stream(s) are tagged with. In theory there could also be a video backchannel. Not in the current ONVIF spec though.
(In reply to Mandar Joshi from comment #3) > Created attachment 368805 [details] > Hikvision ONVIF IP Camera This can't be opened in wireshark btw, and 107 bytes seems a bit small :)
Created attachment 369138 [details] hikvision.pcapng.gz Please try this file
Thanks, so exactly the problem as expected and nothing could be done about it other than implement heuristics that will fall apart in other cases, or a property. Let's think about this a bit more
One complication for heuristics here is that it is completely valid (and AFAIU the ONVIF testsuite checks for that) to *only* have a backchannel. So if we see a single audio stream that is recvonly (or sendonly), we can't know whether it is a backchannel or a single audio stream. I would suggest that for 1.14 we ignore the attributes completely unless a backchannel is requested on rtspsrc. If a backchannel is requested, we follow the RFC and not the broken examples in the ONVIF spec, which would then still fail with cameras like this one here though. For 1.16 we can hopefully come up with a better solution. I think ideally I'd like to always look at the attributes, and if we need workarounds for broken hardware out there we can always add a property for that.
Created attachment 369148 [details] [review] rtspsrc: Ignore sendonly/recvonly attributes unless a backchannel is configured This works around a bug in various ONVIF cameras that implement the attributes the wrong way around. They still won't work with a backchannel but at least normal playback will work for the time being. It restores pre-1.14 behaviour where we would fail to preroll on any SDP that lists a recvonly stream. For 1.16 a better solution should be found. The problem here is that the ONVIF spec has the meaning of the two attributes the wrong way around in the examples, compared to RFC4566.
Please someone test this with such a broken ONVIF camera. I'd merge this for 1.14 for now and open a new bug for 1.16 so that we can find a better solution. This now simply restores pre-1.14 behaviour.
Attachment 369148 [details] pushed as f29fe76 - rtspsrc: Ignore sendonly/recvonly attributes unless a backchannel is configured
Thanks Sebastian, the Hikvision camera works now.
Also reverted in 1.12 for 1.12.5