The Cedrus driver would otherwise choose 1KB buffer, which is too small.
This follows what some drivers do, which is simply to use the size a
packed raw image would have. Specifications do not really guaranty any minimum
compression ratio.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1268>
This adds support for slice based decoder like the Allwinner/Cedrus driver. In
order to keep things efficient, we hold the sink buffer until we reach the end
of the picture. Note that as we don't know which one is last, we lazy queue the
slices. This effectively introduces one slice latency.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1268>
GstD3D11ColorConverter implementation is able to rescale video as well.
By doing colorspace conversion and rescale at once, we can save
one cycle of shader pipeline which will can save GPU resource.
Since this element can support color space conversion and rescale,
it's renamed as d3d11convert
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1275>
Using glist requires a lot of small allocation at runtime and also
it comes with a slow sort algorithm. As we play with that for very
frame and slices, use GArray instead. Note that we cache some arrays
in the instance as there is no support for stack allocated arrays
in GArray.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1238>
tsparse leaked input buffers quite badly:
GST_TRACERS=leaks GST_DEBUG=GST_TRACER:9 gst-launch-1.0 audiotestsrc num-buffers=3 ! avenc_aac ! mpegtsmux ! tsparse ! fakesink
The input_done vfunc was passed the input buffer, which it had to
consume. For this reason, the base class takes a reference on the buffer
if and only if input_done is not NULL.
Before 34af8ed66a, input_done was used in
tsparse to pass on the input buffer on the "src" pad. That commit
changed the code to packetize for that pad as well and removed the use
of input_done.
Afterwards, 0d2e908523 set input_done
again in order to handle automatic alignment of the output buffers to
the input buffers. However, it ignored the provided buffer and did not
even unref it, causing a leak.
Since no code makes use of the buffer provided with input_done, just
remove the argument in order to simplify things a bit.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1274>
This is needed for cross-compiling without a build machine compiler
available. The option was added in 0.54, but we only need this in
Cerbero and it doesn't affect older versions so it should be ok.
Will only cause a spurious warning.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1266>
This commit does the following things to fix compilation on FreeBSD:
1. Add required typedefs to linux/types-compat.h.
2. Remove unnecessary include linux/ioctl.h and replace linux/types.h
with linux/types-compat.h. Both files do not exist on FreeBSD.
3. Check the header including makedev macro. FreeBSD does not have
sys/sysmacros.h, and including it unconditionally causes error.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1259>
Instead of storing the raw cc_data, store the 2 cea608 fields individually
as well as the ccp data.
Simply copying the input cc_data to the output cc_data violates a number of
requirements in the cea708 specification. The most prominent being, that
cea608 triples must be placed at the beginning of each cdp.
We also need to comply with the framerate-dpendent limits for both the
cea608 and the ccp data which may involve splitting or merging some
cea608 data but not ccp data or vice versa.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1116>
This was removed in Vulkan 1.2.140.
> Shortly after 2020-04-24, we will be removing the automatically
> generated `VK_*_BEGIN_RANGE`, `VK_*_END_RANGE`, and `VK_*_RANGE_SIZE`
> tokens from the Vulkan headers. These tokens are currently defined for
> some enumerated types, but are explicitly not part of the Vulkan API.
> They existed only to support some Vulkan implementation internals,
> which no longer require them. We will be accepting comments on this
> topic in [#1230], but we strongly suggest any external projects using
> these tokens immediately migrate away from them.
[#1230]: https://github.com/KhronosGroup/Vulkan-Docs/issues/1230
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1255>
