rtsp-media-factory-uri.c: In function ‘rtsp_media_factory_uri_create_element’:
rtsp-media-factory-uri.c:621:17: error: assignment from incompatible pointer type [-Werror=incompatible-pointer-types]
data->factory = g_object_ref (factory);
^
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
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.
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
SDP are now provided *before* the pipeline is fully complete. In order
to know whether a media is seekable or not therefore requires asking
the invididual streams.
API: gst_rtsp_stream_seekable
https://bugzilla.gnome.org/show_bug.cgi?id=790674
There is not need of adding fakesink elements to the media
pipeline in the dynamic-payloader case.
The media pipeline itself is dynamically updated with
the receiver and sender parts that are based on the client
transport information known after SETUP has been received.
Change-Id: I4e88c9b500c04030669822f0d03b1842913f6cb9
https://bugzilla.gnome.org/show_bug.cgi?id=790674
Media is complete when all the transport based parts are
added to the media pipeline. At this point ASYNC_DONE is
posted by the media pipeline and media is ready to enter
the PREPARED state.
Change-Id: I50fb8dfed88ebaf057d9a35fca2d7f0a70e9d1fa
https://bugzilla.gnome.org/show_bug.cgi?id=790674
If we still have some dynamic paylaoders which haven't posted
no-more-pads yet, don't go to PREPARED if one of the streams
blocked.
The risk was that we would end up not exposing/using all specified
streams.
The downside is that if you have _multiple_ _live_ _dynamic_ payloaders
then it will take a bit more time to start. But only if those 3
conditions are present.
https://bugzilla.gnome.org/show_bug.cgi?id=769521
If we have more than one dynamic payloader in the pipeline, we need
to wait until the *last* one emits 'no-more-pads' before switching
to PREPARED.
Failure to do so would result in a race where some of the streams
wouldn't properly be prepared
https://bugzilla.gnome.org/show_bug.cgi?id=769521
