On Mon, 20 Feb 2017 22:49:01 +0000 Mark Thompson <[email protected]> wrote:
> On 20/02/17 06:31, wm4 wrote: > > On Sun, 19 Feb 2017 18:46:39 +0000 > > Mark Thompson <[email protected]> wrote: > > > >> --- > >> 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 1e84c3803..253454358 100644 > >> --- a/doc/APIchanges > >> +++ b/doc/APIchanges > >> @@ -13,6 +13,9 @@ libavutil: 2015-08-28 > >> > >> API changes, most recent first: > >> > >> +2017-xx-xx - xxxxxxx - lavu 55.33.0 - pixfmt.h > >> + Add AV_PIX_FMT_OPENCL. > >> + > >> 2017-02-xx - xxxxxxx - lavc - avcodec.h > >> The vdpau hwaccel now works with the AVCodecContext.hw_frames_ctx and > >> AVCodecContext.hw_device_ctx APIs. > >> diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c > >> index d69eeea9d..6a2742f11 100644 > >> --- a/libavutil/pixdesc.c > >> +++ b/libavutil/pixdesc.c > >> @@ -1759,6 +1759,10 @@ static const AVPixFmtDescriptor > >> av_pix_fmt_descriptors[AV_PIX_FMT_NB] = { > >> .flags = AV_PIX_FMT_FLAG_BE | AV_PIX_FMT_FLAG_PLANAR | > >> AV_PIX_FMT_FLAG_RGB | AV_PIX_FMT_FLAG_ALPHA, > >> }, > >> + [AV_PIX_FMT_OPENCL] = { > >> + .name = "opencl", > >> + .flags = AV_PIX_FMT_FLAG_HWACCEL, > >> + }, > > > > (I wonder if we have any rules on whether log2_chroma_w/h are supposed > > to be set for hwaccel formats, but it's already inconsistent, so no > > matter.) > > Many of them support multiple different sw_formats (OpenCL can support pretty > much any if anyone cares to add them), so I doubt those fields can ever be > meaningful. Yes, I was just wondering about the inconsistency between the different hwaccel pixfmts, and whether there was possibly any weird code anywhere which relies on this. Never mind my comment, it was probably only a distraction. > >> }; > >> #if FF_API_PLUS1_MINUS1 > >> FF_ENABLE_DEPRECATION_WARNINGS > >> diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h > >> index 41498ccef..ae1e2349b 100644 > >> --- a/libavutil/pixfmt.h > >> +++ b/libavutil/pixfmt.h > >> @@ -248,6 +248,13 @@ enum AVPixelFormat { > >> AV_PIX_FMT_GRAY12BE, ///< Y , 12bpp, big-endian > >> AV_PIX_FMT_GRAY12LE, ///< Y , 12bpp, little-endian > >> > >> + /** > >> + * Hardware surfaces used in OpenCL. > >> + * data[i] contain 2D image objects (typed in C as cl_mem, used > >> + * in OpenCL as image2d_t) for each plane of the surface. > >> + */ > >> + AV_PIX_FMT_OPENCL, > > > > That's interesting. Normally hwaccel pixfmts have data only in data[3]. > > I wonder how AVFrame.bufs is supposed to be set here? > > The normal allocation comes up with: > > bufs[plane] = reference to the cl_mem object in data[plane] > bufs[num_planes] = reference to the single cl_mem object from which all of > the planes were created > > This isn't necessary, though - mapped and user-created frames can work in > other ways. I don't think there can be more buffers in bufs[] than used planes, though. elenril (in his role as an API watchdog) will probably know better. Originally the rule was that every allocation in data[] must be covered by a buffer. It never made much sense for hwaccels, though, since they usually have something in data[3] that's clearly not covered by a buffer. I think it's worth discussing this to avoid further chaos. _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
