osxaudiodeviceprovider now probes devices more than once to determine
if the device can function as both an input AND and output device.
Previously, if the device provider detected that a device had any output
capabilities, it was treated solely as an Audio/Sink. This causes issues
that have both input and output capabilities (for example, USB interfaces
for professional audio have both input and output channels). Such devices
are now listed as both an Audio/Sink as well as an Audio/Source.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1809>
The RTP payload seems to be required as it carries the frame count
information. Also, gst_rtp_base_payload_allocate_output_buffer had
the second argument incorrect.
Strangely some devices like Shanling MP4 and Sony XM3 would still
work without this while some like the Sony XM4 do not.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1804>
If the video4linux device supports norms but has no norm set, norm is
returned as an uninitialized variable after the ioctl call, leading to
gst_v4l2_tuner_get_norm_by_std_id() returning a random norm from the
supported norms. Catch this case and instead return NULL to indicate
that no norm is setup.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1758>
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/1793>
Update x264enc long-name to be more than just the name. Then the
description also was updated to be longer than the long-name, and
similar to the plugin description.
Finally, as I am here, H264 was replaced by H.264 and x264 is only a
plugin (not plugins).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1781>
... 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/1755>
It was assumed that the kernel parameters would match with the bitstream value
but instead the author when with another set of value. Surprisingly, this
makes no difference with the resulting fluster score.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1754>
If present, add '-lsocket' and '-lnsl' to network_deps.
ext/curl/meson.build: add network_deps to dependencies
gst/festival/meson.build: same
sys/shm/meson.build: same
Fixes linking issues on Illumos distros.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1736>
The libjpeg-turbo internal state might not be correctly initialized for
the first frame in a stream, pull the frame stride from gstreamer frame
metadata instead, which is correct even for the first frame, and which
makes this code consistent with the surrounding lines.
Fixes: e6d83d8f96 ("jpegdec: Support libjpeg-turbo colorspace conversion")
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1716>
It is imperative that the libjpeg-turbo state is properly initialized
before jpeg_start_decompress() is called. Make sure cinfo.out_color_space
and cinfo.raw_data_out are set to their final values matching their peer
caps before calling jpeg_start_decompress().
Fixes: e6d83d8f96 ("jpegdec: Support libjpeg-turbo colorspace conversion")
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1716>
Pull out peer caps checking code into gst_jpeg_turbo_parse_ext_fmt_convert().
This code is used by libjpeg-turbo extras to determine whether peer is capable
of handling buffers into which libjpeg-turbo can directly decode data. This
kind of check must be performed before jpeg_start_decompress() is called in
gst_jpeg_dec_prepare_decode() as well as in gst_jpeg_dec_negotiate(), hence
the common code.
This commit does modify the code a little to make it easier to call from both
call sites without much duplication, hence the extra `if (*clrspc)` test.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1716>
This reverts commit 2aa2477208.
The commit is completely wrong, libjpeg-turbo is perfectly capable
of decoding I420 (YUV) to RGB. The test case provided alongside the
aforementioned commit passes without this revert because it decodes
image of JCS_YCrCb color space, so the new `if (clrspc == JCS_RGB)`
condition is false on that image, and the libjpeg-turbo decoding
does not get used. The real bug is hidden by that commit.
The real problem is in the call order of gst_jpeg_dec_prepare_decode()
and gst_jpeg_dec_negotiate(). The gst_jpeg_dec_prepare_decode() calls
jpeg_start_decompress() which sets up internal state of the libjpeg,
however, neither cinfo.out_color_space nor cinfo.raw_data_out are
set correctly yet. Those two are set up in gst_jpeg_dec_negotiate()
which is called a bit later. Therefore, the real fix is the set up
cinfo.out_color_space and cinfo.raw_data_out before calling
jpeg_start_decompress(). This is however a separate patch.
Fixes: 2aa2477208 ("jpegdec: only allow conversions from RGB")
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1716>
The current manner for deciding the new temporal unit is based on
temporal delimiter(TD) OBU. We only start a new temporal unit when
the TD comes.
But some streams do not have TD at all, which makes the output "TU"
alignment fail to work. We now add check based on the relationship
between the different layers and it can successfully judge the TU edge.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1712>
Some streams may have problematic OBUs at the beginning, which causes
the parse fail to detect the alignment and return error. For example,
there may be verbose OBUs before a valid sequence, which should be
discarded until we meet a valid sequence. We should let the parse
continue when we meet such cases, rather than just return error.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1712>
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/1706>
1. Use api_version variable rather than static string.
2. Remove pkgconfig generation since currently the library
is not installed, only used internally.
3. Rely on dependency "required" to abort compilation.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1702>
In commit e699aaeb we moved linking of libgudev to the plugin rather
the library, because it's only used in the plugin. But the dependency
check is still done in library.
This patch removes the dependency check in library, and updates the
dependency check in plugin.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1702>
There's no need to do this, and it can make seeking far less accurate.
For a specific use case: I am working with a long (45-minute) MPEG-1 layer 3 file, which has a constant bit rate but no seeking tables. Trying to seek the pipeline immediately after pausing it, without the ACCURATE flag, to a location 41 minutes in, yields a location that is potentially over ten seconds ahead of where it should be. This patch improves that drastically.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1695>
During dispose the pool will still have a reference count of 1 and all
API on it can still be safely called.
Subclasses will have already freed their own data before finalize is
called but would nonetheless be called into again via the pool
deactivation.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1661>
... 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>
The kCVPixelFormatType_64RGBALE enum is only available on macOS Big
Sur (11.3) and newer. We also cannot use that while configuring the
encoder or decoder on older macOS.
Define the symbol unconditionally, but only use it when we're running
on Big Sur with __builtin_available().
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1613>
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>
Platform wise, is not possible, as far as I known, to have Wayland
without kernel's DRM. Though, it's possible to configure
gstreamer-vaapi without DRM but Wayland support, with the enhanced
handling of dmabuf in vaapisink for Wayland, vaapisink will always
fail. Given both issues, configuration with no DRM but Wayland, makes
things more complex, and a simpler approach is to refuse that
configuration.
This patch disables Wayland support if there isn't DRM support. Also,
it disables the display test for Wayland, relying only on DRM and
X11.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1606>
Formats map is instantiated at the end of the display
instantiation. The problem is the Wayland display which looks for a
format in a callback, before the map is populated.
If user compiles gstreamer-vaapi with DRM support, the map is
populated with a DRM display at GStreamer plugin registration. But if
not, or a VA driver is not available, the plugin will try with a
Wayland driver, which cause the NULL de-reference.
Nevertheless, in the case of no DRM support, and if the Wayland
display doesn't get a reply from the format conversion is not a
problem.
So the solution is the trivial one, check if the format map is already
populated before de-reference it.
Fixes: #977
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1606>
This is listed as a public interface implemented by osxaudio, so we
need to mark it as a plugin API so that it's listed in the
documentation correctly.
This is an ancient symbol, so add it to the symbol index too.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1601>
These symbols from macOS plugins osxaudio, osxvideo, and applemedia
have been present for a very long time but were never documented.
This allows us to document these, and also add Since: markers for new
features (symbols) there were added in 1.20
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1601>
This moves the ABI check to the registration, so we don't expose
decoders with the wrong ABI or that are just broken somehow. It
also makes few enhancement:
- Handle missing, but required controls
- Prints the controls macro name instead of id
This should fix RK3399 support with a currently release minor
regression in the Hantro driver that cause errors.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1599>
