We need different export decorators for the different libs.
For now no actual change though, just rename before the release,
and add prelude headers to define the new decorator to GST_EXPORT.
This allows us to later map signals from rtpbin/rtpsource back to the
corresponding stream transport, and allows to do keep-alive based on
RTCP packets in case of TCP media transport.
https://bugzilla.gnome.org/show_bug.cgi?id=789646
As READY_TO_PAUSED can no longer return async, the RECORD
command will be queued before the OPEN command fails
(for example in case the server could not be connected),
and record then waits for ever.
https://bugzilla.gnome.org/show_bug.cgi?id=793896
The test_record case was working because async=false had
been added in https://bugzilla.gnome.org/show_bug.cgi?id=757488
but that was incorrect, as it should not be needed.
Removing async=false made the test fail as expected, this is
fixed by not trying to preroll when preparing the media for
RECORD, as start_prepare is called upon receiving ANNOUNCE,
and our peer will not start sending media until it has received
a response to that request, and sent and received a response
to RECORD as well, thus obviously preventing preroll.
https://bugzilla.gnome.org/show_bug.cgi?id=793738
res is a boolean variable which is defined in the function scope and
redefined, with no reason, in the loop scope. This patch removes the
redefinition.
https://bugzilla.gnome.org/show_bug.cgi?id=793592
...and replace all checks for RECORD in GstRTSPMedia which are really
for "sender-only". This way the code becomes more generic and introducing
support for onvif-backchannel later on will require no changes in
GstRTSPMedia.
They are wrong in the ONVIF streaming spec. The backchannel should be
recvonly and the normal media should be sendonly: direction is always
from the point of view of the SDP offerer (the server) according to
RFC 3264.
This adds a new RTSP server, client, media-factory and media subclass
for handling the specifics of the backchannel. Ideally this later can be
extended with other ONVIF specific features.
WARNING: Trying to compare values of different types (str, int).
The result of this is undefined and will become a hard error
in a future Meson release.
The return value type is defined with G_DEFINE_POINTER_TYPE,
and gi emits the following warning:
Invalid non-constant return of bare structure or union; register as
boxed type or (skip)
This maps _new_empty() to _new(), which also makes RTSPToken()
work properly now. Since this API wasn't usable from bindings
before, this should hopefully be fine.
https://bugzilla.gnome.org/show_bug.cgi?id=787073
In the multicast case (as in test-multicast, not test-multicast2), the
address could be allocated/reserved (and thus set) already without
allocating the actual socket. We need to allocate the socket here still
instead of just claiming that it was already allocated.
See https://bugzilla.gnome.org/show_bug.cgi?id=791743#c2
