Table 1.10 – "Levels for the AAC Profile" only goes to 5 max channels
/ 7 max channel post amendmend, so I assume the number of channels
should not include LFE, otherwise there's no valid level for 5.1 resp.
7.1 (post amendmend)
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/680>
Existing VP9 parser implementation doesn't provide information
required by other stateless decoding APIs (i.e., DXVA and NVDEC),
specifically loop filter and segmentation parameters might not exist
current frame. So parser needs to fill the information by using previously
parsed information.
We can update the gstvp9parser implementation so that it can provide
all information required by stateless decoding APIs with a huge API break,
or adding more ugly struct in it.
Instead doing as such, this commit introduce a new VP9 parser implementation.
What is different from existing one?
* All variables will follow the specification as much as possible:
VP9 Bitstream & Decoding Process Specification - v0.6 31st March 2016
* Parser will fill all the required information for decoding frame
to GstVp9FrameHeader struct. In case of old VP9 parser,
user needs to read additional data from parser's member variables.
* GstVp9StatefulParser object struct is completely completely opaque
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2112>
The picture buffer (V4L2 CAPTURE buffer) was being released immediatly
when the request was done. This was problematic since even after the
request is done, the picture buffer might still be used as a reference
and should not be reused for further decoding yet.
This change effectively bind the picture buffer lifetime to the request.
So that if the picture is never showned (decode only frame) or the request
queue is full before the buffer is displayed, the picture buffer will
remain alive.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2142>
Different VA drives might have different definitions for RGB32 color
formats because different bit interpretation. Sadly the specification
doesn't clarify these interpretations. So VA users have to figure out
what's the correct mapping with it's rendering color format
definition.
This patch aims to fix the static map structure after the
VAImageFormats are queried. There is another static map with the
different interpretations of the RGB32 formats, and compare them with
the given VAImageFormat, then with the GStreamer color format, update
the mapping table.
Finally, some RGB32 color formats were added.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2129>
The peeked buffer was always reset after calling ::aggregate() but under
no other circumstances. If a pad was removed after peeking and before
::aggregate() returned then the peeked buffer would be leaked.
This can easily happen if pads are removed from the aggregator from a
pad probe downstream of the source pad but still in the source pad's
streaming thread.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/784>
Add missing include for sys/ioctl.h so that these warnings dissapear
when compiling:
../subprojects/gst-plugins-bad/sys/v4l2codecs/gstv4l2decoder.c:179:9:
warning: implicit declaration of function ‘ioctl’
[-Wimplicit-function-declaration]
Signed-off-by: Daniel Almeida <daniel.almeida@collabora.com>
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2140>
If the application did not define one yet, define our own
VK_DEFINE_NON_DISPATCHABLE_HANDLE that is independent of the
architecture.
Vulkan, by default, provides a define that depends on the architecture,
which causes the symbol type to be different. This causes an
architecture dependent .gir file, which then causes multilib
installation problems because the .gir files can't be shared.
Make it possible to override the format specifier and provide
a default one that is compatible with the default non dispatchable
handle.
Return VK_NULL_HANDLE from functions that return a non-dispatchable
handle.
Fixes#1566
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2130>
At the point of get_windows_shell() execution, the current directory
equals DEFAULT_BUILDDIR=./build. But cmd_or_ps.ps1 is in SCRIPTDIR=./
(repo root). Point subprocess.check_output() to the correct directory.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-build/-/merge_requests/238>
vapostproc tries to be in passthrough mode as much as possible. But
they might be situations where the user might force to process the
frames. For example, when upstream sets the crop meta and the user
wants VA do that cropping, rather than downstream.
For those situations this property will disable the passthrough mode,
if it's enabled.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2058>
If incoming buffers have crop meta it's done by vapostproc, iif
vapostproc is not in passthrough mode and downstream doesn't handle
it.
This patch announces the crop meta API in proposed bufferpool, while
it stops filtering meta APIs, since it was only filter crop api.
Also if downstream supports crop and video metas, vapostporoc
announces both meta APIs in upstream bufferpool.
Finally, the meta is removed from the buffer if the crop is enabled.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2058>
This new struct describes the input and output GstBuffers to
post-process, including VA flags. It also contains the VASurfaceID and
VARectangle, but those are private, completed inside GstVaFilter.
It is used for pass arguments to gst_va_filter_convert_surface() function.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2058>
When an input buffer needs to be copied into a VA memory, it's
required to create a buffer pool. This patch uses the
propose_allocation() caps to instantiate the allocator and pool,
instead of the negotiated caps, which rather represents the resolution
to display.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2058>
Based upon valgrind finding:
Conditional jump or move depends on uninitialised value(s)
at 0x4AFF589: read_rtp_header_extensions (gstrtpbasedepayload.c:1197)
by 0x4AFF9E5: gst_rtp_base_depayload_set_headers
(gstrtpbasedepayload.c:1298)
by 0x4AFFEE0: gst_rtp_base_depayload_do_push
(gstrtpbasedepayload.c:1413)
by 0x4AFFF53: gst_rtp_base_depayload_push
(gstrtpbasedepayload.c:1448)
by 0x4AFDEBA: gst_rtp_base_depayload_handle_buffer
(gstrtpbasedepayload.c:801)
by 0x4AFE41E: gst_rtp_base_depayload_chain_list
(gstrtpbasedepayload.c:899)
by 0x48F262C: gst_pad_chain_data_unchecked (gstpad.c:4414)
by 0x48F3333: gst_pad_push_data (gstpad.c:4655)
by 0x48F3DF8: gst_pad_push_list (gstpad.c:4814)
by 0x4AFAD87: gst_rtp_base_payload_push_list
(gstrtpbasepayload.c:1978)
by 0x72B3154: gst_rtp_vp8_pay_handle_buffer (gstrtpvp8pay.c:672)
by 0x4AF7031: gst_rtp_base_payload_chain (gstrtpbasepayload.c:868)
Uninitialised value was created by a heap allocation
at 0x483C77F: malloc (in
/usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x4B8BA78: g_malloc (gmem.c:106)
by 0x4BA3A9D: g_slice_alloc (gslice.c:1069)
by 0x488D777: _sysmem_new_block (gstallocator.c:413)
by 0x488DB28: default_alloc (gstallocator.c:512)
by 0x488D3E8: gst_allocator_alloc (gstallocator.c:310)
by 0x4AE97E3: gst_rtp_buffer_set_extension_data (gstrtpbuffer.c:856)
by 0x4AF9EC6: set_headers (gstrtpbasepayload.c:1757)
by 0x489FE4D: gst_buffer_list_foreach (gstbufferlist.c:287)
by 0x4AFA87A: gst_rtp_base_payload_prepare_push
(gstrtpbasepayload.c:1915)
by 0x4AFAD06: gst_rtp_base_payload_push_list
(gstrtpbasepayload.c:1970)
by 0x72B3154: gst_rtp_vp8_pay_handle_buffer (gstrtpvp8pay.c:672)
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1075>
Instead of requiring interlaced video, simply skip CC detection
when the input is progressive.
This allows placing line21decoder unconditionally in pipelines,
without having to worry about whether the input stream will be
interlaced, or even worse interlacing just in case!
+ update doc cache
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1885>
Derived images are direct maps to surfaces bits, but in Intel Gen7 to
Gen9, that memory is not cachable, thus reading can be very slow (it
might produce timeout is tests such as fluster).
This patch tries first to define if derived images are possible, and
later use them only if mapping is not for reading.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2128>
This plugin, for decoders more concretely, assumes that a VA config
can do certain color conversions when mapping frames onto CPU's
memory.
This assumption was valid for i965 and Gallium drivers which generates
valid outputs in bitstreams testers (v.gr. fluster). Nonetheless, iHD,
even when it generates acceptable rendered frames, output's MD5 of
tests weren't valid.
This patch append the image formats, for color conversion when mapping
to memory, for non-iHD drivers.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2128>
Some streams have unknown colorimetry in caps, but v4l2object sets
default values for each primaries. It will cause check colorimetry
fail when do gst_v4l2_video_colorimetry_matches().
To fix this, need to keep the unknown colorimetry in caps same as
the default value set by v4l2object.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/923>
