Some streams, badly constructed, could have signaled an interlaced
frame while the sequence was meant to be progressive. Warn and force
frame to be progressive in this case.
Add first-field (FF) flag to GstVaapiPicture, thus not requiring is_first_field
member in each decoder. Rather, when a GstVaapiPicture is created, it is considered
as the first field. Any subsequent allocated field will become the second field.
Add gst_vaapi_picture_new_field() function that clones a picture, while
preserving the parent picture surface. i.e. the surface proxy reference
count is increased and other fields copied as is. Besides, the picture
is reset into a "non-output" mode.
Add top-field-first (TFF) and interlaced flags to GstVaapiPicture so they
could be propagated to the surface proxy when it is pushed for rendering.
Besides, top and bottom fields are now expressed with picture structure flags
from GstVaapiSurfaceRenderFlags.
If GstVaapiPicture has flag SKIPPED set, this means gst_vaapi_picture_output()
will not push the underlying surface for rendering. Besides, VC-1 skipped P-frame
has nothing to do with rendering. This only means that the currently decoded
picture is just a copy of its reference picture.
Add new "interlaced" attribute to GstVaapiSurfaceProxy. Use this in
vaapipostproc so that to handles cases where bitstream is interlaced
but almost only frame pictures are generated. In this case, we should
not be alternating between top/bottom fields.
Allow rendering flags, as a combination of GstVaapiSurfaceRenderFlags,
to be set to the video buffer. In particular, this is mostly useful for
basic deinterlacing.
Some streams have incorrect GOP timestamps, or nothing set at all.
i.e. GOP time is 00:00:00 for all GOPs. Try to recover in this case
from demuxer timestamps, which are monotonic.
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Skip all pictures prior to the first sequence_header(). Besides,
skip all picture_data() if there was no prior picture_header().
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
VA-API expects slice_vertical_position as the initial position from the
bitstream. i.e. the direct slice() information. VA drivers will be fixed
accordingly.
Unlike what VA-API documentation defines, the slice_data_bit_offset
represents the offset to the first macroblock in the slice data, minus
any emulation prevention bytes in the slice_header().
This fix copes with binary-only VA drivers that won't be fixed any
time soon. Besides, this aligns with the current FFmpeg behaviour
that was based on those proprietary drivers implementing the API
incorrectly.
Original values from sequence_header() are 12-bit and the remaining
2 most significant bits are coming from sequence_extension().
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
6.3.15 says that "some slices may have the same slice_vertical_position,
since slices may start and finish anywhere". So, we can't submit the current
picture to the HW right away since subsequent slices would be missing.
vaRenderPicture() implicitly disposes VA buffers. Some VA drivers would
push the VA buffer object into a list of free buffers to be re-used. However,
reference pictures (and data) that was kept would explicitly release the VA
buffer object later on, thus possibly destroying a valid (re-used) object.
Besides, some other VA drivers don't support correctly the vaRenderPicture()
semantics for VA buffers disposal and would leak memory if there is no explicit
vaDestroyBuffer(). The temporary workaround is to explcitily destroy VA buffers
right after vaRenderPicture(). All VA drivers need to be aligned.
This ensures the VA context is clear when the encoded resolution
changes. i.e. make sure older picture is decoded with the older
VA context before it changes.
On sequence end, if the last decoded picture is not output for rendering,
then the proxy surface is not created. In this case, the original surface
must be released explicitly to the context.
VA drivers may have a faster means to transfer user buffers to GPU
buffers than using memcpy(). In particular, on Intel Gen graphics, we
can use pwrite(). This provides for faster upload of bitstream and can
help higher bitrates.
vaapi_create_buffer() helper function was also updated to allow for
un-mapped buffers and pre-initialized data for buffers.
Only the explicit pred_weight_table(), possibly with the inferred default
values, shall be required. e.g. don't fill in the table if weighted_pred_flag
is not set for P/SP slices.
Keep a valid reference to the proxy in GstVaapiPicture so that frames
marked as "used for reference" could be kept during the lifetime of the
picture. i.e. don't release them too soon as they could be re-used right
away.
Drop obsolete gst_vaapi_decoder_push_surface() that was no longer used.
Change gst_vaapi_decoder_push_surface_proxy() semantics to assume PTS
is already set correctly and reference count increased, if necessary.
The new API simplifies a lot reference counting and makes it more
flexible for future additions/changes. The GstVaapiCodecInfo is
also gone. Rather, new helper macros are provided to allocate
picture, slice and quantization matrix parameter buffers.
HACK: qtdemux does not report profiles for H.263. So, assume plain
"video/x-h263" is H.263 Baseline profile.
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
gst_vaapi_surface_get_parent_context() was not meant to be exposed globally.
It's just an internal helper function. However, it's still possible to get
the parent context through the "parent-context" property.
GST_VAAPI_DECODER_STATUS_ERROR_UNSUPPORTED_PROFILE: for unsupported profile
GST_VAAPI_DECODER_STATUS_ERROR_UNSUPPORTED_CHROMA_FORMAT: for unsupported chroma format
