In h265, bigger profile idc may not be compatible with the small profile
idc. And more important, there are multi profiles with the same profile
idc. Such as main-422-10, main-444 and main-444-10, they all have profile
idc 4.
So recording the max profile idc is not enough, the encoder needs to know
all allowed profiles when deciding the real profile.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/349>
In h265, higher profile idc number does not mean better compression
performance and may be not compatible with the lower profile idc.
So, it is not suitable to find the heighest idc for hw to ensure the
compatibility.
On the other side, when the entrypoint of the selected profile is valid,
it means the hw really support this profile, no need to check it again.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/349>
The double reference lists may be required by drivers and there should
be no P frames in the of stream. The old way of converting P frames to
B frames is by setting `low-delay-b` property, which is unconvenient
and has bad user experience, since most of the users do not know when
to set this property, and if it is not set correctly, the encoding
pipeline fails or even hangs on some platforms. VA driver now provides
a attribute to query whether both reference lists must be un-NULL for
a profile/entrypoint pair.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/284>
In HEVC, P and B definitions are different from AVC: P frames have
just one reference list and so 1 MV, while B frames have two reference
lists and so 2 MVs. No matter B or P, ist reference lists can contain
forward/backward reference. So P and B can both have bi-directions
dependency, the difference is just their reference list
number (i.e. MV number). This is different from the AVC.
The *low delay b mode* refers to a special HEVC mode, in which the
stream just contain I and B frames, without P frames, and all B frames
only have forward direction dependencies (i.e. all inter frames have 2
reference lists but no backward reference in both lists). This is
similar to AVC I/P mode, but changing the P to the forward dependent
B.
The `low-delay-b` property is now just used to simply convert all P
frames to B frames when driver does not support P frames (so both
reference lists have the same references frames). This is a little
different from the meaning of low delay b mode (the two ref lists may
have the different reference frames). And the driver now can report
whether it supports P frames correctly, so there is no need to use
this property and deprecate it.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/284>
The h265 encoder just support tune mode:
(0): none - None
(3): low-power - Low power mode
So, no need to check and set the high compression parameters.
And by the way, the current ensure_tuning_high_compression manner
of choosing the hightest profile idc as the best compression profile
is not correct. Unlike h264, in h265 the higher profile idc number
does not mean it has more compression tools, and so it has better
compression performance. It may even be un-compatible with the lower
profile idc. For example, the SCREEN_CONTENT_CODING profile with idc
9 is not compatible with 3D_MAIN profile with idc 8.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/348>
These properties are used for support of tile encoding. We just
support uniform mode of tile encoding, that is, separating picture
equally by (num-tile-cols X num-tile-rows).
According to HEVC spec A1, the max number of tiles in column is 20
and in rows is 22, so add two constant definitions.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/294>
We need to use the chroma_format_idc as the index for getting the
SubWidthC and SubHeightC values as the spec 6.1(table 6-1) defines.
The wrong SubWidthC or SubHeightC make us calculate a wrong right
or bottom offset for crop size and generate garbage in output.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/334>
When the tune is NONE, we now can choose entrypoint freely. So the
GST_VAAPI_ENCODER_TUNE macro may not return the correct current
entrypoint.
We also delay CTU size calculation after entrypoint has been decided.
Some profile, such as H265_MAIN_444 on new Intel platform, may only
support ENTRYPOINT_SLICE_ENCODE_LP entrypoint. This leads two
problems:
1. We need to specify the tune mode like `vaapih265enc tune=low-power`
every time when we need to use this kind of profile. Or we can not
create the encoder context successfully.
2. More seriously, we set the entrypoint to a fixed value in
init_context_info() and so the create_test_context_config() can not
create the test context for these profile and can not get the
supported video formats, either.
We now change the entrypoint setting based on the tune option of the
encoder. If no tune property provided, we just choose the first
available entrypoint.
Instead of init_context_info() setting the passed profile, it is
assumed that it has to be set by each encoder.
Signed-off-by: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>
GstVaapiMiniObject and GstVaapiObject are deprecated.
This is the first step to remove them by porting GstVaapiCodedBuffer
as a GstMiniBuffer descendant.
Signed-off-by: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>
This patch makes use of GST_PARAM_USER_SHIFT to define the internal
param in encoders to decide which parameters to expose. Thus
gstreamer-vaapi will not interfere with any change in GStreamer in the
future.
Also, the internal symbol was change to
GST_VAAPI_PARAM_ENCODER_EXPOSURE to keep the namespacing.
G_PARAM_CONSTRUCT make all properties init correctly, we do not
need to init the properties manually.
G_PARAM_FLAG_VAAPI_ENCODER_EXPOSURE is a vaapi encoder specific
flag, means need to expose the property to according encode class.
Install properties for h265 encoder class. Also set the new get/set
property functions for gobject class. Still use the old properties
way now and this new feature will be enabled later.
Replace all gstvaapiobject in vaapi encoders with standard gstobject.
Let the gstobject common logic to handle all the init and finalize
works. But the property install/set/get still use the old way, need
to be improved later.
gst_vaapi_profile_get_name() returns a proper name for
GstCaps. Nonetheless, there are many profiles which don't have a name
representation for that realm.
gst_vaapi_profile_get_va_name() returns the name of the profile
according to its VAProfile name.
This new funtion is used in the encoder error message.
When enable low delay B, the reference list 1 will be same with
reference list 0, so need reset the num_ref_idx_l1_active_minus1
to num_ref_idx_l0_active_minus1.
Fixes: #160
g_assert will take no effect when glib's G_DISABLE_ASSERT macro is
defined. The function inside the g_assert will take no effect and
we will fail to set the correct slice number.
This patch fixes a regression from commit 5b1fe9c6.
max_qp, in rate control configuration, appeared in libva release
2.1 (API 1.1), thus it is required to guard the VA API version.
Fixes: #150
The current manner can not recognize the correct level and always
set the tier to main. Need to add frame rate check to recognize
levels such as 4.1, 6.2, etc. We also add a logic to check main
and high tier based on bitrate.
Fixes: #145
media-driver currently fails to set a correct value of max_qp when
min_qp is different to zero, in CBR and VBR mode, generating full
quality frames, thus unexpected huge output.
This patch sets max_qp to an arbitrary value to avoid this output
temporary.
Fixes: #144
Currently the minimal value for either min_qp and init_qp are 1,
but VA documentation specifiy that zero is also valid and means
to ignore the quantiser.
The default value is not changed though to avoid behaivor changes
to users.
In order to flush the pending pictures, a new internal encoder vmethod
is used: get_pending_reordered()
This method follows an iterator pattern which will return the next
picture to encode and push.
The base encoder will call this function in a loop when flush() is called.
For now, only H.264 and H.265 encoders implement this flushing mechanism.
