The older 0.28 version has a buggy --msvc-syntax option:
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8717#note_3001648
This 32-bit version was compiled from our meson port of pkg-config:
https://gitlab.freedesktop.org/gstreamer/meson-ports/pkg-config
The toolchain used was MSYS2's mingw32-gcc toolchain
`mingw-w64-i686-gcc` so that it uses 32-bit MSVCRT, which gives it
maximum compatibility with all Windows versions. UCRT DLLs are
specific to the VS version and Windows version.
This version will also not insert any system library or include paths,
like the previous 0.28 version. The build commands were:
```
meson setup --optimization=s --strip \
--wrap-mode=forcefallback \
-Dpc_path='' \
-Dsystem_include_path='' \
-Dsystem_library_path='' \
_mingw32
meson install --destdir $PWD/install -C _mingw32
cp install/bin/pkg-config.exe .
zip pkg-config-$VERSION.zip pkg-config.exe
```
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9376>
This causes servers such as AWS MediaLive to drop the connection, and
the message flow chart as documented in the "spec" always has the
server sending it first, and the client replying to it on reception of
the Set Peer Bandwidth, which we do since 286a3829b637.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9360>
Previous version passed just enough data to the parser to detect
main/main-10, but main-422-10 is one of the range extensions profiles.
Those need a few more bits to be accurately detected, and since those
were just uinitialized memory previously, we'd incorrectly end up with
main or main-10 when the encoder was in fact giving us 4:2:2 10bit
output.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9348>
Similar to h264parse, this patch enhances the element to parse LCEVC enhancement
data from SEI, and attach it to output buffers as GstLcevcMeta. The 'lcevc'
field in the output caps is also set to TRUE or FALSE depending on whether LCEVC
data is present or not.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9335>
The download element relied on a fuzzy translation from GStreamer format to a
DRM fourcc, and then all supported modifiers for that fourcc. Since !9306 this
was fixed to only enumerate that way when direct import is used.
Flag direct upload to the transform caps helper, so that we now enumerate all
non-external formats again.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9339>
When using direct DMABuf upload, supported DRM formats and modifiers
pairs should be translated to RGBA. Instead of overwriting the translation
to RGBA, which may endup having nothing to override, we introduce a new
flag for the transform helper, so it can do direct translation.
This fixes a regression introduced by !9306, and fixes more negotiations
issues.
Fixes#4525
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9339>
self->window is created with the first frame, so it is not available when
properties are set during construction of the element.
Skip calling gst_wl_window_ensure_fullscreen() in this case.
The window is already constructed with the current configured fullscreen state,
nothing else in needed here.
Without this, running e.g. 'gst-launch-1.0 -v videotestsrc ! waylandsink
fullscreen=true' will result in:
GStreamer-Wayland-CRITICAL **: 14:11:19.921: gst_wl_window_ensure_fullscreen: assertion 'self' failed
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9283>
Some WebRTC implementations such as Pion are unhappy if the
profile-level-id isn't returned with a compatible profile as the
RFC requires. Let's try to reform it
In practice, the correct way to do this would be to not use caps
intersection, but to instead implement the correct RFC compliant
SDP O/A negotiation of formats.
Include a unit test written by Philippe Normand
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9031>
