summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2017-07-14Release 1.12.21.12.2Sebastian Dröge5-12/+73
2017-07-03vaapipostproc: set multivew-mode flags to src capsHyunjun Ko1-0/+25
vaapipostproc didn't negotiate the proper multiview caps losing downstream information. This patch enables the playing of MVC encoded stream by setting the proper multiview mode/flags and views to src caps, according to sink caps. https://bugzilla.gnome.org/show_bug.cgi?id=784320
2017-06-20Release 1.12.11.12.1Sebastian Dröge5-11/+119
2017-06-15libs: decoder: h264: initialize active_sps/pps in resetHyunjun Ko1-0/+2
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
2017-05-12vaapisink: keep handle_events flag except that if user want to setHyunjun Ko1-1/+1
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
2017-05-12libs: window: x11: fix src rect info when using vppHyunjun Ko1-1/+8
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
2017-05-12plugins: remove par from caps negotiationVíctor Manuel Jáquez Leal1-2/+1
https://bugzilla.gnome.org/show_bug.cgi?id=781759
2017-05-04Release 1.12.01.12.0Sebastian Dröge5-11/+795
2017-05-04Revert "vaapidecodebin: fix element's classification"Víctor Manuel Jáquez Leal1-1/+1
This reverts commit 8cbe03599a4f27c2001380e2ec150c4f4267a9cf.
2017-05-02build: Require libva < 0.99.0Scott D Phillips2-2/+2
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
2017-05-02vaapidecodebin: fix element's classificationVictor Toso1-1/+1
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
2017-04-27Release 1.11.911.11.91Sebastian Dröge5-10/+304
2017-04-27Revert "plugins: reject pixel-aspect-ratio with value 0/1"Víctor Manuel Jáquez Leal1-1/+1
This reverts commit c0be7b1890ea8da915a81ae82bc9f504aee7cc26.
2017-04-27plugins: reject pixel-aspect-ratio with value 0/1Víctor Manuel Jáquez Leal1-1/+1
Do not negotiate a pixel-aspect-ratio of 0/1. https://bugzilla.gnome.org/show_bug.cgi?id=781759
2017-04-27plugins: handle pixel-aspect-ratio with value 0/1Víctor Manuel Jáquez Leal2-0/+4
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
2017-04-27vaapivideobufferpool: fix leak of created allocatorHyunjun Ko1-0/+1
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
2017-04-25vaapivideobufferpool: create or reconfig allocatorVíctor Manuel Jáquez Leal1-0/+21
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
2017-04-25test: elements: fix compilation flagsVíctor Manuel Jáquez Leal1-1/+1
This issue was spotten on bug #766704 Original-patch-by: Hyunjun Ko <zzoon@igalia.com>
2017-04-25libs: windows: wayland: fix leak if failure of syncHyunjun Ko1-0/+3
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
2017-04-24Automatic update of common submoduleTim-Philipp Müller1-0/+0
From 60aeef6 to 48a5d85
2017-04-24libs: window: wayland: mark frames as doneHyunjun Ko1-5/+17
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>
2017-04-24libs: window: wayland: don't sync at destroy()Víctor Manuel Jáquez Leal1-8/+2
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>
2017-04-21libs: window: wayland: null buffer at destroy()Hyunjun Ko1-0/+9
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>
2017-04-21libs: window: wayland: rt event queue at destroy()Jagyum Koo1-0/+5
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>
2017-04-21libs: window: wayland: cancel read at poll messageVíctor Manuel Jáquez Leal1-4/+4
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
2017-04-21vaapidecodebin: skips configuration once it's doneHyunjun Ko2-1/+3
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
2017-04-20vaapipostproc: fixes for memory leaksVíctor Manuel Jáquez Leal1-5/+6
The use of gst_vaapi_value_set_format() and gst_structure_*_value() requires to clear the used GValue to avoid a memory leak.
2017-04-12plugins: enable direct rendering with envvarVíctor Manuel Jáquez Leal2-1/+6
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
2017-04-12vaapidecode: Don't renegotiate on every flushJan Schmidt1-4/+6
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
2017-04-12h264 decoder: Implement reset() for faster flushJan Schmidt1-0/+32
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
2017-04-12Implement decoder reset on flush, rather than recreatingJan Schmidt8-28/+112
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
2017-04-11libs: window: don't add an unused functionVíctor Manuel Jáquez Leal1-3/+0
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
2017-04-11libs: window: remove surface_format memberVíctor Manuel Jáquez Leal2-6/+4
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
2017-04-11libs: window: x11/wayland: use new api for conversionHyunjun Ko3-101/+77
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
2017-04-11libs: window: add gst_vaapi_window_vpp_convert_internal()Hyunjun Ko2-0/+117
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
2017-04-11libs: window: x11/wayland: chaining up to GstVaapiWindowHyunjun Ko5-0/+40
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
2017-04-11plugins: Fix usage of GST_GL_HAVE_WINDOW_* definesScott D Phillips1-4/+4
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
2017-04-10Automatic update of common submoduleTim-Philipp Müller1-0/+0
From 39ac2f5 to 60aeef6
2017-04-07Release 1.11.901.11.90Sebastian Dröge5-11/+375
2017-04-07vaapiencode: h265: add main-10 in caps templateVíctor Manuel Jáquez Leal1-1/+1
This patch adds h265's main-10 profile in encoder src caps template. https://bugzilla.gnome.org/show_bug.cgi?id=771291
2017-04-07libs: encoder: h265: chroma and luma with formatVíctor Manuel Jáquez Leal1-2/+9
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
2017-04-06libs: encoder: admit YUV420_10BPP as valid chromaVíctor Manuel Jáquez Leal1-1/+2
Accepts as supported the GST_VAAPI_CHROMA_TYPE_YUV420_10BPP chroma type. https://bugzilla.gnome.org/show_bug.cgi?id=771291
2017-04-06libs: encoder: h265: ensures profile given formatVíctor Manuel Jáquez Leal1-0/+5
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
2017-04-06libs: encode: merge all possible surface formatsVíctor Manuel Jáquez Leal1-6/+70
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
2017-04-06vaapiencode: add get_profile() vmethodVíctor Manuel Jáquez Leal4-2/+54
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
2017-04-06libs: encoder: pass profile to get_surface_formats()Víctor Manuel Jáquez Leal3-6/+13
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
2017-04-06libs: encoder: dummy context for get_surface_formats()Víctor Manuel Jáquez Leal1-9/+16
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
2017-04-06libs: encoder: refactor init_context_info()Víctor Manuel Jáquez Leal1-5/+5
In order to generate vaapi contexts iterative, the function init_context_info() is refactored to pass, as parameters the GstVaapiContextInfo and the GstVaapiProfile. https://bugzilla.gnome.org/show_bug.cgi?id=771291
2017-04-06libs: encoder: initialize chroma_typeVíctor Manuel Jáquez Leal3-0/+70
Instead of initialize the chroma_type with a undefined value, which will be converted to GST_VAAPI_CHROMA_TYPE_YUV420 by GstVaapiContext, this patch queries the VA config, given the received GstVaapiContextInfo's parameters, and gets the first response. In order to get the GstVaapiChromaType value, also it was needed to add a new utility function: to_GstVaapiChromaType(), which, given a VA_RT_FORMAT_* will return the associated GstVaapiChromaType. https://bugzilla.gnome.org/show_bug.cgi?id=771291
2017-04-06vaapiencode: enhance logs of negotiated capsVíctor Manuel Jáquez Leal1-1/+4
https://bugzilla.gnome.org/show_bug.cgi?id=771291