Handle raw video buffers that were not created from a VA video buffer
pool. Use the generic GstVideo API to copy buffers in GStreamer 1.0.x
builds instead of the GstVaapiUploader.
https://bugs.freedesktop.org/show_bug.cgi?id=55818
Fix _getcaps() implementation to not report codecs with size information
filled in the returned caps. That's totally useless nowadays. Ideally,
this is a hint to insert a video parser element, thus allowing future
optimizations, but this is not a strict requirement for gstreamer-vaapi,
which is able to parse the elementary bitstreams itself.
https://bugzilla.gnome.org/show_bug.cgi?id=704734
If there is no frame delimiter at the end of the stream, e.g. no
end-of-stream or end-of-sequence marker, and that the current frame
was fully parsed correctly, then assume that last frame is complete
and submit it to the decoder.
https://bugzilla.gnome.org/show_bug.cgi?id=705123
Signed-off-by: Guangxin.Xu <Guangxin.Xu@intel.com>
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
As a last resort, if video processing capabilities (VPP) are not available,
or they did not produce anything conclusive enough, then try to fallback to
the original rendering code path whereby the whole VA surface is rendered
as is, no matter of video cropping or deinterlacing requests.
Note: under those conditions, the visual outcome won't be correct but at
least, something gets displayed instead of bailing out.
Try to use VA/VPP processing capabilities to handle video cropping and
additional rendering flags that may not be directly supported by the
underlying hardware when exposing a suitable Wayland buffer for the
supplied VA surface. e.g. deinterlacing, different color primaries than
BT.601, etc.
Update the frame redraw infrastructure with a new FrameState stucture
holds all the necessary information used to display the next pending
surface.
While we are at it, delay the sync operation down to when it is actually
needed. That way, we keep performing additional tasks meanwhile.
Fix creation of GstVaapiVideoBuffer objects (i) to have that type for real;
and (ii) to correctly extract the GstSurfaceConverter from the video buffer
object meta.
This fixes support for cluttersink with GStreamer 0.10 builds.
Disable video cropping in MPEG-2 codec because it is partially implemented
and actually because nobody implements it that way, and the standard spec
does not specify the display process either anyway.
Most notably, there are two possible use cases for sequence_display_extension()
horizontal_display_size & vertical_display_size: (i) guesstimating the
pixel-aspect-ratio, or (ii) implement some kind of span & scan process
in conjunction with picture_display_extension() information.
https://bugzilla.gnome.org/show_bug.cgi?id=704848
Other GStreamer sinks, like xvimagesink, have a force-aspect-ratio property,
which allows you to say that you don't want the sink to respect aspect
ratio. Add the same property to vaapisink.
http://lists.freedesktop.org/archives/libva/2012-September/001298.html
Signed-off-by: Simon Farnsworth <simon.farnsworth at onelan.co.uk>
Fix GstBaseSink::get_caps() implementation for GStreamer 1.0.X builds
by honouring the filter caps argument. More precisely, this fixes the
following pipeline: gst-launch-1.0 videotestsrc ! vaapisink
https://bugzilla.gnome.org/show_bug.cgi?id=705192
Signed-off-by: Guangxin.Xu <Guangxin.Xu@intel.com>
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
This fixes the following issue:
CC libgstvaapi_0.10_la-gstvaapidecoder_mpeg4.lo
gstvaapidecoder_mpeg4.c:113: error: redefinition of typedef
'GstVaapiDecoderMpeg4Class'
gstvaapidecoder_mpeg4.c:44: note: previous declaration of
'GstVaapiDecoderMpeg4Class' was here
make[5]: *** [libgstvaapi_0.10_la-gstvaapidecoder_mpeg4.lo] Error 1
make[5]: Leaving directory
`/builddir/build/BUILD/gstreamer-vaapi-0.5.5.1/gst-libs/gst/vaapi'
https://bugzilla.gnome.org/show_bug.cgi?id=705148
Add --deinterlace option to enable deinterlacing through explicit VA/VPP
deinterlacing filter. However, if --deinterlace option is not set but the
--deinterlace-flags option is set with "top-field-first", then the very
basic bob deinterlacing filter is set through VA/VPP proc pipeline flags.
Add --denoise option to enable noise reduction with the level specified
as the option value (float). Likewise, add --sharpen option to enable
sharpening.
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Add support for frame cropping through the --crop-rect|-c argument.
The format used is either <WIDTH> 'x' <HEIGHT>, with origin at (0,0) ;
or full specification with '('? <X> ',' <Y> ')'? <WIDTH> 'x' <HEIGHT>.
Add basic deinterlacing support, i.e. bob-deinterlacing whereby only
the selected field from the input surface is kept for the target surface.
Setting gst_vaapi_filter_set_deinterlacing() method argument to
GST_VAAPI_DEINTERLACE_METHOD_NONE means to disable deinterlacing.
Also move GstVaapiDeinterlaceMethod definition from vaapipostproc plug-in
to libgstvaapi core library.
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Add ProcAmp (color balance) adjustments for hue, saturation, brightness
and contrast. The respective range for each filter shall be the same as
for the VA display attributes.
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Sharpening is configured with a float value. The supported range is
-1.0 .. 1.0 with 0.0 being the default, and that means no sharpening
operation at all.
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Noise reduction is configured with a float value. The supported range
is 0.0 .. 1.0 with 0.0 being the default, and that means no denoise
operation at all.
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Add helper functions to ensure an operation VA buffer is allocated to
the right size; that filter caps get parsed and assigned to the right
operation too; and that float parameters are correctly scaled to fit
the reported range from the VA driver.
Add gst_vaapi_video_format_from_string() helper function to convert from
a video format string representation to a suitable GstVideoFormat. This
is just an alias to gst_video_format_from_string() for GStreamer 1.0.x
builds, and a proper iteration over all GstVideoFormat string representations
otherwise for earlier GStreamer 0.10.x builds.
Add helper functions to describe GstVaapiPoint and GstVaapiRectangle
structures as a standard GType. This could be useful to have them
described as a GValue later on.
Don't expose GstVaapiContext APIs and make them totally private to
libgstvaapi core library. That API would also tend to disappear in
a future revision. Likewise, don't expose GstVaapiDisplayCache API
but keep symbols visible so that the various render backends could
share a common display cache implementation in libgstvaapi.
Try to clean-up the documentation from any stale entry too.
Add image_generate_full() function to create interleaved color rectangles.
If flags is zero, the whole frame is generated with a unique pattern. If
flags is non-zero, then each field is handled individually.
On some platforms, vaPutImage() would fail even if it does not involve
color format conversion or scaling, whereas copying raw pixels through
vaDeriveImage() could work instead.
Don't expose functions that reference a GstVaapiImageRaw, those are
meant to be internal only for implementing subpictures sync. Also add
a few private definitions to avoid functions calls for retrieving
image size and format information.
Install a new video converter that supports X11 pixmap targets for X11
backends only, or make the GLX converter creation function chain up to
the X11 converter whenever requested.
Add --pixmap option to test-decode so that to allow copies of VA
surface to an intermediate pixmap and rendering from that pixmap.
Only X11 backends are supported for now.
Use hardware accelerated XRenderComposite() function, from the RENDER
extension, to blit a pixmap to screen. Besides, this can also support
cropping and scaling.
Implement the new render-to-pixmap API. The only supported pixmap format
that will work is xRGB, with native byte ordering. Others might work but
they were not tested.
Add API to transfer VA urfaces to native pixmaps. Also add an API to
render a native pixmap, for completeness. In general, rendering to
pixmap would only be useful to certain VA drivers and use cases on
X11 display servers. e.g. GLX_EXT_texture_from_pixmap (TFP) handled
in an upper layer.
After the code got moved to create the gst_vaapi_create_display() helper,
this comparison was not updated to dereference the newly-created
pointer, so the code was comparing the pointer itself to the type, and
therefore failing to retrieve the VA display.
This fixes the following error (and gets gst-vaapi decoding again):
ERROR vaapidecode gstvaapidecode.c:807:gst_vaapidecode_ensure_allowed_caps: failed to retrieve VA display
https://bugzilla.gnome.org/show_bug.cgi?id=704410
Signed-off-by: Emilio López <emilio@elopez.com.ar>
