Add crop-left, crop-right, crop-top and crop-bottom
properties to vaapipostproc.

U. Artie Eoff authored Aug 30, 2019 and Víctor Manuel Jáquez Leal committed Sep 05, 2019

When forwarding crop meta to downstream, the output
buffer and crop meta need to be rotated, too.

Test:
 for i in 90r 180 90l vert horiz ul-lr ur-ll
 do
  gst-launch-1.0 -vf videotestsrc num-buffers=500 \
   ! videocrop top=100 bottom=30 left=40 right=20 \
   ! vaapipostproc video-direction=$i \
   ! vaapisink & \
  gst-launch-1.0 -vf videotestsrc num-buffers=500 \
   ! videocrop top=100 bottom=30 left=40 right=20 \
   ! vaapipostproc video-direction=$i \
   ! identity drop-allocation=true \
   ! vaapisink
 done

U. Artie Eoff authored Aug 30, 2019 and Víctor Manuel Jáquez Leal committed Sep 05, 2019

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

U. Artie Eoff authored Aug 20, 2019 and Víctor Manuel Jáquez Leal committed Aug 30, 2019

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

set_property and get_default_properties functions are no longer
needed for encoder class.

We no longer need this obsolete set_property function now after
switch to standard gobject's property manner.
Also delete the old encoder's property enum in the header file.

Also delete the get_properties function in encode class. We now
use g_object_class_list_properties to get all properties for
internal encoder class.

Use standard gobject's property functions to replace the old way.

No need to init the properties got by get_default_properties func
now. The properties are inited correctly in internal encoder class.

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.

G_PARAM_CONSTRUCT make all properties init correctly, we do not
need to init the properties manually.
G_PARAM_FLAG_VAAPI_ENCODER_EXPOSURE is a vaapi encoder specific
flag, means need to expose the property to according encode class.

Install properties for h264 encoder fei class. Also set the new get/set
property functions for gobject class. Still use the old properties
way now and this new feature will be enabled later.

Install properties for h264 fei encoder class. Also set the new get/set
property functions for gobject class. Still use the old properties
way now and this new feature will be enabled later.

Install properties for vp9 encoder class. Also set the new get/set
property functions for gobject class. Still use the old properties
way now and this new feature will be enabled later.

Install properties for vp8 encoder class. Also set the new get/set
property functions for gobject class. Still use the old properties
way now and this new feature will be enabled later.