- May 04, 2017
-
-
Sebastian Dröge authored
-
Víctor Manuel Jáquez Leal authored
This reverts commit 8cbe0359.
-
- May 02, 2017
-
-
libva >= 0.99.0 is not currently supported by gstreamer-vaapi, so fail to configure instead of failing late in the build. This libva is bundled in msdk[1] and it is ahead in time with respect the official and open source libva[2]. GStreamer-VAAPI only supports the latter for now. 1. https://software.intel.com/en-us/media-sdk/download 2. https://github.com/01org/libva/ https://bugzilla.gnome.org/show_bug.cgi?id=781866
-
This bin should have similar classification as decodebin which is "Generic/Bin/Decoder" otherwise it will appear wrongly as video decoder. Signed-off-by: Victor Toso <victortoso@redhat.com> https://bugzilla.gnome.org/show_bug.cgi?id=782063
-
- Apr 27, 2017
-
-
Sebastian Dröge authored
-
Víctor Manuel Jáquez Leal authored
This reverts commit c0be7b18.
-
Víctor Manuel Jáquez Leal authored
Do not negotiate a pixel-aspect-ratio of 0/1. https://bugzilla.gnome.org/show_bug.cgi?id=781759
-
Víctor Manuel Jáquez Leal authored
When downstream negotiates a pixel-aspect-ratio of 0/1, the calculations for resizing and formatting in vaapipostproc and vaapisink, respectively, failed, and thus the pipeline. This patch handles this situation by converting p-a-r of 0/1 to 1/1. This is how other sinks, such as glimagesink, work. https://bugzilla.gnome.org/show_bug.cgi?id=781759
-
Since it's created by itself, it should be unref-counted after gst_buffer_pool_config_set_allocator call. Afterwards, this allocator will be ref-counted again when assigning to priv->allocator. https://bugzilla.gnome.org/show_bug.cgi?id=781577
-
- Apr 25, 2017
-
-
Víctor Manuel Jáquez Leal authored
Sometimes a video decoder could set different buffer pool configurations, because their frame size changes. In this case we did not reconfigure the allocator. This patch enables this use case, creating a new allocator inside the VAAPI buffer pool if the caps changed, if it is not dmabuf-based. If so, it is just reconfigured, since it doesn't have a surface pool. https://bugzilla.gnome.org/show_bug.cgi?id=781577
-
Víctor Manuel Jáquez Leal authored
This issue was spotten on bug #766704 Original-patch-by: Hyunjun Ko <zzoon@igalia.com>
-
Sometimes gst_vaapi_window_wayland_sync returns FALSE when poll returns EBUSY during destruction. In this case, if GstVaapiWindow is using vpp, leak of vpp surface happens. This surface is not attached to anything at this moment, so we should release it manually. https://bugzilla.gnome.org/show_bug.cgi?id=781695
-
- Apr 24, 2017
-
-
Tim-Philipp Müller authored
From 60aeef6 to 48a5d85
-
When the frame listener callbacks 'done', the number of pending frames are decreased. Nonetheless, there might be occasions where the buffer listener callbacks 'release', without calling previously frame's 'done'. This leads to problem with gst_vaapi_window_wayland_sync() operation. This patch marks as done those frames which were callbacked, but if the buffer callbacks 'release' and associated frame is not marked as 'done' it is so, thus the number of pending frames keeps correct. https://bugzilla.gnome.org/show_bug.cgi?id=780442 Signed-off-by: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>
-
Víctor Manuel Jáquez Leal authored
Don't call gst_vaapi_window_wayland_sync() when destroying the wayland window instance, since it might lead to a lock at gst_poll_wait() when more than one instances of vaapisink are rendering in the same pipeline, this is because they share the same window. Since now all the frames are freed we don't need to freed the private last_frame, since its address is invalid now. https://bugzilla.gnome.org/show_bug.cgi?id=780442 Signed-off-by: Hyunjun Ko <zzoon@igalia.com>
-
- Apr 21, 2017
-
-
Fix leakage of the last wl buffer. VAAPI wayland sink needs to send a null buffer while destruction, it assures that all the wl buffers are released. Otherwise, the last buffer's callback might be not called, which leads to leak of GstVaapiDisplay. This was inspired by gstwaylandsink. https://bugzilla.gnome.org/show_bug.cgi?id=774029 Signed-off-by: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>
-
The proxy object of wl_buffer for the last frame remains in the wl_map. Even though we call wl_buffer_destroy() in frame_release_callback(), the proxy object remains without being removed, since proxy object is deleted when wayland server sees the delete request and sends 'delete_id' event. We need to call roundtrip before destroying event_queue so that the proxy object is removed. Otherwise, it would be mess up as receiving 'delete_id' event from previous play, when playing in the next va/wayland window with the same wl_display connection. https://bugzilla.gnome.org/show_bug.cgi?id=773689 Signed-off-by: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>
-
Víctor Manuel Jáquez Leal authored
Always call wl_display_cancel_read() when an errno is set, but different to EAGAIN or EINTR. https://bugzilla.gnome.org/show_bug.cgi?id=780442
-
Skips configuration of creation of vpp/capsfilter and link them once it's done. Otherwise, it always fails when it's trying to re-start playback. https://bugzilla.gnome.org/show_bug.cgi?id=781573
-
- Apr 20, 2017
-
-
Víctor Manuel Jáquez Leal authored
The use of gst_vaapi_value_set_format() and gst_structure_*_value() requires to clear the used GValue to avoid a memory leak.
-
- Apr 12, 2017
-
-
Víctor Manuel Jáquez Leal authored
Direct rendering (use vaDeriveImage rather than vaPutImage) has better performance in some Intel platforms (Haswell, for example) but in others (Skylake) is the opposite. In order to have some control, the patch enables the direct rendering through the environment variable GST_VAAPI_ENABLE_DIRECT_RENDERING. Also it seems to generating some problems with gallium/radeon backend. See bug #779642. https://bugzilla.gnome.org/show_bug.cgi?id=775848
-
Jan Schmidt authored
If caps don't actually change, don't update the decoder and don't set the do_renego flag forcing downstream renegotiation https://bugzilla.gnome.org/show_bug.cgi?id=781142
-
Jan Schmidt authored
Implement a custom reset() function for faster flushes that just clear the reference pictures but don't reallocate the DPB or clear out SPS/PPS https://bugzilla.gnome.org/show_bug.cgi?id=781142
-
Jan Schmidt authored
Clear decoders out on a flush but keep the same instance, rather than completely recreating them. That avoids unecessarily freeing and recreating surface pools and contexts, which can be quite expensive https://bugzilla.gnome.org/show_bug.cgi?id=781142
-
- Apr 11, 2017
-
-
Víctor Manuel Jáquez Leal authored
The macro GST_VAAPI_OBJECT_DEFINE_CLASS_WITH_CODE only defines a function that is never used, thus when compiling we might see this warning (clang): gstvaapiwindow.c:147:1: warning: unused function 'gst_vaapi_window_class' [-Wunused-function] GST_VAAPI_OBJECT_DEFINE_CLASS_WITH_CODE (GstVaapiWindow, ^ https://bugzilla.gnome.org/show_bug.cgi?id=759533
-
Víctor Manuel Jáquez Leal authored
Since we always convert to NV12, there is no need to keep a variable for that. Let us hard code it. https://bugzilla.gnome.org/show_bug.cgi?id=759533
-
Hyunjun Ko authored
Since gst_vaapi_window_vpp_convert_internal is created, GstVaapiWindowX11/Wayland can use it for conversion. Note that once it chooses to use vpp, it's going to use vpp until the session is finished. https://bugzilla.gnome.org/show_bug.cgi?id=759533
-
Hyunjun Ko authored
If a backend doesn't support specific format, we can use vpp for conversion and make it playing. This api is originated from GstVaapiWindowWayland and moved to GstVaapiWindow, so that GstVaapiWindowX11 could use it. https://bugzilla.gnome.org/show_bug.cgi?id=759533
-
Hyunjun Ko authored
Currently, GstVaapiWindowX11/Wayland are not descendants of GstVaapiWindow. This patch chains them up to GstVaapiWindow to handle common members in GstVaapiWindow. https://bugzilla.gnome.org/show_bug.cgi?id=759533
-
Scott D Phillips authored
When these definitions are false, they are undef in the preprocessor, not a defined value of 0. When they are unset the compile fails with: 'GST_GL_HAVE_WINDOW_WAYLAND' undeclared (first use in this function) https://bugzilla.gnome.org/show_bug.cgi?id=780948
-
- Apr 10, 2017
-
-
Tim-Philipp Müller authored
From 39ac2f5 to 60aeef6
-
- Apr 07, 2017
-
-
Sebastian Dröge authored
-
Víctor Manuel Jáquez Leal authored
This patch adds h265's main-10 profile in encoder src caps template. https://bugzilla.gnome.org/show_bug.cgi?id=771291
-
Víctor Manuel Jáquez Leal authored
If the profile is main-10 the bit_depth_luma_minus8, in the sequence parameter buffer, shall be the color format bit depth minus 8, 10-8 which is 2. Also for bit_depth_chroma_minus8. This patch gets the negotiated sink caps format and queries its luma's depth and uses that value to fill the mentioned parameters. https://bugzilla.gnome.org/show_bug.cgi?id=771291
-
- Apr 06, 2017
-
-
Víctor Manuel Jáquez Leal authored
Accepts as supported the GST_VAAPI_CHROMA_TYPE_YUV420_10BPP chroma type. https://bugzilla.gnome.org/show_bug.cgi?id=771291
-
Víctor Manuel Jáquez Leal authored
Set the VA profile as GST_VAAPI_PROFILE_H265_MAIN10 if the configured color format is P010_10LE. Otherwise, keep GST_VAAPI_PROFILE_H265_MAIN https://bugzilla.gnome.org/show_bug.cgi?id=771291
-
Víctor Manuel Jáquez Leal authored
When the function gst_vaapi_encoder_get_surface_formats() was added it was under the assumption that any VA profile of the specific codec supported the same format colors. But it is not, for example the profiles that support 10bit formats. In other words, different VA profiles of a same codec may support different color formats in their upload surfaces. In order to expose all the possible color formats, if no profile is specified via source caps, or if the encoder doesn't have yet a context, all the possible VA profiles for the specific codec are iterated and their color formats are merged. https://bugzilla.gnome.org/show_bug.cgi?id=771291
-
Víctor Manuel Jáquez Leal authored
This new virtual method, get_profile(), if implemented by specific encoders, will return the VA profile potentially determined by the source caps. Also it is implemented by h264 and h265 encoders, which are the main users of this vmethod. https://bugzilla.gnome.org/show_bug.cgi?id=771291
-
Víctor Manuel Jáquez Leal authored
In order to get the supported surface formats within a specific profile this patch adds the GstVaapiProfile as property to gst_vaapi_encoder_get_surface_formats(). Currently the extracted formats are only those related with the default profile of the element's codec. https://bugzilla.gnome.org/show_bug.cgi?id=771291
-
Víctor Manuel Jáquez Leal authored
Instead of creating (if it doesn't exist, yet) the encoder's context the method gst_vaapi_encoder_get_surface_formats() now it creates dummy contexts, unless the encoder has it already created. The purpose of this is to avoid setting a encoder's context with a wrong profile. https://bugzilla.gnome.org/show_bug.cgi?id=771291
-