Since glib 2.62, the accumulated return values in RUN_CLEANUP override the
accumulated return values in RUN_FIRST. Since:
1. We have a default handler that always returns TRUE, and
2. User handlers are only run in RUN_FIRST, and
3. Our accumulator just takes the latest return value
We were discarding the return value from the user handler and always
sending messages even if the user handler said not to. See
https://gitlab.gnome.org/GNOME/glib/-/issues/2352 for more details.
This signal does not need RUN_CLEANUP or RUN_FIRST, so just change it
to RUN_LAST so that it's emitted exactly once and accumulated once.
With this fix, this signal can now be used to intercept PAUSE when
going to GST_STATE_NULL so that the server does a TEARDOWN (if
necessary) and not a PAUSE, which will confuse other RTSP clients when
playing shared media.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/909>
Directly setting rtspsrc to the NULL state before putting the pipeline
in the NULL state usually works, but it can cause a deadlock in some
cases, so it's not a reliable mechanism to fix this.
This reverts commit f37afdafff:
"rtspsrc: Fix state changes from PAUSED to PLAYING"
and commit 76d624b2df:
"rtspsrc: Do not send PAUSE command when going to GST_STATE_NULL"
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/908>
The old code had a couple of issues that all lead to potential memory
safety bugs.
- Use a constant for the Wavpack4Header size instead of using sizeof.
It's written out into the data and not from the struct and who knows
what special alignment/padding requirements some C compilers have.
- gst_buffer_set_size() does not realloc the buffer when setting a
bigger size than allocated, it only allows growing up to the maximum
allocated size. Instead use a GstAdapter to collect all the blocks
and take out everything at once in the end.
- Check that enough data is actually available in the input and
otherwise handle it an error in all cases instead of silently
ignoring it.
Among other things this fixes out of bounds writes because the code
assumed gst_buffer_set_size() can grow the buffer and simply wrote after
the end of the buffer.
Thanks to Natalie Silvanovich for reporting.
Fixes https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/859
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/902>
This usually doesn't matter, but it is disruptive when streaming from
a shared media since it will pause all other clients when any client
exits.
This new behaviour is opt-in and should be safe because you need to
set the NULL state on rtspsrc directly, instead of just on the
pipeline. See the updated documentation for an explanation.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/901>
Some cameras (e.g. HikVision DS-2CD2732F-IS) return "551 Option
not supported" when a command is sent that is not implemented
(e.g. PAUSE). Instead; it should return "501 Not Implemented".
This is wrong, as previously, the camera did announce support for PAUSE
in the OPTIONS.
In this case, handle the 551 as if it was 501 to avoid throwing errors
to application level. */
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/885>
wavparse claims to be able to support seeking in the READY state by
saving the pending seek event and actually seeking later after having parsed the
header.
Problem was that this seek event was reset on the READY to PAUSED
transition, making all this code useless. Fixing it by stop resetting
on READY to PAUSED transition as we already reset on PAUSED to READY
and when initiating the element.
Note that DTS marker detection isn't support in such scenario as
gst_type_find_helper_for_buffer() needs a buffer containing the
beginning of the stream.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/879>
Similar to rtpvp8depay, when packet loss occurs, the depayloader
starts waiting for a keyframe.
We try to only stop waiting when all the packets for the new keyframe
have been received, by only resetting waiting_for_keyframe when
encountering the first packet of a keyframe, this is slightly
fragile because there is no bit that explicitly marks the start
of an access unit, so we rely on the existing picture_start
detection code.
As a consequence, the property is only meaningful when outputting
access units, and is ignored when outputting NALs directly.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/834>
Due to the may_cancel flag in GstRTSPConnection, receiving might not get
cancelled when supposed to. In this case, gst_rtsp_src_receive_response
will have to wait until timeout instead but if busy receiving RTP
data, this timeout will never occur.
With this patch, gst_rtsp_src_receive_response returns GST_RTSP_EINTR
if flushing is set to TRUE instead of continuing to receive.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/831>
These should be with a single ':'. The double '::' results in a CI with
build failure message like below.
ERROR: [links]: (mandatory-link-not-found): Mandatory link Link GstSocketTimestamp -> None (GstSocketTimestamp) could not be resolved
ERROR: [check-missing-since-markers]: (missing-since-marker): Missing since marker for udpsrc:socket-timestamp
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/828>
A classic case of not enough locking.
One interesting thing with this is the interaction between the
rotation value and caps negotiation. i.e. the width/height of the caps
can be swapped depending on the video-direction property. We can't lock
the entirety of the caps negotiation for obvious reasons so we need to
do something else. This takes the approach of trying to use a single
rotation value throughout the entirety of the negotiation and then
subsequent output frame in a kind of latching sequence.
Fixes: https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/792
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/836>
While the standard is a bit vague about whether the padding,
extension and marker bits should be protected:
> The usage, by senders and receivers, of the following bits shall
> be defined by the associated video/audio transport standards:
It is obviously necessary and useful for some formats (eg VP8)
that those indeed be protected.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/839>
https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/798
introduced a check in the need-new-fragment logic to avoid starting a
new fragment unless there has been some data on the reference stream,
but the check is done against the number of bytes that have been
received on the input, not the number that were released for output
into the current fragment.
Fix the check to remember and test against bytes that have been sent
for output.
This also fixes a problem where starting a new fragment fails to
request a new filename from the format-location signal.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/833>
This will end up as a "received" packet, due to the code in
source_push_rtp, which will think this is a packet being received.
Instead drop the packet and hope that either:
1. Something upstream responds to the GstRTPCollision event and changes
SSRC used for sending.
2. That the application responds to the "on-ssrc-collision" signal, and
forces the sender (payloader) to change its SSRC.
3. That the BYE sent to the existing user of this SSRC will respond to
the BYE, and that we timeout this source, so we can continue sending
using the chosen SSRC.
The test reproduces a scenario where we previously would have sent
on a non-internal source.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/817>
