gstreamer1: updated to 1.28.3
GStreamer 1.28.3 stable bug fix release
Highlighted bugfixes:
Various security fixes and playback fixes
applemedia: vtdec stability, MoltenVK integration and planar video format handling fixes
audioresample: Fix regression on armv7hf
bpmdetect: Fixes for stereo and multi-channel modes
devicemonitor: wait for start thread to finish when listing devices so all the info is there for e.g. v4l2 provider
fallbacksrc: Add fallback-source and enable-dummy properties
nvidia: fix cudaconvert performance regression and nvdec device creation regression
opengl: add GBRA swizzle support, and fix glcolorconvert vertical flip issue on crop
rtspsrc: include user-agent property in HTTP tunnel requests and fix mikey regression
threadshare: add leaky mode to dataqueue-based elements
v4l2: fix negotiation error when trying to force stateful decoders to output dmabufs
webrtcsink: Add support imx8mp vpuenc_hevc hardware H.265 encoder
cerbero: Extend gst-plugins-rs melding to Darwin platforms for smaller binary sizes and static linking improvements
[3 lines not shown]
[mlir][spirv] Remove ConstantLike trait from spirv.ARM.GraphConstant (#198054)
Operations with the `ConstantLike` trait can always be folded into a
concrete attribute value. However, the `spirv.ARM.GraphConstant` op
cannot be folded, because its GraphConstantID is merely a unique
identifier used to map to the actual constants defined in the SPIR-V
module. Therefore, the `ConstantLike` trait should be removed from
`pirv.ARM.GraphConstant`. Fixes #197970.
unknown_ext_print: avoid casting away const
The BIO_dump_indent() API masterpiece expects a const char pointer as
input. Don't cast away const when suppressing pointer sign warnings.
Prompted by a report by N. Dossche
ok kenjiro
Ensure X509V3_EXT_print() only returns 0 and 1
In a rare mistake by schwarze, X509V3_EXT_print() is documented to return
0 and 1. This is also what most internal callers expect.
However, if either X509V3_EXT_DUMP_UNKNOWN or X509V3_EXT_PARSE_UNKNOWN is
set, the extension has an unknown NID or on failure to deserialize the
extension value, the return values of BIO_dump_indent() (which is number
of bytes written or -1 on error) and ASN1_parse_dump() (which is 0, 1, or
2 on EOC) are propagated.
Follow what OpenSSL did and translate to Boolean returns. Error indicators
are rather useless here since most errors are ignored anyway. Most callers
do if (!X509V3_EXT_print(...)) but they also pass a zero flag.
Reported by N. Dossche
ok kenjiro
[llvm-ir2vec] Breaking up llvm-ir2vec lib implementation to clean up MIR deps from ir2vec python bindings (#194414)
The Python bindings only expose IR2Vec functionality. MIR2Vec has no
Python API. However, the single `LLVMEmbUtils` library bundled both
IR2VecTool and MIR2VecTool, causing CodeGen and Target components to be
linked into the nanobind module unnecessarily.
This patch splits the library along that boundary. LLVMIREmbUtils covers
IR2Vec and is linked by both the CLI tool and the Python bindings.
LLVMMIREmbUtils covers MIR2Vec and is linked only by the CLI tool.
Result: Python wheel size reduces from ~14 MB to ~4 MB.
[llvm-ir2vec] Setting up ir2vec python bindings testing for ml-opt bots (#194593)
- ~We are enabling IR2Vec Python binding tests in the LLVM monolithic
Linux CI by adding -D LLVM_IR2VEC_ENABLE_PYTHON_BINDINGS=ON to
monolithic-linux.sh.~
- We're adding testing for ir2vec python bindings with the ml-opt
buildbots. To that end, we need to add pip install requirements, and
other relevant flags to make way for a seamless warning-free llvm build.
The following changes are being done here
- Adding a requirements.txt file, putting out an explicit nanobind
requirement.
- Adding the option for downstream users to test bindings as part of the
`check llvm` umbrella, by passing the appropriate bindings flag
- Suppressing warnings from the nanobind headers, in order to ensure a
seamless llvm cI build
