Can not find a suitable chrome_type for this GST_VIDEO_FORMAT_RGB
packed 24 format. Just use GST_VAAPI_CHROMA_TYPE_RGB32 as its chrome
type. This kind of surface will just be created by new API with fourcc
and no old style chrome based creation is available.
fixes: #151
Coverity scan bug:
If the function actually returns a null value, a null pointer
dereference will occur.
In gst_vaapi_encoder_ensure_param_roi_regions(): Return value of
function which returns null is dereferenced without checking
The decoder's surface chroma type should depend on the bit depth
of VP9's parser. For 10bits VP9 stream, we need to use P10LE kind
10 bits surface as the decoder result.
Fixes#155
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
string_of_va_chroma_format() gets a wrong string format description.
For example, the YUV420_10BPP get a string of 0x00000100 as output.
It's because VA_RT_FORMAT_xxx values are macro definitions. And
STRINGIFY(VA_RT_FORMAT_xxx) will expand to its real value
0x00000XXX.
To avoid the macro evaluation, it is changed to show only the color
format without VA_RT_FORMAT_ prefix.
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.
GValueArray is deprecated. Use GstValueArray instead.
gst_param_spec_array can be deserialized from command line using:
vaapih264enc view-ids="<(uint)40,(uint)100>" num-views=2
While the g_param_spec_value_array() can not, and always get
error: "gst_value_deserialize_g_value_array: unimplemented"
Also fixed an out-of-range bug.
The order in gst_vaapi_enc_picture_encode when encoding one
picture is not very correct. The misc parameters are set before
the picture parameters. Some of the misc parameters such as
ROI may change the current picture parameters. But the later
setting of picture parameter will re-init all picture related
parameters and clear the previous setting. The right order
should be picture parameter first and then misc parameters.
Signed-off-by: He Junyan <junyan.he@hotmail.com>
This code is just confused. It's asking for at least as many bits of
(z-axis) depth as the root window has bits of (color) depth. For rgb565
or rgb888 this is harmless, but at 10 bits per channel this demands a
30-bit or deeper Z buffer. While some hardware could in principle do a
32-bit Z buffer, Mesa does not expose such fbconfigs (at least on Intel
and AMD).
We're not actually using the Z buffer, so just stop asking for one.
[wl_shell] is officially [deprecated], so provide support for the
XDG-shell protocol should be provided by all desktop-like compositors.
(In case they don't, we can of course fall back to wl_shell).
Note that the XML file is directly provided by the `wayland-protocols`
dependency and generates the protocol marshalling code.
[wl_shell]: https://people.freedesktop.org/~whot/wayland-doxygen/wayland/Client/group__iface__wl__shell.html
[deprecated]: 698dde1958
native-id property is problematic since the variable that stores it is
gsize, which is platform specific, and in some is bigger than unsigned
long, and there are not way to handle gsize properties.
Also, GST_VAAPI_ID_INVALID is defined in gsize terms, and we would
like to keep using it for this scope.
This patch removes the native-id property and set it manually in
gst_vaapi_window_new_internal().
gst_vaapi_encoder_put_frame() and gst_vaapi_encoder_flush() duplicates
the same code segment where the coded buffer is created, the picture
encoded on it and pushed to the async queue.
The function gst_vaapi_encoder_encode_and_queue() refactor this.
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.
This is another step in the gobjectification of the internal library
of gstreamer-vaapi. Now it is the turn of GstVaapiWindow and its
derivates.
The idea is to minimize the changeset keeping the same design as
much as possible.
GstVaapiWindow is defined as an abstract class with two properties:
the GstVaapiDisplay and the native ID. Thus, many of the
GstVaapiObject macros were copied as GstVaapiWindow macros.
The function gst_vaapi_window_new_internal() is kept as a decorator
of for calling gst_vaapi_window_create() and the possibility of
failure.
The descendant classes, such as glx, still use the private
structures, but through the gobject mechanism.
Add 444 10bit yuv format Y410, which can be used to decode
main-444 10bit streams. Currently, this feature is only
supported by media-driver in Icelake.
Add more kinds of chrometype which will be used to describe
new video formats. Sync it with 1.4.0 version header file.
Alse delete useless GST_VAAPI_CHROMA_TYPE_YUV410 chrome type.
Signed-off-by: He Junyan <junyan.he@hotmail.com>
We lack some video format because endianness declare.
The video format should not directly relate to endianness. For example,
ARGB on big endian should not be simplely seen as BGRA on little endian
machine. We should provide endianess convert or format convert help
functions if endianness does not match.
https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/issues/112
Signed-off-by: Junyan He <junyan.he@intel.com>
Add 422 10bit yuv format Y210, which can be used to decode
main-10-422 10bit streams. Currently, this feature is only
supported by media-driver in Icelake.
https://bugzilla.gnome.org/show_bug.cgi?id=797264
