Fix for a regression from commit 8f1384c9. That commit moved the debug
category definition, as static, into a gstvideocropelement.c, but that
category was used as default, in gstvideocrop.c, so it was never used
at logging, so the debug selector never showed the logs for
videocrop.
This patch move back the category definition into gstvideocrop.c and
leaving the function videocrop_element_init() as a noop.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/1049>
By this new property, user can select physical port to connect,
and element will pick requested port instead of random ones.
User should provide full port name including "client_name:" prefix.
An example is
jackaudiosrc port-names="system:capture_1,system:capture_3" ! ...
jackaudiosink port-names="system:playback_2"
In addition to "port-names" property, a new connect type "explicit"
is added so that element can post error message if requested
"port-names" contains invalid port(s).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/1037>
E.g. a pipeline like qmlglsrc ! gldownload ! ... would currently fail to
run because the OpenGL context are not created in the correct order.
The QtWindow also needs to know the OpenGL context used by downstream
elements in order to set optimize for the correct GstGLSyncMeta for
synchonisation purposes.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/1036>
Prevent a condition where splitmuxsink won't go back to NULL state
after a child element fails to change state by making sure that
a READY->READY state change doesn't fail, and by returning
GST_FLOW_ERROR or GST_FLOW_FLUSHING upstream to shut down streaming
as quickly as possible.
This can happen after (for example) setting an invalid filename
on the sink element. In that case, the READY->PAUSED transition
fails, but with internal elements still in the NULL state. Trying
to set splitmuxsink back to NULL then ends up trying to bring
those NULL elements up to READY with a READY->READY transition,
(which fails, prevent splitmuxsink from getting to NULL)
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/1023>
Instead of using the new "application/x-cbcs" caps, we are just adding
a new structure field "ciphe-mode", to indicate which encryption scheme
is used: "cenc", "cbcs", "cbc1" or "cens".
Similarly for the protection metadata, we add the "cipher-mode" field
to specify the encryption mode with which the buffers are encrypted.
"cenc": AES-CTR (no pattern)
"cbc1": AES-CBC (no pattern)
"cens": AES-CTR (pattern specified)
"cbcs": AES-CBC (pattern specified, using a constant IV)
Currently only "cenc" and "cbcs" are supported.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/1013>
If downstream tries to seek in BYTES format, don't pass that through
to upstream. The byte positions downstream requests won't make any
sense in the muxed stream. There might be other formats we want to
pass through to upstream, but BYTES is not one of them. If we get a
seeking query about BYTES format, refuse that too.
This fixes a situation where we're playing a fragmented mp4 over http
and qtdemux refuses the initial seek (in TIME format), but then
h264parse/baseparse send a seek in BYTES format and everything falls
apart.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/1014>
Updating of codec_data in the caps is important to propagate changes
in sps/pps/vps via NALs. Without this, downstream does not renegotiate
when upstream changes resolution.
The comment referring to rtph264pay is from 2015 and is out of date.
rtph264pay stopped doing that in 2017 with commit
dabeed52a9
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/1011>
- atom nodes/bytereader sizes are already checked
- palettes: are fixed/known size
g_memdup() is deprecated since GLib 2.68 and we want to avoid
deprecation warnings with recent versions of GLib.
Also use gst_buffer_new_memdup() instead of _wrapped(g_memdup(),..).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/993>
- ebml-read: add some sanity checks when going from 64-bit
to 32-bit length
- matroska-ids: codec_data_size has been checked via
gst_ebml_read_binary(), is existing allocation.
- matroska-demux: alloc size is from existing allocations
g_memdup() is deprecated since GLib 2.68 and we want to avoid
deprecation warnings with recent versions of GLib.
Also use gst_buffer_new_memdup() instead of _wrapped(g_memdup(),..).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/993>
- png: alloc size variable is a png type that's always 32-bit
- vpx: alloc size based on existing allocation
- wavpack: alloc size based on existing allocation
- icles: gdkpixbufoverlay: trusted and hard-coded input data
- rtp tests: rtp-payloading, vp8, vp9, h264, h265: trusted and/or static input data
g_memdup() is deprecated since GLib 2.68 and we want to avoid
deprecation warnings with recent versions of GLib.
Also use gst_buffer_new_memdup() instead of _wrapped(g_memdup(),..)
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/993>
On Windows with MSVC, jpeg_header_size would end up 2 bytes larger
than it should be. This then leads to the first 2 bytes of the
actual jpeg image data to be dropped, because we think those
belong to the header, which results in an undecodable image when
reconstructed in the depayloader.
What happens is that when the compiler evaluates
jpeg_header_size = mem.offset + read_u16_and_inc_offset_by_2(&mem);
it actually uses the mem.offset value after it has been increased
by the function call on the right hand size of the equation.
From section 6.5 of the C99 spec:
3. The grouping of operators and operands is indicated by the syntax [74].
Except as specified later (for the function-call (), &&, ||, ?:, and
comma operators), the order of evaluation of subexpressions and the
order in which side effects take place are both unspecified.
Fixes https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/889
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/999>
This crash could happen at any time a RTP and RTCP buffer arrived
simultaneously in ssrcdemux.
The problem was that sticky-event arriving while the rtp and rtcp pads
were being set up could arrive just too late to be included in the initial
forwarding.
The fix checks if the stickies have been sent on the srcpad about to be
pushed on, and if not sends them. It also blocks any stickes from
being forwarded *prior* to this happening, to avoid them arriving on
the srcpad multiple times.
Since the test loops 1000 times, this will make running under valgrind
take forever, so use the RUNNING_ON_VALGRIND variable to detect we
are running under valgrind, and reduce the loop-count to 2 in that case.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/992>
