Internally videcrop can call gst_video_crop_set_info() with NULL as in
caps. Then critical messages are raised when the in caps are
processed.
To fix this the in caps are checked, and if they are present, its
capsfeature is extracted, otherwise, the previous raw caps detection
remains as before.
Also the videocrop-test removes the format field in the structure
because now its always passed.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/1056>
When connecting to an RTSP server in tunnled mode (HTTP) the server
usually replies with a x-server header. This contains the address
of the intended streaming server. However some servers return an
"invalid" address. Here follows two examples when it might happen.
1. A server use Apache combined with a separate RTSP process to handle
Https request on port 443. In this case Apache handle TLS and
connects to the local RTSP server, which results in a local
address 127.0.0.1 or ::1 in the x-server reply. This address is
returned to the actual RTSP client in the x-server header.
The client will receive this address and try to connect to it
and fail.
2. The client use a ipv6 link local address with a specified scope id
fe80::aaaa:bbbb:cccc:dddd%eth0 and connects via Http on port 80.
The RTSP server receives the connection and returns the address
in the x-server header. The client will receive this address and
try to connect to it "as is" without the scope id and fail.
In the case of streaming data from RTSP servers like 1. and 2. it's
useful to have the option to simply ignore the x-server header reply
and continue using the original address.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/1007>
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>
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>
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>
This will be used to select the appropriate decoders. We also only attach the
GstVideoCodecAlphaMeta if the AlphaMode element is set, this is to stay on the
safe side and mimic what browsers (verified in Firefox and Chromium code) do.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/968>
This generalize the feature over using mini object quark data. If
that feature was Matroska specifc, using the new CustomMeta would have
been enough and arguably cleaner then QData, though it seems that
similar technique is use with AV1 Image Format (AVIF).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/968>
qtmux attempts to choose between writing a 32-bit stco chunk offset table
when it can, but switch to a 64-bit co64 table when file offsets go over
4GB.
This patch fixes a problem where the atom handling code was checking
mdat-relative offsets instead of the final file offset (computed by
adding the mdat position plus the mdat-relative offset) - leading to
problems where files with a size between 4GB and 4GB+offset-of-the-mdat
would write incorrect STCO tables with some samples having truncated
32-bit offsets.
Smaller files write STCO correctly, larger files would switch to
co64 and also output correctly.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/970>
* Try to make variable and function names more clear.
* Add plenty of comments describing the logic step-by-step.
* Improve the logging around this, making the logs easier to read and
understand when debugging these issues.
* Revise the logic of packets that are actually beyond saving in doing
the following:
1. Do an optimistic estimation of which packets can still arrive.
2. Based on this, find which packets (and duration) are now hopelessly
lost.
3. Issue an immediate lost-event for the hopelessly lost and then add
lost/rtx timers for the ones we still hope to save, meaning that if
they are to arrive, they will not be discarded.
* Revise the use of rtx-delay:
Earlier the rtx-delay would vary, depending on the pts of the latest
packet and the estimated pts of the packet it being issued a RTX for,
but now that we aim to estimate the PTS of the missing packet accurately,
the RTX delay should remain the same for all packets.
Meaning: If the packet have a PTS of X, the delay in asked for a RTX
for this packet is always a constant X + delay, not a variable one.
* Finally ensure that the chaotic "check-for-stall" tests uses timestamps
that starts from 0 to make them easier to debug.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/952>
