Upon fatal errors the loop function will first post an error message
then push out an EOS event.
An application may react immediately to the error message by setting the
state of the pipeline to NULL, meaning by the time we push out the EOS
event PAUSED_TO_READY may have reset the seek seqnum to -1.
While this is harmless, the assertion when setting an invalid seqnum
isn't tidy, fix this by simply not resetting to INVALID as it serves no
practical purpose and the next READY_TO_PAUSED will select a new seqnum
anyway.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7032>
Even if no new synchronization information is available.
This is necessary because the timestamp offset logic in rtpbin depends
on the base RTP time that is determined by the jitterbuffer, but this
changes all the time (especially in mode=slave) and the timestamp
offsets have to be updated accordingly. Doing so is especially important
if they're only determined by the RTP-Info, which never changes from the
very beginning.
The interval can be configured via the new min-sync-interval property.
Synchronization happens at least that often, but at most as often as the
old sync-interval property allows.
Both intervals are now based on the monotonic system clock.
Additionally, clean up synchronization code a bit, only emit either
inband NTP or RTCP SR synchronization at the same time, based on which
one has the more recent time information, and only emit RTP-Info
synchronization if it wasn't provided previously at the same time as the
NTP-based synchronization information.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6543>
There is generally no requirement to ignore RTCP SR if the RTP time of
the SR differs a lot from the last received RTP packet. The mapping
between RTP and NTP time stays valid until there was a stream reset, in
which case we wouldn't use that information anyway.
When using rtcp-sync-send-time=false the default of 1s difference can
easily be exceeded, e.g. if encoding of the stream after capture adds
more than 1s of latency.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6543>
Never is useful for some RTSP servers that report plain garbage both via
RTCP SR and RTP-Info, for example.
NTP is useful if synchronization should only ever happen based on RTCP
SR or NTP-64 RTP header extension.
Also slightly change the behaviour of always/initial to take RTP-Info
based synchronization into account too. It's supposed to give the same
values as the RTCP SR and is available earlier, so will generally cause
fewer synchronization glitches if it's made use of.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6543>
Instead of switching on the very first stream, require that all streams
have switched before switching to the different synchronization
mechanism.
Without this there will be a noticeable gap during the switch. E.g. when
going from RTP-Info to NTP-based association, first the first stream
only would get an offset, then the first two, ... then all of them.
Depending on the order of streams this will cause a lot of changes in
ts-offset during the transition.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6543>
Previously these parameters were randomly changed in the body of the
function to avoid having to declare a new variable, which made the code
very hard to follow. By marking them as const this won't be possible
anymore in the future.
Also the RTP clock-base (RTP time from RTSP RTP-Info) is an unsigned
64 bit integer as it's an extended RTP timestamp.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6543>
Both were entangled previously and very hard to follow what happens
under which conditions. Now as a very first step the code decides which
of the two cases it is going to apply, and then proceeds accordingly.
This also avoids calculating completely invalid values along the way and
even printing them int the debug output.
Also improve debug output in various places.
This shouldn't cause any behaviour changes.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6543>
This simplifies the code as it's a much simpler case than the normal
inter-stream synchronization, and interleaving it with that only
reduces readability of the code.
Also improve some debug output in this code path.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6543>
If we have constant duration buffers, set the duration on
outgoing buffers, like rtpmp4adepay does. This fixes
problems with (for example) muxers like mp4mux not writing
the duration of the final sample into the index.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6878>
During RTP-Info synchronization, clock_base was temporarily switched
from the actual clock-base to the base RTP time and then back some lines
later.
Instead directly work with the base RTP time. The comment about using a
signed variable for convenience doesn't make any sense because all
calculations done with the value are unsigned.
Similarly, rtp_clock_base was overridden with the rtp_delta when
calculating it, which was fine because it is not used anymore
afterwards. Instead, introduce a new variable `rtp_delta` to make this
calculation clearer.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6536>
It's not in the same period as the current RTP base time but always in
the very first period. This avoids using it again at a much later time.
The code in question is only triggered with rtcp-sync=rtp-info.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6536>
It is compared to other extended RTP timestamps all over rtpjitterbuffer
and since 4df3da3bab the initial extended RTP timestamp is not equal
anymore to the plain RTP time.
Continue passing a non-extended RTP timestamp via the `sync` signal for
backwards compatibility. It will always be a timestamp inside the first
extended timestamp period anyway.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6536>
When the buffer DTS is estimated based on arrival time at the
jitterbuffer (rather than provided on the incoming buffer itself),
it shouldn't be used for skew adjustment. The typical case is
packets being deinterleaved from a tunnelled TCP/HTTP RTSP stream,
and the arrival times at the jitter buffer are not well enough
correlated to usefully do skew adjustments.
This restores the original intended behaviour for the 'estimated dts'
path, that was broken years ago during other jitterbuffer refactoring.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6509>
If we can calculate timestamps for buffers, then set the duration
on outgoing buffers based on the number of samples depayloaded.
This can fix the muxing to mp4, where otherwise the last packet
in a muxed file will have 0 duration in the mp4 file.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6447>
When we're doing a state change from PLAYING to NULL, first we invoke
gst_rtspsrc_loop_send_cmd_and_wait (..., CMD_CLOSE, ...) during
PAUSED_TO_READY which will schedule a TEARDOWN to happen async on the
task thread.
The task thread will call gst_rtspsrc_close(), which will send the
TEARDOWN and once it's complete, it will call gst_rtspsrc_cleanup()
without taking any locks, which frees src->streams.
At the same time however, the state change in the app thread will
progress further and in READY_TO_NULL it will call gst_rtspsrc_stop()
which calls gst_rtspsrc_close() a second time, which accesses
src->streams (without a lock again), which leads to simultaneous
access of src->streams, and a segfault.
So the state change and the cleanup are racing, but they almost always
complete sequentially. Either the cleanup sets src->streams to NULL or
_stop() completes first. Very rarely, _stop() can start while
src->streams is being freed in a for loop. That causes the segfault.
This is unlocked access is unfixable with more locking, it just leads
to deadlocks. This pattern has been observed in rtspsrc a lot: state
changes and cleanup in the element are unfixably racy, and that
foundational issue is being addressed separately via a rewrite.
The bandage fix here is to prevent gst_rtspsrc_stop() from accessing
src->streams after it has already been freed by setting src->state to
INVALID.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6302>
The transport stream only returned the CAPS for the first matching PT entry
from the `ptmap`. Other SSRC with the same PT where not included. For a stream
which bundled multiple audio streams for instance, only the first SSRC was
knowed to the SSRC demux and downstream elements.
This commit adds all the `ssrc-` attributes from the matching PT entries.
The RTP jitter buffer can now find the CNAME corresponding its SSRC even if it
was not the first to be registered for a particular PT.
The RTP PT demux removes `ssrc-*` attributes cooresponding to other SSRCs
before pushing SSRC specific CAPS to downstream elements.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6119>
And also re-timestamp them with the current buffer's PTS.
Not doing so keeps the timestamps of event packets as
GST_CLOCK_TIME_NONE or the timestamp of the previous buffer, both of
which are bogus.
Making sure that (especially) the first packet has a valid timestamp
allows putting e.g. the NTP timestamp RTP header extension on it.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5173>
Parse the speed and scale in the server's response
*before* the range, so that the range start/stop
are swapped (or not swapped) correctly based
on the server's actual chosen values. Otherwise,
the old rate from the segment is used - what the
last seek asked for, but not necessarily what
the server chooses.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6248>
