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>
In baseparse we set the fixed caps flag on all src pads, therefore the
source pad caps query in get_allowed_caps will return the current caps.
Current caps won't necessarily intersect with the new caps (e.g. sample
rate change). Replace get_allowed_caps with peer_query_caps.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/816>
