This reverts commit 1dbcc8a0e1 and commit
372a03a9e3.
While the dmabuf handle is exported, the derive image must exist, otherwise
the image's VA buffer is invalid, thus the dmabuf handle is never released,
leading into a file descriptors leak.
A planar(or some other) buffer allocation may fail on the driver, then
the wayland connection becomes invalid, not able to send request or
receive any event. So we need to set up a new wayland connection if
there's an error detected on the cached wl_display.
https://bugzilla.gnome.org/show_bug.cgi?id=768761
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
Change defaults for max-bframes, cabac, and dct8x8 to be enabled
by default. This will cause the default profile to be high instead
of baseline. In most situations this is the right decision, and
the profile can still be lowered in the case of caps restrictions.
Signed-off-by: Scott D Phillips <scott.d.phillips@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=757941
Without this, all dpb pictures are not released during flush,
because we used the global dpb_count variable for checking the
dpb fullness which get decremented in dpb_remove_index()
routine during each loop iteration.
https://bugzilla.gnome.org/show_bug.cgi?id=767934
Clarify that vaapi context resets are never needed for vp9, but
that ensure_context() needs called when the size increases so that
new surfaces can be allocated.
Signed-off-by: Scott D Phillips <scott.d.phillips@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=767474
Added two modes(as properties) for reference picture selection:
ref-mode-0: AltRef and GoldRef pointing to the recent keyframe
and LastRef is pointing to the previous frame.
ref-mode-1: Previous frame (n) as LastRef , n-1 th frame as GoldRef
and n-2 th frame as AltRef
https://bugzilla.gnome.org/show_bug.cgi?id=766048
gst_video_info_set_format() and gst_video_info_from_caps() call, internally,
gst_video_info_init(), hence it is not required to call it before them. This
patch removes these spurious calls.
This is a workaround since vaapi-intel-driver doesn't have
support for B-frame encode when utilizing low-power-enc
hardware block.
Fixme :We should query the VAConfigAttribEncMaxRefFrames
instead of blindly disabling b-frame support and set b/p frame count,
buffer pool size etc based on the query result.
https://bugzilla.gnome.org/show_bug.cgi?id=766050
Added a new property "low-power-enc" for enabling low power
encoding mode. Certain encoding tools may not be available
with the VAEntrypointEncSliceLP.
https://bugzilla.gnome.org/show_bug.cgi?id=766050
Call gst_vaapi_video_pool_finalize() in coded_buffer_pool_finalize().
Otherwise it is not called when the pool is destroyed and all objects
referenced by the GstVaapiVideoPool are never released.
https://bugzilla.gnome.org/show_bug.cgi?id=764993
If gst_vaapi_image_new_with_image() fails, the created derived image should be
destroyed, otherwise the surface cannot be processed because is being used.
https://bugzilla.gnome.org/show_bug.cgi?id=764607
The subsampling_x, subsampling_y, bit_depth, color_space and color_range
fileds are moved from GstVp9FrameHdr to the global GstVp9Parser structure.
These fields are only present in keyframe or intra-only frame, no need to
duplicate them for inter-frames.
https://bugzilla.gnome.org/show_bug.cgi?id=764082
The array_completeness, reserved bit and num_nal_units fields
in HEVCDecoderConfigurationRecord will be present for each VPS/SPS/PPS array list,
but not for each occurance of similar headers.
https://bugzilla.gnome.org/show_bug.cgi?id=764274
The P010 video format is the native format used by the vaapi intel driver
for HEVCMain10 decode . Add support for planes and images of this video format.
https://bugzilla.gnome.org/show_bug.cgi?id=759181
The colour depth is clamped to 24 when it is not equal {15,16,24,32}. But this
fails with the NVIDIA binary driver as it doesn't advertise a TrueColor visual
with a depth of 24 (only 30 and 32). Allowing the depth to be 30, lets everything
work as expected.
https://bugzilla.gnome.org/show_bug.cgi?id=764256
Copy the data into the dependent slice segment header from the
corresponding independent slice segment header during parsing.
Previously the reference to the "previous" independent header was
held through the parsing phase and then dereferenced during the
decoding phase. This caused all dependent headers to be populated
with the data of the AU's last independent header instead of the
proper corresponding header.
https://bugzilla.gnome.org/show_bug.cgi?id=762352
Changes since v1:
- Reworded commit message
