VA-API needs AC and DC quant scales for both luma and chroma, and the loop
filter level for current frame, but these values are not available outside
the private GstVp9Parser structure. And these values may change from frame
to frame, so they are picture specific.
This patch add GstVp9Segmentation structure array to GstVp9Picture to expose
it to derived classes. This approach is safer than passing the parser at
picture handling flow.
Also, this patch, in order to solve Documentation CI, mark as private the
GstVp9Picture structure.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1700>
In order to know the chroma format, besides profile, subsampling_x and
subsampling_y are needed (Spec 7.2.2 Color config semantics). These values are
in GstVp9Parser but not in GstVp9Framehdr.
Also, bit_depth is available in parser but not frame header. Evenmore, those
values are copied to picture structure later.
In case of VA-API, to configure the pipeline, it is require to know the chroma
format and depth.
It is possible to know chroma and depth through caps coming from vp9parser, but
it requires string parsing. It would be less error prone to get these values
through the parser structure at new_sequence() virtual method.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1700>
Move the show_frame check from sub class to vp8 decoder's base class.
Calling the sub class' output_picture() function only when the frame
is displayed and marking the other automatically as decode only.
This is done to avoid logic and code repetition in subclasses.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1670>
For Dolby AC4 audio experience, parsing PMTs/APD from transport stream layer for all available presentations.
Refer to ETSI EN 300 468 V1.16.1 (2019-05)
1. 6.4.1 Audio preselection descriptor
2. Table M.1: Mapping of codec specific values to the audio preselection descriptor
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1555>
The default BYTE DURATION basesrc query handler will return `-1` and TRUE. In
order to properly handle cases where upstream http servers didn't return a valid
Content-Length we also need to check whether it was valid when calculating
bitrates.
Avoids returning completely bogus bitrates with gogol's video streaming services
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1544>
opencv plugin is pulling a header which makses clang++ 10
complain a lot and blocks -werror.
```
/usr/include/opencv4/opencv2/flann/logger.h:83:36: error: format string is not a string literal [-Werror,-Wformat-nonliteral]
int ret = vfprintf(stream, fmt, arglist);
^~~
```
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1494>
This is to avoid having to create a reference chain in decoders from
GstVideoCodecFrame to GstH264PIcture to implementation wrapper.
So this change introduces:
- gst_h264_dpb_remove_outputed (dpb)
- gst_h264_dpb_get_picture(dpb, system_frame_num)
- gst_h264_decoder_get_picture (dec, system_frame_num)
In order to ensure that frames can be looked up during the draining
process, we now first remove all (including reference) frames that
have been outputed but are still in the DPB. Then for each remaining
buffers, we remove it from the DPB to reach reference 1 and output it.
Previously we could take all not outputed outside of the DPB which would
prevent lookup by the base class.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1449>
... when gst_video_decoder_finish_frame() is called.
Some subclasses attach GstBuffer to GstH264Picture as an user data
which will increase reference count of the buffer. It would result
to buffer copy per every frame.
Background here is, GstVideoDecoder wants writable output buffer for
GstMeta handling, and if the output buffer is not writable
(i.e., reference count is not one), the buffer will be copied.
Even if underlying GstMemory wouldn't be copied, buffer copy operation
will introduce extra memory allocation overhead which is not optimal.
By this modification, subclass might be able to receive the last
reference to GstH264Picture
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1449>
All subclasses are retrieving list to get target output frame, which
can be done by baseclass. And pass the ownership of the GstH264Picture
to subclass so that subclass can clear implementation dependent resources
before finishing the frame.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1449>
... and do more strict validation for num_tile_columns_minus1 and
num_tile_rows_minus1.
As per specification Table A.8, allowed maximum number of tile rows
and tile columns are 22 and 20, respectively. So we should adjust the size
of each array.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1372>
There are some streams, with HRD, where the the calculated
max_dpb_frames is zero (max_dpb_mbs is less than size mb). In order to
get the dbp size it is required to rely on the VUI parameters if they
are present.
According to the spec Annex E.2.1
**max_dec_frame_buffering** specifies the required size of the HRD
decoded picture buffer (DPB) in units of frame buffers. It is a
requirement of bitstream conformance that the coded video sequence
shall not require a decoded picture buffer with size of more than
Max(1, max_dec_frame_buffering) frame buffers to enable the output of
decoded pictures at the output times specified by dpb_output_delay of
the picture timing SEI messages. The value of max_dec_frame_buffering
shall be greater than or equal to max_num_ref_frames. An upper bound
for the value of max_dec_frame_buffering is specified by the level
limits in clauses A.3.1, A.3.2, G.10.2.1, and H.10.2.
When the max_dec_frame_buffering syntax element is not present, the
value of max_dec_frame_buffering shall be inferred as follows:
– If profile_idc is equal to 44, 86, 100, 110, 122, or 244 and
constraint_set3_flag is equal to 1, the value of
max_dec_frame_buffering shall be inferred to be equal to 0.
– Otherwise (profile_idc is not equal to 44, 86, 100, 110, 122, or 244
or constraint_set3_flag is equal to 0), the value of
max_dec_frame_buffering shall be inferred to be equal to MaxDpbFrames.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1381>
Extensions and layers can be enabled before calling
gst_vulkan_instance_open() but after calling
gst_vulkan_instance_fill_info().
Use the list of available extensions to better choose a default display
implementation to use based on the available Vulkan extensions for surface
output.
Defaults are still the same.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1341>
Until now, bound check would simply trace the values and the range. This
enhances the trace by also tracing the name of the variable that was to be set
or read. This is not magically perfect in all cases, but greatly speed the
debugging work. Here's an example before and after this change:
Before: gst_h264_parser_parse_slice_hdr: value not in allowed range. value: 819183, range -87-77
After: gst_h264_parser_parse_slice_hdr: value for 'slice->slice_qp_delta' not in allowed range. value: 819183, range -87-77
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1356>
The unit tests only checked for vulkan_dep.found(), which can
be true if the libs are there but glslc was not found, in which
case the plugin wouldn't be built and the unit tests would fail
because of missing vulkan plugins.
Doesn't really make much sense to build the vulkan integration lib
either if we're not going to build the vulkan plugin, so just disable
both for now if glslc is not available.
Fixes#1301
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1307>
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>
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>
The parser is used all over the place assuming that after calling
gst_h265_parser_identify_nalu(), the start-code found is can also be
identified. In H264 this works, because scan_for_start_code rely on
gst_byte_reader_masked_scan_uint32() that ensures that 1 byte passed the 3
bytes start code is found. But for HEVC, we need two bytes to identify the
following NAL.
This patch will return NO_NAL_END, even if a start code is found in the case
there was not enough bytes. This solution was chosen to maintain backward
compatibility, and reduce complexicity.
Fixes#1287
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1251>
Same as done for H264, this error was trying to catch the case where we had
a start code without any bytes afterward. This will never happen since the
start code scanner only returns a match if there is one byte after start
code (pattern 0x00000100 / mask 0xffffff00). In H264, once byte is sufficient
to identify the NALU.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1251>
This will stop stripping four bytes start code. This was fixed and broken
again as it was causing the a timestamp shift. We now call
gst_base_parse_set_ts_at_offset() with the offset of the first NAL to ensure
that fixing a moderatly broken input stream won't affect the timestamps. We
also fixes the unit test, removing a comment about the stripping behaviour not
being correct.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1251>
This error was trying to catch the case where we had a start code without any
bytes afterward. This will never happen since the start code scanner only returns
a match if there is one byte adter start code (pattern 0x00000100 / mask
0xffffff00).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1251>
This is the first version of AV1 parser implementation in GStreamer.
A test file is also provied with several test cases. It contains a
test sequence taken from the aom testdata set, with one key and one
inter-frame. The same test sequence has been reencoded to annexb.
testdata is taken from aom testdata (and reencoded for annexb) as well
as handcrafted testcases. Once reference testdata is available, the
testing could be imporved aswell.
Co-author: He Junyan <junyan.he@hotmail.com>
Co-author: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/785>
the old manner does not consider the profile idc. The profile idc should
play an more important role in recognizing the profile than the other
information. And there is no need to mix profiles of different extensions
together to find the closest profile when the bits stream is not standard,
different extensions support different features and should not be mixed.
The correct way should be recognize the extension category by profile idc
firstly, and then find the closest profile.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1121>
FormatRangeExtensionProfile declares the common bits used for not
only format range extensions profiles, but also for several different
h265 extension profiles, such as high throughput, screen content
coding extensions, etc. And So the old name is not proper.
We also rename the get_h265_extension_profile function.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1121>
