... 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>
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 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>
We should use the traget ExtensionProfile's IDC to check the
profile_compatibility_flag, rather than the profile_idc in the
stream. The old profile_compatibility_flag check always return
true. This causes that profiles with same constraint flags but
different profile_idc can't be recognized correctly. For example,
the screen-extended-main-444 profile is always be recognized as
the high-throughput-444 profile.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1121>
gst_h265_parser_parse_{vps,sps,pps} APIs were used to parse VPS/SPS/PPS and
also in order to update parser's internal state at once. Meanwhile
gst_h265_parse_{vps,sps,pps} APIs are to parse VPS/SPS/PPS without state update.
This commit introduces new APIs so that only accepted VPS/SPS/PPS by user
can be updated to be used by parser.
gst_h264_parser_parse_{sps,pps} APIs were used to parse SPS/PPS and
also in order to update parser's internal state at once. Meanwhile
gst_h264_parse_{sps,pps} APIs are to parse SPS/PPS without state update.
This commit introduces new APIs so that only accepted SPS/PPS by user
can be updated to be used by parser.
... and store all parsed values.
We are storing pic_struct_present_flag although it's not part of
this SEI message but GstH264PicTiming includes it to clarify
following syntax values.
In addition to that, by adding CpbDpbDelaysPresentFlag, we don't need to
refer to VUI anymore.
gsth265parser does it already. Although corresponding API of h265parser is
gst_h265_sei_free, _clear suffix is more consistent naming for h264parser
since there are gst_h264_{sps,pps}_clear().
That's the value of NumDeltaPocs[RefRpsIdx] and we might be able to derive
the value from given sps and slice header.
Because well known hardware implementations refer to the value, however,
storing the value makes things easier.
Following is the list of hardware implementations
* DXVA2: ucNumDeltaPocsOfRefRpsIdx
* NVDEC/VDPAU: NumDeltaPocsOfRefRpsIdx
Some hardware decoders, for example Hantro G1, have to be told the
size of the pic_order_cnt related syntax elements pic_order_cnt_lsb,
delta_pic_order_cnt_bottom, delta_pic_order_cnt[0], and
delta_pic_order_cnt[1] in bits.
