Michael Tretter [Fri, 8 Dec 2017 13:46:02 +0000 (14:46 +0100)]
vaapipostproc: lock ensure_filter with postproc_lock
gst_vaapipostproc_ensure_filter might free the allowed_srcpad_caps
and allowed_sinkpad_caps. This can race with copying these caps in
gst_vaapipostproc_transform_caps and lead to segfaults.
The gst_vaapipostproc_transform_caps function already locks
postproc_lock before copying the caps. Make sure that calls to
gst_vaapipostproc_ensure_filter also acquire this lock.
https://bugzilla.gnome.org/show_bug.cgi?id=791404
Víctor Manuel Jáquez Leal [Wed, 10 Jan 2018 16:10:28 +0000 (17:10 +0100)]
tests: test-filter: fix dereference before null check
Null-checking op_info suggests that it may be null, but it has already
been dereferenced on all paths leading to the check.
There may be a null pointer dereference, or else the comparison
against null is unnecessary.
Víctor Manuel Jáquez Leal [Wed, 10 Jan 2018 16:06:53 +0000 (17:06 +0100)]
tests: y4mreader: fix string state checkup
str cannot be null in that moment, but it may be the end of string.
Víctor Manuel Jáquez Leal [Wed, 10 Jan 2018 15:59:56 +0000 (16:59 +0100)]
tests: y4mreader: use int for fgetc
Assigning the return value of fgetc to char truncates its value.
It will not be possible to distinguish between EOF and a valid
character.
Víctor Manuel Jáquez Leal [Wed, 10 Jan 2018 15:48:07 +0000 (16:48 +0100)]
tests: y4mreader: fix incompatible cast
Passed pointer in parse_int() are unsigned int (32 bits, unsigned) but
they are dereferenced as a wider long (64 bits, signed). This may lead
to memory corruption.
Tim-Philipp Müller [Tue, 19 Dec 2017 16:01:10 +0000 (16:01 +0000)]
meson: fix fallback for gstreamer-gl-1.0, it's now in -base
Matthew Waters [Thu, 14 Dec 2017 03:53:27 +0000 (14:53 +1100)]
Automatic update of common submodule
From e8c7a71 to 3fa2c9e
Nicolas Dufresne [Wed, 6 Dec 2017 21:11:46 +0000 (16:11 -0500)]
videoconvert: gst_element_post_message() is transfer full on msg
For this reson we need not to unref the message, even if it failed.
Nicolas Dufresne [Wed, 6 Dec 2017 21:11:25 +0000 (16:11 -0500)]
Revert "vaapivideocontext: possible memleak when no bus attached"
This reverts commit
0438a3e62660e64ed390b6bb83bfb560b91664aa.
Víctor Manuel Jáquez Leal [Fri, 1 Dec 2017 22:03:32 +0000 (23:03 +0100)]
test: vaapicontext: process have-context bus message
Víctor Manuel Jáquez Leal [Wed, 29 Nov 2017 17:29:45 +0000 (18:29 +0100)]
test: vaapicontext: app context is not persistent
Víctor Manuel Jáquez Leal [Wed, 29 Nov 2017 10:02:03 +0000 (11:02 +0100)]
vaapivideocontext: only vaapisink process app context
gst.vaapi.app.Display context is made for applications that will
provide the VA display and the native display to used by the
pipeline, when are using vaapisink as overlay. There are no use
case for encoders, decoders, neither for the postprocessor.
In the case of the vaapisink, it shall query for gst.vaapi.Display
upstream first, and then, if there is no reply,
gst.vaapi.app.Display context will be posted in the bus for the
application. If the application replies, a GstVaapiDisplay object
is instantiated given the context info, otherwise a
GstVaapiDisplay is created with the normal algorithm to guess the
graphics platform. Either way, the instantiated GstVaapiDisplay
is propagated among the pipeline and the have-message bus message.
Also only vaapisink will process the gst.vaapi.app.Display, if
and only if, it doesn't have a display already set. This is
caused because if vaapisink is in a bin (playsink, for example)
the need-context is posted twice, leading to an error state.
https://bugzilla.gnome.org/show_bug.cgi?id=790999
Víctor Manuel Jáquez Leal [Fri, 1 Dec 2017 19:21:54 +0000 (20:21 +0100)]
vaapivideocontext: log the name of GstVaapiDisplay
https://bugzilla.gnome.org/show_bug.cgi?id=790999
Víctor Manuel Jáquez Leal [Thu, 30 Nov 2017 13:24:43 +0000 (14:24 +0100)]
vaapivideocontext: possible memleak when no bus attached
https://bugzilla.gnome.org/show_bug.cgi?id=790999
Víctor Manuel Jáquez Leal [Mon, 27 Nov 2017 12:04:24 +0000 (13:04 +0100)]
libs: window: wayland: remove unused header include
Remove wayland-client.h include since there is no exposed symbols from
it.
Víctor Manuel Jáquez Leal [Mon, 27 Nov 2017 11:18:56 +0000 (12:18 +0100)]
libs: encoder: h264,h265: guard rate control's macroblock
macroblock parameter appear on VA-API 1.0.0. It should be guarded.
Matthew Waters [Mon, 27 Nov 2017 09:17:55 +0000 (20:17 +1100)]
Automatic update of common submodule
From 3f4aa96 to e8c7a71
Sreerenj Balachandran [Fri, 29 Jul 2016 11:58:49 +0000 (14:58 +0300)]
libs: encoder: h264: Add Hierarchical-B encode
Frames are encoded as different layers. Frame in a particular
layer will use pictures in lower or same layer as references.
Which means decoder can drop the frames in upper layer but still
decode lower layer frames.
B-frames, except the one in top most layer, are reference frames.
All the base layer frames are I or P.
eg: with 3 temporal layers
T3: B1 B3 B5 B7
T2: B2 B6
T1: I0 P4 P8
T1, T2, T3: Temporal Layers
P1...Pn: P-Frames:
B1...Bn: B-frames:
T1: I0->P4 , P4->P8 etc..
T2: I0--> B2 <-- P4
T3: I0--> B1 <-- B2, B2 --> B3 <-- P4
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=788918
Sreerenj Balachandran [Thu, 28 Jul 2016 15:33:23 +0000 (18:33 +0300)]
libs: encoder: h264: Add Hierarchical-P encode
Frames are encoded as different layers. A frame in a particular
layer will use pictures in lower or same layer as references.
Which means decoder can drop the frames in upper layer but still
decode lower layer frames.
eg: with 3 temporal layers
T3: P1 P3 P5 P7
T2: P2 P6
T1: P0 P4 P8
T1, T2, T3: Temporal Layers
P1...pn: P-Frames:
P0->P1 , P0->P2, P2->P3, P0->P4......repeat
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=788918
Sreerenj Balachandran [Thu, 28 Jul 2016 13:51:28 +0000 (16:51 +0300)]
libs: encoder: h264: Fix frame_num generation
The frame_num generation was not correctly implemented.
According to h264 spec, frame_num should get incremented
for each frame if previous frame is a referece frame.
For eg: IPBPB sequece should have the frame numbers 0,1,2,2,3
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=788918
Sreerenj Balachandran [Thu, 28 Jul 2016 12:53:48 +0000 (15:53 +0300)]
libs: encoder: h264: Add new property "prediction-type"
Adds new property "prediction-type" to select different reference
picture selection modes like hierarchical-p, hierarchical-b etc.
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=788918
XuGuangxin [Thu, 28 Jul 2016 12:12:05 +0000 (15:12 +0300)]
libs: encoder: h264: Add machinery for implementing hierarchical-prediction
Adds some basic building blocks to ease the implementation
of hierarchical prediction modes.
-- add an utility method to find temporal level of each frame
-- define max_ref_frame count based on temporal level count
-- add temporal_level_div[] for finding temporal level each frame
to be encoded.
-- find ip_period based on temporal level count
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=788918
XuGuangxin [Thu, 28 Jul 2016 11:17:53 +0000 (14:17 +0300)]
libs: encoder: h264: Add property "temporal-levels"
Adds new property "temporal-levels" to select the number of
temporal levels to be included in the encoded stream.
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=788918
XuGuangxin [Wed, 27 Jul 2016 13:41:01 +0000 (16:41 +0300)]
libs: encoder: objects: Add a reference flag
We can have p-frame as non-ref and also b-frame as ref
which are not supported yet. Reference flag
is the first machinery needed for more advanced
reference picture selection modes.
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=788918
Daniel van Vugt [Thu, 2 Nov 2017 12:21:34 +0000 (13:21 +0100)]
libs: surface: egl: add comment
Add a warning comment when using old intel-vaapi-drivers (>1.8.4),
where the creation of surfaces from GEM fd may fail.
https://bugzilla.gnome.org/show_bug.cgi?id=773453
Víctor Manuel Jáquez Leal [Tue, 10 Oct 2017 11:38:21 +0000 (13:38 +0200)]
libs: display: egl: add gst_vaapi_display_egl_set_current_display()
Adds a new function that changes the internal EGL display to the
current one (eglGetCurrentDisplay()) and sets the current context
too (eglGetCurrentContext()).
This new function is called by gst_vaapi_texture_egl_create() updating
the GstVaapiDisplayEGL with the current EGL display.
https://bugzilla.gnome.org/show_bug.cgi?id=773453
Víctor Manuel Jáquez Leal [Mon, 9 Oct 2017 14:02:11 +0000 (16:02 +0200)]
libs: texture: egl: update EGL display and context
It is required to use the context of the calling thread when wrapping
a foreign texture. According the documentation of
GstVideoGLTextureUploadMeta:
"The caller of gst_video_gl_texture_upload_meta_upload() must
have OpenGL set up and call this from a thread where it is valid
to upload something to an OpenGL texture."
This patch updates the EGL display and context in GstVaapiDisplay
instance to the one used by te renderer that uploads the texture.
Original-patch-by: Daniel van Vugt <daniel.van.vugt@canonical.com>
https://bugzilla.gnome.org/show_bug.cgi?id=773453
Víctor Manuel Jáquez Leal [Tue, 10 Oct 2017 17:53:04 +0000 (19:53 +0200)]
plugins: centralize assignation of GL objects
Add plugin_set_gst_gl() where the GstGL objects are assigned.
https://bugzilla.gnome.org/show_bug.cgi?id=773453
Víctor Manuel Jáquez Leal [Tue, 10 Oct 2017 17:13:35 +0000 (19:13 +0200)]
plugins: set GL objects if ensured
Only set the GL display and GL other context if they are ensured.
https://bugzilla.gnome.org/show_bug.cgi?id=773453
Víctor Manuel Jáquez Leal [Tue, 10 Oct 2017 15:14:15 +0000 (17:14 +0200)]
plugins: set GL objects if context is handled
Only set the GL display and GL other context if they are extracted
correctly from the gstreamer's context.
https://bugzilla.gnome.org/show_bug.cgi?id=773453
Víctor Manuel Jáquez Leal [Tue, 10 Oct 2017 17:57:45 +0000 (19:57 +0200)]
plugins: fix memory leak when GL context is created
When the GL display and context are created inside an VAAPI element
the created GL context is leaked.
https://bugzilla.gnome.org/show_bug.cgi?id=773453
Víctor Manuel Jáquez Leal [Tue, 10 Oct 2017 12:01:59 +0000 (14:01 +0200)]
libs: display: egl: free leaked memory
The EGL VAAPI display forgot to release the egl display, context and
proxied VAAPI display.
https://bugzilla.gnome.org/show_bug.cgi?id=773453
Víctor Manuel Jáquez Leal [Thu, 5 Oct 2017 17:25:08 +0000 (19:25 +0200)]
libs: texture: egl: code style
https://bugzilla.gnome.org/show_bug.cgi?id=773453
Víctor Manuel Jáquez Leal [Wed, 4 Oct 2017 11:51:23 +0000 (13:51 +0200)]
libs: surface: egl: error message if no extension
Instead of silently fail to export the image if there is not available
the EGL_MESA_drm_image, log an error message. Also a code refactoring
was done.
https://bugzilla.gnome.org/show_bug.cgi?id=773453
Víctor Manuel Jáquez Leal [Tue, 31 Oct 2017 12:10:50 +0000 (13:10 +0100)]
plugins: direct rendering on memory:VASurface
As buffers negotiated with memory:VASurface caps feature can also be
mapped, they can also be configured to use VA derived images, in other
words "direct rendering".
Also, because of the changes in dmabuf allocator as default allocator,
the code for configuring the direct rendering was not clear.
This patch cleans up the code and enables direct rendering when the
environment variable GST_VAAPI_ENABLE_DIRECT_RENDERING is defined,
even then the memory:VASurface cap feature is negotiated.
https://bugzilla.gnome.org/show_bug.cgi?id=786054
Víctor Manuel Jáquez Leal [Wed, 4 Oct 2017 09:54:31 +0000 (11:54 +0200)]
plugins: only dmabuf on srcpad if downstream
Set if source pad can handle dmabuf only if the GstGL context comes
from downstream.
It is possible to know that at two moments:
1\ In the case of GstGLTextureUpload caps feature is negotiated and
downstream pool reports back gst.gl.GstGLContext.
2\ When GstGLContext is found as GstContext from dowstream.
https://bugzilla.gnome.org/show_bug.cgi?id=788503
Víctor Manuel Jáquez Leal [Wed, 4 Oct 2017 09:52:32 +0000 (11:52 +0200)]
vaapivideocontext: add inline documentation
Document function gst_vaapi_find_gl_local_context().
https://bugzilla.gnome.org/show_bug.cgi?id=788503
Víctor Manuel Jáquez Leal [Wed, 4 Oct 2017 09:50:25 +0000 (11:50 +0200)]
vaapivideocontext: return the direction of gl context
In function gst_vaapi_find_gl_context() add a direction parameter to
return back the direction where the GstGL context was found.
This is going to be useful when checking if downstream can import
dmabuf-based buffers.
https://bugzilla.gnome.org/show_bug.cgi?id=788503
Víctor Manuel Jáquez Leal [Wed, 4 Oct 2017 06:30:51 +0000 (08:30 +0200)]
plugins: add gst_vaapi_plugin_base_set_srcpad_can_dmabuf()
This patch refactors the code by adding the function
vaapi_plugin_base_set_srcpad_can_dmabuf(), it determines if the passed
GstGLContext can handle dmabuf-based buffers.
The function is exposed publicly since it is intended to be used later
at GstVaapiDisplay instantiation.
https://bugzilla.gnome.org/show_bug.cgi?id=788503
Hyunjun Ko [Fri, 20 Oct 2017 10:37:15 +0000 (12:37 +0200)]
vaapiencode: allow to set property on runtime
Tis patch, allows some properties that we want to be set on
runtime. (eg. bitrate)
Note that all properties are under control by num_codedbuf_queued.
https://bugzilla.gnome.org/show_bug.cgi?id=786321
Hyunjun Ko [Fri, 15 Sep 2017 06:38:18 +0000 (15:38 +0900)]
libs: encoder: allow to set bitrate on runtime
In case of streaming, controlling bitrate dynamically for encoder might be
important to manage quality of the streaming.
This patch is to support such a scenario.
https://bugzilla.gnome.org/show_bug.cgi?id=786321
Sebastian Dröge [Tue, 10 Oct 2017 08:35:24 +0000 (11:35 +0300)]
vaapidecodebin: Register element if no VPP support is available too
VPP support is only needed for advanced deinterlacing, which is not
enabled by default either. Error out if it is selected but VPP is not
supported, and otherwise just work without VPP support.
https://bugzilla.gnome.org/show_bug.cgi?id=788758
Thibault Saunier [Mon, 16 Oct 2017 09:57:16 +0000 (11:57 +0200)]
Avoid infinite loop when vaapi_create_display fails
Which might be the case when using, for example, xvfb.
Víctor Manuel Jáquez Leal [Mon, 2 Oct 2017 16:53:21 +0000 (18:53 +0200)]
libs: utils: log warn if display fail
gstreamer-vaapi initializes the display by trial-and-error, thus
logging an error message if the display initialisation fails the user
may be weary of the error message in the screen, if using VA-API 1.0
This commit set the VA error log handler to GStreamer warning level
while calling vaInitialize() and set it to error after that.
https://bugzilla.gnome.org/show_bug.cgi?id=783169
Víctor Manuel Jáquez Leal [Fri, 29 Sep 2017 18:05:22 +0000 (20:05 +0200)]
plugins: try to create test display in order
When creating the test display for querying capabilites, it try in
certain order: DRM, Wayland and finally X11. GLX nor EGL are tried
since they are either composited with X11 or Wayland.
The reason for this is to reduce the posibility of failure that could
blacklist the plugin.
https://bugzilla.gnome.org/show_bug.cgi?id=782212
Víctor Manuel Jáquez Leal [Fri, 29 Sep 2017 13:07:47 +0000 (15:07 +0200)]
libs: display: delay getting screen resolution
Instead of extracting the screen resolution at GstVaapiDisplay
creation, this patch delay it until the screen size is requested for
first time.
https://bugzilla.gnome.org/show_bug.cgi?id=782212
Víctor Manuel Jáquez Leal [Thu, 28 Sep 2017 16:58:17 +0000 (18:58 +0200)]
libs: display: egl: avoid two vaDisplay instantiates
GstVaapiDisplayEGL is a wrapper of another GstVaapiDisplay, either X11
or Wayland. Nonetheless it created another vaDisplay for it, instead
of using the wrapped one.
This patch enables the reuse of the wrapped vaDisplay avoiding
instantiating two.
https://bugzilla.gnome.org/show_bug.cgi?id=782212
Víctor Manuel Jáquez Leal [Thu, 28 Sep 2017 15:45:00 +0000 (17:45 +0200)]
libs: display: remove display_type from display info
Since it's no required to pass the display type in the display info,
the structure member is removed.
https://bugzilla.gnome.org/show_bug.cgi?id=782212
Víctor Manuel Jáquez Leal [Thu, 28 Sep 2017 15:35:01 +0000 (17:35 +0200)]
libs: display: remove display_type member
It is not used any more since GstVaapiDisplay was ported as a
GstObject-based. This information is part of the class information.
https://bugzilla.gnome.org/show_bug.cgi?id=782212
Víctor Manuel Jáquez Leal [Thu, 28 Sep 2017 14:12:23 +0000 (16:12 +0200)]
libs: display: remove parent member
Parent was a crumb left from display cache.
https://bugzilla.gnome.org/show_bug.cgi?id=782212
Sebastian Dröge [Tue, 3 Oct 2017 11:06:33 +0000 (13:06 +0200)]
vaapi: Also register vaapipostproc without VPP support
It can still do simple deinterlacing then.
Sebastian Dröge [Tue, 3 Oct 2017 08:51:06 +0000 (10:51 +0200)]
vaapipostproc: Allow running without VPP support
We returned FALSE from ::start() if VPP support is not available, but it
is only really needed for complex filters and during transform we check
for that. For simple deinterlacing it is not needed.
Víctor Manuel Jáquez Leal [Wed, 27 Sep 2017 16:35:20 +0000 (18:35 +0200)]
vaapipostproc: use scoped variable for return value
Instead of reusing a parameter variable for the return value of
gst_vaapipostproc_transform_caps(), this patch uses the function
scoped pointer. Thus, the code is cleaner.
https://bugzilla.gnome.org/show_bug.cgi?id=785706
Víctor Manuel Jáquez Leal [Wed, 27 Sep 2017 16:32:03 +0000 (18:32 +0200)]
vaapipostproc: removed unused parameter
Removed caps parameter from gst_vaapipostproc_transform_caps_impl()
helper function since the it is not used.
https://bugzilla.gnome.org/show_bug.cgi?id=785706
Víctor Manuel Jáquez Leal [Wed, 27 Sep 2017 11:32:34 +0000 (13:32 +0200)]
vaapipostproc: use scoped variable for return value
Instead of reusing a parameter variable for the return value of
gst_vaapipostproc_fixate_caps(), this patch uses the function scoped
pointer. Thus, the code is cleaner.
https://bugzilla.gnome.org/show_bug.cgi?id=785706
Víctor Manuel Jáquez Leal [Wed, 27 Sep 2017 09:27:40 +0000 (11:27 +0200)]
plugins: memory:DMABuf only handles planar formats
When glimagesink negotiates the caps feature memory:DMABuf the
exported dmabufs buffers with NV12 format are not well rendered, thus
setting only planar.
https://bugzilla.gnome.org/show_bug.cgi?id=788229
Víctor Manuel Jáquez Leal [Mon, 25 Sep 2017 15:04:12 +0000 (17:04 +0200)]
vaapiencode: flush pending frames before set format
Flush pending frames, if any, in the internal encorder, before setting
the new negotiated format.
https://bugzilla.gnome.org/show_bug.cgi?id=786173
Víctor Manuel Jáquez Leal [Mon, 25 Sep 2017 13:50:19 +0000 (15:50 +0200)]
vaapidecode: drain pending frames before set format
Drain pending frames, if any, in the internal decoder before setting
the new negotiated format.
https://bugzilla.gnome.org/show_bug.cgi?id=786173
Víctor Manuel Jáquez Leal [Fri, 22 Sep 2017 17:35:04 +0000 (19:35 +0200)]
tests: display: use GObject getter
Instead of using the gst_vaapi_display_get_property(), this patch
replaces it with g_object_get_property() to dump the available VA
display properties.
https://bugzilla.gnome.org/show_bug.cgi?id=788058
Víctor Manuel Jáquez Leal [Fri, 22 Sep 2017 17:25:20 +0000 (19:25 +0200)]
vaapisink: use GObject setter and getter
Instead of using gst_vaapi_display_set_property() or
gst_vaapi_display_get_property(), this patch set replace it usage
with g_object_set() or g_object_get().
Also the internal helper cb_set_value() is removed since it is not
used anymore.
https://bugzilla.gnome.org/show_bug.cgi?id=788058
Víctor Manuel Jáquez Leal [Fri, 22 Sep 2017 16:59:49 +0000 (18:59 +0200)]
libs: display: initialize value if they are not yet
This is a difference between the GObject API and the GstVaapi one: the
GValue passed to get a property value, in GObject has to be
initialized with g_value_init(), but in GstVaapi is has not.
In order to overcome this mismatch, this patch call g_value_init()
internally only in the passed one is not already initialized.
https://bugzilla.gnome.org/show_bug.cgi?id=788058
Víctor Manuel Jáquez Leal [Fri, 22 Sep 2017 15:04:17 +0000 (17:04 +0200)]
libs: display: optimize properties setters and getters
Shuffled some code to avoid to find the properties descriptor in the
array twice, adding the internal functions _set_property() and
_get_property().
https://bugzilla.gnome.org/show_bug.cgi?id=788058
Víctor Manuel Jáquez Leal [Fri, 22 Sep 2017 14:29:02 +0000 (16:29 +0200)]
libs: display: install properties in class
Install the properties in the class as a normal GObject. Implement
set_property() and get_property() vmethods.
https://bugzilla.gnome.org/show_bug.cgi?id=788058
Víctor Manuel Jáquez Leal [Fri, 22 Sep 2017 13:16:34 +0000 (15:16 +0200)]
libs: display: remove gst_vaapi_display_properties_init()
Remove gst_vaapi_display_properties_init() since it can be unrolled in
gst_vaapi_display_class_init()
https://bugzilla.gnome.org/show_bug.cgi?id=788058
Víctor Manuel Jáquez Leal [Fri, 22 Sep 2017 13:12:05 +0000 (15:12 +0200)]
libs: display: remove libgstvaapi_init_once()
It is not required since it can be unrolled in
gst_vaapi_display_class_init()
https://bugzilla.gnome.org/show_bug.cgi?id=788058
Víctor Manuel Jáquez Leal [Fri, 22 Sep 2017 15:50:15 +0000 (17:50 +0200)]
tests: test-display: remove display cache tests
Since commit
ec3e10f6, display cache was removed. This patch removes
this leftovers in the display test.
Hyunjun Ko [Mon, 18 Sep 2017 05:29:55 +0000 (14:29 +0900)]
libs: decoder: h264/h265: decode codec data only if opened
Fixes regression introduced by commit
2eb2b26a.
There is a use case when the decoder set the src caps and immediatly
tries to process the media codec_data, this happens before decoder is
even opened, thus priv->parser is not instantiated yet.
https://bugzilla.gnome.org/show_bug.cgi?id=787818
Víctor Manuel Jáquez Leal [Mon, 18 Sep 2017 17:11:45 +0000 (19:11 +0200)]
libs: encoder: change mbbrc from uint to enum
Instead of handling the macroblock bitrate control as a integer, this
patch changes it as a enum, which is more self documented in the
GStreamer elements.
https://bugzilla.gnome.org/show_bug.cgi?id=787855
Jan Schmidt [Mon, 18 Sep 2017 03:55:49 +0000 (13:55 +1000)]
Fix a typo in the prop string for compliance-mode
Víctor Manuel Jáquez Leal [Fri, 15 Sep 2017 16:31:49 +0000 (18:31 +0200)]
libs: encoder: don't unref properties
This patch fixes a regression introduced in commit
148f867c, since the
props variable is set to object's member variable
encoder->properties. And it is set in the instance initialization,
thus it will not be leaked.
https://bugzilla.gnome.org/show_bug.cgi?id=787733
Hyunjun Ko [Fri, 15 Sep 2017 06:14:47 +0000 (15:14 +0900)]
vaapiencode/libs: encoder: fix leaks of properties
https://bugzilla.gnome.org/show_bug.cgi?id=786321
Víctor Manuel Jáquez Leal [Thu, 24 Aug 2017 19:51:22 +0000 (21:51 +0200)]
libs: decoder: at update_caps() decode codec_data
When updating the caps in decoder, if the caps has codec_data (avC
format), it has to be parsed to update the state of the decoder.
https://bugzilla.gnome.org/show_bug.cgi?id=786173
Hyunjun Ko [Wed, 13 Sep 2017 06:44:32 +0000 (15:44 +0900)]
libs: context: fix wrong counter of the array of attributes
The counter value passed to vaCreateConfig is always +1.
This is a regression caused by commit
e42ec3ad.
The present patch fixes wrong counting of the array of attributes.
https://bugzilla.gnome.org/show_bug.cgi?id=787613
Hyunjun Ko [Wed, 13 Sep 2017 03:23:42 +0000 (12:23 +0900)]
libs: encoder: h265: support I/P/B QP setting seperatedly
Creates 2 properties, qp-ip and qp-ib for setting different QP for P/B
frames
and set slice_qp_delta for each frame according to the value provided.
https://bugzilla.gnome.org/show_bug.cgi?id=785923
Hyunjun Ko [Wed, 13 Sep 2017 03:22:07 +0000 (12:22 +0900)]
libs: encoder: h264: support I/P/B QP setting seperatedly
Creates 2 properties, qp-ip and qp-ib for setting different QP for P/B
frames
and set slice_qp_delta for each frame according to the value provided.
In addition, remove the limitation of (<= 4) when setting
slice_qp_delta.
https://bugzilla.gnome.org/show_bug.cgi?id=785923
Hyunjun Ko [Wed, 13 Sep 2017 03:15:57 +0000 (12:15 +0900)]
libs: encoder: h264/h265: keep min_qp as is unless it's over init_qp
Creates new variable for QP for I frame and keep it at configuration and
use this for pic_init_qp and slice_qp_delta setting.
Since changing min qp doesn't make sense, keep min qp as is.
https://bugzilla.gnome.org/show_bug.cgi?id=785923
Hyunjun Ko [Wed, 13 Sep 2017 03:09:45 +0000 (12:09 +0900)]
libs: encoder: h265: Add mbbrc property
This property supports Macroblock level Bitrate Control as the
following (same as h264 encoder):
0: auto
1: on
2: off
https://bugzilla.gnome.org/show_bug.cgi?id=785917
Hyunjun Ko [Wed, 13 Sep 2017 03:02:53 +0000 (12:02 +0900)]
libs: encoder: h264: Add mbbrc property
This property supports Macroblock level Bitrate Control as the
following:
0: auto
1: on
2: off
https://bugzilla.gnome.org/show_bug.cgi?id=785917
Hyunjun Ko [Wed, 13 Sep 2017 02:39:09 +0000 (11:39 +0900)]
libs: encoder: h265: add multi reference support
This is doing the same as h264 encoder as the following:
Using num_ref_frames provided and the result of the Query
VAConfigAttribEncMaxRefFrames, it determines the size of reference list
and perform encoding with multi reference frames as the following:
1\ The num_ref_frames is being considered as the number of
reference picture list0
2\ Encoder adds 1 reference frame more to the reference picture list1
internally if b-frame encoding.
3\ If num_ref_frames is bigger than the number of refrence frames
supported in the driver, it will be lowered.
Also this patch includes:
- Set num_negative_pics and num_positive_pics according to the number of
refs.
- Set delta_poc according to the number of refs.
- Increase max_dec_pic_buffering according to the number of refs
- Change max_num_reorder_pics according to num of bframes
https://bugzilla.gnome.org/show_bug.cgi?id=783804
Hyunjun Ko [Wed, 13 Sep 2017 02:37:33 +0000 (11:37 +0900)]
libs: encoder: h265: add refs property
Users can provide the number of reference frame by this property,
which is exaclty same as h264.
The value of the property will be considered as the number of
reference picture list0 and will add 1 reference frame more to the
reference picture list1 internally if b-frame encoding.
If the value provided is bigger than the number of refrence frames
supported in the driver, it will be lowered.
The maximum value is aligned to the value of the driver supported now.
https://bugzilla.gnome.org/show_bug.cgi?id=783804
Hyunjun Ko [Wed, 13 Sep 2017 02:17:26 +0000 (11:17 +0900)]
libs: encoder: h264/5: determine num_ref_idx_active_override_flag according to reference list
Follows the specification as below:
7.4.7.1 in Rec. ITU-T H.265 v4 (12/2016)
num_ref_idx_active_override_flag equal to 1 specifies that the syntax
element num_ref_idx_l0_active_minus1 is present for P and B slices and
that the syntax element num_ref_idx_l1_active_minus1 is present for B
slices.
num_ref_idx_active_override_flag equal to 0 specifies that the syntax
elements num_ref_idx_l0_active_minus1 and num_ref_idx_l1_active_minus1
are not present.
https://bugzilla.gnome.org/show_bug.cgi?id=783804
Hyunjun Ko [Wed, 13 Sep 2017 02:06:20 +0000 (11:06 +0900)]
libs: encoder: h265: keep idr_period equal to keyframe period
Remove FIXME code, which makes previous assignation spurious.
This also means to make idr_period equal to keyframe period,
which is same as h264 encoder.
https://bugzilla.gnome.org/show_bug.cgi?id=783804
Nicolas Dufresne [Wed, 6 Sep 2017 18:03:25 +0000 (14:03 -0400)]
Request minimum buffer even if need_pool is FALSE
When tee is used, it will not request a pool, but still it wants to
know how many buffers are required.
https://bugzilla.gnome.org/show_bug.cgi?id=730758
U. Artie Eoff [Tue, 5 Sep 2017 17:58:57 +0000 (10:58 -0700)]
libs: encoder: h264_fei: VA-API 1.0 compat
Use VA_ENC_PACKED_HEADER_H264_SEI compat macro for VA-API 1.0
compatibility.
https://bugzilla.gnome.org/show_bug.cgi?id=787322
Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com>
Sreerenj Balachandran [Fri, 1 Sep 2017 20:48:01 +0000 (13:48 -0700)]
vaapisink: Fix rendering in drm display
Make sure vaapisink create a va surface backed buffer pool and all
required attributes get assigned correctly for drm display type.
This is needed to make the below pipeline working:
gst-launch-1.0 filesrc location= raw_video.mov ! videoparse format=uyvy
width=320 height=240 framerate=30/1 ! vaapisink display=drm
https://bugzilla.gnome.org/show_bug.cgi?id=786954
Sreerenj Balachandran [Thu, 10 Aug 2017 01:46:09 +0000 (18:46 -0700)]
FEI: Add test applications to showcase fei use case
test-fei-enc-out: A simple fei encoding application to output mv, mbcode and distortion
eg:
./test-fei-enc-out -i sample_320x240.nv12 -w 320 -h 240 -o out.264 -v mv.out -d out.dist -m out.mbcode -e 1
test-fei-enc-in: A simple fei encoding application for testing input fei buffers
eg:
./test-fei-enc-in -c h264 -o out.264 -e 4 -q 1 sample_i420.y4m
Fixme: Running test-fei-enc-in in PAK mode with mv and mbcode input buffers
from saved files is still not working
People contributed:
Wang, Yi <yi.a.wang@intel.com>
Leilei <leilei.shang@intel.com>
Zhong, Xiaoxia <xiaoxia.zhong@intel.com>
xiaominc <xiaomin.chen@intel.com>
Li, Jing B <jing.b.li@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=785712
https://bugzilla.gnome.org/show_bug.cgi?id=784667
Sreerenj Balachandran [Thu, 10 Aug 2017 01:36:13 +0000 (18:36 -0700)]
FEI: plugin: Add vaapih264feienc element
A new FEI based encoder element for h264 is added: vaapih264feienc
FEI is a an extension to VA-API which is providing low level
advanced control over different stages of encoding.
Extending vaapih264enc with fei support is possible, but it will
make the code too much complicated and will be difficult
to debug. So adding the new encoder element, but keeping
the rank as 0 , vaapih264enc will stay as the primary
encoder for normal use cases.
The vaaih264feienc is mainly useful for customers who want to play
with MotionVectors and Macroblock Predictions. Also user can
do one stage of encoding(eg: only the Motion Vector Calculation)
in software and offload trasformation/entroy-coding etc to
Hardware (which is what PAK module is doing) using FEI element.
vaapih264feienc can work in different modes using fei-mode properoty
eg: gst-launch-1.0 videotestsrc ! vaapih264feienc fei-mode=ENC+PAK ! filesink location=sample.264
Important Note: ENC only mode won't produce any encoded data which is expected.
But ENC alwys requires the output of PAK in order to do the inter-prediction
over reconstructed frames.
Similary PAK mode alway requires MV and MBCode as input, so unless there is an
upstream element providing those buffers, PAK only won't work as expected.
In a nutshell, ENC_PAK and the ENC+PAK modes are the only options we can verify
with vaapih264feienc. But ideally, EN+PAK mode verification is enough to make sure
that ENC and PAK are working as expected since ENC+PAK mode always invoke ENC and PAK
separately in vaapih264feienc.
People contributed:
Wang, Yi <yi.a.wang@intel.com>
Leilei <leilei.shang@intel.com>
Zhong, Xiaoxia <xiaoxia.zhong@intel.com>
xiaominc <xiaomin.chen@intel.com>
Li, Jing B <jing.b.li@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=785712
https://bugzilla.gnome.org/show_bug.cgi?id=784667
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
Yi A Wang [Thu, 10 Aug 2017 01:32:13 +0000 (18:32 -0700)]
FEI: plugin: Add virtual methods to base encode
Two new virtual methods are added to gstvaapiencode.
load_control_data(): load the FEI input buffers set by the upstream elements
save_stats_to_meta(): save the FEI output buffers to Meta for downnstream elements
https://bugzilla.gnome.org/show_bug.cgi?id=785712
https://bugzilla.gnome.org/show_bug.cgi?id=784667
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
Yi A Wang [Thu, 10 Aug 2017 01:26:57 +0000 (18:26 -0700)]
FEI: plugin: Add fei specific video meta
GstVaapiFeiVideoMeta holds the below fei codec objects:
GstVaapiEncFeiMbCode
GstVaapiEncFeiMv
GstVaapiEncFeiMvPredictor
GstVaapiEncFeiMbControl
GstVaapiEncFeiQp
GstVaapiEncFeiDistortion
https://bugzilla.gnome.org/show_bug.cgi?id=785712
https://bugzilla.gnome.org/show_bug.cgi?id=784667
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
Sreerenj Balachandran [Thu, 10 Aug 2017 01:19:06 +0000 (18:19 -0700)]
FEI: libs: Add FEI encoder
Adding FEI encoder to core lib.
The code is splitted into three session:
1: gstvaapiencoder_h264_fei.{h,c}
This is the replica of gstvaapiencoder_h264.{c,h} but with FEI.
All the modes ENC, PAK and ENC_PAK are running based
the code in these files.
2: gstvaapifeienc_h264.{h,c}
Abstract implementation intended for ENC (only VME) operation.
3: gstvaapifeipak_h264.{h,c}
Abstrct implementation intended for PAK (only the PAK module)
Right now ENC_PAK, ENC and PAK are running based on code
in gstvaapiencoder_h264_fei.{h,c}. The abstract implementations
in gstvaapifeienc_h264.{h,c} and gstvaapifeipak_h264.{h,c} are
needed if user request for ENC+PAK mode operation.
ENC+PAK: Here we need to invoke two sequence of
vaBeginPicture/vaRenderPicutre/vaEndPicture for each frame,
first for the ENC only and the second for PAK only.
Each mode associated with separate context ,but same pool of surfaces are
shared between the modes.
This is more useful once we have custom BRC algorithms.
Other Contributors:
Wang, Yi <yi.a.wang@intel.com>
Leilei <leilei.shang@intel.com>
Zhong, Xiaoxia <xiaoxia.zhong@intel.com>
xiaominc <xiaomin.chen@intel.com>
Li, Jing B <jing.b.li@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=785712
https://bugzilla.gnome.org/show_bug.cgi?id=784667
Sreerenj Balachandran [Thu, 10 Aug 2017 00:54:27 +0000 (17:54 -0700)]
FEI: libs: Add fei codec objects to GstVaapiEncPicture
All the codec objects(vaapi buffers) supposed to be
submited in vaRenderPicutre are associated with a GstVaapiEncPicture
for each frame, follow the same design for FEI too.
https://bugzilla.gnome.org/show_bug.cgi?id=785712
https://bugzilla.gnome.org/show_bug.cgi?id=784667
Sreerenj Balachandran [Wed, 9 Aug 2017 23:05:13 +0000 (16:05 -0700)]
FEI: libs: Add fei codec objects in codedbufferproxy
MbCode, MV and Distortion buffers (fei codec objects)
can be treated as output of different fei modes based user request.
For eg: MbCode and MV are the output of ENC only. MbCode, MV and Dist
can be dumped as output in ENC_PAK mode for analysis purpose.
So treating them as a part of CodedBufferProxy too.
Here we avoided Qp, MbControl and MvPredictor codec objects since
there is no practical use case of treating them as "output buffers".
Other contributors:
Zhong, Xiaoxia <xiaoxia.zhong@intel.com>
xiaominc <xiaomin.chen@intel.com>
Leilei <leilei.shang@intel.com>
Li, Jing B <jing.b.li@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=785712
https://bugzilla.gnome.org/show_bug.cgi?id=784667
Sreerenj Balachandran [Wed, 9 Aug 2017 22:49:21 +0000 (15:49 -0700)]
FEI: libs: Add fei codec objects to surface proxy
Add fei codec objects to surface proxy since handling the
fei buffers(codec objects here) external to gstvaapisurfaceproxy
will make the code complicated. Especially considering the behavior
of encoder where the input frame order from upstream and output
frame order to the downstream are not sequential.
Other contributors:
Zhong, Xiaoxia <xiaoxia.zhong@intel.com>
xiaominc <xiaomin.chen@intel.com>
Leilei <leilei.shang@intel.com>
Li, Jing B <jing.b.li@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=785712
https://bugzilla.gnome.org/show_bug.cgi?id=784667
Sreerenj Balachandran [Wed, 9 Aug 2017 22:35:10 +0000 (15:35 -0700)]
FEI: Add codec objects for fei usecase
There are 6 new va buffer types, each defined as a specific codec object.
Borrowed the code from gstvaapicodecobject , but made a clear separation
to avoid any possible mess-up. Because unlike the other gstvaaicodecobjects,
feicodecobjects can be shared between elements and also can be accessed
from different thread.
Unlike the other fei codecs object, VAEncMiscParameterTypeFEIFrameControl
object is not shared between elements.So we utilize the already
existing gst_vaapi_enc_misc_param_new(), but still keeping the code
in gstvaapfei_objects_priv.h in order to have a better
code readability.
Fixme:
-- Probably we need _locked_map() and _unlocked_map()
-- Context can be associated with PreEnc(not just Enoder)
once we have the proper support inplace, but for now we don't have
PreEnc support, so should be safe enough to use GstVaapiEncoder.
https://bugzilla.gnome.org/show_bug.cgi?id=785712
https://bugzilla.gnome.org/show_bug.cgi?id=784667
Sreerenj Balachandran [Wed, 9 Aug 2017 21:22:12 +0000 (14:22 -0700)]
FEI: libs: add H264 fei specific utility functions
Added enum/flag type definitions for a number of FEI
input and output parameters.
Original author of the patch: Wang, Yi <yi.a.wang@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=785712
https://bugzilla.gnome.org/show_bug.cgi?id=784667
Signed-off-by: Wang, Yi <yi.a.wang@intel.com>
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
Sreerenj Balachandran [Wed, 9 Aug 2017 21:10:16 +0000 (14:10 -0700)]
FEI: libs: Add virtual method for secondary context creation.
Add a new vitrual method ensure_secondary_context to the
base encoder which is only required for the FEI entrypoint, that too
only when user configures the ENC+PAK mode. ENC+PAK mode is not something
supported directly by libva or driver, but this can be enabled
from the middleware.
Original Author of this idea: Leilei Shang <leilei.shang@intel.com>
Signed-off-by: Leilei Shang <leilei.shang@intel.com>
Signed-off-by: xiaominc <xiaomin.chen@intel.com>
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=785712
https://bugzilla.gnome.org/show_bug.cgi?id=784667
Sreerenj Balachandran [Wed, 9 Aug 2017 21:05:03 +0000 (14:05 -0700)]
FEI: libs: make sure the default context creation works as expected.
Current code always guess the entrypoint during init phase in case
if there is no entrypoint already configured in GstVaapiContextInfo.
Make sure FEI Entrypoint is not messing up with this logic.
https://bugzilla.gnome.org/show_bug.cgi?id=785712
https://bugzilla.gnome.org/show_bug.cgi?id=784667
Sreerenj Balachandran [Wed, 9 Aug 2017 20:45:40 +0000 (13:45 -0700)]
FEI: libs: Add FEI functional mode configuration
FEI Entrypoint can work in either one of the 3 different modes:
VA_FEI_FUNCTION_ENC, VA_FEI_FUNCTION_PAK or VA_FEI_FUNCTION_ENC_PAK.
Add infrastructure in gstvaapicontext and gstvaapiencoder for this
functioal mode configuration.
https://bugzilla.gnome.org/show_bug.cgi?id=785712
https://bugzilla.gnome.org/show_bug.cgi?id=784667
Sreerenj Balachandran [Wed, 9 Aug 2017 20:02:24 +0000 (13:02 -0700)]
FEI: libs: Add FEI Entrypoint mapping
Define the new mapping GST_VAAPI_ENTRYPOINT_SLICE_ENCODE_FEI
for VAEntrypointFEI.
https://bugzilla.gnome.org/show_bug.cgi?id=785712
https://bugzilla.gnome.org/show_bug.cgi?id=784667
Sreerenj Balachandran [Wed, 9 Aug 2017 19:58:29 +0000 (12:58 -0700)]
FEI: Add support for FEI conditional build
FEI(Flexible Encoding Infrastructure) is an extension
to VA API. Define USE_H264_FEI_ENCODER based on
fei header file and required structures availability.
https://bugzilla.gnome.org/show_bug.cgi?id=785712
https://bugzilla.gnome.org/show_bug.cgi?id=784667