The base plugin public API function implementations determine
which pad should be passed to the internal helper functions.
Currently, only the base plugin static sinkpad and static
srcpad are supported/used. However, this change enables future
API functions to be added that can accept a pad (i.e. request pad)
from an element subclass (e.g. a GstVideoAggregator subclass).
Define a struct (GstVaapiPadPrivate) to encapsulate the
pad-specific data (i.e. buffer pool, allocator, info,
caps, etc.).
Add an interface to retrieve the data struct for a given
pad.
Finally, update the base plugin to use the data struct
throughout the implementation.
This will enable us to easily extend the base plugin in the
future to allow for N-to-1 pad subclasses (e.g. overlay/
composite).
We do not need to maintain a standalone list of decoder's output
template for raw formats and that is easy to make mistake(for
example, the AYVU is wrong in that list, should be VUYA).
Just use GST_VAAPI_FORMATS_ALL to replace the raw formats list for
src template.
We need to provide more precise template caps for postproc's src
and sink pads. The GST_VIDEO_FORMATS_ALL make all video formats
available which are really superfluous.
GST_VAAPI_FORMATS_ALL collects all declared formats in video-format
as a caps template string, and make them available in caps with
memory:VASurface feature.
Fixes: #199
When translating navigation x,y coordinates for
video-direction, it is necessary to subtract 1
when using the video dimensions to compute the
new x,y coordinates. That is, a 100x200 image
should map coordinates in x=[0-99],y=[0-199].
This issue was found with unit tests provided
in !182.
Currently the parameter of skin-tone-enhancement filter is forced
to zero. In fact it could be set different value by the user.
So create a new property named as "skin-tone-enhancement-level"
for accepting the used defined parameter value.
At the same time, skin-tone-enhancement is marked as deprecated.
When skin-tone-enhancement-level is set, skin-tone-enhancement
will be ignored.
The expression "len >= 0" is always true since "len"
is an unsigned type. And it is clear that the writers
intention was not to write "len > 0" since we handle
len == 0 in the ensuing "if (len < 3)" conditional
block.
This patch makes use of GST_PARAM_USER_SHIFT to define the internal
param in encoders to decide which parameters to expose. Thus
gstreamer-vaapi will not interfere with any change in GStreamer in the
future.
Also, the internal symbol was change to
GST_VAAPI_PARAM_ENCODER_EXPOSURE to keep the namespacing.
The Mesa Gallium driver is poorly tested currently, leading to bad user
experience for AMD users. The driver can be added back to the white list at
runtime using the GST_VAAPI_ALL_DRIVERS environment variable.
Adding crop meta x,y to w,h only compensates for left,top
cropping. But we also need to compensate for right,bottom
cropping.
The video meta contains the appropriate w,h (uncropped)
values, so use it instead.
Test:
gst-launch-1.0 -vf videotestsrc num-buffers=500 \
! videocrop top=50 bottom=30 left=40 right=20 \
! vaapipostproc ! vaapisink & \
gst-launch-1.0 -vf videotestsrc num-buffers=500 \
! videocrop top=50 bottom=30 left=40 right=20 \
! vaapipostproc ! identity drop-allocation=1 \
! vaapisink
Mapping a pointer event needs to consider both size and
video-direction operations together, not just one or the other.
This fixes an issue where x,y were not being mapped correctly
for 90r, 90l, ur-ll and ul-lr video-direction. In these directions,
the WxH are swapped and GST_VAAPI_POSTPROC_FLAG_SIZE is set. Thus,
the first condition in the pointer event handling was entered and
x,y scale factor were incorrectly computed due to srcpad WxH
swap.
This also fixes all cases where both video-direction and scaling
are enabled at the same time.
Test that all pointer events map appropriately:
for i in `seq 0 7`
do
GST_DEBUG=vaapipostproc:5 gst-launch-1.0 -vf videotestsrc \
! vaapipostproc video-direction=${i} width=300 \
! vaapisink
GST_DEBUG=vaapipostproc:5 gst-launch-1.0 -vf videotestsrc \
! vaapipostproc video-direction=${i} width=300 height=200 \
! vaapisink
GST_DEBUG=vaapipostproc:5 gst-launch-1.0 -vf videotestsrc \
! vaapipostproc video-direction=${i} height=200 \
! vaapisink
GST_DEBUG=vaapipostproc:5 gst-launch-1.0 -vf videotestsrc \
! vaapipostproc video-direction=${i} \
! vaapisink
done
Advertise to upstream that vaapipostproc can handle
crop meta.
When used in conjunction with videocrop plugin, the
videocrop plugin will only do in-place transform on the
crop meta when vaapipostproc advertises the ability to
handle it. This allows vaapipostproc to apply the crop
meta on the output buffer using vaapi acceleration.
Without this advertisement, the videocrop plugin will
crop the output buffer directly via software methods,
which is not what we desire.
vaapipostproc will not apply the crop meta if downstream
advertises crop meta handling; vaapipostproc will just
forward the crop meta to downstream. If crop meta is
not advertised by downstream, then vaapipostproc will
apply the crop meta.
Examples:
1. vaapipostproc will forward crop meta to vaapisink
gst-launch-1.0 videotestsrc \
! videocrop left=10 \
! vaapipostproc \
! vaapisink
2. vaapipostproc will do the cropping
gst-launch-1.0 videotestsrc \
! videocrop left=10 \
! vaapipostproc \
! identity drop-allocation=1 \
! vaapisink
The encoder is a true gstobject now and all the properties are using
gobject's properties mechanism. Add help functions to handle the properties
between encode and encoder class.
The basic idea is mapping the same property between encoder and encode. All
the encoder's properties will have the same name, the same type in encode.
The set/get property function just forward the property setting/getting to
the encoder using the same property name and value. Because the encoder is
created on needed, we need to cache the property setting in encode.
While ensuring the allowed sink pad caps, the filter attributes set
the frame size restriction, but it is not ensured, at that moment,
that the filter is already instantiaded.
In order to silence the glib logs, this patch add only calls
gst_vaapi_filter_append_caps() if the filter is instantiated.
In commit 18031dc6 surface's parent context is not assigned because of
circular references. Since then (2013), there's has no issue with
subpictures attached to a context, the current only users of this API.
This patch cleans up all of related code with the unused surface's
parent context.
This code doesn't define the profile used by the internal encoder, but
it used to "predict" which is going to be used and to get the caps
restrictions.
Before the profile was predicted by checking the donwstream caps, but
sometimes they are not defined, setting an unknown profile. In order
to enhances this situation, the encoder asks to internal encoder if it
has one. If so, it is used.
To ask the internal encoder's profile a new accessor function was
added: gst_vaapi_encoder_get_profile()
Now that vaapipostproc can possible handle video-direction, it
should also handle the image-orientation event from upstream if
video-direction property is set to auto.
It is requiered to know if postproc is capable to change the video
direction before fixating the source caps.
In order to do it, it'ss required to know if there's a functional VPP,
but that's checked at create() vmethod, which occurs after caps
fixating.
This patch checks for a functional VPP at fixate caps and, if so,
checks for the enabled filtes and later do the caps fixations.
If the video direction is unsupported by the driver, an element
warning is posted in the bus to notify the application.
gst_vaapi_enum_type_get_nick() was added in the library thus it can
be used elsewhere. It retrives the nick from an enum gtype.
The main reason to demote the message's level is because it is not an
error, it's a possible output of the trial and there's a code path
that handles it.
Secondly, it's very annoying when using gallium driver for radeon.
Otherwise the queue will swallow all the available decoder's surfaces
reaching a dead-lock.
This setting might impact the bin's peformance, but it's a trade-off.
When the code path goes to push buffers downstream when no surface
available in decoder context, and it fails the code bails out with a
fatal error.
That behavior is wrong, since it shouldn't be fatal. The use case is
when the video stream is disabled.
This patch just ignores the errors in this situation and demotes the
level of a log message.
For surfaces with different chroma type, it is prefer to initialize
a format which chroma type should be same with surface chroma type
instead of using fixed NV12.
When create vaapi surface, it is better to use the chroma type get
from jpeg file instead of using fixed 420 format. And the correct
chroma type can be determined by horizontal_factor/vertical_factor
flags that get from jpegparse.
If the allocation caps and negotiated caps are the same,
then ensure any previously negotiated video info is also
removed. This can occur when multi-resolution video
decoding returns to it's original resolution.
Fixes#170
This fixes a deadlock in gst_vaapiencode_change_state, which was due to
srcpad's chain function was locked waiting for available buffers. Since the
coded buffers in codedbuf_queue become available after sinkpad consume the
encoded frames, Paused -> Ready state change leads to deadlock. Coded buffers
are never consumed and marked free, hence gst_vaapiencode_handle_frame waits for
available buffers and holds the stream_lock of the srcpad.
