Add initial support for Subset SPS, Prefix NAL and Slice Extension NAL
for non-base-view streams encoding, and the usual SPS, PPS and Slice
NALs for base-view encoding.
The H.264 Stereo High profile encoding mode will be turned on when the
"num-views" parameter is set to 2. The source (raw) YUV frames will be
considered as Left/Right view, alternatively.
Each of the two views has its own frames reordering pool and reference
frames list management system. Inter-view references are not supported
yet, so the views are encoded independently from each other.
Signed-off-by: Li Xiaowei <xiaowei.a.li@intel.com>
[limited to Stereo High profile per the definition of MAX_NUM_VIEWS]
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Fix generation of source tarballs when certain conditionals are not
met. e.g. always include all buildable codecparsers sources in the
distribution tarball, fix plug-in element sources set to include X11
and encoder bits.
This maps GstVideoColorimetry information in vaapisink's sinkpad caps
to GST_VAAPI_COLOR_STANDARD_* flags, if per-buffer information was not
available.
https://bugzilla.gnome.org/show_bug.cgi?id=722255
[factored out code, added SMPTE240M, handle per-buffer flags]
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Add support for hue, saturation, brightness and constrat adjustments.
Also fix cap info local copy to match the really expected cap subtype
of interest.
https://bugzilla.gnome.org/show_bug.cgi?id=720376
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Fix copy/paste error when submitting the "sharpen" value to the
GstVaapiFilter instance.
https://bugzilla.gnome.org/show_bug.cgi?id=720375
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
When gst_vaapisink_video_overlay_set_window_handle() is called early,
before the pipeline has been set to PLAYING, the display has not yet
been initialized and _PLUGIN_BASE_DISPLAY_TYPE() is not yet
up-to-date. For this reason the foreign XID is not attached.
Now _ensure_display() is called earlier.
https://bugzilla.gnome.org/show_bug.cgi?id=722244
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Fix vaapidecode to correctly report caps features downstream, when
a custom pipeline is built manually.
https://bugzilla.gnome.org/show_bug.cgi?id=719372
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Since vaapidecode provides buffer that can be mapped as regular memory,
those caps should be added to the template caps. That only applies to
GStreamer >= 1.2.
https://bugzilla.gnome.org/show_bug.cgi?id=720608
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
vaapidecode hangs when pipeline is stopped without any EOS, e.g. when
<Ctrl>+C is pressed, thus causing the srcpad task to keep running and
locked. This fixes a deadlock on state change from PAUSED to READY.
https://bugzilla.gnome.org/show_bug.cgi?id=720584
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
vaapiencode might hang when the pipeline is stopped without any EOS,
e.g. when <Ctrl>+C is pressed, thus causing the srcpad task to keep
running and locked. This fixes a possible deadlock on state change
from PAUSED to READY.
https://bugzilla.gnome.org/show_bug.cgi?id=720584
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Add gst_vaapi_video_format_new_template_caps_with_features() helper
function to add the supplied caps feature string on GStreamer >= 1.2.
Add gst_vaapi_find_preferred_caps_feature() helper function to discover
the "best" caps feature to use for the supplied pad. In practice, we
will always favor memory:VASurface first, then meta:GLTextureUploadMeta,
and finally the system memory caps.
https://bugzilla.gnome.org/show_bug.cgi?id=719372
The GLTextureUpload function is not in charge of doing the overlay
composition if any.
https://bugzilla.gnome.org/show_bug.cgi?id=721859
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Allow user to precise the largest profile to use for encoding due
to target decoder constraints. For instance, if CABAC entropy coding
mode is requested by "constrained-baseline" profile only is desired,
then an error is returned during codec configuration.
Also make sure that the suitable profile we derived actually matches
what the HW can cope with.
https://bugzilla.gnome.org/show_bug.cgi?id=719694
Various clean-ups to improve consistency and readability: rename some
variables, drop unused macro definitions, drop initialization of vars
that are zero-initialized from the base class, drop un-necessary casts.
Add interface to communicate the encoder resolution and related info
like framerate, interlaced vs. progressive, etc. This new interface
supersedes gst_vaapi_encoder_set_format() and doesn't use any GstCaps
but rather use GstVideoCodecState.
Note that gst_vaapi_encoder_set_codec_state() is also a synchronization
point for codec config. This means that the encoder is reconfigured
there to match the latest properties.
Don't try to destroy an encoder, in GstVideoEncoder::finish() handler,
if it was not created in the first place. Return "not-negotiated" error
since this means we did not even reach GstVideoEncoder::set_format(),
where the encoder could have been created.
This fixes a crash when the vaapiencode_* plug-in elements get deallocated
and that we failed to negotiate either pad.
https://bugzilla.gnome.org/show_bug.cgi?id=719704
The specified caps in gst_video_encoder_set_output_state() function
arguments should not contain any resolution, pixel-aspect-ratio,
framerate, codec-data et al. Those rather should be set through the
returned GstVideoCodecState. This means that output caps creation
could be delayed until before gst_video_encoder_finish_frame() is
called.
This greatly simplifies the GstVideoEncoder::set_format() callback
by the way.
Make base GstVaapiEncode class an abstract type so that we cannot
create an instance from it without going through any of the codec
specific derived class.
Rename a few member functions to make them more consistent:
- alloc_encoder(): now reduced to allocate the encoder object only;
- alloc_buffer(): allocate buffer from srcpad, and copy bitstream.
Update MPEG-2 and H.264 encode elements to cope with the new core
libgstvaapi properties API. i.e. all configurable properties are now
directly handled at the GstVaapiEncoder level.
Besides, this also makes sure to not use or modify the GstVaapiEncoder
private definitions directly. Private data need to remain private.
https://bugzilla.gnome.org/show_bug.cgi?id=719529
Add gst_vaapi_encoder_set_bitrate() interface to allow the user control
the bitrate for encoding. Currently, changing this parameter is only
valid before the first frame is encoded. Should the value be modified
afterwards, then GST_VAAPI_ENCODER_STATUS_ERROR_OPERATION_FAILED is
returned.
https://bugzilla.gnome.org/show_bug.cgi?id=719529
Add gst_vaapi_encoder_set_rate_control() interface to request a new
rate control mode for encoding. Changing the rate control mode is
only valid prior to encoding the very first frame. Afterwards, an
error ("operation-failed") is issued.
https://bugzilla.gnome.org/show_bug.cgi?id=719529
Fixes a crash when multiple vaapidecode elements are finalized since
the debug category is created once in the class init method.
This is a regression from git commit 7e58d60.
https://bugzilla.gnome.org/show_bug.cgi?id=721390
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Fix formts for various GST_DEBUG et al. invocations. More precisely,
make size_t arguments use the %zu format specifier accordingly; force
XID formats to be a 32-bit unsigned integer; and fix the format used
for gst_vaapi_create_surface_with_format() error cases since we have
been using strings nowadays.
Use standard GstVideoInfo related functions to build the output caps,
thus directly preserving additional fields as needed, instead of
manually copying them over through gst_vaapi_append_surface_caps().
Also ensure that the input caps are fixated first.
Add new helper functions to build video template caps.
- gst_vaapi_video_format_new_template_caps():
create GstCaps with size, frame rate and PAR to full range
- gst_vaapi_video_format_new_template_caps_from_list():
try to create a "simplified" list from the supplied formats
Add new helper functions to build GValues from GstVideoFormat:
- gst_vaapi_value_set_format():
build a GValue from the supplied video format
- gst_vaapi_value_set_format_list():
build a GValue list from the supplied array of video formats
Replace gst_vaapi_display_get_{decode,encode}_caps() APIs with more
more convenient APIs that return an array of GstVaapiProfile instead
of GstCaps: gst_vaapi_display_get_{decode,encode}_profiles().
Replace gst_vaapi_display_get_{image,subpicture}_caps() APIs, that
returned GstCaps, with more convenient APIs that return an array of
GstVideoFormat: gst_vaapi_display_get_{image,subpicture}_formats().
Makes the copies of a buffer reference their own GLTextureUploadMeta
user data and prevent the original buffer accessing already freed
memory if its copies has been released and freed.
https://bugzilla.gnome.org/show_bug.cgi?id=720336
[Propagate the original meta texture to the copy too]
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Factor out propose_allocation() hooks, creation of video buffer pool
for the sink pad, conversion from raw YUV buffers to VA surface backed
buffers. Update vaapidecode, vaapiencode and vaapipostproc to cope
with the new GstVaapiPluginBase abilities.
Fix display creation code to check that any display obtained from a
neighbour actually has the type we expect. Note: if display type is
set to "any", we can then accept any VA display type.
Move common VA display creation code to GstVaapiPluginBase, with the
default display type remaining "any". Also add a "display-changed"
hook so that subclasses could perform additional tasks when/if the
VA display changed, due to a new display type request for instance.
All plug-ins are updated to cope with the new internal APIs.
Introduce a new GstVaapiPluginBase object that will contain all common
data structures and perform all common tasks. First step is to have a
single place to hold VA displays.
While we are at it, also make sure to store and subsequently release
the appropriate debug category for the subclasses.
The GLTextureUploadMeta implementation assumed that for each upload()
sequence, the supplied texture id is always the same as the one that
was previously cached into the underlying GstVaapiTexture. Cope with
any texture id change the expense to recreate the underlying VA/GLX
resources.
https://bugzilla.gnome.org/show_bug.cgi?id=719643
