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.
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
Constify pointers wherever possible. Drop unused variables, and use
consistent variable names. Fix gst_vaapiencode_h264_allocate_buffer()
to correctly report errors, especially when in-place conversion from
bytestream to avcC format failed.
Move "rate-control" mode and "bitrate" properties to the GstVaapiEncode
base class. The actual range of supported rate control modes is currently
implemented as a plug-in element hook. This ought to be determined from
the GstVaapiEncoder object instead, i.e. from libgstvaapi.
Align the plug-in debug category to its actual name. i.e. enable debug
logs through vaapiencode_<CODEC> where <CODEC> is mpeg2, h264, etc. Fix
the plug-in element description to make it more consistent with other
VA-API plug-ins.
Add a GST_VAAPIENCODE_CAST() helper to avoid run-time checks against
the GObject type system. We are guaranteed to only deal with the same
plug-in element object.
Allow vaapiencode plug-in elements to encode from raw YUV buffers.
The most efficient way to do so is to let the vaapiencode elements
allocate a buffer pool, and subsequently buffers from it. This means
that upstream elements are expected to honour downstream pools.
If upstream elements insist on providing their own allocated buffers
to the vaapiencode elements, then it possibly would be more efficient
to insert a vaapipostproc element before the vaapiencode element.
This is because vaapipostproc currently has better support than other
elements for "foreign" raw YUV buffers.
Add GstVaapiEncodeMPEG2 element object. The actual plug-in element
is called "vaapiencode_mpeg2".
Valid properties:
- rate-control: rate control mode (default: cqp - constant QP)
- bitrate: desired bitrate in kbps (default: auto-calculated)
- key-period: maximal distance between two key frames (default: 30)
- max-bframes: number of B-frames between I and P (default: 2)
- quantizer: constant quantizer (default: 8)
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
