Those messagse should be attached to the object, also the lack of
caps is not an error, in particular in the case of JPEG encoding.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=744042
When we query for the VAConfigAttribEncJPEG, we get a value which packs the
VAConfigAttribValEncJPEG structure, but we did not assign it. This patch
assigns the returned value to the attribute.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=744042
Framerate 0/1 is valid, and it is particularly useful for picture
encoding, such as jpeg. This patch makes the encoder to admit that
framerate.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=744042
Working on bug #744042 I realized that the gstvaapiuploader is practically not
used.
This patch removes the gstvaapiuploader and add the method
gst_vaapi_plugin_base_get_allowed_raw_caps () that returns the raw caps that
the system can handle, which is used by vaapisink and vaapipostproc.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=752777
When seeking, the decoder is reset, but the buffer pool is not
re-negotiated, but in reset_full() the code forgets if the negotiated buffer
pool has the GLTextureUpload meta.
The decoder knows that GLTextureUpload meta was negotiated in
decide_allocation(), but this method is not called when seeking.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=752929
gst_pad_get_allowed_caps() query the pad and the peer pad. In the case
decoders, that is OK, but in the case of the postproc might lead loops,
since the gst_base_transform_query_caps() forwards the query upstream
and forth.
Instead of gst_pad_get_allowed_caps() we only query the peer with
gst_pad_peer_query_caps() using the pad's template as filter.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=752558
All API/ABI changes for S3D/MVC are added in 1.5, backporting
them to older verison is not recommended.
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
ed13220: mpegvideometa: add meta transform function
18d5efd: codecparsers: jpeg: add some padding to ScanHdr struct
7a51722: codecparsers: jpeg: fix docs for table parsing functions
06b8ded: codecparsers: jpeg: fix validity checking of data parsed
387a39d: codecparsers: jpeg: fix up API
db9d6a9: codecparsers: jpeg: tweak API a little
bb6951e: codecparsers: jpeg: hide gst_jpeg_scan_for_marker_code()
f33c30c: codecparsers: jpeg: fix and optimize scan for next marker code
4658c30: codecparsers: jpeg: fix calculation of segment size
759bcb9: codecparsers: jpeg: fix default Huffman tables generation
b4811ee: codecparsers: jpeg: add JPEG bitstream parser
9422464: h264parse: fix typo in log message
9e793a0: h264parse: Move PAR calcs, and use them for stereoscopic half-aspect
77704ce: nalutils: trivial patch to check if
8bb9249: codecparsers: mpeg4: actually return full number of bits of resync marker
7862f95: Revert "codecparsers: remove ignored increment of return"
54017b1: h264parse: Add support for passing stereoscopic/multiview info
8667ee4: h264parse: Don't switch to passthrough on set_caps()
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
Improve closure of gaps in frame_num by strictly following and trying
to fill them with previous reference frames. So, they are now tracked
thus avoiding insertion of dummy ("greenish") frames.
If the new picture to be added to the DPB is not a first field, then
it shall be the second field of the previous picture that was added
before.
This removes the need for dpb_find_picture() now that we track the
immediately preceding decoded picture, in decode order.
When a dummy "other-field" is inserted, it is assumed to inherit the
reference flags from the first field, and the sliding window decoded
reference picture marking process is also executed so that corrupted
frames are moved out as early as possible.
While doing so, we also try to output frames that now contain a single
valid field picture, prior to inserting any other picture into the DPB.
Note: this may be superfluous currently based on the fact that dpb_add()
combines the two most recent pairable fields, but this process would be
further simplified later on.
Mark the picture as "corrupted" if it is reconstructed from corrupted
references or if those references are fake, e.g. resulting from lost
frames.
This is useful for notifying the upper layer, or downstream elements,
that the decoded frame may contain artefacts.
https://bugzilla.gnome.org/show_bug.cgi?id=703921
Add initial infrastructure in core codec library and vaapidecode to mark
corrupted frames as such. A corrupted frame is such a frame that was
reconstructed from invalid references for instance.
https://bugzilla.gnome.org/show_bug.cgi?id=751434
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
This patch fix the auto-plugging problem in gstreamer 1.2 and gstreamer 1.4
Right now there is not a primary ranked parser for vc1 and the demuxers
delivers caps without specifying the profile. This situation is not an issue
for avdec_vc1 but for vaapidecode it is, which refuses to negotiate without a
explicit profile defined in the negotiated caps.
Nonetheless, in gstreamer 1.5 it seems not to be a problem since the
negotiation admits caps subsets try outs.
This patch solves the issue ignoring the profile negotiation in the caps. For
gstreamer < 1.5 the profile string is not handled, so the auto-plugging get
done without the vc1 parser, such as happens in gstreamer 1.5.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
Unfortunately vaapidecodebin element is not seems to be stable
enough for autoplugging ahead of vaapidecode.
Lowering the rank for now (cosidering the immediate 0.6 release).
See this: https://bugzilla.gnome.org/show_bug.cgi?id=749554
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
Fix the regression introduced in commit eb465fb.
VAProcFilterSkinToneEnhancement is avaialbe from VA >= 0.36.
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
One buffering_period() SEI message shall be present in every IDR access unit
when NalHrdBpPresentFlag is inferred to be equal to 1. This is the case when we
use a non-CQP mode, e.g. CBR. In other words, when
nal_hrd_parameters_present_flag is set to 1.
One picture_timing() SEI messages shall be present in every access unit
if CpbDpbDelaysPresentFlag is equal to 1 or pic_struct_present_flag is equal to 1
https://bugzilla.gnome.org/show_bug.cgi?id=722734https://bugzilla.gnome.org/show_bug.cgi?id=751831
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
When the system is aware that VPP is not available by the VA driver,
it would be useful to notify to the user that the disable-vpp property
has changed.
https://bugzilla.gnome.org/show_bug.cgi?id=749554
Instead of creating and adding VPP into the bin at setup, we wait until
we are sure the VA driver supports it. We know that when the VA video
context is received by the bin. Afterwards, it is decided to instanciate
and link the VPP or not.
This is more efficient and safer than waiting the VPP to fail and then
disable it.
https://bugzilla.gnome.org/show_bug.cgi?id=749554
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
