- 08 Oct, 2017 3 commits
-
-
Mark Thompson authored
Uses vaExportSurfaceHandle() from libva2.
-
Mark Thompson authored
The message callbacks are library-safe in libva2, so we can now use them.
-
Mark Thompson authored
This was duplicated between normal device creation and creation by derivation from a DRM device.
-
- 19 Sep, 2017 1 commit
-
-
Mark Thompson authored
-
- 14 Sep, 2017 1 commit
-
-
Jun Zhao authored
Signed-off-by: Jun Zhao <jun.zhao@intel.com> Signed-off-by: Mark Thompson <sw@jkqxz.net>
-
- 13 Sep, 2017 1 commit
-
-
Mark Thompson authored
-
- 14 Jun, 2017 1 commit
-
-
Mark Thompson authored
The driver is somewhat bitrotten (not updated for years) but is still usable for decoding with this change. To support it, this adds a new driver quirk to indicate no support at all for surface attributes. Based on a patch by wm4 <nfxjfg@googlemail.com>. (cherry picked from commit e791b915)
-
- 29 May, 2017 1 commit
-
-
Elviss Strazdins authored
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
-
- 02 Mar, 2017 1 commit
-
-
Mark Thompson authored
Cherry-picked from Libav d30719e6. Signed-off-by: wm4 <nfxjfg@googlemail.com>
-
- 13 Feb, 2017 1 commit
-
-
Mark Thompson authored
The driver is somewhat bitrotten (not updated for years) but is still usable for decoding with this change. To support it, this adds a new driver quirk to indicate no support at all for surface attributes. Based on a patch by wm4 <nfxjfg@googlemail.com>.
-
- 05 Feb, 2017 1 commit
-
-
Mark Thompson authored
The original code is correctly following the API - vaTerminate() must be called to free the resources of a VADisplay after it is created by any of the vaGetDisplay*() calls; it is not necessary to have successfully called vaInitialize() on it. The segfaults which prompted this change must therefore be bugs in libva or the driver it loads. This reverts commit 3606602f.
-
- 02 Feb, 2017 1 commit
-
-
Aman Gupta authored
Program terminated with signal SIGSEGV, Segmentation fault. #0 0x0000000000aff8a4 in vaTerminate () #1 0x0000000000ae50ce in vaapi_device_free (ctx=<optimized out>) at libavutil/hwcontext_vaapi.c:882 #2 0x0000000000ae1f9e in hwdevice_ctx_free (opaque=<optimized out>, data=<optimized out>) at libavutil/hwcontext.c:66 #3 0x0000000000ad856f in buffer_replace (src=0x0, dst=0x7fffa26ef1b8) at libavutil/buffer.c:119 #4 av_buffer_unref (buf=buf@entry=0x7fffa26ef1f8) at libavutil/buffer.c:129 #5 0x0000000000ae299f in av_hwdevice_ctx_create (pdevice_ref=0x170ac50 <hw_device_ctx>, type=type@entry=AV_HWDEVICE_TYPE_VAAPI, device=<optimized out>, opts=opts@entry=0x0, flags=flags@entry=0) at libavutil/hwcontext.c:494 #6 0x0000000000400968 in vaapi_device_init (device=<optimized out>) at ffmpeg_vaapi.c:223 Signed-off-by: Mark Thompson <sw@jkqxz.net>
-
- 01 Feb, 2017 1 commit
-
-
Anton Khirnov authored
-
- 26 Nov, 2016 1 commit
-
-
Mark Thompson authored
-
- 13 Nov, 2016 3 commits
-
-
Anton Khirnov authored
The Intel binary iHD driver does not support the VASurfaceAttribMemoryType, so surface allocation will fail when using it. (cherry picked from commit 2124711b)
-
Mark Thompson authored
If no string argument is supplied when av_hwdevice_ctx_create() is called to create a VAAPI device, we currently only try the default X11 display (that is, $DISPLAY) to find a device, and will therefore fail in the absence of an X server to connect to. Change the logic to also look for a device via the first DRM render node (that is, "/dev/dri/renderD128"), which is probably the right thing to use in most simple configurations which only have one DRM device. (cherry picked from commit 121f34d5)
-
Mark Thompson authored
The driver being used is detected inside av_hwdevice_ctx_init() and the quirks field then set from a table of known device. If this behaviour is unwanted, the user can also set the quirks field manually. Also adds the Intel i965 driver quirk (it does not destroy parameter buffers used in a call to vaRenderPicture()) and detects that driver to set it. (cherry picked from commit 4926fa9a)
-
- 03 Nov, 2016 1 commit
-
-
Mark Thompson authored
Can map to any supported software format (using a GPU copy if it doesn't actually match the surface format underneath).
-
- 02 Oct, 2016 2 commits
-
-
Mark Thompson authored
This is required for 10-bit surfaces.
-
Anton Khirnov authored
The Intel binary iHD driver does not support the VASurfaceAttribMemoryType, so surface allocation will fail when using it.
-
- 13 Aug, 2016 1 commit
-
-
Mark Thompson authored
If no string argument is supplied when av_hwdevice_ctx_create() is called to create a VAAPI device, we currently only try the default X11 display (that is, $DISPLAY) to find a device, and will therefore fail in the absence of an X server to connect to. Change the logic to also look for a device via the first DRM render node (that is, "/dev/dri/renderD128"), which is probably the right thing to use in most simple configurations which only have one DRM device.
-
- 02 Aug, 2016 1 commit
-
-
Carl Eugen Hoyos authored
Fixes ticket #5484.
-
- 02 Jul, 2016 1 commit
-
-
Mark Thompson authored
The driver being used is detected inside av_hwdevice_ctx_init() and the quirks field then set from a table of known device. If this behaviour is unwanted, the user can also set the quirks field manually. Also adds the Intel i965 driver quirk (it does not destroy parameter buffers used in a call to vaRenderPicture()) and detects that driver to set it.
-
- 28 Jun, 2016 1 commit
-
-
Mark Thompson authored
The hw frame used as reference has an attached size but it need not match the actual size of the surface, so enforcing that the sw frame used in copying matches its size exactly is not useful. Signed-off-by: Anton Khirnov <anton@khirnov.net>
-
- 21 Jun, 2016 1 commit
-
-
Mark Thompson authored
No longer make a dummy device configuration to query. Instead, just return everything we recognise from the whole format list. Also change the device setup code to query that list only, rather than intersecting it with the constraint output. This makes hwupload more usable on mesa/gallium where the video processor only declares support for RGB formats, making it unable to deal with YUV formats before this patch. It might introduce some different trickier failures in the internal upload/download code because the set of allowed formats there has changed, though I didn't find any obvious regressions with i965.
-
- 01 Jun, 2016 1 commit
-
-
Mark Thompson authored
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
- 26 May, 2016 1 commit
-
-
Anton Khirnov authored
-
- 19 Mar, 2016 1 commit
-
-
Mark Thompson authored
Signed-off-by: Anton Khirnov <anton@khirnov.net>
-