After READY -> NULL -> READY state change, the configured video
orientation didn't get applied on the new GstVaFilter instance.
Resettig prev_direction to default value in update_properties ensures
gst_va_filter_set_orientation() isn't inadvertently skipped.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8871>
This reverts commit 8c017c79c5736c9e45e635df210e08550287646d.
1.22 was the correct pkg-config version. It's only the subproject
version that was wrong. Since we bumped libva.wrap to 2.22 version, h266
is now always available when using the subproject.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8800>
This happens on F42 with the JPEG decoders for some reason and trying to
actually use them with any resolution simply gives a "resolution not supported"
error.
A minimum of 64 is correctly reported though and trying to create caps with an
int range of [64, 0] gives critical warnings.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8736>
Extended is identical to main but allows for FMO/ASO features to be
used, and prevent using CABAC. Using similar logic to "baseline",
assume that if we support main, we can also do extended.
This fixes the following fluster vectors, which otherwise would fail
when trying to link the parsebin pad.
- BA3_SVA_C
- MR6_BT_B
- MR7_BT_B
- MR8_BT_B
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8164>
In fact, the va decoder is just a internal helper class and its access
is under the control of all dec elements. So far, there is no parallel
operation on it now.
At the other side, some code scan tools report race condition issues.
For example, the "context" field is just protected with lock at _open()
but is not protected at _add_param_buffer().
So we just delete all its lock usage.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7547>
Since bins can set the context of their children elements, the set_context()
vmethod shouldn't call bus messages post methods, since it locks the parent
object, the bin, which might be already locked, leading to a deadlock.
Fixes: #3706
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7378>
num_backward_references > 0 means we need to cache several frames
after the current frame. But the basetransform class does not
provide any _drain() kind function, so we do not have the chance
to push out our cached frames when EOS or set caps event comes.
Rather than losing the last several frames, we should just give up
the backward reference here.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7348>
The current code forgets to push the first several frames if the forward
reference > 0. They are just cached in history array and will never be
deinterlaced and pushed.
For the first several frames, even the forward reference frames are not
enough, we still need to deinterlace them as normal and push them after that.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7348>
Doing so resets the stride from the VideoMeta and it wasn't done before
the commit below. While on it, drop the plane size check as we can't
reliably predict the correct size when using DRM modifiers.
Fixes: 89b0a6fa23 ("va: refactor buffer import")
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7187>
The changes to the VideoInfo, notably the stride from the VideoMeta,
were lost. Avoid such mistakes by explicitly using the VideoInfo from
drm_info.
Fixes: 9f5b2c4e25 ("va: use GstVideoInfoDmaDrm when importing buffers")
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7187>
