Transport specific sink elements are added to the pipeline
in PLAY request and sockets are already created in SETUP so
it's actually wrong to require the presence of sinks in
_get_*_socket() functions.
https://bugzilla.gnome.org/show_bug.cgi?id=793441
If a multicast client requests different transport settings
than the existing one make sure that this new transport
configuruation is propagated to the multicast udp sink.
https://bugzilla.gnome.org/show_bug.cgi?id=793441
Passwords are usually not stored in clear text, but instead
stored already hashed in a .htdigest file.
Add support for parsing such files, add API to allow setting
a custom realm in RTSPAuth, and update the digest example.
https://bugzilla.gnome.org/show_bug.cgi?id=796637
When streaming data over TCP then is not the keep-alive
functionality working.
The reason is that the function do_send_data have changed
to boolean but the code is still checking the received result
from send_func with GST_RTSP_OK.
The result is that a successful send_func will always lead to
that do_send_data is returning false and the keep-alive will
not be updated.
https://bugzilla.gnome.org/show_bug.cgi?id=795321
This reverts commit 3d275b1345.
While RFC 3264 (SDP) says that sendonly/recvonly are from the point of view of
the requester, the actual RTSP RFCs (RFC 2326 / 7826) disagree and say
the opposite, just like the ONVIF standard.
Let's follow those RFCs as we're doing RTSP here, and add a property at
a later time if needed to switch to the SDP RFC behaviour.
https://bugzilla.gnome.org/show_bug.cgi?id=793964
If the media is complete, i.e. one or more streams have been configured
with sinks, then we want to query the position on those streams only.
A query on an incomplete stream may return a position that originates from
an earlier preroll.
https://bugzilla.gnome.org/show_bug.cgi?id=794964
Added it right before pushing the previous commit, it is
incorrect and deadlocks because this function gets called
from the join_bin thread, which already holds the lock,
that's the reason why request_aux_sender didn't take the
lock either.
"do-retransmission" was previously set when rtx-time != 0,
which made no sense as do-retransmission is used to enable
the sending of retransmission requests, where as rtx-time
is used by the peer to enable storing of buffers in order
to respond to retransmission requests.
rtsp-media now also provides a callback for the
request-aux-receiver signal.
https://bugzilla.gnome.org/show_bug.cgi?id=794822
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
The initial pipeline does not contain specific transport
elements. The receiver and the sender parts are added
after PLAY.
If the media is shared, the streams are dynamically
reconfigured after each PLAY.
https://bugzilla.gnome.org/show_bug.cgi?id=788340
If no sinks have been added yet, obtain the current and
the stop position of the stream from the send_src pad.
Change-Id: Iacd4ab4bdc69f6b49370d06012880ce48a7d595a
https://bugzilla.gnome.org/show_bug.cgi?id=788340
According to the documentation, a timeout of value 0 means
that the session never timeouts. This adds handling of that.
If timeout=0 we just return with a -1 from
gst_rtsp_session_next_timeout_usec ().
https://bugzilla.gnome.org/show_bug.cgi?id=785058
This adds basic support for new 2.0 features, though the protocol is
subposdely backward incompatible, most semantics are the sames.
This commit adds:
- features:
* version negotiation
* pipelined requests support
* Media-Properties support
* Accept-Ranges support
- APIs:
* gst_rtsp_media_seekable
The RTSP methods that have been removed when using 2.0 now return
BAD_REQUEST.
https://bugzilla.gnome.org/show_bug.cgi?id=781446
Commit 852cc09f54 assumed that
multiudpsink's last-sample always comes from the payloader. Which
is wrong if auxiliary streams are multiplexed in the same stream.
So check the buffer's ssrc against the caps'ssrc before to use its
seqnum. If not the same ssrc just use the payloader as done prior
the commit above or when there is no last-sample yet.
https://bugzilla.gnome.org/show_bug.cgi?id=784094
Calling function gst_rtsp_stream_get_server_port() results in
segmenation fault in the RTP/RTSP/TCP case.
Port that the server will use to receive RTCP makes only
sense in the UDP case, however the function should handle
the TCP case in a nicer way.
https://bugzilla.gnome.org/show_bug.cgi?id=776345
85c52e194b introduced a more correct
detection of the srtp rollover counter to add to the SDP.
Unfortunately, it was incomplete for live pipelines where the logic
blocks the source bin before creating the SDP and thus would never have
the necessary informaiton to create a correct SDP with srtp encryption.
Move the pad blocks to rtpbin's output pads instead so that the
necessary information can be created before we need the information for
the SDP.
https://bugzilla.gnome.org/show_bug.cgi?id=770239
The RTSP server will not timeout an idle RTSP connection
(note this is different from doing timeout on a RTSP
session).
At least for Apache this is a problem when running RTSP over
HTTPS since it uses one of the threads (there is a rather
limited number) that are available for handling requests.
https://bugzilla.gnome.org/show_bug.cgi?id=771830
With this RTSP server can use the sockets independent on the udpsrc
state.
When the udp src is finalized it will unref socket and when g_socket
is finalized the socket will be closed.
https://bugzilla.gnome.org/show_bug.cgi?id=765673
These signals let the application validate the requests, configure the
media/stream in a certain way and also generate error status code in
case of error or bad request.
https://bugzilla.gnome.org/show_bug.cgi?id=758062
Call session filter with filter_session_media as paramer in
client_unwatch_session if using drop_backlog = FALSE.
In client_unwatch_session its allowed to grow the watchs backlog.
If using drop_backlog = FALSE and the backlog is full it will cause
a deadlock when setting session media state to NULL
if the backlog is not allowed to grow.
https://bugzilla.gnome.org/show_bug.cgi?id=771983
When using dynamic elements, gst_rtsp_stream_join_bin() is called from
"pad-added" signal. In that case priv->srcpad could already have its caps,
and they'll be sent to priv->send_src[0] pad. That means that when it
connects "notify::caps" signal, that pad could already have received its
caps and the signal won't be emitted anymore.
In that case priv->caps stay to NULL and when building the SDP that stream
gets ignored. Leading to missing video or audio when playing in client side.
https://bugzilla.gnome.org/show_bug.cgi?id=772478
Adding them later will cause deadlocks due to
1) pre-rolling and staying in PAUSED with the unicast/TCP sinks
2) adding the multicast sink
3) waiting for it to get data to preroll again
3) never happens because the queues after the tee are full.
This is basically reverting changes introduced in commit f62a9a7,
because it was introducing various regressions:
- It introduces a leak of udpsrc elements that got wrongly fixed by adding
an hash table in commit cba045e. We should have at most 4 udpsrc for unicast:
ipv4/ipv6, rtp/rtcp. They can be reused for all unicast clients.
- If a mcast client connects, it creates a new socket in SETUP to try to respect
the destination/port given by the client in the transport, and overrides the
socket already set on the udpsink element. That means that if we already had a
client connected, the source address on the udp packets it receives suddenly
changes.
- If a 2nd mcast client connects, the destination/port in its transport is
ignored but its transport wasn't updated.
What this patch does:
- Revert back to create udpsrc/udpsink for unicast clients on DESCRIBE.
- Always have a tee+queue when udp is enabled. This could be optimized
again in a later patch, but is more complicated. If no unicast clients
connects then those elements are useless, this could be also optimized
in a later patch.
- When mcast transport is added, it creates a new set of udpsrc/udpsink,
seperated from those for unicast clients. Since we already support only
one mcast address, we also create only one set of elements.
https://bugzilla.gnome.org/show_bug.cgi?id=766612
We add different crypto sessions in MIKEY, one for each sender
SSRC. Currently, all of them will have the same security policy, 0.
The rollover counters are obtained from the srtpenc element using the
"stats" property.
https://bugzilla.gnome.org/show_bug.cgi?id=730539
It's what introspection.mak does as well. Should
fix spurious build failures on gnome-continuous
(caused by g-ir-scanner getting compiler details
via python which is broken in some environments
so passing the compiler details bypasses that).
- Unicast udpsrcs are now managed in a hash table. This allows for proper cleanup in with shared streams and fixes a memory leak.
- Unicast udpsrcs are now properly cleaned up when shared connections exit. See the update_transport() function.
- Create unit test for shared media.
https://bugzilla.gnome.org/show_bug.cgi?id=764744
For NTP and PTP clocks we signal the actual clock that is used and signal
the direct media clock offset.
For all other clocks we at least signal that it's the local sender clock.
This allows receivers to know which clock was used to generate the media and
its RTP timestamps. Receivers can then implement network synchronization,
either absolute or at least relative by getting the sender clock rate directly
via NTP/PTP instead of estimating it from RTP timestamps and packet receive
times.
https://bugzilla.gnome.org/show_bug.cgi?id=760005
Without this, RECORD pipelines are broken because
a) we wait for ASYNC_DONE which never happens anymore because udpsrc would be
added later. Previously it was there earlier and due to NO_PREROLL caused the
pipeline to preroll immediately
b) the udpsrc for the pipeline is added later and never set to PLAYING state,
as the corresponding code previously was only for PLAY pipelines.
https://bugzilla.gnome.org/show_bug.cgi?id=763281
On Windows this is a receiver-side setting, on Linux a sender-side setting. As
we provide a socket ourselves to udpsrc, udpsrc is never setting the multicast
loopback setting on the socket... while udpsink does which unfortunately has
no effect here on Windows but on Linux.
https://bugzilla.gnome.org/show_bug.cgi?id=757488
On Linux it is still needed to bind to the multicast address
to filter out random other packets, while on Windows binding
to multicast addresses just fails.
