Re: [libav-devel] [PATCH 09/14] svq3: Change type of array stride parameters to ptrdiff_t

On 20/09/16 19:36, Diego Biurrun wrote: > ptrdiff_t is the correct type for array strides and similar. > --- > libavcodec/svq3.c | 18 +- > 1 file changed, 9 insertions(+), 9 deletions(-) > > diff --git a/libavcodec/svq3.c b/libavcodec/svq3.c > index aa85e7c..bd83731 100644 > ---

Re: [libav-devel] [Libav-devel][Patch] hwupload_cuda - Add P010 and YUV444P16 pixel format

On 19/09/16 15:38, Yogender Gupta wrote: > Added support for P010 and YUV444P16 pixel formats to hwupload_cuda. While it adds support usable from hwupload_cuda, the patch is to hwcontext_cuda - the title and commit message probably want to be corrected. Patch itself LGTM. Thanks, - Mark

[libav-devel] [PATCH 3/3] vaapi_encode: Sync to input surface rather than output

While outwardly bizarre, this change makes the behaviour consistent with other VAAPI encoders which sync to the encode /input/ picture in order to wait for /output/ from the encoder. It is not harmful on i965 (because synchronisation already happens in vaRenderPicture(), so it has no effect

[libav-devel] [PATCH 2/3] vaapi_encode: Check packed header capabilities

This improves behaviour with drivers which do not support packed headers, such as AMD VCE on mesa/gallium. --- libavcodec/vaapi_encode.c | 36 +--- libavcodec/vaapi_encode.h | 3 +++ libavcodec/vaapi_encode_h264.c | 4

[libav-devel] [PATCH 1/3] vaapi_encode: Refactor initialisation

This allows better checking of capabilities and will make it easier to add more functionality later. It also commonises some duplicated code around rate control setup and adds more comments explaining the internals. --- libavcodec/vaapi_encode.c | 253

[libav-devel] [PATCH] hwcontext_vdpau: Fix missing subscripts

Also remove the redundant casts which were hiding the error here. --- On 14/09/16 12:33, Diego Biurrun wrote: > On Tue, Sep 13, 2016 at 08:45:55PM +0100, Mark Thompson wrote: >> --- a/libavutil/hwcontext_vdpau.c >> +++ b/libavutil/hwcontext_vdpau.c >> @@ -304,7

[libav-devel] [PATCH] vf_scale_vaapi: Crop input surface to active region

If the input has been decoded from a stream which uses edge cropping then the whole surface need not be valid. This defines an input region for the scaler so we only use the active area of the frame. --- Visible at the bottom of the frame with a 1080p input video. (I noticed the effect of this

[libav-devel] [PATCH 2/2] hwcontext_vdpau: Fix missing subscript

--- And this part fixes a typo with a missiny array subscript. It was hidden by the explicit cast, which works on the pointer as well. libavutil/hwcontext_vdpau.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavutil/hwcontext_vdpau.c b/libavutil/hwcontext_vdpau.c index

[libav-devel] [PATCH 1/2] hwcontext_vdpau: Remove duplicate definition of GET_CALLBACK

--- On 13/09/16 09:58, Luca Barbato wrote: > On 12/09/16 23:44, Mark Thompson wrote: >> Typo: linesize should be linesize[i], but the error is hidden by the >> explicit cast. Probably invisible because AVFrame has to be heap-allocated >> and is small, so it will alway

[libav-devel] [PATCH] vaapi_h264: Fix HRD bit_rate/cpb_size scaling

There should be an extra offset of 6 on bit_rate_scale and of 4 on cpb_size_scale which were not accounted for here (see H.264 E.2.2). --- libavcodec/vaapi_encode_h264.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/libavcodec/vaapi_encode_h264.c

[libav-devel] [PATCH] hwcontext_vdpau: Fix warning and typo

--- Warning: GET_CALLBACK is redefined with a subtle difference; just make them the same and remove the second definition. Typo: linesize should be linesize[i], but the error is hidden by the explicit cast. Probably invisible because AVFrame has to be heap-allocated and is small, so it will

[libav-devel] [PATCH] vaapi_vp8: Explicitly include libva vp8 decode header

With some old libva versions does not automatically include the per-codec subsidiary headers, so we need to include the right one explicitly ourselves. --- FATE has one of these versions. Apparently testing the oldest (fails the configure test) and the newest (all works) libva versions is not

Re: [libav-devel] [PATCH 1/3] vp8: Add hwaccel hooks

On 08/09/16 11:33, Hendrik Leppkes wrote: > On Thu, Sep 8, 2016 at 7:17 AM, Anton Khirnov <an...@khirnov.net> wrote: >> Quoting Mark Thompson (2016-09-06 22:53:18) >>> @@ -2480,6 +2514,20 @@ int vp78_decode_frame(AVCodecContext *avctx, void >>> *data, int

Re: [libav-devel] [PATCH 2/3] lavc/vaapi: Add VP8 decode hwaccel

On 06/09/16 21:54, Mark Thompson wrote: > --- > configure | 2 + > libavcodec/Makefile| 1 + > libavcodec/allcodecs.c | 1 + > libavcodec/vaapi_vp8.c | 231 > + > libavcodec/vp8.c | 3 + &g

[libav-devel] [PATCH 3/3] vaapi_decode: Ignore the profile when not useful

Enables VP8 decoding - the decoder places the the bitstream version in the profile field, which we want to ignore. --- libavcodec/vaapi_decode.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/libavcodec/vaapi_decode.c b/libavcodec/vaapi_decode.c index 51b6d47..ab8445a

[libav-devel] [PATCH 2/3] lavc/vaapi: Add VP8 decode hwaccel

--- configure | 2 + libavcodec/Makefile| 1 + libavcodec/allcodecs.c | 1 + libavcodec/vaapi_vp8.c | 231 + libavcodec/vp8.c | 3 + 5 files changed, 238 insertions(+) create mode 100644 libavcodec/vaapi_vp8.c diff

[libav-devel] [PATCH 1/3] vp8: Add hwaccel hooks

Also adds some extra fields to the main context structure that may be needed by a hwaccel decoder. --- v2: review comments incorporated. On 06/09/16 09:57, Anton Khirnov wrote: > Quoting Mark Thompson (2016-09-04 14:43:21) >> @@ -313,13 +336,19 @@ static void get_quants(VP8C

[libav-devel] [PATCH] configure: Don't silently disable explicitly-enabled VAAPI

--- On 05/09/16 12:10, Diego Biurrun wrote: > Module: libav > Branch: master > Commit: 2610c9528f86286e4c6e174411a26ff5b4815cde > > Author:Diego Biurrun > Committer: Diego Biurrun > Date: Tue Mar 17 13:12:41 2015 +0100 > > configure: Move initial

Re: [libav-devel] [PATCH 2/3] lavc/vaapi: Add VP8 decode hwaccel

On 04/09/16 14:49, Diego Biurrun wrote: > On Sun, Sep 04, 2016 at 01:46:37PM +0100, Mark Thompson wrote: >> --- /dev/null >> +++ b/libavcodec/vaapi_vp8.c >> @@ -0,0 +1,225 @@ >> +/* >> + * This file is part of FFmpeg. > > Nah ;) Oops, fixed. (Much of

[libav-devel] [PATCH 3/3] vaapi_decode: Ignore the profile when not useful

Enables VP8 decoding - the decoder places the the bitstream version in the profile field, which we want to ignore. --- An alternative would be defining FF_PROFILE_VP8_VERSION[0-3] in avcodec.h and then using those here, but I think that is worse. libavcodec/vaapi_decode.c | 3 ++- 1 file

[libav-devel] [PATCH 2/3] lavc/vaapi: Add VP8 decode hwaccel

--- Tested on Skylake. Passes the conformance tests, except for 6 and 14 (the ones with odd frame dimensions). configure | 2 + libavcodec/Makefile| 1 + libavcodec/allcodecs.c | 1 + libavcodec/vaapi_vp8.c | 225 + 4 files

[libav-devel] [PATCH 1/3] vp8: Add hwaccel hooks

Also adds some extra fields to the main context structure that may be needed by a hwaccel decoder. --- libavcodec/vp8.c | 190 +++ libavcodec/vp8.h | 25 2 files changed, 162 insertions(+), 53 deletions(-) diff --git

Re: [libav-devel] [PATCH 5/8] lavu: OpenCL hwcontext implementation

On 30/08/16 10:08, Diego Biurrun wrote: > On Tue, Aug 30, 2016 at 12:51:24AM +0100, Mark Thompson wrote: >> --- a/configure >> +++ b/configure >> @@ -4675,6 +4677,10 @@ enabled omx && { check_header >> OMX_Core.h || >>

Re: [libav-devel] [PATCH 7/8] hwcontext_opencl: OpenCL <-> VAAPI mapping for Intel platforms

On 30/08/16 00:53, Mark Thompson wrote: > --- > configure| 5 + > libavutil/hwcontext_opencl.c | 335 > +++ > 2 files changed, 340 insertions(+) > > diff --git a/configure b/configure > index f32f505..4d08c6a

Re: [libav-devel] [PATCH 1/8] hwcontext: Hardware frame mapping

On 30/08/16 09:58, Diego Biurrun wrote: > On Tue, Aug 30, 2016 at 12:47:41AM +0100, Mark Thompson wrote: >> --- a/libavutil/hwcontext.c >> +++ b/libavutil/hwcontext.c >> @@ -495,3 +495,98 @@ fail: >> +static void ff_hwframe_unmap(void *opaque, uint8_t *data) >> +{

[libav-devel] [PATCH 8/8] avconv: Trivial support for making an OpenCL device

Creates the device to use with the hwupload filter. --- Makefile| 1 + avconv.h| 1 + avconv_opencl.c | 37 + avconv_opt.c| 15 +++ 4 files changed, 54 insertions(+) create mode 100644 avconv_opencl.c diff --git a/Makefile

[libav-devel] [PATCH 7/8] hwcontext_opencl: OpenCL <-> VAAPI mapping for Intel platforms

--- configure| 5 + libavutil/hwcontext_opencl.c | 335 +++ 2 files changed, 340 insertions(+) diff --git a/configure b/configure index f32f505..4d08c6a 100755 --- a/configure +++ b/configure @@ -1672,6 +1672,7 @@ HAVE_LIST="

[libav-devel] [PATCH 6/8] lavfi: Add filter to run an arbitrary OpenCL kernel on frames

--- configure | 1 + libavfilter/Makefile| 1 + libavfilter/allfilters.c| 1 + libavfilter/vf_opencl_program.c | 406 4 files changed, 409 insertions(+) create mode 100644 libavfilter/vf_opencl_program.c

[libav-devel] [PATCH 4/8] lavu: Add OpenCL hardware pixfmt

--- doc/APIchanges | 3 +++ libavutil/pixdesc.c | 4 libavutil/pixfmt.h | 7 +++ libavutil/version.h | 2 +- 4 files changed, 15 insertions(+), 1 deletion(-) diff --git a/doc/APIchanges b/doc/APIchanges index 9df0f7c..6cb9582 100644 --- a/doc/APIchanges +++ b/doc/APIchanges @@

[libav-devel] [PATCH 5/8] lavu: OpenCL hwcontext implementation

--- configure | 6 + doc/APIchanges | 4 + libavutil/Makefile | 2 + libavutil/hwcontext.c | 3 + libavutil/hwcontext.h | 1 + libavutil/hwcontext_internal.h | 1 + libavutil/hwcontext_opencl.c | 817

[libav-devel] [PATCH 3/8] hwcontext_vaapi: Frame mapping support

Can map to any supported software format (using a GPU copy if it doesn't actually match the surface format underneath). --- libavutil/hwcontext_vaapi.c | 91 + 1 file changed, 50 insertions(+), 41 deletions(-) diff --git a/libavutil/hwcontext_vaapi.c

[libav-devel] [PATCH 1/8] hwcontext: Hardware frame mapping

Adds the external mapping function (with flags enum), along with some internal support for making mapped frames. --- doc/APIchanges | 3 ++ libavutil/hwcontext.c | 95 ++ libavutil/hwcontext.h | 16 +++

[libav-devel] [PATCH 0/8] Hardware frame mapping, OpenCL hwcontext (v2)

Hi all, Little has changed about hardware frame mapping since last time (), so this part is mostly a ping for further discussion. Questions advanced there still apply. OpenCL has advanced significantly - it is now mostly

Re: [libav-devel] [PATCH 1/9] vaapi_h264: Constify pointers

On 11/08/16 09:28, Anton Khirnov wrote: > So, the set looks mostly fine to me. The apichanges entry should > mention what is the replacement for the old API. Also, > struct vaapi_context should probably be tagged with > attribute_deprecated. 2016-xx-xx - xxx - lavc 59.26.0 - vaapi.h

[libav-devel] [PATCH 10/9] vaapi_mpeg4: Convert to use the new VAAPI hwaccel code

--- Here's a go at MPEG-4 part 2. This is not tested, because I don't have anything which supports it. (I thought it worked on AMD with gallium/mesa, but the driver here does not declare support for it - I haven't pursued that further, maybe it's possible somehow.) I'm also wondering whether

Re: [libav-devel] [PATCH 5/9] lavc: Rewrite VAAPI decode infrastructure

On 06/08/16 23:22, Mark Thompson wrote: > Moves much of the setup logic for VAAPI decoding into lavc; the user > now need only provide the hw_frames_ctx. > > Also deprecates struct vaapi_context and the installed header vaapi.h > which contains it, while continuing to support it

[libav-devel] [PATCH 9/9] avconv_vaapi: Convert to use hw_frames_ctx only

Most of the functionality here has moved into lavc. --- avconv_vaapi.c | 353 - 1 file changed, 23 insertions(+), 330 deletions(-) diff --git a/avconv_vaapi.c b/avconv_vaapi.c index ddee72c..584b8b4 100644 --- a/avconv_vaapi.c +++

[libav-devel] [PATCH 8/9] vaapi_vc1: Convert to use the new VAAPI hwaccel code

--- libavcodec/vaapi_vc1.c | 346 + 1 file changed, 206 insertions(+), 140 deletions(-) diff --git a/libavcodec/vaapi_vc1.c b/libavcodec/vaapi_vc1.c index 2fc03e6..fe1a20f 100644 --- a/libavcodec/vaapi_vc1.c +++ b/libavcodec/vaapi_vc1.c @@ -20,8

[libav-devel] [PATCH 6/9] vaapi_h264: Convert to use the new VAAPI hwaccel code

--- The parameter buffers are now build on the stack to avoid the mapping, so the change is larger here. (As before, tested on i965 (Skylake) and mesa/gallium (Bonaire).) libavcodec/vaapi_h264.c | 235 1 file changed, 137 insertions(+), 98

[libav-devel] [PATCH 7/9] vaapi_mpeg2: Convert to use the new VAAPI hwaccel code

--- libavcodec/vaapi_mpeg2.c | 167 ++- 1 file changed, 106 insertions(+), 61 deletions(-) diff --git a/libavcodec/vaapi_mpeg2.c b/libavcodec/vaapi_mpeg2.c index 459eb75..6c10578 100644 --- a/libavcodec/vaapi_mpeg2.c +++ b/libavcodec/vaapi_mpeg2.c @@

[libav-devel] [PATCH 5/9] lavc: Rewrite VAAPI decode infrastructure

Moves much of the setup logic for VAAPI decoding into lavc; the user now need only provide the hw_frames_ctx. Also deprecates struct vaapi_context and the installed header vaapi.h which contains it, while continuing to support it in the new code. --- Now avoids mapping buffers entirely.

[libav-devel] [PATCH 4/9] vaapi_vc1: Remove redundant version check

The lowest supported VAAPI version is 0.34 (checked at configure time), so this test is no longer needed. --- libavcodec/vaapi_vc1.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/libavcodec/vaapi_vc1.c b/libavcodec/vaapi_vc1.c index efe950a..2fc03e6 100644 --- a/libavcodec/vaapi_vc1.c +++

[libav-devel] [PATCH 3/9] vaapi_vc1: Constify pointers

--- libavcodec/vaapi_vc1.c | 28 ++-- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/libavcodec/vaapi_vc1.c b/libavcodec/vaapi_vc1.c index 4022549..efe950a 100644 --- a/libavcodec/vaapi_vc1.c +++ b/libavcodec/vaapi_vc1.c @@ -39,7 +39,7 @@ static int

[libav-devel] [PATCH 2/9] vaapi_mpeg2: Constify pointers

--- libavcodec/vaapi_mpeg2.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/libavcodec/vaapi_mpeg2.c b/libavcodec/vaapi_mpeg2.c index cb77745..459eb75 100644 --- a/libavcodec/vaapi_mpeg2.c +++ b/libavcodec/vaapi_mpeg2.c @@ -26,21 +26,21 @@ #include "internal.h" /**

[libav-devel] [PATCH 1/9] vaapi_h264: Constify pointers

--- Cosmetic changes removed. libavcodec/vaapi_h264.c | 24 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/libavcodec/vaapi_h264.c b/libavcodec/vaapi_h264.c index 931357a..2dd45e7 100644 --- a/libavcodec/vaapi_h264.c +++ b/libavcodec/vaapi_h264.c @@

[libav-devel] [PATCH 6/6] avconv_vaapi: Convert to use hw_frames_ctx only

Most of the functionality here has moved into lavc. --- Now at the end of the series, because unconverted decoders will not work with it applied. (The converted decoders work with or without this change.) avconv_vaapi.c | 353 - 1 file

[libav-devel] [PATCH 5/6] vaapi_mpeg2: Convert to use the new VAAPI hwaccel code

--- The generic end_frame taking an MpegEncContext (wtf?) is no longer commonc - there seems little point in it. libavcodec/vaapi_mpeg2.c | 53 1 file changed, 40 insertions(+), 13 deletions(-) diff --git a/libavcodec/vaapi_mpeg2.c

[libav-devel] [PATCH 4/6] vaapi_h264: Convert to use the new VAAPI hwaccel code

--- The const changes were split out (see 1/6). libavcodec/vaapi_h264.c | 53 +++-- 1 file changed, 29 insertions(+), 24 deletions(-) diff --git a/libavcodec/vaapi_h264.c b/libavcodec/vaapi_h264.c index 8769786..8e30dcd 100644 ---

[libav-devel] [PATCH 3/6] lavc: Rewrite VAAPI decode infrastructure

Moves much of the setup logic for VAAPI decoding into lavc; the user now need only provide the hw_frames_ctx. Also deprecates struct vaapi_context and installed header vaapi.h which contains it, while continuing to support it in the new code. --- I've ducked the interlacing problem by allowing

[libav-devel] [PATCH 2/6] vaapi_mpeg2: Constify pointers

--- The same as the previous patch, for MPEG-2. libavcodec/vaapi_mpeg2.c | 20 1 file changed, 12 insertions(+), 8 deletions(-) diff --git a/libavcodec/vaapi_mpeg2.c b/libavcodec/vaapi_mpeg2.c index cb77745..3ea868c 100644 --- a/libavcodec/vaapi_mpeg2.c +++

[libav-devel] [PATCH 1/6] vaapi_h264: Constify pointers

--- Split from the conversion to follow, as suggested by Diego. libavcodec/vaapi_h264.c | 36 ++-- 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/libavcodec/vaapi_h264.c b/libavcodec/vaapi_h264.c index 931357a..8769786 100644 ---

Re: [libav-devel] [PATCH 1/3] lavc: Rewrite VAAPI decode infrastructure

On 31/07/16 23:22, Mark Thompson wrote: > +void *ff_vaapi_decode_alloc_slice_buffer(AVCodecContext *avctx, > + VAAPIDecodePicture *pic, > + size_t params_size, > +

Re: [libav-devel] [PATCH] h264dec: reset nb_slice_ctx_queued for hwaccel decoding

On 01/08/16 06:44, Anton Khirnov wrote: > Fixes hwaccel decoding of files with multiple slices. > > Found-By: Mark Thompson <s...@jkqxz.net> > --- > libavcodec/h264dec.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/libavcodec/h2

[libav-devel] [PATCH 3/3] vaapi_h264: Convert to use new VAAPI hwaccel code

Also constify lots of pointers. --- Not very well tested because *someone* broke hwaccel decode with multiple slices per frame. I think it passes FATE for the files with single-slice frames. I've only converted H.264 so far - the other codecs should be straightforward, but I wanted to get

[libav-devel] [PATCH 2/3] avconv_vaapi: Convert to use hw_frames_ctx only

Most of the functionality here has moved into lavc. --- This doesn't actually work until codecs have been converted too. (Maybe this should go at the end of the series because of that?) avconv_vaapi.c | 353 - 1 file changed, 23

[libav-devel] [PATCH 1/3] lavc: Rewrite VAAPI decode infrastructure

Moves much of the setup logic for VAAPI decoding into lavc; the user now need only provide the hw_frames_ctx. Also deprecates struct vaapi_context and installed header vaapi.h which contains it, while continuing to support it in the new code. --- The intent here is to move to a cleaner setup with

[libav-devel] [PATCH] hwcontext_vaapi: Try the first render node as the default DRM device

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

Re: [libav-devel] [PATCH] hwcontext_vaapi: Try the first render node as the default DRM device

On 28/07/16 13:11, Diego Biurrun wrote: > On Thu, Jul 28, 2016 at 01:04:53PM +0100, Mark Thompson wrote: >> If no device argument is supplied, we currently only try the default >> X11 display (that is, $DISPLAY) to find a device, and will fail in >> the absence of X11. T

[libav-devel] [PATCH] hwcontext_vaapi: Try the first render node as the default DRM device

If no device argument is supplied, we currently only try the default X11 display (that is, $DISPLAY) to find a device, and will fail in the absence of X11. This makes it also try to find a device via the first render node ("/dev/dri/renderD128"), which is probably the right thing in a simple

Re: [libav-devel] [PATCH 00/10] Hardware frame mapping, OpenCL hwcontext

On 14/07/16 09:57, John Högberg wrote: > On 14/07/16 10:53, John Högberg wrote: >> If I were you I'd just create a temporary image to hold the result and >> enqueue a copy operation that waits for the kernel event. It'll work >> everywhere and the performance penalty is tiny. > > ... If you

Re: [libav-devel] [PATCH 00/10] Hardware frame mapping, OpenCL hwcontext

On 13/07/16 11:54, John Högberg wrote: > On 13/07/16 01:45, Mark Thompson wrote: >> * 2D images. Are they actually sensible in general? I was pushed into >> using them by tiled memory on Intel (if you take a buffer instead of an >> image then you have to untile address

Re: [libav-devel] [PATCH 01/10] hwcontext: Hardware frame mapping

On 13/07/16 04:36, Andrey Turkin wrote: > 2016-07-13 2:47 GMT+03:00 Mark Thompson <s...@jkqxz.net>: > >> +hwmap = av_malloc(sizeof(*hwmap)); >> > mallocz so error path don't get uninitialized reference Yep, fixed. Thanks, - Mark

Re: [libav-devel] [PATCH 05/10] lavu: OpenCL hwcontext implementation

On 13/07/16 06:02, Luca Barbato wrote: > On 13/07/16 01:52, Mark Thompson wrote: >> WIP: very incomplete. > > What's missing? * Transfer data in/out (you can only map to/from VAAPI at the moment). * Support for non-NV12 frames - I'd like at least YUV420P and some RGB form

Re: [libav-devel] [PATCH 01/10] hwcontext: Hardware frame mapping

On 13/07/16 04:48, Luca Barbato wrote: > On 13/07/16 01:47, Mark Thompson wrote: >> +int av_hwframe_map(AVFrame *dst, const AVFrame *src, int flags) >> +{ >> +AVHWFramesContext *ctx; >> +int ret; >> + >> +if (src->hw_frames_ctx) {

[libav-devel] [PATCH 10/10] lavfi: scaler for OpenCL hardware frames

WIP: working but very dirty. This is called scale_opencl, but it could actually be an arbitrary transform. --- libavfilter/Makefile | 1 + libavfilter/allfilters.c | 1 + libavfilter/vf_scale_opencl.c | 395 ++ 3 files changed, 397

[libav-devel] [PATCH 09/10] lavfi: OpenCL filter for arbtrary in-place transformation

WIP: working but very dirty. Loads an arbitrary OpenCL kernel and runs it on the image. --- libavfilter/Makefile| 1 + libavfilter/allfilters.c| 1 + libavfilter/vf_opencl_inplace.c | 280 3 files changed, 282 insertions(+) create

[libav-devel] [PATCH 08/10] vf_drawtext: NV12 support hack

Simple hack to allow writing on NV12 hardware frames. (Not to be pushed like this - just nice for testing other stuff in this series.) --- libavfilter/vf_drawtext.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/libavfilter/vf_drawtext.c b/libavfilter/vf_drawtext.c index

[libav-devel] [PATCH 07/10] avconv: Trivial support for making an OpenCL device

Makes a naughty global that other stuff can refer to - not a sane thing to do at all, but helps for testing the other patches. --- Makefile| 1 + avconv.h| 1 + avconv_opencl.c | 40 avconv_opt.c| 15 +++ 4 files changed,

[libav-devel] [PATCH 06/10] hwcontext_openc: OpenCL <-> VAAPI mapping for Intel platforms

WIP. --- configure| 5 + libavutil/hwcontext_opencl.c | 354 +++ 2 files changed, 359 insertions(+) diff --git a/configure b/configure index e601de5..1311612 100755 --- a/configure +++ b/configure @@ -1655,6 +1655,7 @@ HAVE_LIST="

[libav-devel] [PATCH 05/10] lavu: OpenCL hwcontext implementation

WIP: very incomplete. This just adds enough generic stuff to support the mapping in the following patch. --- configure | 6 + libavutil/Makefile | 2 + libavutil/hwcontext.c | 3 + libavutil/hwcontext.h | 1 +

[libav-devel] [PATCH 04/10] lavu: Add OpenCL hardware pixfmt

--- Seemed better to keep as a separate patch. libavutil/pixdesc.c | 4 libavutil/pixfmt.h | 7 +++ 2 files changed, 11 insertions(+) diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c index cf2ea9c..3669342 100644 --- a/libavutil/pixdesc.c +++ b/libavutil/pixdesc.c @@ -1614,6

[libav-devel] [PATCH 03/10] hwcontext_vaapi: Frame mapping support

Can map to any supported software format (using a GPU copy if it doesn't actually match the surface format underneath). --- The mapping code was already there for transfer*, it just gets some parts renamed and rearranged. libavutil/hwcontext_vaapi.c | 91

[libav-devel] [PATCH 02/10] lavfi: Hardware map and unmap filters

The hwmap filter takes a hardware frame as input and maps it to something else (hardware or software) for other processing. The hwunmap filter undoes a hwmap - the frame which was mapped is put back into the filter chain. --- libavfilter/Makefile | 2 + libavfilter/allfilters.c | 2 +

[libav-devel] [PATCH 01/10] hwcontext: Hardware frame mapping

Adds the external mapping function (with flags enum), along with some internal support for making mapped frames. --- libavutil/hwcontext.c | 95 ++ libavutil/hwcontext.h | 16 +++ libavutil/hwcontext_internal.h | 34 +++ 3

[libav-devel] [PATCH 00/10] Hardware frame mapping, OpenCL hwcontext

Hi all, This is kindof a dump of current progress. Only the first few patches are plausibly complete, but I'd like to invite comments on what I've done so far. First, some real things you can do with this: * Hardware frame map/modify/unmap with VAAPI: ./avconv -vaapi_device

Re: [libav-devel] [PATCH 1/2] avconv: Rename hwaccel_lax_profile_check to hwaccel_ignore_capabilities

On 27/06/16 14:33, Rémi Denis-Courmont wrote: > Le 2016-06-27 15:14, Mark Thompson a écrit : >> The stream profile is a very specific thing to apply to, provoked by >> the VAAPI implementation. This changes the name so that it can apply >> more generally. > > I th

Re: [libav-devel] [PATCH 1/2] avconv: Rename hwaccel_lax_profile_check to hwaccel_ignore_capabilities

On 27/06/16 14:14, Mark Thompson wrote: > The stream profile is a very specific thing to apply to, provoked by > the VAAPI implementation. This changes the name so that it can apply > more generally. > --- > avconv.h | 2 +- > avconv_opt.c | 6 +++--- > avconv_vaap

[libav-devel] [PATCH 2/2] avconv_vdpau: Allow the user to ignore the decoder's declared level

This is not a total override - the width/height is still checked inside ff_vdpau_common_init(). --- Tested on AMD/Gallium - before this change a 1080p level 5.1 stream was rejected, after this it works with -hwaccel_ignore_capabilities. (Also needs Anton's hwframe size change to actually work at

[libav-devel] [PATCH 1/2] avconv: Rename hwaccel_lax_profile_check to hwaccel_ignore_capabilities

The stream profile is a very specific thing to apply to, provoked by the VAAPI implementation. This changes the name so that it can apply more generally. --- avconv.h | 2 +- avconv_opt.c | 6 +++--- avconv_vaapi.c | 2 +- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git

Re: [libav-devel] [PATCH 4/4] hwcontext_vaapi: allow transfers to/from any size of sw frame

On 25/06/16 22:04, Luca Barbato wrote: > On 25/06/16 16:19, Anton Khirnov wrote: >> From: Mark Thompson <s...@jkqxz.net> >> >> 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 fra

Re: [libav-devel] [PATCH 1/4] hwcontext: clarify the behaviour of transfer_data() for cropped frames

On 25/06/16 15:19, Anton Khirnov wrote: > hwcontext: clarify the behaviour of transfer_data() for cropped frames > hwcontext: allocate the destination frame for the pool size > vf_hwdownload: allocate the destination frame for the pool size > hwcontext_vaapi: allow transfers to/from any size of sw

[libav-devel] [PATCH] vf_scale_vaapi: Respect driver quirks around buffer destruction

--- And we need this one too. Destroy was already present - following existing examples without reading the documentation properly is a good way to propagate errors. libavfilter/vf_scale_vaapi.c | 15 --- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git

[libav-devel] [PATCH] hwcontext_vaapi: Add driver quirks to the hwdevice

to vaRenderPicture()) and detects that driver to set it. --- On 23/06/16 20:54, Anton Khirnov wrote: > Quoting Mark Thompson (2016-06-22 00:26:49) >> Do we want an explicit way to disable the autodetection and let the >> user set the quirks field? Currently it works for t

Re: [libav-devel] [PATCH 3/3] vaapi_encode: Maintain a pool of bitstream output buffers

On 23/06/16 21:13, Anton Khirnov wrote: > Quoting Mark Thompson (2016-06-22 00:28:31) >> Previously we would allocate a new one for every frame. This instead >> maintains an AVBufferPool of them to use as-needed. >> >> Also makes the maximum size of an output buffer

Re: [libav-devel] [PATCH 07/10] avconv: do packet ts rescaling in write_packet()

On 25/06/16 11:00, Anton Khirnov wrote: > Quoting Mark Thompson (2016-06-23 01:12:14) >> On 21/06/16 18:50, Anton Khirnov wrote: >>> This will be useful in the following commit, after which the muxer >>> timebase is not always available when encoding.

Re: [libav-devel] [PATCH 03/10] avconv: buffer the packets written while the muxer is not initialized

On 21/06/16 18:50, Anton Khirnov wrote: > --- > avconv.c| 76 > +++-- > avconv.h| 7 ++ > avconv_opt.c| 10 > doc/avconv.texi | 9 +++ > 4 files changed, 84 insertions(+), 18 deletions(-) Is

[libav-devel] [PATCH] avconv: Remove hw_device_ctx output filter reinit hack

Not needed any more because we no longer have any useful case which will reinitialise with hardware frames here. --- To go on top of Anton's avconv series. This was always a nasty hack because it could break stream changes with non-hardware streams when a hardware device was present. Now that

Re: [libav-devel] [PATCH 10/10] avconv_qsv: use the device creation API

On 21/06/16 18:50, Anton Khirnov wrote: > --- > avconv_qsv.c | 247 > +-- > 1 file changed, 38 insertions(+), 209 deletions(-) Yay, qsv_transcode_init() is gone :) LGTM. - Mark ___ libav-devel

Re: [libav-devel] [PATCH 09/10] avconv: pass the hwaccel frames context to the decoder

On 21/06/16 18:50, Anton Khirnov wrote: > --- > avconv.c | 7 +++ > 1 file changed, 7 insertions(+) OK. Probably we should consider how this setup should be working in the non-hwaccel decoder case soon. - Mark ___ libav-devel mailing list

Re: [libav-devel] [PATCH 08/10] avconv: init filtergraphs only after we have a frame on each input

On 21/06/16 18:50, Anton Khirnov wrote: > This makes sure the actual stream parameters are used, which is > important mainly for hardware decoding+filtering cases, which would > previously require various weird workarounds to handle the fact that a > fake software graph has to be constructed, but

Re: [libav-devel] [PATCH 07/10] avconv: do packet ts rescaling in write_packet()

On 21/06/16 18:50, Anton Khirnov wrote: > This will be useful in the following commit, after which the muxer > timebase is not always available when encoding. > --- > avconv.c | 23 --- > avconv.h | 2 ++ > 2 files changed, 14 insertions(+), 11 deletions(-) > ... > @@ -314,7

Re: [libav-devel] [PATCH 06/10] avconv: decouple configuring filtergraphs and setting output parameters

On 21/06/16 18:50, Anton Khirnov wrote: > The reasoning is the same as in 563aa6b80bf87712910404d6fb5495a75e40ae86 > --- > avconv.c| 3 +++ > avconv.h| 12 +++ > avconv_filter.c | 50 +- > avconv_opt.c| 62 >

Re: [libav-devel] [PATCH 05/10] avconv: factor out initializing stream parameters for encoding

On 21/06/16 18:50, Anton Khirnov wrote: > Setting the filter input parameters is moved to init_input_stream(), > so that it is done before the decoder is opened, potentially overwriting > the information from avformat_find_stream_info() with less accurate > data. > > This commit temporarily

Re: [libav-devel] [PATCH 04/10] avconv: decouple configuring filtergraphs and setting input parameters

On 21/06/16 18:50, Anton Khirnov wrote: > Currently, calling configure_filtergraph() will pull in the input > parameters from the corresponding decoder context. This has the > following disadvantages: > - the decoded frame is a more proper source for this information > - a filter accessing decoder

Re: [libav-devel] [PATCH 03/10] avconv: buffer the packets written while the muxer is not initialized

On 21/06/16 18:50, Anton Khirnov wrote: > --- > avconv.c| 76 > +++-- > avconv.h| 7 ++ > avconv_opt.c| 10 > doc/avconv.texi | 9 +++ > 4 files changed, 84 insertions(+), 18 deletions(-) The

Re: [libav-devel] [PATCH 02/10] avconv: explicitly postpone writing the header until all streams are initialized

On 21/06/16 18:50, Anton Khirnov wrote: > This should have no practical effect for now, but will make a difference > in the following commits. > --- > avconv.c | 97 > +--- > avconv.h | 8 ++ > 2 files changed, 71 insertions(+), 34

Re: [libav-devel] [PATCH 01/10] lavfi: set the link hwframes context before configuring the dst input

On 21/06/16 18:50, Anton Khirnov wrote: > The destination filter might expect the hw frames context to be already > set (this is the case e.g. for hwdownload). > --- > libavfilter/avfilter.c | 16 > 1 file changed, 8 insertions(+), 8 deletions(-) OK. (Though the diff would be

[libav-devel] [PATCH 3/3] vaapi_encode: Maintain a pool of bitstream output buffers

Previously we would allocate a new one for every frame. This instead maintains an AVBufferPool of them to use as-needed. Also makes the maximum size of an output buffer adapt to the frame size - the fixed upper bound was a bit too easy to hit when encoding large pictures at high quality. ---

[libav-devel] [PATCH 2/3] vaapi_encode: Respect driver quirks around buffer destruction

No longer leaks memory when used with a driver with the "render does not destroy param buffers" quirk (i.e. Intel i965). --- libavcodec/vaapi_encode.c | 22 +- 1 file changed, 21 insertions(+), 1 deletion(-) diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c

[libav-devel] [PATCH 1/3] hwcontext_vaapi: Add driver quirks to the hwdevice

The driver being used is detected inside av_hwdevice_ctx_init(), and the quirks field then set from a table of known drivers. 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. --- Not-quite-as-long

<    3   4   5   6   7   8   9   10   >