Commit graph

3063 commits

Author SHA1 Message Date
Sreerenj Balachandran
4f343f82e3 encoders: add quality level tuning
This patch adds the handling of VAEncMiscParameterTypeQualityLevel,
in gstreamer-vaapi encoders:

  The encoding quality could be set through this structure, if the
  implementation supports multiple quality levels. The quality level set
  through this structure is persistent over the entire coded sequence, or
  until a new structure is being sent. The quality level range can be queried
  through the VAConfigAttribEncQualityRange attribute. A lower value means
  higher quality, and a value of 1 represents the highest quality. The quality
  level setting is used as a trade-off between quality and speed/power
  consumption, with higher quality corresponds to lower speed and higher power
  consumption.

The quality level is set by the element's parameter "quality-level" with a
hard-coded range of 1 to 8.

Later, when the encoder is configured in run time, just before start
processing, the quality level is scaled to the codec range. If
VAConfigAttribEncQualityRange is not available in the used VA backend, then
the quality level is set to zero, which means "disabled".

All the available codecs now process this parameter if it is available.

https://bugzilla.gnome.org/show_bug.cgi?id=778733

Signed-off-by: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>
2017-05-11 11:51:56 +02:00
Sebastian Dröge
10eb6efb30 Back to development 2017-05-04 18:59:31 +03:00
Sebastian Dröge
14ed473dbd Release 1.12.0 2017-05-04 15:46:03 +03:00
Víctor Manuel Jáquez Leal
c45d448a15 Revert "vaapidecodebin: fix element's classification"
This reverts commit 8cbe03599a.
2017-05-04 11:49:33 +02:00
Scott D Phillips
33888bf534 build: Require libva < 0.99.0
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-02 17:03:30 +02:00
Victor Toso
8cbe03599a vaapidecodebin: fix element's classification
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-05-02 16:14:49 +02:00
Sebastian Dröge
5647e3392b Release 1.11.91 2017-04-27 17:49:52 +03:00
Víctor Manuel Jáquez Leal
c7d4664609 Revert "plugins: reject pixel-aspect-ratio with value 0/1"
This reverts commit c0be7b1890.
2017-04-27 13:08:56 +02:00
Víctor Manuel Jáquez Leal
c0be7b1890 plugins: reject pixel-aspect-ratio with value 0/1
Do not negotiate a pixel-aspect-ratio of 0/1.

https://bugzilla.gnome.org/show_bug.cgi?id=781759
2017-04-27 12:43:54 +02:00
Víctor Manuel Jáquez Leal
4820d2d09d 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.

https://bugzilla.gnome.org/show_bug.cgi?id=781759
2017-04-27 11:17:12 +02:00
Hyunjun Ko
cce5ce4a9d 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.

https://bugzilla.gnome.org/show_bug.cgi?id=781577
2017-04-27 11:03:02 +02:00
Víctor Manuel Jáquez Leal
158b44fc1e 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.

https://bugzilla.gnome.org/show_bug.cgi?id=781577
2017-04-25 15:06:39 +02:00
Víctor Manuel Jáquez Leal
10fc9a97b5 test: elements: fix compilation flags
This issue was spotten on bug #766704

Original-patch-by: Hyunjun Ko <zzoon@igalia.com>
2017-04-25 12:58:44 +02:00
Hyunjun Ko
2d7c7630c9 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.

https://bugzilla.gnome.org/show_bug.cgi?id=781695
2017-04-25 11:24:38 +02:00
Tim-Philipp Müller
307148dfc8 Automatic update of common submodule
From 60aeef6 to 48a5d85
2017-04-24 20:30:30 +01:00
Hyunjun Ko
824974e657 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.

https://bugzilla.gnome.org/show_bug.cgi?id=780442

Signed-off-by: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>
2017-04-24 13:16:03 +02:00
Víctor Manuel Jáquez Leal
3b314ba93e 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.

https://bugzilla.gnome.org/show_bug.cgi?id=780442

Signed-off-by: Hyunjun Ko <zzoon@igalia.com>
2017-04-24 13:14:05 +02:00
Hyunjun Ko
ca314a25cc 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
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-21 16:01:47 +02:00
Jagyum Koo
896a836f1d 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.

https://bugzilla.gnome.org/show_bug.cgi?id=773689

Signed-off-by: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>
2017-04-21 16:01:46 +02:00
Víctor Manuel Jáquez Leal
9c3a4edf05 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.

https://bugzilla.gnome.org/show_bug.cgi?id=780442
2017-04-21 16:01:34 +02:00
Hyunjun Ko
26486c436a 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.

https://bugzilla.gnome.org/show_bug.cgi?id=781573
2017-04-21 11:48:16 +02:00
Víctor Manuel Jáquez Leal
5c3318227b 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.
2017-04-20 18:48:22 +02:00
Víctor Manuel Jáquez Leal
24af97a7d1 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.

https://bugzilla.gnome.org/show_bug.cgi?id=775848
2017-04-12 20:39:06 +02:00
Jan Schmidt
ebca86dcc7 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

https://bugzilla.gnome.org/show_bug.cgi?id=781142
2017-04-12 10:43:49 +10:00
Jan Schmidt
bae56fe0c2 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

