Víctor Manuel Jáquez Leal [Mon, 5 Jun 2017 18:30:07 +0000 (20:30 +0200)]
libs: encoder: vp8,h264,h265,mpeg2: set misc param once
Instead of recalculating the miscellaneous buffer parameters for
every buffer, it is only done once, when the encoder is configured.
And for every buffer, the same structures are just copied.
https://bugzilla.gnome.org/show_bug.cgi?id=783449
Víctor Manuel Jáquez Leal [Mon, 5 Jun 2017 15:31:10 +0000 (17:31 +0200)]
libs: encoder: vp8,h264,h265,mpeg2: refactor misc parameters
This is patch pretends to decouple the assignation of the values
in the parameter structures and the VA buffer's parameters setting.
It may lead to some issues since HRD, framerate or controlrate may
not be handled by the specific encoder, but they are set in
the VA buffer's parameters.
I leave as it because this patch is just a transitional patch.
https://bugzilla.gnome.org/show_bug.cgi?id=783449
Víctor Manuel Jáquez Leal [Mon, 5 Jun 2017 14:34:12 +0000 (16:34 +0200)]
libs: encoder: vp8: fix frame rate calculation
According to the VA documentation:
The framerate is specified as a number of frames per second,
as a fraction. The denominator of the fraction is given in
the top half (the high two bytes) of the framerate field, and
the numerator is given in the bottom half (the low two bytes).
For example, if framerate is set to (100 << 16 | 750), this is
750 / 100, hence 7.5fps.
If the denominator is zero (the high two bytes are both zero)
then it takes the value one instead, so the framerate is just
the integer in the low 2 bytes.
This patch fixes the the framerate calculation in vp8 encoder
according to this.
https://bugzilla.gnome.org/show_bug.cgi?id=783449
Víctor Manuel Jáquez Leal [Fri, 2 Jun 2017 17:46:52 +0000 (19:46 +0200)]
libs: encoder: vp8: refactor FrameRate parameter
Move frame-rate parameter from ensure_misc_params() to
ensure_contro_rate_param() since it only has meaning when the
control rate is either VBR or CBR.
https://bugzilla.gnome.org/show_bug.cgi?id=783449
Víctor Manuel Jáquez Leal [Fri, 2 Jun 2017 17:33:36 +0000 (19:33 +0200)]
libs: encoder: h264,h265,mpeg2,vp8: refactor HDR
Move the Hypothetical Reference Decoder (HRD) parameter, from
ensure_misc_params() to ensure_control_rate_params(), since it
only shall be defined when the control rate is either VBR or CBR.
https://bugzilla.gnome.org/show_bug.cgi?id=783449
Víctor Manuel Jáquez Leal [Fri, 2 Jun 2017 15:21:25 +0000 (17:21 +0200)]
libs: encoder: h264,vp8,mpeg2: refactor control rate
Instead of filling the control rate param in ensure_misc_params(),
this patch refactor it out, as a first step to merge the same code
for all the encoders.
https://bugzilla.gnome.org/show_bug.cgi?id=783449
Víctor Manuel Jáquez Leal [Fri, 2 Jun 2017 14:28:30 +0000 (16:28 +0200)]
libs: encoder: h264, h265, mpeg2: remove assert
Remove spurious asserts for misc parameters. If they cannot be
allocated, FALSE is already returned.
Víctor Manuel Jáquez Leal [Mon, 5 Jun 2017 16:19:05 +0000 (18:19 +0200)]
libs: encoder: use VA quality level structure
Instead of using a proxy to story the buffer quality level, the
encoder now uses the native VA structure, which is copied to the
dynamically allocated VAEncMiscParameterBuffer.
This approach is computationally less expensive.
Víctor Manuel Jáquez Leal [Fri, 26 May 2017 09:10:34 +0000 (11:10 +0200)]
libs: standardize the FIXME comment
This is a trivial patch that makes homogeneous the FIXME tag in
comments.
For more info about these comment style:
http://wiki.c2.com/?FixmeComment
Hyunjun Ko [Mon, 22 May 2017 15:20:45 +0000 (17:20 +0200)]
libs: encoder: vp8: set quality level regardless of rate control mode
https://bugzilla.gnome.org/show_bug.cgi?id=782957
Víctor Manuel Jáquez Leal [Mon, 15 May 2017 16:38:29 +0000 (18:38 +0200)]
libs: encoder: check for maximum number of slices
Right now, H264 and HEVC can set as a property the number of slices to
process. But each driver can set a maximum number of slices, depending
on the supported profile & entry point.
This patch verifies the current num_slices to process against the maximum
permitted by the driver and the media size.
https://bugzilla.gnome.org/show_bug.cgi?id=780955
Víctor Manuel Jáquez Leal [Mon, 15 May 2017 16:36:21 +0000 (18:36 +0200)]
libs: utils: mark functions as internals
The functions in this header are internal to the library.
Víctor Manuel Jáquez Leal [Mon, 15 May 2017 16:35:40 +0000 (18:35 +0200)]
libs: context: add missing documentation
Document the region-of-interest configuration variables.
Víctor Manuel Jáquez Leal [Fri, 12 May 2017 16:46:50 +0000 (18:46 +0200)]
tests: elements: vaapisink: handle nav events
The test app can now handle navigation events to rotate the
display.
Víctor Manuel Jáquez Leal [Fri, 12 May 2017 16:17:55 +0000 (18:17 +0200)]
tests: elements: clean up vaapisink test
- Use gst_element_send_event() instead of gst_pad_push_event()
- don't zero App structure
- check for pipeline parsing error
- only get vaapisink for property set
Hyunjun Ko [Fri, 12 May 2017 04:08:30 +0000 (13:08 +0900)]
vaapisink: keep handle_events flag except that if user want to set
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
Hyunjun Ko [Fri, 12 May 2017 04:06:24 +0000 (13:06 +0900)]
libs: window: x11: fix src rect info when using vpp
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
Víctor Manuel Jáquez Leal [Fri, 28 Apr 2017 13:20:01 +0000 (15:20 +0200)]
plugins: remove par from caps negotiation
https://bugzilla.gnome.org/show_bug.cgi?id=781759
Hyunjun Ko [Thu, 30 Mar 2017 08:57:42 +0000 (17:57 +0900)]
tests: elements: add an example for ROI
This implements a pipleint to recognize difference between ROI and non-ROI.
See comments in this code in detail.
https://bugzilla.gnome.org/show_bug.cgi?id=768248
Signed-off-by: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>
Hyunjun Ko [Thu, 30 Mar 2017 08:54:20 +0000 (17:54 +0900)]
vaapiencode: handle custom event GstVaapiEncoderRegionOfInterest
Handles new custom event GstVaapiEncoderRegionOfInterest
to enable/disable a ROI region.
Writes a way to use new event to document.
https://bugzilla.gnome.org/show_bug.cgi?id=768248
Signed-off-by: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>
Hyunjun Ko [Thu, 23 Feb 2017 09:53:18 +0000 (18:53 +0900)]
tests: simple-encoder: add an option to set ROI
$ simple-encoder -r inputfile.y4m
And you'll got an output file in H264 with two regions of interest.
https://bugzilla.gnome.org/show_bug.cgi?id=768248
Signed-off-by: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>
Hyunjun Ko [Thu, 23 Feb 2017 09:52:48 +0000 (18:52 +0900)]
libs: encoder: h264: set ROI params during encoding
Set ROI params during encoding each frame, which are set via
gst_vaapi_encoder_add_roi ()
https://bugzilla.gnome.org/show_bug.cgi?id=768248
Signed-off-by: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>
Hyunjun Ko [Tue, 28 Mar 2017 08:41:37 +0000 (17:41 +0900)]
libs: encoder: add api gst_vaapi_encoder_add/del_roi
Implements and exposes new api gst_vaapi_encoder_add/del_roi to set ROI regions.
https://bugzilla.gnome.org/show_bug.cgi?id=768248
Hyunjun Ko [Thu, 23 Feb 2017 08:57:07 +0000 (17:57 +0900)]
libs: encoder/context: query region of interest support
Queries if the driver supports "Region of Interest" (ROI) during the config
creation.
This attribute conveys whether the driver supports region-of-interest (ROI)
encoding, based on user provided ROI rectangles. The attribute value is
partitioned into fields as defined in the VAConfigAttribValEncROI union.
If ROI encoding is supported, the ROI information is passed to the driver
using VAEncMiscParameterTypeROI.
https://bugzilla.gnome.org/show_bug.cgi?id=768248
Signed-off-by: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>
Víctor Manuel Jáquez Leal [Fri, 12 May 2017 09:11:48 +0000 (11:11 +0200)]
libs: encoder: fix a comment
Víctor Manuel Jáquez Leal [Thu, 11 May 2017 10:23:28 +0000 (12:23 +0200)]
libs: encoder: guard quality level configuration
The quality level appeared in VA-API 0.36. So let's guard its
usage.
Sreerenj Balachandran [Wed, 19 Apr 2017 20:04:44 +0000 (13:04 -0700)]
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>
Sebastian Dröge [Thu, 4 May 2017 15:59:31 +0000 (18:59 +0300)]
Back to development
Sebastian Dröge [Thu, 4 May 2017 12:46:03 +0000 (15:46 +0300)]
Release 1.12.0
Víctor Manuel Jáquez Leal [Thu, 4 May 2017 09:49:33 +0000 (11:49 +0200)]
Revert "vaapidecodebin: fix element's classification"
This reverts commit
8cbe03599a4f27c2001380e2ec150c4f4267a9cf.
Scott D Phillips [Fri, 28 Apr 2017 05:55:27 +0000 (22:55 -0700)]
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
Victor Toso [Tue, 2 May 2017 12:08:54 +0000 (14:08 +0200)]
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
Sebastian Dröge [Thu, 27 Apr 2017 14:49:52 +0000 (17:49 +0300)]
Release 1.11.91
Víctor Manuel Jáquez Leal [Thu, 27 Apr 2017 11:08:56 +0000 (13:08 +0200)]
Revert "plugins: reject pixel-aspect-ratio with value 0/1"
This reverts commit
c0be7b1890ea8da915a81ae82bc9f504aee7cc26.
Víctor Manuel Jáquez Leal [Thu, 27 Apr 2017 10:43:54 +0000 (12:43 +0200)]
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
Víctor Manuel Jáquez Leal [Wed, 26 Apr 2017 13:48:01 +0000 (15:48 +0200)]
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
Hyunjun Ko [Thu, 27 Apr 2017 05:42:55 +0000 (14:42 +0900)]
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
Víctor Manuel Jáquez Leal [Fri, 21 Apr 2017 17:07:18 +0000 (19:07 +0200)]
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
Víctor Manuel Jáquez Leal [Tue, 25 Apr 2017 10:58:44 +0000 (12:58 +0200)]
test: elements: fix compilation flags
This issue was spotten on bug #766704
Original-patch-by: Hyunjun Ko <zzoon@igalia.com>
Hyunjun Ko [Tue, 25 Apr 2017 07:23:08 +0000 (16:23 +0900)]
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
Tim-Philipp Müller [Mon, 24 Apr 2017 19:30:30 +0000 (20:30 +0100)]
Automatic update of common submodule
From 60aeef6 to 48a5d85
Hyunjun Ko [Fri, 21 Apr 2017 13:30:09 +0000 (15:30 +0200)]
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>
Víctor Manuel Jáquez Leal [Fri, 21 Apr 2017 12:07:44 +0000 (14:07 +0200)]
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>
Hyunjun Ko [Wed, 19 Apr 2017 01:37:19 +0000 (10:37 +0900)]
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>
Jagyum Koo [Sun, 30 Oct 2016 01:43:49 +0000 (10:43 +0900)]
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>
Víctor Manuel Jáquez Leal [Thu, 20 Apr 2017 18:30:52 +0000 (20:30 +0200)]
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
Hyunjun Ko [Fri, 21 Apr 2017 09:05:48 +0000 (18:05 +0900)]
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
Víctor Manuel Jáquez Leal [Thu, 20 Apr 2017 16:44:41 +0000 (18:44 +0200)]
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.
Víctor Manuel Jáquez Leal [Thu, 8 Dec 2016 17:51:54 +0000 (18:51 +0100)]
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
Jan Schmidt [Fri, 7 Apr 2017 16:05:21 +0000 (02:05 +1000)]
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
Jan Schmidt [Fri, 7 Apr 2017 15:21:23 +0000 (01:21 +1000)]
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
Jan Schmidt [Wed, 5 Apr 2017 07:24:20 +0000 (17:24 +1000)]
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
Víctor Manuel Jáquez Leal [Tue, 11 Apr 2017 16:50:35 +0000 (18:50 +0200)]
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
Víctor Manuel Jáquez Leal [Tue, 11 Apr 2017 16:22:00 +0000 (18:22 +0200)]
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
Hyunjun Ko [Mon, 10 Apr 2017 08:23:26 +0000 (17:23 +0900)]
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
Hyunjun Ko [Mon, 10 Apr 2017 02:41:29 +0000 (11:41 +0900)]
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
Hyunjun Ko [Mon, 3 Apr 2017 07:45:36 +0000 (16:45 +0900)]
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
Scott D Phillips [Wed, 5 Apr 2017 18:19:15 +0000 (11:19 -0700)]
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
Tim-Philipp Müller [Mon, 10 Apr 2017 22:51:06 +0000 (23:51 +0100)]
Automatic update of common submodule
From 39ac2f5 to 60aeef6
Sebastian Dröge [Fri, 7 Apr 2017 13:36:21 +0000 (16:36 +0300)]
Release 1.11.90
Víctor Manuel Jáquez Leal [Mon, 3 Apr 2017 12:52:41 +0000 (14:52 +0200)]
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
Víctor Manuel Jáquez Leal [Mon, 3 Apr 2017 13:34:51 +0000 (15:34 +0200)]
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
Víctor Manuel Jáquez Leal [Wed, 29 Mar 2017 17:20:26 +0000 (19:20 +0200)]
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
Víctor Manuel Jáquez Leal [Wed, 29 Mar 2017 17:16:50 +0000 (19:16 +0200)]
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
Víctor Manuel Jáquez Leal [Thu, 6 Apr 2017 15:21:21 +0000 (17:21 +0200)]
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
Víctor Manuel Jáquez Leal [Thu, 6 Apr 2017 14:28:12 +0000 (16:28 +0200)]
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
Víctor Manuel Jáquez Leal [Thu, 6 Apr 2017 10:49:24 +0000 (12:49 +0200)]
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
Víctor Manuel Jáquez Leal [Thu, 6 Apr 2017 10:28:51 +0000 (12:28 +0200)]
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
Víctor Manuel Jáquez Leal [Tue, 4 Apr 2017 12:39:59 +0000 (14:39 +0200)]
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
Víctor Manuel Jáquez Leal [Tue, 4 Apr 2017 12:21:43 +0000 (14:21 +0200)]
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
Víctor Manuel Jáquez Leal [Fri, 31 Mar 2017 09:21:21 +0000 (11:21 +0200)]
vaapiencode: enhance logs of negotiated caps
https://bugzilla.gnome.org/show_bug.cgi?id=771291
Scott D Phillips [Wed, 5 Apr 2017 18:15:41 +0000 (11:15 -0700)]
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
Sreerenj Balachandran [Fri, 31 Mar 2017 21:12:43 +0000 (14:12 -0700)]
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.
Víctor Manuel Jáquez Leal [Wed, 29 Mar 2017 11:22:47 +0000 (13:22 +0200)]
libs: encoder: h265: fix code style
Trivial patch to remove a double ';' as end of instruction.
Sreerenj Balachandran [Tue, 28 Mar 2017 17:53:20 +0000 (10:53 -0700)]
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
Víctor Manuel Jáquez Leal [Tue, 21 Mar 2017 15:13:56 +0000 (16:13 +0100)]
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.
Víctor Manuel Jáquez Leal [Mon, 20 Mar 2017 15:45:01 +0000 (16:45 +0100)]
plugins: when debug disabled, default category is NULL
As in gstreamer-vaapi a common base class is used, the specific
default category is passed to the base-plugin initializator, thus
the log messages are categorized with the used plugin.
Nonetheless, when the gst-debug is disabled in compilation time,
it is needed to pass NULL to the base-plugin initializator. This
patch does that.
https://bugzilla.gnome.org/show_bug.cgi?id=780302
Hyunjun Ko [Fri, 17 Mar 2017 08:14:01 +0000 (17:14 +0900)]
libs: h26x: adds gst_vaapi_utils_h26x_write_nal_unit()
Implements gst_vaapi_utils_h26x_write_nal_unit(), which writes NAL
unit length and data to a bitwriter.
Note that this helper function applies EPB (Emulation Prevention
Bytes), since otherwise produced codec_data might be broken when
decoder/parser considering EPB, starts parsing.
See sections 7.3 and 7.4 of the H264 and H264 specifications, which
describes the emulation_prevention_three_byte.
https://bugzilla.gnome.org/show_bug.cgi?id=778750
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
Hyunjun Ko [Fri, 17 Mar 2017 07:49:41 +0000 (16:49 +0900)]
libs: utils: h26x: create vaapiutils_h26x
Since there is duplicated code in h264/265 encoder, we could
refactor it to avoid duplicated code.
https://bugzilla.gnome.org/show_bug.cgi?id=778750
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
Hyunjun Ko [Fri, 17 Mar 2017 07:32:36 +0000 (16:32 +0900)]
libs: encoder: h264/5: fix wrong return value
https://bugzilla.gnome.org/show_bug.cgi?id=778750
Hyunjun Ko [Mon, 13 Mar 2017 08:29:59 +0000 (17:29 +0900)]
docs: h264/h265: put parser to the example pipeline
https://bugzilla.gnome.org/show_bug.cgi?id=778749
Hyunjun Ko [Mon, 13 Mar 2017 07:20:59 +0000 (16:20 +0900)]
libs: encoder: h265: fix reserved length of bits
Fix reserved length of bits for bit_depth_luma_minus8 and bit_depth_chroma_minus8
https://bugzilla.gnome.org/show_bug.cgi?id=778749
Thomas Petazzoni [Sun, 12 Mar 2017 17:59:42 +0000 (18:59 +0100)]
O_CLOEXEC needs _GNU_SOURCE defined
From man open(2):
The O_CLOEXEC, O_DIRECTORY, and O_NOFOLLOW flags are not specified
in POSIX.1-2001, but are specified in POSIX.1-2008. Since glibc
2.12, one can obtain their definitions by defining either
_POSIX_C_SOURCE with a value greater than or equal to 200809L or
_XOPEN_SOURCE with a value greater than or equal to 700. In glibc
2.11 and earlier, one obtains the definitions by defining
_GNU_SOURCE.
And indeed, with the uClibc C library, O_CLOEXEC is not exposed if
_GNU_SOURCE is not defined. Therefore, this commit fixes the build of
gstreamer-vaapi with the uClibc C library.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
https://bugzilla.gnome.org/show_bug.cgi?id=779953
Víctor Manuel Jáquez Leal [Tue, 14 Mar 2017 15:07:08 +0000 (16:07 +0100)]
README: fix "Sources" section
Update the URL where the release source tarballs can be downloaded.
Thomas Petazzoni [Sun, 12 Mar 2017 20:39:53 +0000 (21:39 +0100)]
README: fix "Reporting bugs" section
The "Reporting bugs" section gives
https://bugzilla.gnome.org/enter_bug.cgi?product=gstreamer-vaapi as the
link to report a bug, but this link says "Sorry, entering a bug into the
product gstreamer-vaapi has been disabled.".
This commit fixes the URL to point to the proper location, and also
removes the following paragraph that is no longer correct.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
https://bugzilla.gnome.org/show_bug.cgi?id=779954
Víctor Manuel Jáquez Leal [Fri, 3 Mar 2017 18:55:00 +0000 (19:55 +0100)]
plugins: retry to create the VA display
Particularly in GNOME Wayland, the negotiated or created GL context
defines a GLX environment, but VAAPI fails to create a GLX VA
display because there is no a DRI2 connection.
This patch retries to create the VA display if VA cannot create one
with the GL context parameters. Now using the old list of display
types.
This should also work in the case of systems with two GPU, when the
non-VAAPI has the graphics environment, and the VAAPI-enabled one
shall work headless.
https://bugzilla.gnome.org/show_bug.cgi?id=772838
Julien Isorce [Wed, 19 Oct 2016 14:33:41 +0000 (15:33 +0100)]
vaapipostproc: texture upload if driver supports GL
Removes GstVideoGLTextureUploadMeta caps feature if the driver
doesn't support opengl.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=772838
Víctor Manuel Jáquez Leal [Tue, 25 Oct 2016 15:48:47 +0000 (17:48 +0200)]
vaapidecode: texture upload if driver supports GL
When the allowed source pad caps are generated, the GLTextureUpload caps are
only inserted if the driver support OpenGL.
https://bugzilla.gnome.org/show_bug.cgi?id=772838
Sreerenj Balachandran [Wed, 22 Feb 2017 23:02:01 +0000 (15:02 -0800)]
configure: Add missing compiler flags
The AC_CHECK_HEADERS macro was failing to locate some headers, in
particular the va_enc_* headers due to missing compiler flags.
https://bugzilla.gnome.org/show_bug.cgi?id=779101
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
Hyunjun Ko [Wed, 1 Mar 2017 05:48:46 +0000 (14:48 +0900)]
libs: window: wayland: handle more VAStatus to use vpp
Since the commit landed https://github.com/01org/intel-vaapi-driver/pull/55,
we should consider more returned VAStatus to use vpp.
https://bugzilla.gnome.org/show_bug.cgi?id=779400
Hyunjun Ko [Thu, 23 Feb 2017 06:16:06 +0000 (15:16 +0900)]
libs: encoder: ensure profile when context initialization
We can't be sure that encoder's profile is assgined already or not
at context initialization.
https://bugzilla.gnome.org/show_bug.cgi?id=779120
Hyunjun Ko [Thu, 23 Feb 2017 06:13:59 +0000 (15:13 +0900)]
libs: encoder: set rate control info only when query succeed
Currently, it set rate control information even when query fails.
In addition, it doesn't update any more since the flag
got_rate_control_mask is set to TRUE.
https://bugzilla.gnome.org/show_bug.cgi?id=779120
Sebastian Dröge [Fri, 24 Feb 2017 14:00:23 +0000 (16:00 +0200)]
meson: Update version
Sebastian Dröge [Fri, 24 Feb 2017 13:38:22 +0000 (15:38 +0200)]
Back to development
Sebastian Dröge [Fri, 24 Feb 2017 13:10:21 +0000 (15:10 +0200)]
Release 1.11.2
Víctor Manuel Jáquez Leal [Thu, 16 Feb 2017 17:37:59 +0000 (18:37 +0100)]
vaapiencode: merge tags for downstream's info
Add encoder and codec name and the bitrate into the output for
informational purposes. Some muxers or application use it as
media metadata.
https://bugzilla.gnome.org/show_bug.cgi?id=778781
Víctor Manuel Jáquez Leal [Fri, 17 Feb 2017 00:27:52 +0000 (01:27 +0100)]
libs: encoder: caps can change at any time
The encoder should be able to change its caps even it is already
processing a stream.
This is suppose to happen after a flush so the codedbuf_queue should
be empty.
https://bugzilla.gnome.org/show_bug.cgi?id=775490
Víctor Manuel Jáquez Leal [Fri, 17 Feb 2017 00:19:00 +0000 (01:19 +0100)]
libs: encoder: h265: bail if nal unit type fails
Bail out if the NAL unit type is not recognized.
https://bugzilla.gnome.org/show_bug.cgi?id=778782
Víctor Manuel Jáquez Leal [Thu, 16 Feb 2017 17:11:50 +0000 (18:11 +0100)]
libs: decoder: h264,h265 avoid uninitialized variable
Configuring GCC to verify possible usage of uninitialized variables,
shows that found_index might be used without previous assignation.
This patch assigns a initial value to found_index, also avoid a
branching when returning the result value.
https://bugzilla.gnome.org/show_bug.cgi?id=778782
Scott D Phillips [Tue, 14 Feb 2017 00:39:41 +0000 (16:39 -0800)]
build: rename USE_HEVC_DECODER to USE_H265_DECODER
Rename to be consistent with H.264 and also H.265 encoder. The
meson build assumed this was already consistently named, and so
previously was not able to actually build the H.265 decoder.
https://bugzilla.gnome.org/show_bug.cgi?id=778576