We should query the downstream element to answer a precise allocation
query when the passthrough mode is enabled.
The current way still decides the allocation by the postproc itself. The
pipeline such as:
gst-launch-1.0 -v filesrc location=xxx.264 ! h264parse ! vaapih264dec ! \
vaapipostproc ! fakevideosink silent=false sync=true
will lose some info such as the GST_VIDEO_META_API_TYPE.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/413>
Currently the default drm device is always used on a system with
multiple drm devices. This patch allows user to specify the required
drm device via GST_VAAPI_DRM_DEVICE env variable
Example:
GST_VAAPI_DRM_DEVICE=/dev/dri/renderD129 gst-launch-1.0 videotestsrc !
vaapih264enc ! fakesink
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/409>
drmGetBusid() (GET_UNIQUE ioctl) won't return a valid bus id when
drmSetInterfaceVersion() (SET_VERSION ioctl) hasn't been called(see[1]),
so we can't get the right device path. Running test-display will get the
error below:
** (test-display:18630): ERROR **: 10:26:00.434: could not create Gst/VA
display
Calling drmSetInterfaceVersion() before drmGetBusid() can't fix this
issue because a special permission is required for SET_VERSION ioctl.
This patch retrieves the device path from file descriptor via
g_file_read_link()
[1] https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/drm_ioctl.c#L48-L104
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/412>
Texture upload mechanism used by gstreamer-vaapi relies on 8 bpc.
In latest mesa versions the first fbconfig might not be 8 bit, so iterate
over it to find the correct config with supported values.
This also adds 8 bit alpha size to the framebuffer configuration which is
required to get it working properly.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/410>
The AV1 film_graim feature needs two surfaces the same time for
decoding. One is for recon surface which will be used as reference
later, and the other one is for display. The GstVaapiPicture should
contain the surface for display, while the vaBeginPicture() need
the recon surface as the target.
We add a gst_vaapi_picture_decode_with_surface_id API to handle this
kind of requirement.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/191>
The current encoder will hang when EOS comes. When we call the
gst_vaapi_encoder_encode_and_queue(), we should release the stream
lock, just like what we do in gst_vaapiencode_handle_frame().
The deadlock happens when: The input thread holding the stream lock
is using gst_vaapi_encoder_create_coded_buffer() to acquire a coded
buffer, while the output thread which holding the coded buffer resource
is acquiring the stream lock in _push_frame() to push the data to
down stream element.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/404>
gst_vaapi_encoder_h264_get_pending_reordered() does not consider the
case for HIERARCHICAL_B mode. The pipeline:
gst-launch-1.0 videotestsrc num-buffers=48 ! vaapih264enc prediction-type=2 \
keyframe-period=32 ! fakesink
get a assert:
ERROR:../gst-libs/gst/vaapi/gstvaapiencoder_h264.c:1996:reflist1_init_hierarchical_b:
assertion failed: (count != 0)
The last few B frames are not fetched in correct order when HIERARCHICAL_B
is enabled.
We also fix a latent bug for normal mode. The g_queue_pop_tail() of B frames
make the last several frames encoded in reverse order. The NAL of last few
frames come in reverse order in the bit stream, though it can still output
the correct image.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/405>
In scc mode, the I frame can ref to itself and it needs the L0 reference
list enabled. So we should set the I frame to P_SLICE type. We do not need
to change the ref_pic_list0/1 passed to VA driver, just need to enable the
VAEncPictureParameterBufferHEVC->pps_curr_pic_ref_enabled_flag to notify
the driver consider the current frame as reference. For bits conformance,
the NumRpsCurrTempList0 should be incremented by one to include the current
picture as the reference frame. We manually do it when packing the slice header.
Command line like:
gst-launch-1.0 videotestsrc num-buffers=10 ! \
capsfilter caps=video/x-raw,format=NV12, framerate=30/1,width=640,height=360 ! \
vaapih265enc ! capsfilter caps=video/x-h265,profile="{ (string)screen-extended-main }" ! \
filesink location=out.265
Can be used to specify that the encoder should use SCC profiles.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/379>
We need the allowed_profiles to store the allowed profiles in down
stream's caps.
Command line like:
vaapivp9enc ! capsfilter caps=video/x-vp9,profile="{ (string)1, \
(string)3 }"
We need to store GST_VAAPI_PROFILE_VP9_1 and GST_VAAPI_PROFILE_VP9_3
in this list.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/380>
We now use gst_h265_get_profile_from_sps() to replace the old way
of gst_h265_profile_tier_level_get_profile() to get more precise
profile. The new function consider the unstandard cases and give
a more suitable profile decision.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/395>
The removed code set all the reference frames to the current frame it is a key
one, but later, all the reference frames were rewritten with the decoded picture
buffers or VA_INVALID_SURFACE if they were not available.
Basically, all this time the first reference frame assignment has been ignored,
and it's not described by the spec, and this patch removes that code.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/400>
If the pad is already fixed the caps query have to be reply with the
current fixed caps. Otherwise the query has to be replied with the
autogeneratd src caps.
This path fix this by falling back to the normal caps query processing
if the pad is already fixed. Otherwise it will fetch the allowed src
pad caps.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/397>
Since commit 9f627ef2 if the user sets level in the encoder src caps
the caps negotiation is rejected.
But since the same commit the same encoder set the autoconfigured
level in caps. Some change in the base class might fixed the operation
order so now the caps are set and later negotiated.
This patch removes the level check.
Fixes: #273
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/382>
This code path is used when frames are rendered as textures through
GstVideoGLTextureUploadMeta with EGL, mainly under Wayland.
Originally the EGLImage was exported as GEM, which was handled by
Intel drivers, but Gallium ones cannot create VA surfaces from
GEM buffers, only DMABuf.
This patch checks the memory types supported by VA driver to choose
the render the EGLImages from GEM or DMABuf, because GEM is still
better where supported.
DMABuf is well handled either by intel-vaapi-driver and gallium.
Fixes: #137
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/122>
Since nobody uses it, just remove it.
Thus extract_allowed_surface_formats() is refactored to attend only
gst_vaapi_plugin_base_get_allowed_sinkpad_raw_caps().
Now a surface is created when the image chorma is different from the
previous one. And if the driver has the quirk, it outputs all the
supported image formats without trying them.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/381>
The try-and-error approach for getting the possible image formats from
a surface has brought several problems in different drivers, from
crashes to drop in performance.
Instead of that we change the algorithm to determine the possible
image formats based in the surface chroma: only those available image
formats with same chroma are exposed as possible raw caps.
Do this is important to avoid performance degrading in raw sinks
which doesn't handle NV12 but it does YV12 or I420.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/381>
