Somehow this didn't show up earlier, but gst_adapter_prev_timestamp() got
deprecated since GStreamer 1.0.
This patch replace it with gst_adapter_prev_pts()
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
This a very pathological situation: when we have a HEVC encoder but not a HEVC
decoder.
The encoder needs functions that are only available when the decoder is
enabled.
This patch moves the utils functions into the generic sources, such as the
rest of the utils.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
As gstreamer-vaapi now only supports from GStreamer 1.6, this patch removes
all the old GStreamer version guards.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
Since we don't install libraries anymore, it makes no sense to keep
versioning them according to the gstreamer's version.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
This basically reverts 62c3888b76 (wayland:
decouple wl_buffer from frame).
Otherwise the frame may be overwritten while it is still used by the
compositer:
The frame done callback (frame_done_callback()) is called, when the
compositor is done processing the frame and hands it to the hardware.
The buffer release callback (frame_release_callback()) is called when the
buffer memory is no longer used.
This can be quite some time later: E.g. if weston (with the DRM backend)
puts the buffer on a hardware plane, then then buffer release callback is
called when the kernel is done with the buffer. This is usually when the
next frame is shown, so most likely after the frame done callback for the
next frame!
Since 70eff01d36 "wayland: sync() when
destroy()" the mentioned possible leak should no longer be a problem, so
reverting this change should cause no leaking buffers.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=758848
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
Only supporting vaapidecode ! vaapisink combination for now.
Missing dependencies:
1: No support for P010 video format in GStreamer
2: No support for P010 vaGetImage()/vaPutimage() in vaapi-intel-driver
3: As a result of 1&2 , we have no support for Vaapi Video memory mapping
through GstVideoMeta.
Right now we only set chroma format (YUV420 with more than 8 bits per channel)
for surface pool and keeping GST_VIDEO_FORMAT as ENCODED. The underlying format
of the surfaces is implementation (driver) defined, which is P010.
This new API gst_vaapi_surface_pool_new_with_chroma_type() is for
creating a new GstVaapiVideoPool of GstVaapiSurfaces with the specified
chroam type and dimensions. The underlying format of the surfaces is
implementation (driver) defined.
When receiving the texture from the application or the video sink, we must
know it size and border. To query the texture the API has changed according to
the OpenGL version used in the GL context of the application/vsink.
This patch checks the current context API type and queries the texture
according to this detected API.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=753099
gst_vaapi_texture_glx_new_wrapped() only handles a GL_TEXTURE_2D target and
formats GL_RGBA or GL_BGRA.
This patch adds a debugging verification of those values.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=753099
In order to know which OpenGL API use, we must detect the API type of current
context. This patch adds the function gl_get_current_api() which returns the
OpenGL API type.
This function is an adaptation of gst_gl_context_get_current_gl_api() from
GstGL.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=753099
We always set GST_VAAPI_PICTURE_FLAG_SKIPPED for DECODE_ONLY frames and the
gstvaapidecoder base calss is reponsible for handling those frames later on.
No need for explicit verification of frame header's show_frame in order to
do picture outputing.
Set crop rectange if:
There is display_width and display_height which is different from actual width/height
or
The changed resolution is less than the actual configured dimension of surfaces
Unlike other decoders, vp9 decoder doesn't need to reset the
whole context and surfaces for each resolution change. Context
reset only needed if resolution of any frame is greater than
what actullay configured. There are streams where a bigger
resolution set in ivf header or webm header but actual resolution
of all frames are less. Also it is possible to have inter-prediction
between these multi resolution frames.
clang complains about a couple variables and one label which were not
used. This patch removes them.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=757958
Since gstvaapidisplay_glx.h do not expose gl.h/glx.h structures, it is not
required to include them in the header. It is not also required to include
them in gstvaapidisplay_glx.c, since gstvaapiutils_glx.h includes them and
exposes their structures (e.g. GLXPixmap).
Nonetheless, glext.h neither glxext.h are required to include, they are
already included conditionally by gl.h and glx.h, respectively.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=757577
When the GstVaapiParserInfoH264 is allocated, the memory is not initialized,
so it contains random data.
When gst_h264_parser_parse_pps() fails, the PPS structure keeps slice_group_id
pointer uninitialized, leading to a segmentation fault when the memory is
freed.
This patch prevents this by initializing the slice_group_id before the PPS
parsing.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=754845
Explicit flushing of dpb for EOS and EOB nal decoding is wrong,
the dpb_add() itself will handle the flusing(if needed) of dpb
for end of sequence and end of bitstream.
https://bugzilla.gnome.org/show_bug.cgi?id=754010
This fix is based on the V3 vesion of spec which was missing in older versions.
When the current picture has PicOutputFlag equal to 1, for each picture in the
DPB that is marked as "needed for output" and follows the current picture in output order,
the associated variable PicLatencyCount is set equal to PicLatencyCount + 1 (C.5.2.3).
https://bugzilla.gnome.org/show_bug.cgi?id=754010
The default scan order of scaling lists are up-right-diagonal
as per hevc specification. Use the newly implemented
uprightdiagonal_to_raster conversion codecparser APIs to
get the the scaling_list values in raster order, which is
what the VA intel driver requires.
Setting the sink to flushing causes gst_vaapi_window_wayland_sync() to
return FALSE which makes gst_vaapi_window_wayland_render() return
FALSE which ends up posting an ERROR message in
gst_vaapisink_show_frame_unlocked(). Solution is to just return TRUE
in the EBUSY case.
https://bugzilla.gnome.org/show_bug.cgi?id=753598
First added the function gst_vaapi_video_format_get_best_native(), which
returns the best native format that matches a particular chroma type:
YUV 4:2:0 -> NV12, YUV 4:2:2 -> YUY2, YUV 4:0:0 -> Y800
RGB32 chroma and encoded format map to NV12 too.
That format is used to configure, initially, the surface's pool for the
allocator.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=744042
Before, only YUV420 color space where supported. With this patch, the
encoder is queried to know the supported formats and admits YUV422
color space if its available.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=744042
This is necessary for finding ChromaOffsetL0/ChromaOffsetL1
prediction weight table values with out using any hard coding.
Fixme: We don't have parser API for sps_range_extension, so
assumed zero value for high_precision_offsets_enabled_flag.
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
Based on ITU-T rec H265(4/2015): 7-56
This was a wrong equation in rec H265 (4/2013): 7-44...
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
