- Jun 20, 2017
-
-
Sebastian Dröge authored
-
- Jun 15, 2017
-
-
Since commits in https://bugzilla.gnome.org/show_bug.cgi?id=781142 landed, they introduced regression in seek. Formerly, once seek is done, decoder drops P-frames until I-frame arrives. But since the commits landed, it doesn't drop P-frame and does try to decode it continuously because active_sps is still alive. See ensure_sps function. But there are prev_frames and prev_ref_frames reset already, then it causes assertion. So it's necessary to reset active_sps/pps also in reset method. https://bugzilla.gnome.org/show_bug.cgi?id=783726
-
- May 12, 2017
-
-
When state of vaapisink is changed from PLAYING to NULL, the handle_events flag is set to FALSE, and never recovered, and then event thread is never going to run. So we should allow to set the flag only when users try it. https://bugzilla.gnome.org/show_bug.cgi?id=782543
-
Since we started using VPP in VaapiWindowX11, we need to care about the case that src rect and window's size are different. So, once VPP has converted to other format, we should honor the size of the VPP's surface as source rect. Otherwise, it is cropped according the previous size of the source rect. https://bugzilla.gnome.org/show_bug.cgi?id=782542
-
-
- 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
-