video-info sets gst colorimetry to default value when colorimetry in caps
is unparsable or invalid. Then v4l2object uses this gst colorimetry to do
mapping with v4l2 colorimetry. This may cause colorimetry mismatch when
check mapped gst colorimetry with that read from caps directly.
To fix this, need to correct gst colorimetry as that parsed from video-info
when check gst_v4l2_video_colorimetry_matches().
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/917>
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>
This commit negotiate F32 audio format if MODE_FLOAT used in wavpack file.
Wavpack float mode is always in 32-bit IEEE format.
The following pipeline plays distorted audio if source file is encoded in float mode:
gst-launch-1.0 filesrc ... ! wavpackparse ! wavpackdec ! pulsesink
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/894>
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>
Vp8/vp9 supported profiles/levels are listed in decoder sink caps, but
there is no parser for these two formats and the demuxers also don't have
these information. It causes negotiation fail between demuxers and decoder
when check caps "accept = gst_caps_is_subset (caps, template_caps);".
To fix this, need to remove profiles/levels for vp8/vp9 formats in decoder
sink caps.
Fix#854
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/887>
Negotiating v4l2h264dec ! v4l2h264enc transcoding pipelines fails in
case the encoder does not accept framerate=(fraction)0/1.
The acquired caps used for downstream negotiation are determined from
gst_v4l2_object_acquire_format(), which sets the GstVideoInfo::fps_n
and ::fps_d fields to 0.
To fix this, copy the frame rate from the sink side.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/882>
This patch adds the detection, dequeuing and reporting of the SOURCE_CHANGE
event when the CH_RESOLUTION flag is set. The acquire function will now return
a new custom success called GST_V4L2_FLOW_RESOLUTION_CHANGE. In order to use
this new feature, elements must enable it by calling:
gst_v4l2_buffer_pool_enable_resolution_change (pool);
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/870>
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>
