Don't reconfigure outputs when the select-streams
event is sent from the app, as the selection may
not take effect for some time. Instead, wait
for the pipeline to confirm the new set of
selected streams when it sends the message.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1900>
If we previously had subtitles coming in, the video
may be chained through a text overlay block. Before,
the code would end up trying to link pads that were
already linked and video would not get reconnected
properly.
To fix that, make sure that the candidate
pads are actually unlinked first. If a textoverlay
is present and no longer needed, it will be cleaned
up later in the reconfiguration sequence.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1900>
Requesting a new pad can start a reconfiguration cycle, where
playsink will block all input pads and wait for data on them
before doing internal reconfiguration. If a pad is released,
that reconfiguration might never trigger because it's now waiting
for a pad that doesn't exist any more.
In that case, complete the reconfiguration on pad release.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1180>
Fix a small race where a group can receive stream-start
and post a pending buffering message just as another
thread posts a different buffering message, causing them
to be received by the application out of order. In the
worst case, this leads the application receiving a
stale 99% buffering message and going back to buffering
right after the 100% buffering message.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1840>
As specified formally in RFC8851
Each rid description is placed in its own caps field in the structure.
This is very similar to the already existing extmap-$id sdp<->caps
transformations that already exists.
The mapping is as follows:
a=rid:0 direction ';'-separated params
where direction is either 'send' or 'recv'
gets put into a caps structure like so:
rid-0=(string)<"direction","param1","param2",etc>
If there are no rid parameters then the caps structure is generated to
only contain the direction as a single string like:
rid-0=(string)direction
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1760>
Remove the symbolic link `gst-uninstalled` which points to `gst-env`.
The `uninstalled` is the old name and the project should stick to a
single name for the procedure.
Remove the term from all the files, exceptions are variables from
dependencies like `uninstalled_variables` from pkgconfig and
`meson-uninstalled`.
Adjust mentions of the script in the documentation and README.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1743>
Do not maintain similar build instructions within each gst-plugins-*
subproject and the subproject/gstreamer subproject. Use the build
instructions from the mono-repository and link to them via hyperlink.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1743>
While this is slightly more expensive (~48% slower per random number) it
does not cause any measurable difference when running through a complete
audio conversion pipeline.
On the other hand its random numbers are of much higher quality and on
spectrograms for 32 bit to 24 bit conversion the difference is clearly
visible.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1729>
The instant-rate value in the TrickMode enum is a
flag, but the other values are not. Move instant-rate
to the end of the enum and give it a value large enough
for it to be used without modifying the trick-mode
setting.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1788>
They can't be used in any useful way. The type of every GstMemory is
always GST_TYPE_MEMORY and the subtyping relationship has to be
implemented on top of that via the associated allocator and mem_type
string.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1764>
This is a minimal unit test the show that the stride extrapolation can work
with all pixel format we support. This minimal verify that the extrapolation
match the stride we set into GstVideoInfo with 320x240 for all the pixel
format we support. The tiles formats are skipped, since their stride is
set as two 16bit integers, and we also skip over palette planes.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1567>
Many of the legacy APIs, specifically in the Linux Kernel, have a
single stride for the pictures. In this context, it is common
to extrapolate the other strides based on the selected pixel
format. Such function have been copy pasted from video4linux2
plugin into wayland, kms and v4l2codecs plugins.
This patch implements a generalized from of that function and
make it available to everyone through the video library.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1567>
Unlike other simple tiled formats, the Mediatek HW use different tile size
per-plane. The tile size is scaled according to the subsampling. Effectively,
using the name 16L32S to represent linearly layout tiles of size 16x32 bytes
in the Y plane, and 16x16 in the UV plane. In order to make this specificity
discoverable, a new SUBTILES flags have been added.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1567>
... instead of round(). Depending on framerate, calculated position
may not be clearly represented by using uint64, 30000/1001 for example.
Then the result of round() can be sliglhtly larger (1ns) than
buffer timestamp. And that will cause unnecessary frame delay.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1747>
If a serialized event arrives behind a buffer, it should not be send before
it. This fixes the pending event handling so that only early pending events,
the one that arrrived or was generated while the adapter was empty get send
before pushing buffer. All other events are not pushed after.
This issue lead the latency tracer to think our audio encoder did not have any
latency. This was testing with opusenc in a live pipeline.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1266>
For artificial input (in unit tests), all six bytes of
constraint_indicator_flags in hevc_caps_get_mime_codec() can be
zero. Add a guard against an out-of-bounds error that occurred in that
case. Change variables to signed int so comparison with -1 works.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1677>
... in order to make older g-i happy (~1.60) which doesn't like
freeform descriptions in the value_name field. Which in turn
then makes hotdoc happy instead of erroring out when we bump
the symbol index version.
We usually only (ab)use the name field for description strings
for private plugin enums, not for public API visible to bindings.
This lets glib-mkenum generate the _get_type() function for the
enum again, which in turn will generate the expected value names
to match the enums.
We might be able to add this back later once we can upgrade the
g-i version requirement (and the documentation job image).
This reverts most of commit b0aab48cdcf0a454d14aeb4d907209d8ee3f1add
There's a race condition in gsttagdemux.c between typefinding and the
end-of-stream event. If TYPE_FIND_MAX_SIZE is exceeded,
demux->priv->collect is set to NULL and an error is returned. However,
the end-of-stream event causes one last attempt at typefinding to occur.
This leads to gst_tag_demux_trim_buffer() being called with the NULL
demux->priv->collect buffer which it attempts to dereference, resulting
in a segfault.
The malicious MP3 can be created by:
printf "\x49\x44\x33\x04\x00\x00\x00\x00\x00\x00%s", \
"$(dd if=/dev/urandom bs=1K count=200)" > malicious.mp3
This creates a valid ID3 header which gets us as far as typefinding. The
crash can then be reproduced with the following pipeline:
gst-launch-1.0 -e filesrc location=malicious.mp3 ! queue ! decodebin ! audioconvert ! vorbisenc ! oggmux ! filesink location=malicious.ogg
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/967
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1620>
Hotdoc should be able to extract and parse comments out of these. Just
need to be careful to only add the glob in directories that actually
contain *.m (objc) and *.mm (objcpp) files.
Also fix some doc comments and remove redundant ones.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1614>
This is usually necessary to allow gst-indent to treat it as
a statement, but we do not run gst-indent on headers and we do not
have extra semicolons in other places that this macro is used in the
header. Fixes warnings when using the header:
```
In file included from gstreamer/subprojects/gst-plugins-base/gst-libs/gst/video/video.h:185,
from XYZ:9001:
gstreamer/subprojects/gst-plugins-base/gst-libs/gst/video/gstvideoaggregator.h:206:78: warning: ISO C does not allow extra ‘;’ outside of a function [-Wpedantic]
206 | G_DEFINE_AUTOPTR_CLEANUP_FUNC(GstVideoAggregatorConvertPad, gst_object_unref);
| ^
gstreamer/subprojects/gst-plugins-base/gst-libs/gst/video/gstvideoaggregator.h:214:181: warning: ISO C does not allow extra ‘;’ outside of a function [-Wpedantic]
214 | G_DECLARE_DERIVABLE_TYPE (GstVideoAggregatorParallelConvertPad, gst_video_aggregator_parallel_convert_pad, GST, VIDEO_AGGREGATOR_PARALLEL_CONVERT_PAD, GstVideoAggregatorConvertPad);
| ^
```
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1572>
The earlier size of 2 MB was set back in 2009, it doesn't
seem unreasonable to raise it to 8 MB these days. The use
case at hand is matroskademux containing both a video stream
with a very low amount of compression but no decoding latency,
and a H265 stream.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1538>
Sometimes we can't output anything because we don't have enough
incoming frames. In that case, the resampler was trying to call
do_quantize() and do_resample() in a loop forever because there would
never be samples to output (so chain->samples would always be NULL).
Fix this by not calling chain->make_func() in a loop -- seems
completely unnecessary since calling it over and over won't change
anything if the make_func() can't output samples.
Also add some checks for the input and / or output being NULL when
doing conversion or quantization. This will happen when we have
nothing to output.
We can't bail early, because we need resampler->samples_avail to be
updated in gst_audio_resampler_resample(), so we must call that and
no-op everything along the way.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1461>
BT.2020 color primaries are designed to cover much wider range of
CIE chromaticity than BT.709, and also it's used for both SDR and HDR
contents. So, the incorrect assumption (i.e., BT.709 as a BT.2020)
is risky and resulting image color tends to be visually very wrong.
Unless there's obvious clue, don't consider color space of high resolution
video stream as BT.2020
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1445>
The ["level-asymmetry-allowed"] field states that the peer wants the
profile specified in the "profile-level-id" fields but doesn't care
about the level. To express this in GStreamer caps term, we add a
"profile" field in the caps, which reuses the usual "profile" semantics
for H.264 streams and, and remove "profile-level-id" and
"level-asymmetry-allowed" fields.
["level-asymmetry-allowed"]: https://www.iana.org/assignments/media-types/video/H264
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1410>
There's a potential race condition with this sort of pipelines on
certain systems (depends on the processing load):
GST_DEBUG_DUMP_DOT_DIR=/tmp \
gst-launch-1.0 uridecodebin3 uri=file://stream.mp4 ! glupload ! \
glimagesink --gst-debug=*:4
Right after the pipeline passes from PAUSED to READY, bin_to_dot_file
dumps uridecodebin3 properties, but current uri and suburi might be
already freed, causing a potential use-after-freed.
This patch makes NULL the current item right after all the play items
are freed.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1353>
Sometimes the resampler has enough space to store all the incoming
samples without outputting anything. When this happens,
gst_audio_resampler_get_out_frames() returns 0.
In that case, the resampler should consume samples and just return.
Otherwise, we get a segfault when gst_audio_resampler_resample() tries
to resample into a NULL 'out' pointer.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1343>
