Because of duplicated g_signal_connect for request-aux-sender signal,
wrong stream pointer is passed to the signal handler.
Instead of passing each stream, pass stream array and get the relevant stream.
https://bugzilla.gnome.org/show_bug.cgi?id=747839
When the sdp media attribute framesize are converted to caps
the <payload> should not be included.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=725335
Based on the patch for rtspsrc by Linus Svensson <linussn@axis.com>
The sdp framesize attribute is desribed in RFC6064. It is specified
for payloading of H263 and has the following form
a=framesize:<payload type> <width>-<height>. The <width>-<height> part
should be added to the caps in a payloader and the <payload type> should
be added by the rtsp-server.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=725334
Allow specifying the GType of a GstRtspMedia subclass to create
as a simpler way to get the factory to create a custom
GstRtspMedia sub-class, without subclassing GstRtspMediaFactory.
Changed RTSP session timeout handling to monotonic time
and deprecating the API for current system time.
This fixes timeouts when the system time changes.
https://bugzilla.gnome.org/show_bug.cgi?id=743346
If the media was just not seekable, we continue from whatever position we are
and let the client decide if that is what is wanted or not.
Only if the actual seek failed, we can't really recover and should error out.
Fix the logic of gst_rtsp_media_collect_streams() so after looping collecting
all streams it knows if it got any, and can check if the transport mode is OK.
CID #1268400
Just print a warning if the one that was set before disagrees with what
elements we found. It must already be set to something before as this
function is called after we received the SDP from ANNOUNCE in RECORD mode,
and we would reject ANNOUNCE if the RECORD flag was not set.
RTCP packets were not sent because the same tr_cache_cookie was used for
both RTP and RTCP. So only one of the tr_cache lists were populated
depending on which one was sent first. If the tr_cache list is not
populated then no packets can be sent. Most often this happened to be
RTCP. Now seperate RTCP and RTP transport cache cookies are added which
resulted in both the tr_cache_lists to be populated regardless of which
one was sent first.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=743734
RFC4566 Section 5.2 says that it should make the username, session id,
nettype, addrtype and unicast address tuple globally unique. Always using
1188340656180883 is not going to guarantee that: https://xkcd.com/221/
Instead let's create a 64 bit random number, which at least brings us
closer to the goal of global uniqueness.
https://tools.ietf.org/html/rfc4566#section-5.2
We add a trailing \0 in GstRTSPConnection to make parsing of
string message bodies easier (e.g. the SDP from DESCRIBE) but
for actual data this means we have to drop it or otherwise
create invalid data.
Fixes crash when two threads access handle_new_sample() at the same
time, one for RTP, one for RTCP.
Otherwise, when iterating over the transports cache, it might be modified by
another thread at the same time if the transports cookie has changed.
https://bugzilla.gnome.org/show_bug.cgi?id=742954
This reverts commit 935e8f852d.
RFC 2326 states that session IDs may consist of alphanumeric as well as
the safe characters $-_.+ -- N.B. the percent character is not allowed.
Previously the session ID was URI-escaped, this meant that any character
which was not alphanumeric or any of the characters +-._~ would be
percent encoded. While the RFC (surprisingly) mentions that linear white
space in session IDs should be URI-escaped, it does not say anything
about other characters. Moreover no white space is allowed in the
session ID. Finally the percent character which is the result of
URI-escaping is not allowed in a session ID.
So there is no reason to do any URI-escaping, and now it is removed.
https://bugzilla.gnome.org/show_bug.cgi?id=742869
rtsp-stream.c:1351:3: error: non-void function 'gst_rtsp_stream_get_retransmission_time' should return a value [-Wreturn-type]
g_return_if_fail (GST_IS_RTSP_STREAM (stream));
^
rtsp-stream.c:1384:3: error: non-void function 'gst_rtsp_stream_get_retransmission_pt' should return a value [-Wreturn-type]
g_return_if_fail (GST_IS_RTSP_STREAM (stream));
^
The default implementation of configure_client_transport() in
rtsp-client uses the session media when it chooses channels for
interleaved traffic.
https://bugzilla.gnome.org/show_bug.cgi?id=739112
If the media has been managed by a session media, it should not be
cached in the client any longer. The GstRTSPSessionMedia object is now
responsible for unpreparing the GstRTSPMedia object using
gst_rtsp_media_unprepare(). Unprepare the media when finalizing the
session media.
https://bugzilla.gnome.org/show_bug.cgi?id=739112
We need to set session medias to NULL without the client lock otherwise
we can end up in a deadlock if another thread is waiting for the lock
and media unprepare is also waiting for that thread to end.
https://bugzilla.gnome.org/show_bug.cgi?id=737690
If the backlog limit is kept two cases of deadlocks may be
encountered when streaming over TCP. Without the backlog
limit this deadlocks can not happen, at the expence of
memory usage.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=737631
As long as gst-rtsp-server can successfully send RTP/RTCP data to
clients then the client must be reading. This change makes the server
timeout the connection if the client stops reading.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=736647
Allow the send backlog in the RTSP watch to grow to unlimited size while
attempting to bring the media pipeline to NULL due to a session
expiring. Without this change the appsink element cannot change state
because it is blocked while rendering data in the new_sample callback.
This callback will block until it has successfully put the data into the
send backlog. There is a chance that the send backlog is full at this
point which means that the callback may block for a long time, possibly
forever. Therefore the media pipeline may also be prevented from
changing state for a long time.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=736647
rtsp-client.c:2553:50: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
Just in case that guint8 doesn't fit in a pointer. Just in case ...
We need to raise the backlog limits before pausing the pipeline or else
the appsink might be blocking in the render method in wait_backlog() and
we would deadlock waiting for paused.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=736322
link/unlink of the transport in a session was done to keep track of all
TCP transports and to send RTP/RTCP data to the streams. We can simplify
that by putting all the TCP transports in a hashtable indexed with the
channel number.
We also don't need to link/unlink the transports when we pause/resume
the streams. The same effect is already achieved when we pause/play the
media. Indeed, when we pause the media, the transport is removed from
the media and the callbacks will not be called anymore.
See https://bugzilla.gnome.org/show_bug.cgi?id=736041
Make a method to handle the data received on a channel. It sends the
data to the stream of the transport on the RTP or RTCP pads based on
the channel number.
The sequence number is not monotonic for RTP packets after pause. The
reason is basepayloader generates a randon sequence number when the
pipeline goes from ready to pause. With this fix generation of sequence
number will be monotonic when going from pause to play request.
https://bugzilla.gnome.org/show_bug.cgi?id=736017
Fixes a crash when close() is called while merging clients
in handle_tunnel(). In that case close() would destroy the
watch while it is still being used in handle_tunnel().
https://bugzilla.gnome.org/show_bug.cgi?id=735570
The RTCP parts, in specific the RTCP udpsinks, are not flushed when
seeking and will always continue counting the time. This leads to
the NPT after a backwards seek to be something completely different
to the actual seek position.
https://bugzilla.gnome.org/show_bug.cgi?id=732644
When a UDP multicast transport is used it is expected that the server listens
for RTP and RTCP packets on the multicast group with the corresponding port.
Without this we will never get RTCP packets from clients in multicast mode.
https://bugzilla.gnome.org/show_bug.cgi?id=732238
Release the object lock before calling the filter functions. We need to
keep a cookie to detect when the list changed during the filter
callback. We also keep a hashtable to make sure we only call the filter
function once for each object in case of concurrent modification.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=732950
This extra ref will be dropped when all client sessions have been
removed. A session is removed when a client sends teardown, closes its
endpoint of the TCP connection or the sessions expires.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=732226
Once we manage a media in a session, we can't unmanage it anymore
without destroying it. Therefore, first check everything before we
manage the media, otherwise if something is wrong we have no way to
unmanage the media.
If we created a new session and something went wrong, remove the session
again. Fixes a leak in the unit test.
Don't just keep a weak ref to the session objects but use a hard ref. We
will be notified when a session is removed from the pool (expired) with
the new session-removed signal.
Don't automatically close the RTSP connection when all the sessions of
a client are removed, a client can continue to operate and it can create
a new session if it wants. If you want to remove the client from the
server, you have to use gst_rtsp_server_client_filter() now.
Based on patch from Ognyan Tonchev <ognyan.tonchev at axis.com>
See https://bugzilla.gnome.org/show_bug.cgi?id=732226
Add encryption and authentication key length parameters to MIKEY. For
the encoders, the key lengths are obtained from the cipher and auth
algorithms set in the caps. For the decoders, they are obtained while
parsing the key management from the client.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=730472
Coverity was moaning about unreachable code, and I think it was just
confused by { being before the label. We'll see if it pops up again.
Coverity 1197705
When we have too many messages queued for a client (currently hardcoded
to 100) we overflow and drop the messages. Add a drop-backlog property
to control this behaviour. Setting this property to FALSE will retry
to send the messages to the client by waiting for more room in the
backlog.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=725898
Set our state to UNPREPARING and release the state-lock before
setting the pipeline to the NULL state. This way, any pad-added
callback will be able to take the state-lock and check that we are now
unpreparing instead of deadlocking.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=727102
If we have multiple profiles (AVP or AVPF) for a stream, make one m=
line in the SDP for each profile. The client is then supposed to pick
one of the profiles in the SETUP request. Because the m= lines have the
same pt, the client also knows that only 1 option is possible.
Pass the multicast address of the stream in the connection info in the
SDP so that clients try a multicast connection first.
Only allow multicast connections in the test-multicast example. Also
increase the TTL a little.
If client supplied a range check if the range specifies the start point.
If not, then do an accurate seek to the current position. If a start
point was specified do do a key unit seek to make sure the streaming
starts with decodeable frames.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=724611
in gst_rtsp_media_prepare() the thread is not used if media is already
prepared (e.g. media shared) so we want to stop the thread. otherwise, a
leak occurs.
https://bugzilla.gnome.org/show_bug.cgi?id=724182
Ignore streams that can't generate RTP-Info instead of failing.
Don't return the empty string when all streams are unconfigured but
return NULL so that we don't generate and empty RTP-Info header.
Improve docs a little.
Only set the keyframe flag when we modify the start position. The
keyframe flag should probably be ignored when no change is requested but
until we can claim this is all documented properly and all demuxer
implement this, avoid setting the flag.
See also https://bugzilla.gnome.org/show_bug.cgi?id=723075
