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
The calculated size of short_term_ref_pic_set is not a part of
HEVC syntax but the value is used by some stateless decoders
(e.g., vaapi, dxva, vdpau and nvdec) for the purpose of skipping
parsing the syntax by the accelerator.
"High Throughput", "Multiview", "Scalable", "3D", "Screen Content Coding",
and "Scalable format range extensions" profiles can be supported
via h265parser APIs now.
* Add FIXME for future correction of HRDParames parsing.
Spec. defines that the number of HRDParames could be up to
"vps_num_layer_sets_minus1 + 1" (i.e., 1024).
* Add parsing vps_base_layer_{internal,available}_flag.
* Fix possible invalid vps_extension parsing.
Fixes#798
We need different export decorators for the different libs.
For now no actual change though, just rename before the release,
and add prelude headers to define the new decorator to GST_EXPORT.
Those fields have been introduced in version 2 and later to define new
profiles like the format range extensions profiles (A.3.5).
NOTE: This patch breaks the parser ABI, rebuild needed.
https://bugzilla.gnome.org/show_bug.cgi?id=793876
We used to have the same enum to represent H265 profiles and idc values.
Those are no longer the same with extension profiles defined from
version 2 of the spec.
Split those enums so the semantic of each is clearer and we'll be able
to add extension profiles to GstH265Profile.
Also add gst_h265_profile_tier_level_get_profile() to retrieve the
GstH265Profile from the GstH265ProfileTierLevel. It will be used to
implement the detection of extension profiles.
https://bugzilla.gnome.org/show_bug.cgi?id=793876
Section 6.5.1: Coding tree block raster and tile scanning conversion process
Follow the equations 6-3 and 6-4
This will provide correct offset_max in slice_header for parsing
num_entry_point_offsets.
https://bugzilla.gnome.org/show_bug.cgi?id=754024
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
As per 7-42 and 7-43 the ScalingFactor's scanIdx is 0,
which is "up-right-diagonal" scan. Add APIs for converting
up-right-diagonal to raster and vise versa.
https://bugzilla.gnome.org/show_bug.cgi?id=754024