https://bugzilla.gnome.org/show_bug.cgi?id=781142
2017-04-12 10:43:49 +10:00
Jan Schmidt
a7a9b33ad9 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

https://bugzilla.gnome.org/show_bug.cgi?id=781142
2017-04-12 10:43:49 +10:00
Víctor Manuel Jáquez Leal
bd2e304ea4 libs: window: don't add an unused function
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-11 19:22:38 +02:00
Víctor Manuel Jáquez Leal
8e8280efbf 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.

https://bugzilla.gnome.org/show_bug.cgi?id=759533
2017-04-11 19:22:38 +02:00
Hyunjun Ko
c5b3577e88 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.

https://bugzilla.gnome.org/show_bug.cgi?id=759533
2017-04-11 19:20:38 +02:00
Hyunjun Ko
ccfbca733d 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.

https://bugzilla.gnome.org/show_bug.cgi?id=759533
2017-04-11 19:20:24 +02:00
Hyunjun Ko
4752f68a37 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.

https://bugzilla.gnome.org/show_bug.cgi?id=759533
2017-04-11 16:41:41 +02:00
Scott D Phillips
0343649667 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)

https://bugzilla.gnome.org/show_bug.cgi?id=780948
2017-04-11 16:32:26 +02:00
Tim-Philipp Müller
d68edb04a1 Automatic update of common submodule
From 39ac2f5 to 60aeef6
2017-04-10 23:51:06 +01:00
Sebastian Dröge
d2213994f3 Release 1.11.90 2017-04-07 16:36:21 +03:00
Víctor Manuel Jáquez Leal
b2815a376b vaapiencode: h265: add main-10 in caps template
This patch adds h265's main-10 profile in encoder src caps template.

https://bugzilla.gnome.org/show_bug.cgi?id=771291
2017-04-07 12:04:57 +02:00
Víctor Manuel Jáquez Leal
3532dca16a libs: encoder: h265: chroma and luma with format
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-07 12:04:51 +02:00
Víctor Manuel Jáquez Leal
d744aeb5fa libs: encoder: admit YUV420_10BPP as valid chroma
Accepts as supported the GST_VAAPI_CHROMA_TYPE_YUV420_10BPP chroma
type.

https://bugzilla.gnome.org/show_bug.cgi?id=771291
2017-04-06 22:00:05 +02:00
Víctor Manuel Jáquez Leal
48e21d6ba8 libs: encoder: h265: ensures profile given format
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-06 22:00:05 +02:00
Víctor Manuel Jáquez Leal
e534ff5609 libs: encode: merge all possible surface formats
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-06 22:00:05 +02:00
Víctor Manuel Jáquez Leal
5ccadd6e9c vaapiencode: add get_profile() vmethod
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-06 22:00:05 +02:00
Víctor Manuel Jáquez Leal
7153b4597d libs: encoder: pass profile to get_surface_formats()
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-06 22:00:05 +02:00
Víctor Manuel Jáquez Leal
9aa63e4595 libs: encoder: dummy context for get_surface_formats()
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-06 22:00:05 +02:00
Víctor Manuel Jáquez Leal
31d326c9ee libs: encoder: refactor init_context_info()
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-06 22:00:05 +02:00
Víctor Manuel Jáquez Leal
db7268117d libs: encoder: initialize chroma_type
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-06 22:00:05 +02:00
Víctor Manuel Jáquez Leal
914a4712d9 vaapiencode: enhance logs of negotiated caps
https://bugzilla.gnome.org/show_bug.cgi?id=771291
2017-04-06 22:00:05 +02:00
Scott D Phillips
123672a9bd libs: encoder: vp9: Fix initialization of ref_list
gcc 7.0.1 gives a memset-elt-size warning in gst_vaapi_encoder_vp9_init:

 'memset' used with length equal to number of elements without
 multiplication by element size [-Werror=memset-elt-size]

https://bugzilla.gnome.org/show_bug.cgi?id=780947
2017-04-06 11:03:12 +02:00
Sreerenj Balachandran
be990f5ed4 encoder: h264: Fix Backward ReferencePicture flag setting
This is a regression introduced by e829b62 which
override the reference flags and caused issues with
latest intel-vaapi-driver.
2017-03-31 14:14:08 -07:00
Víctor Manuel Jáquez Leal
834557d5b6 libs: encoder: h265: fix code style
Trivial patch to remove a double ';' as end of instruction.
2017-03-29 13:24:41 +02:00
Sreerenj Balachandran
dbbe340906 encoder: h264: Fix B frame encoding artifacts
The current implementation is updating the POC values only
in Slice parameter Buffer.But we are not filling the
picture order count and reference flags in VAPictureH264
while populating VA Picture/Slice structures.The latest
intel-vaapi-driver is directly accessing the above fields
from VAPicutreH264 provided as RefPicLists, which resulted
some wrong maths and prediction errors in driver.

https://bugzilla.gnome.org/show_bug.cgi?id=780620
2017-03-28 10:53:20 -07:00
Víctor Manuel Jáquez Leal
7f8b325450 libs: encoder: h265: remove unused macro definition
Since the h265 encoder doesn't use GValueArray, there is no need to
disable the Glib deprecation warnings, thus removing the macro
definition.
2017-03-21 16:13:56 +01:00