We can't handle recvonly streams, sendonly streams are perfectly fine.
The direction is the one from the point of view of the SDP offerer
(i.e. the RTSP server), and a recvonly stream would be one where the
server expects us to send media.
RFC 3264, section 5.1:
If the offerer wishes to only send media on a stream to its peer, it
MUST mark the stream as sendonly with the "a=sendonly" attribute.
This is mixed up in the ONVIF streaming specification examples, but
actual implementations and conformance tools seem to not care at all
about the attributes.
https://bugzilla.gnome.org/show_bug.cgi?id=792376
else
goto unknown_proto;
- if (gst_sdp_media_get_attribute_val (media, "sendonly") != NULL)
- goto sendonly_media;
+ if (gst_sdp_media_get_attribute_val (media, "recvonly") != NULL)
+ goto recvonly_media;
/* Parse global SDP attributes once */
global_caps = gst_caps_new_empty_simple ("application/x-unknown");
GST_ERROR_OBJECT (src, "unknown proto in media: '%s'", proto);
return;
}
-sendonly_media:
+recvonly_media:
{
- GST_DEBUG_OBJECT (src, "sendonly media ignored");
+ GST_DEBUG_OBJECT (src, "recvonly media ignored");
return;
}
}