Commit 5647e339 authored by Sebastian Dröge's avatar Sebastian Dröge 🍵
Browse files

Release 1.11.91

parent c7d46646
=== release 1.11.91 ===
2017-04-27 Sebastian Dröge <>
releasing 1.11.91
2017-04-27 13:08:56 +0200 Víctor Manuel Jáquez Leal <>
* gst/vaapi/gstvaapipluginutil.c:
Revert "plugins: reject pixel-aspect-ratio with value 0/1"
This reverts commit c0be7b1890ea8da915a81ae82bc9f504aee7cc26.
2017-04-27 12:43:54 +0200 Víctor Manuel Jáquez Leal <>
* gst/vaapi/gstvaapipluginutil.c:
plugins: reject pixel-aspect-ratio with value 0/1
Do not negotiate a pixel-aspect-ratio of 0/1.
2017-04-26 15:48:01 +0200 Víctor Manuel Jáquez Leal <>
* gst/vaapi/gstvaapipostprocutil.c:
* gst/vaapi/gstvaapisink.c:
plugins: handle pixel-aspect-ratio with value 0/1
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.
2017-04-27 14:42:55 +0900 Hyunjun Ko <>
* gst/vaapi/gstvaapivideobufferpool.c:
vaapivideobufferpool: fix leak of created allocator
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.
2017-04-21 19:07:18 +0200 Víctor Manuel Jáquez Leal <>
* gst/vaapi/gstvaapivideobufferpool.c:
vaapivideobufferpool: create or reconfig allocator
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.
2017-04-25 12:58:44 +0200 Víctor Manuel Jáquez Leal <>
* tests/elements/
test: elements: fix compilation flags
This issue was spotten on bug #766704
Original-patch-by: Hyunjun Ko <>
2017-04-25 16:23:08 +0900 Hyunjun Ko <>
* gst-libs/gst/vaapi/gstvaapiwindow_wayland.c:
libs: windows: wayland: fix leak if failure of sync
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.
2017-04-24 20:30:30 +0100 Tim-Philipp Müller <>
* common:
Automatic update of common submodule
From 60aeef6 to 48a5d85
2017-04-21 15:30:09 +0200 Hyunjun Ko <>
* gst-libs/gst/vaapi/gstvaapiwindow_wayland.c:
libs: window: wayland: mark frames as done
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.
Signed-off-by: Víctor Manuel Jáquez Leal <>
2017-04-21 14:07:44 +0200 Víctor Manuel Jáquez Leal <>
* gst-libs/gst/vaapi/gstvaapiwindow_wayland.c:
libs: window: wayland: don't sync at destroy()
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.
Signed-off-by: Hyunjun Ko <>
2017-04-19 10:37:19 +0900 Hyunjun Ko <>
* gst-libs/gst/vaapi/gstvaapiwindow_wayland.c:
libs: window: wayland: null buffer at destroy()
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
This was inspired by gstwaylandsink.
Signed-off-by: Víctor Manuel Jáquez Leal <>
2016-10-30 10:43:49 +0900 Jagyum Koo <>
* gst-libs/gst/vaapi/gstvaapiwindow_wayland.c:
libs: window: wayland: rt event queue at destroy()
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.
Signed-off-by: Víctor Manuel Jáquez Leal <>
2017-04-20 20:30:52 +0200 Víctor Manuel Jáquez Leal <>
* gst-libs/gst/vaapi/gstvaapiwindow_wayland.c:
libs: window: wayland: cancel read at poll message
Always call wl_display_cancel_read() when an errno is set, but
different to EAGAIN or EINTR.
2017-04-21 18:05:48 +0900 Hyunjun Ko <>
* gst/vaapi/gstvaapidecodebin.c:
* gst/vaapi/gstvaapidecodebin.h:
vaapidecodebin: skips configuration once it's done
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.
2017-04-20 18:44:41 +0200 Víctor Manuel Jáquez Leal <>
* gst/vaapi/gstvaapipostprocutil.c:
vaapipostproc: fixes for memory leaks
The use of gst_vaapi_value_set_format() and gst_structure_*_value()
requires to clear the used GValue to avoid a memory leak.
2016-12-08 18:51:54 +0100 Víctor Manuel Jáquez Leal <>
* gst/vaapi/gstvaapipluginbase.c:
* gst/vaapi/gstvaapipluginbase.h:
plugins: enable direct rendering with envvar
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.
2017-04-08 02:05:21 +1000 Jan Schmidt <>
* gst/vaapi/gstvaapidecode.c:
vaapidecode: Don't renegotiate on every flush
If caps don't actually change, don't update the
decoder and don't set the do_renego flag forcing
downstream renegotiation
2017-04-08 01:21:23 +1000 Jan Schmidt <>
* gst-libs/gst/vaapi/gstvaapidecoder_h264.c:
h264 decoder: Implement reset() for faster flush
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
2017-04-05 17:24:20 +1000 Jan Schmidt <>
* gst-libs/gst/vaapi/gstvaapidecoder.c:
* gst-libs/gst/vaapi/gstvaapidecoder.h:
* gst-libs/gst/vaapi/gstvaapidecoder_h264.c:
* gst-libs/gst/vaapi/gstvaapidecoder_h265.c:
* gst-libs/gst/vaapi/gstvaapidecoder_mpeg2.c:
* gst-libs/gst/vaapi/gstvaapidecoder_priv.h:
* gst-libs/gst/vaapi/gstvaapidecoder_vc1.c:
* gst/vaapi/gstvaapidecode.c:
Implement decoder reset on flush, rather than recreating
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
2017-04-11 18:50:35 +0200 Víctor Manuel Jáquez Leal <>
* gst-libs/gst/vaapi/gstvaapiwindow.c:
libs: window: don't add an unused function
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]
2017-04-11 18:22:00 +0200 Víctor Manuel Jáquez Leal <>
* gst-libs/gst/vaapi/gstvaapiwindow.c:
* gst-libs/gst/vaapi/gstvaapiwindow_priv.h:
libs: window: remove surface_format member
Since we always convert to NV12, there is no need to keep a
variable for that. Let us hard code it.
2017-04-10 17:23:26 +0900 Hyunjun Ko <>
* gst-libs/gst/vaapi/gstvaapiwindow_wayland.c:
* gst-libs/gst/vaapi/gstvaapiwindow_x11.c:
* gst-libs/gst/vaapi/gstvaapiwindow_x11_priv.h:
libs: window: x11/wayland: use new api for conversion
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.
2017-04-10 11:41:29 +0900 Hyunjun Ko <>
* gst-libs/gst/vaapi/gstvaapiwindow.c:
* gst-libs/gst/vaapi/gstvaapiwindow_priv.h:
libs: window: add gst_vaapi_window_vpp_convert_internal()
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.
2017-04-03 16:45:36 +0900 Hyunjun Ko <>
* gst-libs/gst/vaapi/gstvaapiwindow.c:
* gst-libs/gst/vaapi/gstvaapiwindow_priv.h:
* gst-libs/gst/vaapi/gstvaapiwindow_wayland.c:
* gst-libs/gst/vaapi/gstvaapiwindow_x11.c:
* gst-libs/gst/vaapi/gstvaapiwindow_x11_priv.h:
libs: window: x11/wayland: chaining up to GstVaapiWindow
Currently, GstVaapiWindowX11/Wayland are not descendants of GstVaapiWindow.
This patch chains them up to GstVaapiWindow to handle common members in GstVaapiWindow.
2017-04-05 11:19:15 -0700 Scott D Phillips <>
* gst/vaapi/gstvaapipluginutil.c:
plugins: Fix usage of GST_GL_HAVE_WINDOW_* defines
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)
2017-04-10 23:51:06 +0100 Tim-Philipp Müller <>
* common:
Automatic update of common submodule
From 39ac2f5 to 60aeef6
=== release 1.11.90 ===
2017-04-07 Sebastian Dröge <>
2017-04-07 16:36:21 +0300 Sebastian Dröge <>
* ChangeLog:
releasing 1.11.90
* gstreamer-vaapi.doap:
Release 1.11.90
2017-04-03 14:52:41 +0200 Víctor Manuel Jáquez Leal <>
This is GStreamer 1.11.90.
This is GStreamer 1.11.91.
# gstreamer-vaapi package version number
m4_define([gst_vaapi_major_version], [1])
m4_define([gst_vaapi_minor_version], [11])
m4_define([gst_vaapi_micro_version], [90])
m4_define([gst_vaapi_micro_version], [91])
m4_define([gst_vaapi_nano_version], [0])
......@@ -16,17 +16,17 @@ dnl - interfaces added/removed/changed -> increment CURRENT, REVISION = 0
dnl - interfaces added -> increment AGE
dnl - interfaces removed -> AGE = 0
# gstreamer-vaapi library (libtool) version number
m4_define([gst_vaapi_lt_current], [1190])
m4_define([gst_vaapi_lt_current], [1191])
m4_define([gst_vaapi_lt_revision], [0])
m4_define([gst_vaapi_lt_age], [1190])
m4_define([gst_vaapi_lt_age], [1191])
# glib version number
m4_define([glib_version], [2.40])
# gstreamer version number
m4_define([gst_version], [1.11.90])
m4_define([gst_plugins_base_version], [1.11.90])
m4_define([gst_plugins_bad_version], [1.11.90])
m4_define([gst_version], [1.11.91])
m4_define([gst_plugins_base_version], [1.11.91])
m4_define([gst_plugins_bad_version], [1.11.91])
# Wayland minimum version number
m4_define([wayland_api_version], [1.0.2])
......@@ -25,6 +25,16 @@
<file-release rdf:resource="" />
project('gstreamer-vaapi', 'c',
version : '1.11.90',
version : '1.11.91',
meson_version : '>= 0.36.0',
default_options : [ 'warning_level=1',
'buildtype=debugoptimized' ])
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment