- Aug 20, 2020
- Aug 18, 2020
-
-
Part-of: <gstreamer/gstreamer-vaapi!384>
-
- Aug 17, 2020
-
-
He Junyan authored
Part-of: <gstreamer/gstreamer-vaapi!385>
-
- Aug 15, 2020
-
-
He Junyan authored
We do not need to ref the allocator when creating GstVaapiVideoMemory kind memory, and then release it in _free(). The framework already does it for us. Part-of: <gstreamer/gstreamer-vaapi!383>
-
- Aug 14, 2020
-
-
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: <gstreamer/gstreamer-vaapi!382>
-
Víctor Manuel Jáquez Leal authored
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: <gstreamer/gstreamer-vaapi!122>
-
Víctor Manuel Jáquez Leal authored
Part-of: <gstreamer/gstreamer-vaapi!122>
-
- Aug 12, 2020
-
-
Víctor Manuel Jáquez Leal authored
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: <gstreamer/gstreamer-vaapi!381>
-
Víctor Manuel Jáquez Leal authored
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: <gstreamer/gstreamer-vaapi!381>
-
- Aug 08, 2020
-
-
He Junyan authored
We can reuse H265 parser's API to recognize the correct profile and then just need to convert them to VAAPI profiles. Part-of: <gstreamer/gstreamer-vaapi!356>
-
- Aug 07, 2020
-
-
Víctor Manuel Jáquez Leal authored
Part-of: <gstreamer/gstreamer-vaapi!378>
-
- Aug 06, 2020
-
-
Xu Guangxin authored
8.2.4.2 required this. Some clips will crash if we do not fill the reference list like this. Part-of: <gstreamer/gstreamer-vaapi!376>
-
- Aug 05, 2020
-
-
He Junyan authored
Part-of: <gstreamer/gstreamer-vaapi!375>
-
He Junyan authored
Part-of: <gstreamer/gstreamer-vaapi!375>
-
- Aug 04, 2020
-
-
Jordan Petridіs authored
the typesystem checks in g_atomic_pointer_compare_and_exchange seem to trigger some false positives with clang 10 similar to gstreamer!584 Part-of: <gstreamer/gstreamer-vaapi!377>
-
- Jul 31, 2020
-
-
Michael Olbrich authored
Some buffers and the associated FrameState state may still be pending at that point. If the wayland connection is shared, then messages for the buffer may still arrive. However, the associated event queue is already deleted. So the result is a crash. With a private connection the associated memory is leaked instead. Part-of: <gstreamer/gstreamer-vaapi!342>
-
Michael Olbrich authored
The callback is called for both windows. So make sure that gst_video_overlay_set_render_rectangle() is called for the correct one. Otherwise, the left video will be randomly moved behind the right video. Part-of: <gstreamer/gstreamer-vaapi!342>
-
Michael Olbrich authored
On Wayland, The whole gtk window is one Wayland surface. So gtk_widget_get_window() must be called on the top-level widget. For any other widget the following gdk_window_ensure_native() may create a new top-level Wayland surface that is never visible. As a result, the coordinates passed to gst_video_overlay_set_render_rectangle() must be relativ to the top-level window. Otherwise the video is placed incorrectly. Original-Patch-By: Víctor Manuel Jáquez Leal <vjaquez@igalia.com> Part-of: <gstreamer/gstreamer-vaapi!342>
-
Part-of: <gstreamer/gstreamer-vaapi!342>
-
They only appear when only one sink is instanciated and their purpose is to test the NULL-PLAY use case in context sharing. Part-of: <gstreamer/gstreamer-vaapi!342>
-
Michael Olbrich authored
gst_vaapi_window_wayland_set_render_rect() may be called from an arbitrary thread. That thread may be responsible for making the window visible. At that point another thread will block in gst_vaapi_window_wayland_sync() because the frame callback will not be called until the window is visible. If that happens, then acquiring the display lock in gst_vaapi_window_wayland_set_render_rect() would result in a deadlock. Cache the size of the opaque rectangle separately and create the opaque region right before applying it to the surface. Part-of: <gstreamer/gstreamer-vaapi!342>
-
Implements new vmethod gst_vaapi_window_set_render_rectangle, which is doing set the information of the rendered rectangle set by user. This is necessary on wayland at least to get exact information of external surface. And vaapisink calls this when gst_video_overlay_set_render_rectangle is called. Part-of: <gstreamer/gstreamer-vaapi!342>
-
Implements gst_vaapisink_wayland_create_window_from_handle() to support using external wl_surface. Part-of: <gstreamer/gstreamer-vaapi!342>
-
Michael Olbrich authored
The Wayland sub-surfaces API is used to embed the video into an application window. See Appendix A. Wayland Protocol Specification as the following. """ The aim of sub-surfaces is to offload some of the compositing work within a window from clients to the compositor. A prime example is a video player with decorations and video in separate wl_surface objects. This should allow the compositor to pass YUV video buffer processing to dedicated overlay hardware when possible. """ Added new method gst_vaapi_window_wayland_new_with_surface() Original-Patch-By: Víctor Manuel Jáquez Leal <vjaquez@igalia.com> Zhao Halley <halley.zhao@intel.com> changzhix.wei@intel.com Hyunjun Ko <zzoon@igalia.com> Part-of: <gstreamer/gstreamer-vaapi!342>
-
Michael Olbrich authored
Part-of: <gstreamer/gstreamer-vaapi!342>
-
Michael Olbrich authored
All close_display() have their own checks for use_foreign_display and only destroy locally created objects in that case. Without this objects other than the actuall foreign display itself are leaked. Part-of: <gstreamer/gstreamer-vaapi!342>
-
Part-of: <gstreamer/gstreamer-vaapi!373>
-
Víctor Manuel Jáquez Leal authored
This utility function is called internally by gst_vaapi_build_caps_from_formats() and can be used outside. This function sets frame size and framerates ranges. Also gst_vaapi_build_caps_from_formats() is simplified. Part-of: <gstreamer/gstreamer-vaapi!374>
-
He Junyan authored
Some context does not report any valid format that we can support. For example, the HEVC 444 12 bits decoder context, all the formats it reports is not supported now, which make the formats list a NULL array. We should check that pointer before we use it. Part-of: <gstreamer/gstreamer-vaapi!372>
-
- Jul 30, 2020
-
-
He Junyan authored
We can decide the profile in ensure_profile(), based on allowed list passed by the encode. We also need to check whether the entrypoint is available. Once it is decided, no need to check the hw entrypoint them again. Part-of: <gstreamer/gstreamer-vaapi!349>
-
He Junyan authored
We should collect all allowed profiles and pass them to the inside encoder, rather than just calculate the max profile idc. The allowed profiles should also be supported by the HW. Part-of: <gstreamer/gstreamer-vaapi!349>
-
He Junyan authored
Part-of: <gstreamer/gstreamer-vaapi!349>
-
He Junyan authored
We should collect all allowed profiles and pass them to the inside encoder, rather than just calculate the max profile idc. Part-of: <gstreamer/gstreamer-vaapi!349>
-
He Junyan authored
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: <gstreamer/gstreamer-vaapi!349>
-
He Junyan authored
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: <gstreamer/gstreamer-vaapi!349>
-
- Jul 29, 2020
-
-
Part-of: <gstreamer/gstreamer-vaapi!371>
-
Víctor Manuel Jáquez Leal authored
Generalize the way how the preferred color format is chosen. Also use new GStreamre API as syntatic sugar. Part-of: <gstreamer/gstreamer-vaapi!370>
-
There is no need to get a profile from the caps and then convert that profile into codec type. We can get the codec type by caps's name easily. Part-of: <gstreamer/gstreamer-vaapi!358>
-
profile_from_codec_data_h265() returns wrong GstVaapiProfile for h265. The codec data of caps contain the profile IDC, but the mapping between profile IDC and GstVaapiProfile is wrong. Part-of: <gstreamer/gstreamer-vaapi!358>
-
Part-of: <gstreamer/gstreamer-vaapi!188>
-