[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 +161

[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 + libavutil/hwcontext_internal

[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 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, 5

[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 e36cfa2..25af

[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 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 inserti

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) {

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 som

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 : > >> +hwmap = av_malloc(sizeof(*hwmap)); >> > mallocz so error path don't get uninitialized reference Yep, fixed. Thanks, - Mark __

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 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 real

[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 confi

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. This

[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 vi

[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 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 insertions

[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 some

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 > --- > libavcodec/h264dec.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/libavcodec/h264dec.c b/libavcodec/h

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, > +

[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 --- a/libavcodec/vaapi

[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 +++ b/libavcodec/vaap

[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 the

[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 --- a/libavcodec/vaapi_h2

[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 b/libavcodec/v

[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 cha

[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 @@ -53,7

[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 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 get_VAM

[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 +++ b

[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. doc/APIc

[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 deleti

[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 @@ -2

[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 +20

[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 +++ b/avconv_v

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 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 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 Deprecat

[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 co

[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 +++ libavutil/hwcont

[libav-devel] [PATCH 2/8] 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 + lib

[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 b/

[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 @@ -13,

[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 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 dif

[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=" libd

[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 b/M

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) >> +{

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 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 || >>

[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 a/libavcodec/vp8.c

[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 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 changed

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 thi

[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 VAAPI check to a more sensible place >

[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 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 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 100644

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

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 wrote: >> Quoting Mark Thompson (2016-09-06 22:53:18) >>> @@ -2480,6 +2514,20 @@ int vp78_decode_frame(AVCodecContext *avctx, void >>> *data, int *got_frame, >>>

[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 suf

[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 al

[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 b/libavcodec/vaapi_en

[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 always be

[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] 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 a

[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 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 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 libavcodec/vaapi_encode_h26

[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 there)

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 _

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] [PATCH 09/14] svq3: Change type of array stride parameters to ptrdiff_t

On 20/09/16 22:07, Diego Biurrun wrote: > On Tue, Sep 20, 2016 at 09:22:06PM +0100, Mark Thompson wrote: >> On 20/09/16 19:36, Diego Biurrun wrote: >>> ptrdiff_t is the correct type for array strides and similar. >>> --- a/libavcodec/svq3.c >>> +++ b/li

Re: [libav-devel] [PATCH 02/14] intrax8: 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. I can't say I looked at the detail with extreme care, but I didn't see anything else in the series which looked fishy. Aside: Seeing a lot of little functions like (picking a random one): >

[libav-devel] [PATCH] vaapi_h264: Set max_num_ref_frames to 1 when not using B frames

--- Thanks to Andy Furniss for noting this: . libavcodec/vaapi_encode_h264.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c index 0cd9

[libav-devel] [PATCH 1/5] vaapi_encode: Decide on GOP setup before initialising sequence parameters

This was always too late; several fields related to it have been incorrectly zero since the encoder was added. --- libavcodec/vaapi_encode.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c index dc6cdfe..b600a00

[libav-devel] [PATCH 2/5] vaapi_h265: Fix slice header writing

This was not observed earlier because the only syntax element which it normally misses with the current setup is slice_qp_delta, but that is always going to be zero (in IDR frames QP isn't varied on the slice) which will always exp-golomb code as a single 1 bit. The immediately following part is t

[libav-devel] [PATCH 3/5] vaapi_h265: Fix buffering parameters

The b_per_p value was previously always zero here, so this wasn't filled in sensibly at all. The correct value is required to give the right output order from the decoder. --- libavcodec/vaapi_encode_h265.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/libavcodec/vaa

[libav-devel] [PATCH 4/5] hwcontext_vaapi: Enable P010 support

This is required for 10-bit surfaces. --- libavutil/hwcontext_vaapi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c index bba0c4d..fd0806c 100644 --- a/libavutil/hwcontext_vaapi.c +++ b/libavutil/hwcontext_vaapi.c @@ -

[libav-devel] [PATCH 5/5] vaapi_h265: Add main 10 encode support

--- Tested on Kaby Lake. Actually, in order to work with the current i965 driver va_rt_format needs to be set to VA_RT_FORMAT_YUV420 rather than VA_RT_FORMAT_YUV420_10BPP. I believe this is a bug, and should be fixed on that side (mesa/gallium on AMD VCE supports Main10 decode with output to 8

[libav-devel] [PATCH] vaapi_encode: Add VP9 support

--- Tested on Kaby Lake. CQP (well, C q_idx) and CBR mode implemented. Some vestigial B-frame-alike support, but not actually working: it will need some more thought about how to construct the superframes from the output buffers. configure | 3 + libavcodec/Makefile

[libav-devel] [PATCH] vaapi_h264: Fix CFR mode with frame_rate set in AVCodecContext

--- framerate is upside down. (Not noticed earlier because it is rarely set, and never by avconv.) libavcodec/vaapi_encode_h264.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c index 020f892..e90ed64 10064

[libav-devel] [PATCH] vaapi_h264: Write bitstream restriction fields

--- Indirectly requested by Anton. No B-frames: @162 VUI: bitstream_restriction_flag 1 ( 1) @163 VUI: motion_vectors_over_pic_boundaries_flag 0 ( 0) @164 VUI: max_bytes_per_pic_denom 1 ( 0) @165 VUI: max_bi

Re: [libav-devel] [PATCH] avconv: set the encoding framerate when the output is CFR

On 01/10/16 10:47, Anton Khirnov wrote: > --- > avconv.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/avconv.c b/avconv.c > index 59eb300..87923b9 100644 > --- a/avconv.c > +++ b/avconv.c > @@ -1978,6 +1978,8 @@ static int init_output_stream_encode(OutputStream *ost) >

Re: [libav-devel] [PATCH] hwcontext_vaapi: add a quirk for the missing MemoryType attribute

On 01/10/16 09:44, Anton Khirnov wrote: > The Intel binary iHD driver does not support the > VASurfaceAttribMemoryType, so surface allocation will fail when using > it. > --- > doc/APIchanges | 3 +++ > libavutil/hwcontext_vaapi.c | 8 +++- > libavutil/hwcontext_vaapi.h | 6 ++

Re: [libav-devel] [PATCH] vaapi_h264: Write bitstream restriction fields

On 01/10/16 11:03, Mark Thompson wrote: > --- > Indirectly requested by Anton. > > No B-frames: > > @162 VUI: bitstream_restriction_flag 1 ( 1) > @163 VUI: motion_vectors_over_pic_boundaries_flag 0 ( 0) > @164 VUI:

[libav-devel] [PATCH] vaapi_h265: Fix buffering parameters

A decoder may need this to be set correctly to output frames in the right order. --- On 30/09/16 17:56, Mark Thompson wrote: > stuff This did fix the ordering problem, but Anton noted that it was still wrong. Here's another go... libavcodec/vaapi_encode_h265.c | 8 1 file ch

Re: [libav-devel] [PATCH] vaapi_encode: Add VP9 support

On 02/10/16 05:44, James Almer wrote: > On 10/1/2016 10:48 AM, Anton Khirnov wrote: >> Quoting Mark Thompson (2016-10-01 11:26:09) >>> --- >>> Tested on Kaby Lake. >> >> Looks simple enough to be ok. I guess it also deserves a changelog >> entry

[libav-devel] [PATCH] vaapi_encode: Write sequence header as extradata

Only works if packed headers are supported, where we can know the output before generating the first frame. --- If this is wanted when packed headers aren't supported, we will need a different approach because we can't know what the output will be until the first frame is written. libavcodec/va

Re: [libav-devel] [PATCH] vaapi_encode: Write sequence header as extradata

On 02/10/16 17:05, Vittorio Giovara wrote: > On Sun, Oct 2, 2016 at 4:19 AM, Mark Thompson wrote: >> Only works if packed headers are supported, where we can know the >> output before generating the first frame. >> --- >> If this is wanted when packed headers aren&

Re: [libav-devel] [PATCH] nvenc: Map the H264 profiles as it is done for HVEC

On 07/10/16 09:47, Luca Barbato wrote: $subject =~ s/VE/EV/ > --- > > Not totally sure about constrained high. If it is correct I'd add it > to the profiles mapped. > > libavcodec/nvenc.c | 8 +--- > 1 file changed, 5 insertions(+), 3 deletions(-) > > diff --git a/libavcodec/nvenc.c b/lib

[libav-devel] [PATCH] vaapi_encode: Write sequence header as extradata

Only works if packed headers are supported, where we can know the output before generating the first frame. --- Added padding; fail harder; informative comment in header. Not sure how to do this in the non-packed-header case - we could just invoke this anyway, but the result is unlikely to precis

[libav-devel] [PATCH] h264: Add progressive and constrained high profiles

--- On 10/10/16 21:00, Luca Barbato wrote: > On 10/10/2016 21:43, Mark Thompson wrote: >> No, constrained high is high|set4|set5. Maybe it needs some new >> FF_PROFILE_H264 flags - *_PROGRESSIVE and *_NO_B_SLICES, or something? > > I guess, do you have time to get the

Re: [libav-devel] [PATCH] vaapi_encode: Write sequence header as extradata

On 12/10/16 10:38, Anton Khirnov wrote: > Quoting Mark Thompson (2016-10-10 21:54:35) >> Only works if packed headers are supported, where we can know the >> output before generating the first frame. >> --- >> Added padding; fail harder; informative comment in header. &g

[libav-devel] [PATCH] vaapi_h265: Include header for slice types

The include was changed correctly in 4abe3b049d987420eb891f74a35af2cebbf52144, but then mistakenly changed back by c359d624d3efc3fd1d83210d78c4152bd329b765 (it's not just the NAL unit types which are used). --- Building is currently broken with libva supporting H.265, this fixes it. libavcodec/v

[libav-devel] [PATCH 1/3] vaapi_h264: fix RefPicList[] field flags.

From: Gwenole Beauchesne Use new H264Ref.reference field to track field picture flags. The H264Picture.reference flag in DPB is now irrelevant here. This is a regression from git commit d8151a7, and that affected multiple interlaced video streams. Signed-off-by: Gwenole Beauchesne --- >From >

[libav-devel] [PATCH 2/3] vaapi_decode: Clear parameter buffers to fix picture reuse

When decoding interlaced pictures, the structure is reused to render to the same surface twice. The parameter buffers were not being cleared, which caused the i965 driver to error out. --- This fixes the error Luca was seeing (unrelated to the previous patch). libavcodec/vaapi_decode.c | 1 + 1

[libav-devel] [PATCH 3/3] vaapi_decode: Remove vestigial unmap code

The buffer map/unmap code was in an early version of this before it was committed, but the unmap was never removed. While wrong, this was harmless (and therefore unnoticed) because the buffers can't be mapped at this point - all drivers just did nothing with the call. --- libavcodec/vaapi_decode.

Re: [libav-devel] [PATCH 1/3] vaapi_h264: fix RefPicList[] field flags.

On 20/10/16 11:56, Diego Biurrun wrote: > On Wed, Oct 19, 2016 at 11:57:26PM +0100, Mark Thompson wrote: >> From: Gwenole Beauchesne >> >> Use new H264Ref.reference field to track field picture flags. The >> H264Picture.reference flag in DPB is now irrelevant here. >

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

Adds the new av_hwframe_map() function, which allows mapping between hardware frames and normal memory, along with internal support for implementing it. Also adds av_hwframe_ctx_create_derived(), for creating a hardware frames context associated with one device using frames mapped from another by

<    1   2   3   4   5   6   7   8   9   10   >