Adding a new propery "disable-vpp", enabling it will prevent
the insertion of vaapipostproc child element.
This is helpful in debugging, specifically to narrow-down the
vaapidecodebin/vaapipostproc related negotiation issues.
No support for run-time disabling for now.
https://bugzilla.gnome.org/show_bug.cgi?id=745901
The Current code path is falling back to passthorugh mode if there is no
vpp property set by the user explictily. But we should not use the
passthrough mode if the negotiated src pad caps have a differnt color space
format than sink pad caps (Even though the user didn't set the format property
explicitly).
https://bugzilla.gnome.org/show_bug.cgi?id=748184
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
This is a workaround to deal with the va-intel-driver for non-native
formats while doing advanced deinterlacing. The format of reference surfaces must
be same as the format used by the driver internally for motion adaptive
deinterlacing and motion compensated deinterlacing.
A permanent solution could be to do the color space conversion internally
for reference surfaces.
https://bugzilla.gnome.org/show_bug.cgi?id=730925
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
vaapisink takes the display lock, then does a gst_buffer_replace which can
take the lock on the gst_vaapi_video_pool.
vaapipostproc asks the gst_vaapi_video_pool for a new surface. This takes
the lock on the gst_vaapi_video_pool; if you're unlucky, there are no free
surfaces, which means that gst_vaapi_surface_create is
called. gst_vaapi_surface_create takes the display lock.
If vaapisink and vaapipostproc are in different threads, and this happens,
you get a deadlock. vaapisink holds the display lock, and wants the
gst_vaapi_video_pool lock. vaapipostproc holds the gst_vaapi_video_pool lock
and wants the display lock.
Work around this by releasing the display lock in vaapisink around the
gst_buffer_replace.
https://bugzilla.gnome.org/show_bug.cgi?id=738249
Signed-off-by: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
This patch enhance the code path when an error is found when rendering a
buffer.
If the video meta doesn't contain a surface proxy or a surface, a warning
message is printed.
If the rendering backend fails, a error message is posted in the bus.
https://bugzilla.gnome.org/show_bug.cgi?id=749382
This fixes the regression introduced in 64acc74.
If a pad supports multiple set of capsfeatures, it needs to add
multiple equal structures with different feature sets to the caps.
Because caps structures with the same name but with a non-equal
set of caps features are not compatible.
Without this patch, playbin will autoplug xvimagesink instead of vaapisink.
https://bugzilla.gnome.org/show_bug.cgi?id=750095
This is a work-around to satisfy the va-intel-driver.
Normalize the quality factor and scale QM values (only for packed header
generation) similar to what VA-Intel driver is doing . Otherwise the
generated packed headers will be wrong, since the driver itself is
scaling the QM values using the normalized quality factor.
https://bugzilla.gnome.org/show_bug.cgi?id=748335
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
Fix uninitialized variables when decoding SPS and PPS NAL units from
"codec-data" buffers. This is particularly important when seeking ops
are involved, and the new persistent states are used more often.
https://bugzilla.gnome.org/show_bug.cgi?id=750094
This is a naïve approach to the calculation of the VA-API decoding latency. It
takes into consideration when the frame-rate has some insane value.
https://bugzilla.gnome.org/show_bug.cgi?id=740419
The approximation of 6 times compression ratio migh not
work in all cases. Especially when enabling I frames.
Provide large enough size for coded-buffer creation.
The approximation of 4 times compression ratio will not
work in all cases. Especially when enabling I frames.
Provide large enough size for coded-buffer creation.
Implement decoding process for gaps in frame_num (8.5.2). This
also somewhat supports unintentional loss of pictures.
https://bugzilla.gnome.org/show_bug.cgi?id=745048https://bugzilla.gnome.org/show_bug.cgi?id=703921
Original-patch-by: Wind Yuan <feng.yuan@intel.com>
[fixed derivation of POC, ensured clone is valid for reference,
actually fixed detection of gaps in FrameNum by PrevRefFrameNum]
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Try to identify missing first fields too, thus disregarding any
intermediate gaps in frames. We also assume that we keep the same
field sequence, i.e. if previous frames were in top-field-first
(TFF) order, then so are subsequent frames.
Note that insertion of dummy first fields need to operate in two
steps: (i) create the original first field that the current field
will inherit from, and (ii) submit that field into the DPB prior
to initializing the current (other) field POC values but after any
reference flag was set. i.e. copy reference flags from the child
(other field) to the parent (first field).
https://bugzilla.gnome.org/show_bug.cgi?id=745048
Interlaced H.264 video frames always have two fields to decode and
display. However, in some cases, e.g. packet loss, one of the field
can be missing. This perturbs the reference picture marking process,
whereby the number of references available in DPB no longer matches
the expected value.
This patch adds initial support for missing field within a decoded
frame. The current strategy taken is to find out the nearest field,
by POC value, and with the same parity.
https://bugzilla.gnome.org/show_bug.cgi?id=745048
Try to maintain a "top-field-first" (TFF) flag, even if the H.264 standard
does not mandate it. This will be useful for tracking missing fields, and
also for more correct _split_fields() implementation for frames in the DPB.
Don't try to decode pictures until the first I-frame is received within
the currently active sequence. There is no point is decoding and then
displaying frames with artifacts.
Fix decoding of end_of_seq() NAL unit so that to not submit the current
picture for decoding again. This is pretty vintage code that dates back
before the existing of the whole decoder units machinery.
One issue that could be arising if that code was kept is that we could
have submitted a picture, and subsequently a GstVideoCodec frame, twice.
Once without the decode_only flag set, and once with that flag set. The
end result is that the GstVideoDecoder would release the codec frame
twice, thus releasing stale data.
In short, the piece of code that is removed by this patch is for once
completely obsolete for a while, and secondly error-prone in corner
cases.
If the GOP temporal sequence number (TSN) is interpolated from a valid
PTS, then we need to compensate that PTS corresponding to the start of
GOP with the next picture to be decoded, which shall be an I-frame,
based on its sequence number.
https://bugzilla.gnome.org/show_bug.cgi?id=748676
b7dded3: h264parse: don't consider unknown stream-format as avc
5110ad9: h264parse: fix up handling of input caps corner cases
e51db3e: h264parse: Remove dead code
3d739d0: codecparser: h265: Fix the number of tile rows/columns parsing
8482957: h265parse: Fix profile, tier and level setting in caps
4649acb: h265parse: Fix the memory freeing of stored VPS nals
f2beeb7: h265parse: Fix source caps to report cropped dimensions
6886a31: h264parse: Fix profile and level setting in caps
5286c1a: h264parse: Consider SEI NALU as "HEADER" packets
eb97854: videoparsers: h264: bit-exact sync with upstream, minor changes here and there
53074fc: build: Upgrade GStreamer dependency to 1.0
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
