H.264 base class oriented for hardware accelerated encoders, such as Vulkan, VA
and others.
1. It can be parametrized for hardware limits, such as lists size, b-frames
supports, etc.
2. It produces a GOP structure map [IDR, R/I/B, ...)
3. It proposes parameters set and other strucures such as bitrate limites.
Subclases can modify those structures.
4. It calls the subclass encode virtual method implementation.
It doesn't handle rate control algorithms or other encoding quality mechanisms.
For a deeper introduction to the class there was a lighting talk in the GstConf
2024: <https://www.youtube.com/watch?v=-fQY54KHH38>
Co-authored-by: He Junyan <junyan.he@intel.com>
Co-authored-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
Co-authored-by: Stéphane Cerveau <scerveau@igalia.com>
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7197>
... and merge wasapi2{capture,render}deviceprovider into single
wasapi2deviceprovider since we can enumerate input/output audio
devices at once using IMMDeviceEnumerator
This is a preparation for complete porting to Win32 API
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9307>
Install properties at the given offset as intended instead of at 0.
Currently there are no elements with any properties, so this has no
effect. This change is needed if any element adds properties in the
future.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9179>
This is for cases where:
* We *do* want to refer to the PCR stream to figure out global positioning, gap
detection, wrapover correction.
* But we do not want to apply any skew correction to the output
This is useful for cases where:
* the input stream has already been clock-corrected (for example with
mpegtslivesrc)
* or where the output doesn't require synchronization against a clock (ex: for
storage)
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9301>
It is not possible to do frame cropping when DMABuf caps feature is negotiated.
The VideoInfo size is zero, resulting in empty destination buffers, and video
convert library may not understand what the format actually is.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9305>
If the conformance window does not requires cropping the top or left of the
window, we can use GstVideoMeta to crop in a zero-copy fashion. If a copy
is needed, the frame copy can also handle it, and is a lot faster.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9305>
Similar to and inspired by glimagesink, xvimagesink and others.
The waylandsink never transform the buffer in any way but delegates this to the
Wayland compositor with the Wayland buffer transform API.
Rotation and window size are already supported, so this just changes the video
surface geometry that is communicated to the Wayland compositor.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9210>
Cleans up the code and fixes two issues:
- If there are no streamheaders in the caps but we have `HEADER`
buffers, it would run `gst_buffer_list_foreach` with `self->headers`
being `NULL`.
- The code forgot to unmap the buffer if it decided to ignore it.
Fixes: 0a562a92d7ee38d8919d1b802add84d3c93b59eb
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9284>
Adding "hip-amd-precompile" build option. If enabled, AMD kernels
will be precompiled at build time. Also "hip-hipcc-arch" build option
(corresponding to --offload-arch hipcc option) is added
so that user can specify target GPU arch instead of auto-detection by hipcc
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8923>
