New plugin with an element for H.264 decoding with VA-API. This novel
approach, different from gstreamer-vaapi, uses gstcodecs library for
state handling.
The code is expected to looks cleaner because it uses VA-API without
further layers or wrappers.
* It uses the first supported DRM device as default VA display (other
displays will be supported through user's GstContext)
* Requires libva >= 1.6
* No multiview/stereo profiles neither interlaced streams because
gstcodecs doesn't handle them yet
* It is incompatible with gstreamer-vaapi
* Even if memory:VAMemory is exposed, it is not handled yet by any
other element
* Caps templates are generated dynamically querying VAAPI, but YV12
and I420 are added for system memory caps because they seem to be
supported for all the drivers when downloading frames onto main
memory, as they are used by xvimagesink and others, avoiding color
conversion.
* Surfaces aren't bounded to context, so they can grow beyond the DBP
size, allowing smooth reverse playback.
* There isn't yet error handling and recovery.
* 10-bit H.264 streams aren't supported by libva.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1379>
There are some streams, with HRD, where the the calculated
max_dpb_frames is zero (max_dpb_mbs is less than size mb). In order to
get the dbp size it is required to rely on the VUI parameters if they
are present.
According to the spec Annex E.2.1
**max_dec_frame_buffering** specifies the required size of the HRD
decoded picture buffer (DPB) in units of frame buffers. It is a
requirement of bitstream conformance that the coded video sequence
shall not require a decoded picture buffer with size of more than
Max(1, max_dec_frame_buffering) frame buffers to enable the output of
decoded pictures at the output times specified by dpb_output_delay of
the picture timing SEI messages. The value of max_dec_frame_buffering
shall be greater than or equal to max_num_ref_frames. An upper bound
for the value of max_dec_frame_buffering is specified by the level
limits in clauses A.3.1, A.3.2, G.10.2.1, and H.10.2.
When the max_dec_frame_buffering syntax element is not present, the
value of max_dec_frame_buffering shall be inferred as follows:
– If profile_idc is equal to 44, 86, 100, 110, 122, or 244 and
constraint_set3_flag is equal to 1, the value of
max_dec_frame_buffering shall be inferred to be equal to 0.
– Otherwise (profile_idc is not equal to 44, 86, 100, 110, 122, or 244
or constraint_set3_flag is equal to 0), the value of
max_dec_frame_buffering shall be inferred to be equal to MaxDpbFrames.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1381>
keys_exported flag should be set only if keys are actually exported.
For that the next conditions are needed:
1 - SSL_export_keying_material on success
2 - SSL_get_selected_srtp_profile returns a valid profile
3 - The profile ID is SRTP_AES128_CM_SHA1_80 or SRTP_AES128_CM_SHA1_32
Also don't crash if NULL is returned as profile.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1156>
Current shader code is not compatible with HLSL profile "ps_4_0_level_9_3"
or lower. So d3dcompiler cannot compile our shader code in that case.
Note that VirtualBox is one known driver which doesn't support currently
implemented shader code.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1343>
Try to negotiate if the framerates on either sides of the interlace are
decided using capsfilters and the framerates are correct. Otherwise the
following pipelines would fail to negotiate:
gst-launch-1.0 videotestsrc !
video/x-raw,framerate=24/1,interlace-mode=progressive ! interlace
field-pattern=2 ! video/x-raw,framerate =30/1 ! fakesink
gst-launch-1.0 videotestsrc !
video/x-raw,framerate=60/1,interlace-mode=progressive ! interlace
field-pattern=0 ! video/x-raw,framerate=30/1 ! fakesink
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1349>
This reverts commit b75a61342f.
The parser would only set the mode to progressive or mixed, missing the
cases where it should have been interleaved. Interleaved is more
difficult to detect because in h264 it happens per frame. On the other
hand, h264 decoders detect the interlacing information per-frame and set
the caps correctly. By giving potentially incorrect interlacing
information in the parser already, it's being enforced downstream even
after decoding, breaking some use cases (e.g. an encoder can't properly
mark the stream as TFF or BFF). On the other hand, there's no valid use
case for having interlacing information on the caps at the parsing
stage, so after a lot of discussion, it was decided to revert this.
Initial commit message:
=========================
Those are the rules:
In the SPS:
* if frame_mbs_only_flag=1 => all frame progressive
* if frame_mbs_only_flag=0 => field_pic_flag defines if each frame is
progressive or interlaced, thus the mode is 'mixed' in GStreamer
terms.
https://bugzilla.gnome.org/show_bug.cgi?id=779309
=========================
Fixes#1313
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1335>
