... even if hardware does not support interlaced encoding at bitstream level.
Although interlacing information is not written in the bitstream,
that information can be signalled via container, thus allow interlaced
stream.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9328>
Add a new action signal to allow applications to capture
the most recently rendered frame directly from the swapchain
back buffer.
Unlike the existing "last-sample" property, which exposes
the raw input sample before any sink-side processing, this
signal captures the final displayed image after any internal
image processing (e.g., UV remap, color balance, overlay) has been
applied.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9423>
- Add a videoconvert element before the videosink so that the output
works no matter what format gets negotiated (A444_16LE for me)
- Specify a reasonable video format and size with a capsfilter, so
we don't default to something silly like A444_16LE @ 240p.
- Add a timeoverlay element, so it's obvious when stoppping/restarting
the pipeline that the input stream is just picked up again from the
moment the consumer pipeline is restarted.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9422>
Modify the API to retrieve the tensor meta to check for the dimensions
as well.
Also fix an API mistake, the buffer whose dimensions should be checheck
is the one inside the GstTensor, not another buffer some outside.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9411>
Similar to h264parse and h265parse, 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/9365>
Similar to h264parse and h265parse, this patch improves the element to parse
the SEI registered user data from NAL units. The core structure of H266 SEI for
ITU-T T.35 is the same as the other parsers, so we can re-use the same logic.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9365>
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>
