Re: [FFmpeg-devel] [PATCH] libavcodec/qsv.c: Re-design session control and internal allocation

[Gwenole Beauchesne]

2015-10-26 12:44 GMT+01:00 wm4 <nfx...@googlemail.com>:
> On Mon, 26 Oct 2015 11:22:38 +0100
> Gwenole Beauchesne <gb.de...@gmail.com> wrote:
>
>
>> >> /**
>> >>  * Hardware Accelerator identifier.
>> >>  *
>> >>  * @note
>> >>  * A hardware accelerator can be device-less. This means that only the
>> >>  * underlying hardware resource, e.g. a Linux dma_buf handle, is being
>> >>  * transported in the AVFrame. That hardware resource could be mapped
>> >>  * through standard OS-dependent calls, e.g. mmap() on Linux.
>> >>  */
>> >> enum AVHWAccelId {
>> >> AV_HWACCEL_ID_NONE = -1,
>> >> AV_HWACCEL_ID_VAAPI,
>> >> AV_HWACCEL_ID_NB,   ///< Not part of ABI
>> >> };
>> >>
>> >> Name to be improved if people have better suggestions, as this really
>> >> is to be seen as HW resource, not necessarily attached to a particular
>> >> HW device. i.e. this could be a dma_buf handle from a V4L2 buffer or
>> >> VA surface.
>> >
>> > OK. (Minor nit: if ID_NONE is valid and means HW API without context,
>> > maybe it should be 0, not -1. Also, if it was meant this way, maybe
>> > these should still have their own ID for other purposes.)
>>
>> In my current model, ID_NONE is not meant to be valid because the
>> hwaccel side data shall only exist for hwaccel purposes. Besides,
>> having ID_NONE set to -1 is consistent with other liavu enums and
>> convenient to have ID_NB express directly the exact number of
>> hwaccels.
>
> OK, this makes sense to me.
>
>> >> I am reworking the patch series as I changed my mind again: current
>> >> map strategy was overly complex (and required to be). There were at
>> >> least 4 map flags: AV_FRAME_MAP_{READ,WRITE,READ_FIRST,USWC_MEMORY}. I
>> >> am now preferring a unique av_hwaccel_frame_get_pixels() defined as
>> >> follow:
>> >>
>> >> /**
>> >>  * Returns AVFrame pixels into linear memory
>> >>  *
>> >>  * This function takes a snapshot of the underlying HW surface and
>> >>  * exposes it to SW backed memory. This may involve a copy from GPU
>> >>  * memory to CPU memory.
>> >>  *
>> >>  * @note
>> >>  * There is no effort underway to commit the modified pixels back to
>> >>  * GPU memory when the \ref dst AVFrame is released.
>> >>  *
>> >>  * @param[in] src   the source frame to read
>> >>  * @param[inout] dstthe target frame to update, or create if NULL
>> >>  * @param[in] flags an optional combination of AV_FRAME_FLAG_xxx flags
>> >>  * @return 0 on success, an AVERROR code on failure.
>> >>  */
>> >> int
>> >> av_hwaccel_frame_get_pixels(AVFrame *src, AVFrame **dst, unsigned flags);
>> >>
>> >> i.e. the cost of allocating and copying AVFrame metadata should be
>> >> less than the actual work needed behind the scene. So, it looks like a
>> >> better interim solution for starters.
>> >
>> > So this is for read-access only, right? If it can map data, there
>> > also needs to be an unmap function, and the user would have to know
>> > about when to use it.
>>
>> Well, put can be implementing by reversing src/dst in this function. :)
>> Actually, this can be av_hwaccel_frame_copy(), but the benefit of
>> having get_pixels() is to leave out the allocation business to lavu
>> and just having the user to bother about _unref().
>
> Also makes sense to me.
>
> What is a problem is that mapped frames and CPU frames (let's call pure
> CPU-allocated surfaces that) are not exactly the same thing. If the API
> user assumes the frame is a CPU frame, it might reference it for a long
> time, which would cause various problems. On the other hand, you don't
> want the user to force copying a frame if it's really a CPU frame.
>
> Maybe this is not really a problem. I'm just mentioning it as another
> detail.
>
>> >> For compatibility, that's also the idea behind another generic
>> >> AV_PIX_FMT_HWACCEL that would enforce data[i] to be clear of any
>> >> user-supplied pointers, and buf[i] shall be filled in by appropriate
>> >> accessors, or while creating the side-data, e.g.
>> >> av_vaapi_frame_create_side_data(). i.e. when lavc swallows up an
>> >> AVFrame with new-style hwaccel, this is where the AV_PIX_FMT_VAAPI
>> >> 

[FFmpeg-devel] [RFC] mem: facilitate imports into GPU memory space.

[Gwenole Beauchesne]

Allow for av_malloc() to allocate memory that could be mapped into
the GPU address space. This requires allocations on page boundaries.
On the video memory buffers side, this requires minimal alignment of
strides to 64 bytes.

Option 1: use heuristics in av_malloc()
- break down into mem, frame, and avcodec changes.

Option 2: use a finer decision model
- mem: add av_malloc_aligned()
- buffer: add av_buffer_alloc2() with align and/or flags
- frame/avcodec: use new APIs

Signed-off-by: Gwenole Beauchesne <gwenole.beauche...@intel.com>
---
 configure |  1 +
 libavcodec/internal.h |  4 +++-
 libavutil/mem.c   | 42 +++---
 3 files changed, 43 insertions(+), 4 deletions(-)

diff --git a/configure b/configure
index a38b290..25081a8 100755
--- a/configure
+++ b/configure
@@ -6262,6 +6262,7 @@ cat > $TMPH <> CHAR_BIT * sizeof(x) - 1)
 
-#if HAVE_AVX
+#if HAVE_GPU
+#   define STRIDE_ALIGN 64
+#elif HAVE_AVX
 #   define STRIDE_ALIGN 32
 #elif HAVE_SIMD_ALIGN_16
 #   define STRIDE_ALIGN 16
diff --git a/libavutil/mem.c b/libavutil/mem.c
index 323b183..b707d7e 100644
--- a/libavutil/mem.c
+++ b/libavutil/mem.c
@@ -35,6 +35,9 @@
 #if HAVE_MALLOC_H
 #include 
 #endif
+#if HAVE_UNISTD_H
+#include 
+#endif
 
 #include "avassert.h"
 #include "avutil.h"
@@ -61,7 +64,33 @@ void  free(void *ptr);
 
 #include "mem_internal.h"
 
-#define ALIGN (HAVE_AVX ? 32 : 16)
+#define ALIGN (HAVE_GPU ? 64 : (HAVE_AVX ? 32 : 16))
+
+static size_t get_page_size(void)
+{
+static size_t page_size;
+
+if (!page_size) {
+#ifdef HAVE_UNISTD_H
+page_size = getpagesize();
+#else
+page_size = 4096;
+#endif
+}
+return page_size;
+}
+
+static void get_malloc_props(size_t *size_ptr, size_t *align_ptr)
+{
+size_t align = ALIGN;
+
+/* Heuristic: use GPU mappable buffers for at least CIF resolutions */
+if (HAVE_GPU && *size_ptr > 288 * FFALIGN(352, align)) {
+align = get_page_size();
+*size_ptr = FFALIGN(*size_ptr, align);
+}
+*align_ptr = align;
+}
 
 /* NOTE: if you want to override these functions with your own
  * implementations (not recommended) you have to link libav* as
@@ -80,11 +109,18 @@ void *av_malloc(size_t size)
 #if CONFIG_MEMALIGN_HACK
 long diff;
 #endif
+#if HAVE_POSIX_MEMALIGN || HAVE_MEMALIGN
+size_t align;
+#endif
 
 /* let's disallow possibly ambiguous cases */
 if (size > (max_alloc_size - 32))
 return NULL;
 
+#if HAVE_POSIX_MEMALIGN || HAVE_MEMALIGN
+get_malloc_props(, );
+#endif
+
 #if CONFIG_MEMALIGN_HACK
 ptr = malloc(size + ALIGN);
 if (!ptr)
@@ -94,13 +130,13 @@ void *av_malloc(size_t size)
 ((char *)ptr)[-1] = diff;
 #elif HAVE_POSIX_MEMALIGN
 if (size) //OS X on SDK 10.6 has a broken posix_memalign implementation
-if (posix_memalign(, ALIGN, size))
+if (posix_memalign(, align, size))
 ptr = NULL;
 #elif HAVE_ALIGNED_MALLOC
 ptr = _aligned_malloc(size, ALIGN);
 #elif HAVE_MEMALIGN
 #ifndef __DJGPP__
-ptr = memalign(ALIGN, size);
+ptr = memalign(align, size);
 #else
 ptr = memalign(size, ALIGN);
 #endif
-- 
1.9.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavcodec/qsv.c: Re-design session control and internal allocation

[Gwenole Beauchesne]

Hi,

2015-10-07 18:40 GMT+02:00 wm4 <nfx...@googlemail.com>:
> On Wed, 7 Oct 2015 19:20:56 +0300
> Ivan Uskov <ivan.us...@nablet.com> wrote:
>
>> Hello Hendrik,
>>
>> Wednesday, October 7, 2015, 5:58:25 PM, you wrote:
>>
>> HL> On Wed, Oct 7, 2015 at 4:41 PM, Ivan Uskov <ivan.us...@nablet.com> wrote:
>>
>> HL> Global static variables are not acceptable, sorry.
>> HL> You'll have to find another way to solve your problem, but global
>> HL> state is not the way to go.
>> Unfortunately   I   do   not   have   ideas  how to provide single and common
>> memory  block  for  separatemodules   by  another  way.   Memory  mapping
>> files  looks not too portable and much more bulky solution then one global 
>> variable.
>> I  do  not  see  the  way to use appropriate field of AVCodecContext to share
>> global data.
>> Has anybody any ideas?
>> Is  me  missed  something?  There is really the necessary to have a global 
>> common
>> structure shared between decoder, vpp and decoder.
>>
>
> There's no automagic way to get this done.
>
> Hardware accelerators like vaapi and vdpau need the same thing. These
> have special APIs to set an API context on the decoder. Some APIs use
> hwaccel_context, vdpau uses av_vdpau_bind_context().
>
> The hwaccel_context pointer is untyped (just a void*), and what it means
> is implicit to the hwaccel or the decoder that is used. It could point
> to some sort of qsv state, which will have to be explicitly allocated
> and set by the API user (which might be ffmpeg.c).
>
> For filters there is no such thing yet. New API would have to be
> created. For filters in particular, we will have to make sure that the
> API isn't overly qsv-specific, and that it is extendable to other APIs
> (like for example vaapi or vdpau).

I have been looking into a slightly different way: the common object
being transported is an AVFrame. So, my initial approach is to create
an AV_FRAME_DATA_HWACCEL metadata. Lookups could be optimized by
keeping around an AVFrameInternal struct that resides in the same
allocation unit as the AVFrame. But, this is a detail.

From there, there are at least two usage models, when it comes to filters too:

1. Make the AVHWAccelFrame struct hold multiple hwaccel-specific info,
with a master one, and slave ones for various different APIs.
Advantage: a single AVFrame can be used and impersonified whenever
necessary. e.g. a VA surface master could be exported/re-used with an
mfxSurface, a dma_buf (for OpenCL), or userptr buffer. Drawback:
terribly tedious to manage.

2. Simpler approach: the AVHWAccelFrame holds a unique struct to
hwaccel specific data. Should we need to export that for use with
another API, it's not too complicated to av_frame_ref() + add new
hwaccel-specific metadata.

For VA-API specific purposes, I then have:
- AVVADisplay, which is refcounted, and that can handle automatic
initialize/terminate calls ;
- AVVAFrameBuffer that holds an { AVVADisplay, VASurfaceID, and
possibly VAImageID } tuple (for mappings in non-USWC memory), and that
populates AVFrame.buf[0].

I am undecided yet on whether I'd create an AV_PIX_FMT_HWACCEL format
and allow hwaccel specific AVFrame to absorb an existing AVFrame, as a
transitional method from existing vaapi hwaccel to "new" vaapi
hwaccel. In that new generic hwaccel format model, buf[0] et al. would
be clearly defined, and data[i] not supposed to be touched by user
application. For now, the trend towards that option is low in my mind.

PS: other benefit of the AVHWAccelFrame side-data is that I can stuff
crop information into there. Since this is only useful to hwaccel, no
need to populate AVFrame with additional fields IMHO.

>
> Unfortunately, you can be sure that we won't accept your current patch,
> though. Global mutable variables are a no in new code.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Regards,
-- 
Gwenole Beauchesne
Intel Corporation SAS / 2 rue de Paris, 92196 Meudon Cedex, France
Registration Number (RCS): Nanterre B 302 456 199
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavcodec/qsv.c: Re-design session control and internal allocation

[Gwenole Beauchesne]

Hi,

2015-10-23 15:41 GMT+02:00 wm4 <nfx...@googlemail.com>:
> On Fri, 23 Oct 2015 14:54:56 +0200
> Gwenole Beauchesne <gb.de...@gmail.com> wrote:
>
>> Hi,
>>
>> 2015-10-07 18:40 GMT+02:00 wm4 <nfx...@googlemail.com>:
>> > On Wed, 7 Oct 2015 19:20:56 +0300
>> > Ivan Uskov <ivan.us...@nablet.com> wrote:
>> >
>> >> Hello Hendrik,
>> >>
>> >> Wednesday, October 7, 2015, 5:58:25 PM, you wrote:
>> >>
>> >> HL> On Wed, Oct 7, 2015 at 4:41 PM, Ivan Uskov <ivan.us...@nablet.com> 
>> >> wrote:
>> >>
>> >> HL> Global static variables are not acceptable, sorry.
>> >> HL> You'll have to find another way to solve your problem, but global
>> >> HL> state is not the way to go.
>> >> Unfortunately   I   do   not   have   ideas  how to provide single and 
>> >> common
>> >> memory  block  for  separatemodules   by  another  way.   Memory  
>> >> mapping
>> >> files  looks not too portable and much more bulky solution then one 
>> >> global variable.
>> >> I  do  not  see  the  way to use appropriate field of AVCodecContext to 
>> >> share
>> >> global data.
>> >> Has anybody any ideas?
>> >> Is  me  missed  something?  There is really the necessary to have a 
>> >> global common
>> >> structure shared between decoder, vpp and decoder.
>> >>
>> >
>> > There's no automagic way to get this done.
>> >
>> > Hardware accelerators like vaapi and vdpau need the same thing. These
>> > have special APIs to set an API context on the decoder. Some APIs use
>> > hwaccel_context, vdpau uses av_vdpau_bind_context().
>> >
>> > The hwaccel_context pointer is untyped (just a void*), and what it means
>> > is implicit to the hwaccel or the decoder that is used. It could point
>> > to some sort of qsv state, which will have to be explicitly allocated
>> > and set by the API user (which might be ffmpeg.c).
>> >
>> > For filters there is no such thing yet. New API would have to be
>> > created. For filters in particular, we will have to make sure that the
>> > API isn't overly qsv-specific, and that it is extendable to other APIs
>> > (like for example vaapi or vdpau).
>>
>> I have been looking into a slightly different way: the common object
>> being transported is an AVFrame. So, my initial approach is to create
>> an AV_FRAME_DATA_HWACCEL metadata. Lookups could be optimized by
>> keeping around an AVFrameInternal struct that resides in the same
>> allocation unit as the AVFrame. But, this is a detail.
>>
>> From there, there are at least two usage models, when it comes to filters 
>> too:
>>
>> 1. Make the AVHWAccelFrame struct hold multiple hwaccel-specific info,
>> with a master one, and slave ones for various different APIs.
>> Advantage: a single AVFrame can be used and impersonified whenever
>> necessary. e.g. a VA surface master could be exported/re-used with an
>> mfxSurface, a dma_buf (for OpenCL), or userptr buffer. Drawback:
>> terribly tedious to manage.
>>
>> 2. Simpler approach: the AVHWAccelFrame holds a unique struct to
>> hwaccel specific data. Should we need to export that for use with
>> another API, it's not too complicated to av_frame_ref() + add new
>> hwaccel-specific metadata.
>
> It could be something like an API identifier (an enum or so) + API
> specific pointer to a struct.

That's exactly that:

/**
 * Hardware Accelerator identifier.
 *
 * @note
 * A hardware accelerator can be device-less. This means that only the
 * underlying hardware resource, e.g. a Linux dma_buf handle, is being
 * transported in the AVFrame. That hardware resource could be mapped
 * through standard OS-dependent calls, e.g. mmap() on Linux.
 */
enum AVHWAccelId {
AV_HWACCEL_ID_NONE = -1,
AV_HWACCEL_ID_VAAPI,
AV_HWACCEL_ID_NB,   ///< Not part of ABI
};

Name to be improved if people have better suggestions, as this really
is to be seen as HW resource, not necessarily attached to a particular
HW device. i.e. this could be a dma_buf handle from a V4L2 buffer or
VA surface.

I am reworking the patch series as I changed my mind again: current
map strategy was overly complex (and required to be). There were at
least 4 map flags: AV_FRAME_MAP_{READ,WRITE,READ_FIRST,USWC_MEMORY}. I
am now preferring a unique av_hwaccel_frame_get_pixels() defined as
follow:

/**
 * Returns AVFrame pixels into linear memory
 *
 * This function takes a snapshot of the underlying HW surfa

Re: [FFmpeg-devel] [PATCH][RFC] avcodec: disallow hwaccel with frame threads

[Gwenole Beauchesne]

2015-10-21 11:27 GMT+02:00 Hendrik Leppkes <h.lepp...@gmail.com>:
> On Sat, Oct 17, 2015 at 9:28 PM, Hendrik Leppkes <h.lepp...@gmail.com> wrote:
>> On Sat, Oct 17, 2015 at 9:27 PM, Hendrik Leppkes <h.lepp...@gmail.com> wrote:
>>> ---
>>>  libavcodec/utils.c | 6 ++
>>>  1 file changed, 6 insertions(+)
>>>
>>
>> Above patch is submitted as an RFC, however I strongly believe its the
>> only way to keep hwaccels sane in the future.
>> There are several known problems when a hwaccel is used with frame
>> threading, at least with DXVA2, ranging from simple image corruption
>> to crashes in the GPU drivers.
>>
>> All the problems essentially come down to two factors:
>>
>> (1) while avcodec tries to prevent simultaneous access from different
>> threads, it cannot control user code.
>> As a API user you have no chance to avoid simultaneous access to the
>> hardware surfaces with frame threading, because as soon as avcodec
>> hands you a decoded surface,
>> it'll already have started working on the next one. This is a common
>> source for image corruption, as the decoder may fail to get a
>> reference frame if its currently
>> locked by the user code.
>>
>> This issue is not really fixable, other than introducing a mutex
>> around every call that the user code would have to lock as well.
>> API break and making hwaccel even more complex to use.
>>
>> (2) decoders often have had (or still have) trouble initializing the
>> hwaccel properly with multiple threads, which can result in multiple
>> threads re-creating the hwaccel
>> and disrupting decoding, or even crashing in the driver.
>>
>> While this is in theory fixable inside the decoders in question, it
>> can lead to quite a bit of complexity, which should be avoided.
>>
>> We should not be offering a mode that is known to be broken and even
>> crash (even if the crash is not in our code).
>> On top of that, frame threading with hwaccel does not actually improve
>> the speed at all, if anything it might be slightly slower, and will
>> definitely use more GPU memory.
>>
>> The only reason this combination even exists is because API users
>> insisted on it, and it was then added without properly taking the
>> consequences into account.
>>
>> There is an easy solution to keep using frame threads with software
>> decoding while using a hwaccel otherwise - its used by myself, by mpv
>> and by Kodi - simply re-open the decoder with the new threading flags.
>> Its really not a lot of work, and keeps the code sane and the decoding 
>> reliable.
>>
>
> No further comments? No thoughts? No-one that would object if I were
> to push the proposed patch?

Fine with me.

Probably add a link to your ffmpeg-devel message since it provides all
the necessary rationale behind this?

Thanks,
-- 
Gwenole Beauchesne
Intel Corporation SAS / 2 rue de Paris, 92196 Meudon Cedex, France
Registration Number (RCS): Nanterre B 302 456 199
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC] QSV support clarifications

[Gwenole Beauchesne]

Hi,

2015-10-12 20:10 GMT+02:00 Stefano Sabatini <stefa...@gmail.com>:
> Hi all,
>
> I wanted to test QSV encoding and decoding, which is included since
> several months in FFmpeg, and have a few questions.
>
> 1. QSV encoding and decoding depends on libmfx, but no references are
> present in the code to the library, so I have to suppose that the
> required library is this one:
> https://github.com/lu-zero/mfx_dispatch

Luca's repo is indeed what allows it to build effortlessly, while also
supplying a DSO for libmfx.
It is also possible to build against the Intel supplied headers but a
correct pkg-config file is indeed missing, and additional configury
would be needed in the FFmpeg part to use the libs.private portions of
it. i.e. in case we are stuck to a static library.

FFmpeg should also provide an explicit link to libva-drm, since it
uses it in the MFX specific parts.

> While at it, do you know what's the point of the mfx_dispatch
> component (why adding the intel media library path to flags is not
> enough)?

Probably to select between the SW and HW implementations. :)

> 2. The mfx_dispatch library compiles fine on my system, but then I
> wonder how it is supposed to reference the Intel Media library:
> https://software.intel.com/en-us/intel-media-server-studio

IIRC, there is an installation script in the Media Server Studio.
However, I didn't use it but rather used the "Generic" variant and
installed everything into a dedicated subdirectory.

>
> ...
>
> I'm able to compile FFmpeg with --enable-libmfx after installing
> the mfx_dispatch library, and run this command:
> ffmpeg -i test.mp4 -c:v h264_qsv -y test.out.mp4
>
> but then it fails with:
> Error initializing an internal MFX session
>
> Running strace on the command it results that it's looking for the
> libmfxsw64.so library and failing:
> open("/lib/x86_64-linux-gnu/libmfxsw64.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT 
> (No such file or directory)
> open("/usr/lib/x86_64-linux-gnu/libmfxsw64.so", O_RDONLY|O_CLOEXEC) = -1 
> ENOENT (No such file or directory)
> open("/lib/libmfxsw64.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or 
> directory)
> open("/usr/lib/libmfxsw64.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file 
> or directory)
> munmap(0x7f9a55072000, 155122)  = 0
>
> If I update the LD_LIBRARY_PATH to point to the intel media library in
> /opt/intel/mediasdk it will find the library and then hang.
>
> I had some hard time finding relevant information on the Internet, so
> I ask if you can help to clarify these points.
>
> I'll happily provide a few benchmarks and update documentation
> accordingly if I manage to make it work.
> --
> FFmpeg = Fancy and Forgiving Mean Problematic Excellent Gymnast
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Regards,
-- 
Gwenole Beauchesne
Intel Corporation SAS / 2 rue de Paris, 92196 Meudon Cedex, France
Registration Number (RCS): Nanterre B 302 456 199
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [DECISION] Server "move"

[Gwenole Beauchesne]

Hi,

2015-09-22 14:21 GMT+02:00 Clément Bœsch :
> On Mon, Sep 21, 2015 at 08:27:47PM +0100, Kieran Kunhya wrote:
>> > This "decision" thingy, is intended to confirm that
>> > * Stuff should be moved to the telepoint server, possibly duplicates
>> >   should be left at/moved to the hetzner server for redundancy, if
>> >   this is technically possible (maybe it should be called copy instead
>> >   of move in that case)
>>
>> As discussed at VDD15 and posted to the admin IRC and emailed to the
>> root email address:
>> It was agreed by a large group of developers that this should be put
>> on hold and videolan remain a valid option.
>>
>
> Well, to be completely honest, it was Ronald & you mainly, the rest of the
> people in the room remained mostly silent, and it was about "a random
> server in Hungary [or sth like this] no ones know anything about".
>
> It was also raised the fact that using Videolan infrastructure needs a lot
> of work for the admins, for which most of us couldn't really say much
> about it.

That's probably part of the issue. Is there actually a precise list of
tasks that are needed to achieve the transition to VideoLAN's
infrastructure (Docker, etc.). From what I understood, the transition
is not impossible, "just" that nobody has time/desire/skills to
migrate everything in one-shot. The bug tracking system was also an
issue since videolan's trac instance was to be decommissioned.

Maybe if there was a well defined list of things to would make it
clearer to estimate the transition cost? And, in the worst case, it's
not as if VideoLabs was hosted in a famous hoster in France, and
probably some help could be gathered from there independently as a
service? :)

>
>> You can't just make these unilateral decisions.
>>
>
> We have a voting committee in order to make decision with a much better
> "large group of developers" defined, that's what this thread is about.
>
> That said, on a personal note I'm pretty much neutral about the decision
> taken as long as I'm not asked to do any work, so I have no opinion on
> which servers to keep or use in the future.
>
>> Kieran
>
> --
> Clément B.
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Opinons on adding "tickets fixed" to the Changelog

[Gwenole Beauchesne]

Hi,

2015-09-06 17:27 GMT+02:00 Ganesh Ajjanagadde <gajja...@mit.edu>:
> Hi all,
>
> I noticed that glibc lists all the tickets/bug reports fixed in the
> Changelog, and was wondering whether it would be beneficial if ffmpeg
> did the same for its releases.
>
> The benefit I see is that this is a "user-facing" change and thus
> ideally should be documented in the relase notes.
>
> The drawback I see is that this is an additional burden on the people
> in charge of the release, and technically one can examine the git logs
> to get the list of tickets fixed. On the other hand, such log
> examination can be troublesome for some users, and many might just
> obtain the snapshot lacking such history.
>
> I myself have no opinions on this.

I think, at the minimum, simply an URL to the ticket fixed in the git
commit log is enough. As to the ChangeLog or NEWS file, this is boring
by experience unless you generate that from the git log and the
summary was properly written already. :) And, anyway, to the end-user,
this doesn't really bring in much information. For him, I'd believe
"add XXX codec", or "fix/improve codec YYY" is just enough
information, IMHO.

I'd say, it depends on the amount of tickets fixed per release. I
don't think users are much interested in reading through 50+ ticket
numbers.

Regards,
-- 
Gwenole Beauchesne
Intel Corporation SAS / 2 rue de Paris, 92196 Meudon Cedex, France
Registration Number (RCS): Nanterre B 302 456 199
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2 2/3] vaapi: streamline public context structure.

[Gwenole Beauchesne]

Hi,

2015-08-19 16:12 GMT+02:00 Michael Niedermayer mich...@niedermayer.cc:
 On Wed, Aug 19, 2015 at 11:03:05AM +0200, Gwenole Beauchesne wrote:
 Move libavcodec managed objects from the public struct vaapi_context
 to a new privately owned FFVAContext. This is done so that to clean up
 and streamline the public structure, but also to prepare for new codec
 support, thus requiring new internal data to be added in there.

 The AVCodecContext.hwaccel_context, that holds the public vaapi_context,
 shall no longer be accessed from within vaapi_*.c codec support files.

 v2: add one minor check for hwaccel_context existence, mark older
   vaapi_context fields as deprecated until we reach lavc major+2,
   amend doc/APIchanges.

 Signed-off-by: Gwenole Beauchesne gwenole.beauche...@intel.com
 ---
  doc/APIchanges  |  4 
  libavcodec/vaapi.c  | 40 +++-
  libavcodec/vaapi.h  | 16 
  libavcodec/vaapi_h264.c | 10 +++---
  libavcodec/vaapi_internal.h | 42 --
  libavcodec/vaapi_mpeg2.c|  8 ++--
  libavcodec/vaapi_mpeg4.c| 11 +--
  libavcodec/vaapi_vc1.c  | 11 +--
  libavcodec/version.h|  3 +++
  9 files changed, 121 insertions(+), 24 deletions(-)
 [...]

 diff --git a/libavcodec/vaapi.h b/libavcodec/vaapi.h
 index 815a27e..4448a2e 100644
 --- a/libavcodec/vaapi.h
 +++ b/libavcodec/vaapi.h
 @@ -31,6 +31,8 @@
   */

  #include stdint.h
 +#include libavutil/attributes.h
 +#include version.h

 is this intended to be libavutil/attributes.h and not 
 libavutil/attributes.h ?

You are right. There are also other includes to fix. Though, I have
only removed the one that I was too bored to see hanging around. I
will fix.

Thanks,
-- 
Gwenole Beauchesne
Intel Corporation SAS / 2 rue de Paris, 92196 Meudon Cedex, France
Registration Number (RCS): Nanterre B 302 456 199
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [RFC 2/4] hwaccel: try get_buffer*() if hwaccel alloc_frame() yields ENOSYS.

[Gwenole Beauchesne]

By default, lavc can manage frame buffer allocations itself without
explicit intervention from the user and custom get_buffer*() hooks.
In view to simplifying usages, there is a desire to operate on the
same model for hardware accelerated pipelines, i.e. delegate all HW
resources management to lavc.

AVHWAccel.alloc_frame() can serve this purpose just fine. However,
if the previous model is needed, whereby get_buffer*() hooks are
required, there is zero chance to call into them if alloc_frame() is
defined.

One way to solve this problem is simply to detect this usage model
from the hwaccel implementation and return AVERROR(ENOSYS) in the
.alloc_frame() hook so that to notify get_buffer_internal() to try
to call into .get_buffer*() hooks.

This is an internal semantical change only, and does not affect any
existing hwaccel implementation.

Signed-off-by: Gwenole Beauchesne gwenole.beauche...@intel.com
---
 libavcodec/utils.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index d6be93d..321bdde 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -903,7 +903,9 @@ static int get_buffer_internal(AVCodecContext *avctx, 
AVFrame *frame, int flags)
 if (hwaccel) {
 if (hwaccel-alloc_frame) {
 ret = hwaccel-alloc_frame(avctx, frame);
-goto end;
+if (ret != AVERROR(ENOSYS))
+goto end;
+/* Try out through get_buffer2() interfaces */
 }
 } else
 avctx-sw_pix_fmt = avctx-pix_fmt;
-- 
1.9.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [RFC 0/4] vaapi: delegate HW resources allocation to lavc

[Gwenole Beauchesne]

Hi,

As indicated before, I foresee at most 2 use-cases for lavc/vaapi:
1. Allow for implicit allocation of HW resources in lavc ;
2. Allow for the user to share the pain and manage the HW resources:
   a. The old way through AVCodecContext.get_format() + maintaining a
  vaapi_context struct + multiple calls to .get_buffer2() or the
  even older .get_buffer*() family of functions ;
   b. The new way without vaapi_context, but through a unique
  interface, yet flexible: av_vaapi_set_pipeline_params(). In such
  case, the user provides VA display  context + .get_buffer2()
  hooks to satisfy his desire.

That's the goal: provide a simple enablement path of the client
application, yet still allowing for extended usages if ever needed.

To that end, I only need 2 non-intrusive and minimal additions/changes
to the core hwaccel infrastructure. One hwaccel_config dict to hold
pipeline parameters, and one fixlet to allow for fallbacks to
.get_buffer2().

On the vaapi side, there is a bit more fun to write/merge, but I would
like to prepare for even more additions. In short, I need various
casual helper functions related to vaapi, and that could be useful to
not only vaapi decoders, but also filters. For now, I stuffed the
minimal set of helpers I immediately need into libavcodec/vaapi_utils.c.

How much would you like a libavutil_vaapi/libavhwaccel_vaapi library?
This is really utility functions like av_freep() variants to
destroying VA resources (i.e. restting id to VA_INVALID_ID after
release for instance), converting a VAStatus to some FFmpeg error,
etc.

I have attached two additional patches so that to give a glimpse at
how it could look like.

Regards,
Gwenole Beauchesne (4):
  hwaccel: add infrastructure to hold accelerator config options.
  hwaccel: try get_buffer*() if hwaccel alloc_frame() yields ENOSYS.
  vaapi: add new API to configure a VA pipeline.
  vaapi: add common utilities.

 doc/APIchanges  |   6 +-
 libavcodec/Makefile |   4 +-
 libavcodec/internal.h   |  14 
 libavcodec/utils.c  |   6 +-
 libavcodec/vaapi.c  |  87 --
 libavcodec/vaapi.h  |  49 +++-
 libavcodec/vaapi_internal.h |   4 +
 libavcodec/vaapi_utils.c| 178 
 libavcodec/vaapi_utils.h|  53 +
 9 files changed, 386 insertions(+), 15 deletions(-)
 create mode 100644 libavcodec/vaapi_utils.c
 create mode 100644 libavcodec/vaapi_utils.h

-- 
1.9.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [RFC 3/4] vaapi: add new API to configure a VA pipeline.

[Gwenole Beauchesne]

Add av_vaapi_set_pipeline_params() interface to initialize the internal
FFVAContext with a valid VA display, and optional parameters including
a user-supplied VA context id.

This is preparatory work for delegating VA pipeline (decoder) creation
to libavcodec. Meanwhile, if this new interface is used, the user shall
provide the VA context id and a valid AVCodecContext.get_buffer2() hook.
Otherwise, the older vaapi_context approach is still supported.

This is an API change. The whole vaapi_context structure is no longer
needed, and thus deprecated.

Signed-off-by: Gwenole Beauchesne gwenole.beauche...@intel.com
---
 doc/APIchanges  |  6 ++--
 libavcodec/vaapi.c  | 87 -
 libavcodec/vaapi.h  | 49 +++--
 libavcodec/vaapi_internal.h |  4 +++
 4 files changed, 134 insertions(+), 12 deletions(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index aa92b69..fcdaa26 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -16,8 +16,10 @@ libavutil: 2014-08-09
 API changes, most recent first:
 
 2015-xx-xx - lavc 56.58.100 - vaapi.h
-  Deprecate old VA-API context (vaapi_context) fields that were only
-  set and used by libavcodec. They are all managed internally now.
+  Add new API to configure the hwaccel/vaapi pipeline, currently
+  useful for decoders: av_vaapi_set_pipeline_params()
+  Deprecate old VA-API context (vaapi_context) structure, which is no
+  longer used for initializing a VA-API decode pipeline.
 
 2015-xx-xx - lavu 54.31.100 - pixfmt.h
   Add a unique pixel format for VA-API (AV_PIX_FMT_VAAPI) that
diff --git a/libavcodec/vaapi.c b/libavcodec/vaapi.c
index c081bb5..afddbb3 100644
--- a/libavcodec/vaapi.c
+++ b/libavcodec/vaapi.c
@@ -41,24 +41,95 @@ static void destroy_buffers(VADisplay display, VABufferID 
*buffers, unsigned int
 }
 }
 
+/** @name VA-API pipeline parameters (internal) */
+/**@{*/
+/** Pipeline configuration flags (AV_HWACCEL_FLAG_*|AV_VAAPI_PIPELINE_FLAG_*) 
*/
+#define AV_VAAPI_PIPELINE_PARAM_FLAGS   flags
+/** User-supplied VA display handle */
+#define AV_VAAPI_PIPELINE_PARAM_DISPLAY display
+/**@}*/
+
+#define OFFSET(x) offsetof(FFVAContext, x)
+static const AVOption FFVAContextOptions[] = {
+{ AV_VAAPI_PIPELINE_PARAM_FLAGS, flags, OFFSET(flags),
+  AV_OPT_TYPE_INT, { .i64 = 0 }, 0, UINT32_MAX },
+{ AV_VAAPI_PIPELINE_PARAM_DISPLAY, VA display, OFFSET(user_display),
+  AV_OPT_TYPE_INT64, { .i64 = 0 }, 0, UINTPTR_MAX },
+{ AV_VAAPI_PIPELINE_PARAM_CONTEXT, VA context id, 
OFFSET(user_context_id),
+  AV_OPT_TYPE_INT, { .i64 = VA_INVALID_ID }, 0, UINT32_MAX },
+{ NULL, }
+};
+#undef OFFSET
+
+static const AVClass FFVAContextClass = {
+.class_name = FFVAContext,
+.item_name  = av_default_item_name,
+.option = FFVAContextOptions,
+.version= LIBAVUTIL_VERSION_INT,
+};
+
+int av_vaapi_set_pipeline_params(AVCodecContext *avctx, VADisplay display,
+ uint32_t flags, AVDictionary **params)
+{
+int ret;
+
+if (!display) {
+av_log(avctx, AV_LOG_ERROR, No valid VA display supplied.\n);
+return AVERROR(EINVAL);
+}
+
+if (params  *params)
+av_dict_copy(avctx-internal-hwaccel_config, *params, 0);
+
+ret = av_dict_set_int(avctx-internal-hwaccel_config,
+  AV_VAAPI_PIPELINE_PARAM_FLAGS, flags, 0);
+if (ret != 0)
+return ret;
+
+return av_dict_set_int(avctx-internal-hwaccel_config,
+   AV_VAAPI_PIPELINE_PARAM_DISPLAY,
+   (int64_t)(intptr_t)display, 0);
+}
+
 int ff_vaapi_context_init(AVCodecContext *avctx)
 {
 FFVAContext * const vactx = ff_vaapi_get_context(avctx);
-const struct vaapi_context * const user_vactx = avctx-hwaccel_context;
+int ret;
 
-if (!user_vactx) {
-av_log(avctx, AV_LOG_ERROR, Hardware acceleration context 
(hwaccel_context) does not exist.\n);
-return AVERROR(ENOSYS);
-}
+vactx-klass = FFVAContextClass;
+av_opt_set_defaults(vactx);
 
-vactx-display  = user_vactx-display;
-vactx-config_id= user_vactx-config_id;
-vactx-context_id   = user_vactx-context_id;
+#if FF_API_VAAPI_CONTEXT
+FF_DISABLE_DEPRECATION_WARNINGS
+if (avctx-hwaccel_context) {
+const struct vaapi_context * const user_vactx = avctx-hwaccel_context;
+vactx-user_display = (uintptr_t)user_vactx-display;
+vactx-user_context_id  = user_vactx-context_id;
+}
+FF_ENABLE_DEPRECATION_WARNINGS
+#endif
 
+vactx-context_id   = VA_INVALID_ID;
 vactx-pic_param_buf_id = VA_INVALID_ID;
 vactx-iq_matrix_buf_id = VA_INVALID_ID;
 vactx-bitplane_buf_id  = VA_INVALID_ID;
 
+ret = av_opt_set_dict(vactx, avctx-internal-hwaccel_config);
+if (ret != 0)
+return ret;
+
+vactx-display  = (void *)(uintptr_t)vactx-user_display

[FFmpeg-devel] [RFC 4/4] vaapi: add common utilities.

[Gwenole Beauchesne]

Handful set of self-contained utility functions:
- ff_vaapi_get_error():
  Converts VA status to an FFmpeg error code
- ff_vaapi_get_profiles():
  Retrieves all supported profiles
- ff_vaapi_get_entrypoints():
  Retrieves all supported entrypoints for the supplied profile
- ff_vaapi_get_chroma_format():
  Converts FFmpeg pixel format to VA chroma format
- ff_vaapi_get_pixel_format():
  Converts FFmpeg pixel format to VA fourcc

At some point, they could be migrated to some libavutil_vaapi and
exposed from there.

Signed-off-by: Gwenole Beauchesne gwenole.beauche...@intel.com
---
 libavcodec/Makefile  |   4 +-
 libavcodec/vaapi_utils.c | 178 +++
 libavcodec/vaapi_utils.h |  53 ++
 3 files changed, 233 insertions(+), 2 deletions(-)
 create mode 100644 libavcodec/vaapi_utils.c
 create mode 100644 libavcodec/vaapi_utils.h

diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index d595fe1..15f5a1b 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -696,7 +696,7 @@ OBJS-$(CONFIG_VIMA_DECODER)   += vima.o 
adpcm_data.o
 # hardware accelerators
 OBJS-$(CONFIG_D3D11VA)+= dxva2.o
 OBJS-$(CONFIG_DXVA2)  += dxva2.o
-OBJS-$(CONFIG_VAAPI)  += vaapi.o
+OBJS-$(CONFIG_VAAPI)  += vaapi.o vaapi_utils.o
 OBJS-$(CONFIG_VDA)+= vda.o videotoolbox.o
 OBJS-$(CONFIG_VIDEOTOOLBOX)   += videotoolbox.o
 OBJS-$(CONFIG_VDPAU)  += vdpau.o
@@ -919,7 +919,7 @@ SKIPHEADERS-$(CONFIG_QSV)  += qsv.h 
qsv_internal.h
 SKIPHEADERS-$(CONFIG_QSVDEC)   += qsvdec.h
 SKIPHEADERS-$(CONFIG_QSVENC)   += qsvenc.h
 SKIPHEADERS-$(CONFIG_XVMC) += xvmc.h
-SKIPHEADERS-$(CONFIG_VAAPI)+= vaapi_internal.h
+SKIPHEADERS-$(CONFIG_VAAPI)+= vaapi_internal.h vaapi_utils.h
 SKIPHEADERS-$(CONFIG_VDA)  += vda.h vda_vt_internal.h
 SKIPHEADERS-$(CONFIG_VDPAU)+= vdpau.h vdpau_internal.h
 SKIPHEADERS-$(CONFIG_VIDEOTOOLBOX) += videotoolbox.h vda_vt_internal.h
diff --git a/libavcodec/vaapi_utils.c b/libavcodec/vaapi_utils.c
new file mode 100644
index 000..5f8a5fa
--- /dev/null
+++ b/libavcodec/vaapi_utils.c
@@ -0,0 +1,178 @@
+/*
+ * vaapi_utils.c - Video Acceleration API (VA-API) utilities
+ *
+ * Copyright (C) 2013-2015 Intel Corporation
+ *   Author: Gwenole Beauchesne gwenole.beauche...@intel.com
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include vaapi_utils.h
+
+/* Converts VA status to an FFmpeg error code */
+int
+ff_vaapi_get_error(VAStatus status)
+{
+int ret;
+
+switch (status) {
+case VA_STATUS_ERROR_OPERATION_FAILED:
+ret = AVERROR(ENOTSUP);
+break;
+case VA_STATUS_ERROR_INVALID_DISPLAY:
+case VA_STATUS_ERROR_INVALID_CONFIG:
+case VA_STATUS_ERROR_INVALID_CONTEXT:
+case VA_STATUS_ERROR_INVALID_SURFACE:
+case VA_STATUS_ERROR_INVALID_BUFFER:
+case VA_STATUS_ERROR_INVALID_IMAGE:
+case VA_STATUS_ERROR_INVALID_SUBPICTURE:
+ret = AVERROR(EINVAL);
+break;
+case VA_STATUS_ERROR_INVALID_PARAMETER:
+case VA_STATUS_ERROR_INVALID_VALUE:
+ret = AVERROR(EINVAL);
+break;
+case VA_STATUS_ERROR_ALLOCATION_FAILED:
+ret = AVERROR(ENOMEM);
+break;
+case VA_STATUS_ERROR_UNIMPLEMENTED:
+ret = AVERROR(ENOSYS);
+break;
+case VA_STATUS_ERROR_SURFACE_BUSY:
+ret = AVERROR(EBUSY);
+break;
+default:
+ret = AVERROR_UNKNOWN;
+break;
+}
+return ret;
+}
+
+/* Retrieves all supported profiles */
+int
+ff_vaapi_get_profiles(VADisplay display, VAProfile **profiles_ptr,
+unsigned int *n_profiles_ptr)
+{
+VAStatus status;
+int n_profiles, ret;
+
+n_profiles = vaMaxNumProfiles(display);
+ret = av_reallocp_array(profiles_ptr, n_profiles, sizeof(VAProfile));
+if (ret != 0)
+return ret;
+
+status = vaQueryConfigProfiles(display, *profiles_ptr, n_profiles);
+if (status != VA_STATUS_SUCCESS)
+return ff_vaapi_get_error(status);
+
+if (n_profiles_ptr)
+*n_profiles_ptr = n_profiles;
+return 0;
+}
+
+/* Retrieves all supported

Re: [FFmpeg-devel] [RFC 3/4] vaapi: add new API to configure a VA pipeline.

[Gwenole Beauchesne]

Hi,

2015-08-19 18:50 GMT+02:00 wm4 nfx...@googlemail.com:
 On Wed, 19 Aug 2015 18:01:36 +0200
 Gwenole Beauchesne gb.de...@gmail.com wrote:

 Add av_vaapi_set_pipeline_params() interface to initialize the internal
 FFVAContext with a valid VA display, and optional parameters including
 a user-supplied VA context id.

 This is preparatory work for delegating VA pipeline (decoder) creation
 to libavcodec. Meanwhile, if this new interface is used, the user shall
 provide the VA context id and a valid AVCodecContext.get_buffer2() hook.
 Otherwise, the older vaapi_context approach is still supported.

 This is an API change. The whole vaapi_context structure is no longer
 needed, and thus deprecated.

 Signed-off-by: Gwenole Beauchesne gwenole.beauche...@intel.com
 ---
  doc/APIchanges  |  6 ++--
  libavcodec/vaapi.c  | 87 
 -
  libavcodec/vaapi.h  | 49 +++--
  libavcodec/vaapi_internal.h |  4 +++
  4 files changed, 134 insertions(+), 12 deletions(-)

 diff --git a/doc/APIchanges b/doc/APIchanges
 index aa92b69..fcdaa26 100644
 --- a/doc/APIchanges
 +++ b/doc/APIchanges
 @@ -16,8 +16,10 @@ libavutil: 2014-08-09
  API changes, most recent first:

  2015-xx-xx - lavc 56.58.100 - vaapi.h
 -  Deprecate old VA-API context (vaapi_context) fields that were only
 -  set and used by libavcodec. They are all managed internally now.
 +  Add new API to configure the hwaccel/vaapi pipeline, currently
 +  useful for decoders: av_vaapi_set_pipeline_params()
 +  Deprecate old VA-API context (vaapi_context) structure, which is no
 +  longer used for initializing a VA-API decode pipeline.

  2015-xx-xx - lavu 54.31.100 - pixfmt.h
Add a unique pixel format for VA-API (AV_PIX_FMT_VAAPI) that
 diff --git a/libavcodec/vaapi.c b/libavcodec/vaapi.c
 index c081bb5..afddbb3 100644
 --- a/libavcodec/vaapi.c
 +++ b/libavcodec/vaapi.c
 @@ -41,24 +41,95 @@ static void destroy_buffers(VADisplay display, 
 VABufferID *buffers, unsigned int
  }
  }

 +/** @name VA-API pipeline parameters (internal) */
 +/**@{*/
 +/** Pipeline configuration flags 
 (AV_HWACCEL_FLAG_*|AV_VAAPI_PIPELINE_FLAG_*) */
 +#define AV_VAAPI_PIPELINE_PARAM_FLAGS   flags
 +/** User-supplied VA display handle */
 +#define AV_VAAPI_PIPELINE_PARAM_DISPLAY display
 +/**@}*/
 +
 +#define OFFSET(x) offsetof(FFVAContext, x)
 +static const AVOption FFVAContextOptions[] = {
 +{ AV_VAAPI_PIPELINE_PARAM_FLAGS, flags, OFFSET(flags),
 +  AV_OPT_TYPE_INT, { .i64 = 0 }, 0, UINT32_MAX },
 +{ AV_VAAPI_PIPELINE_PARAM_DISPLAY, VA display, OFFSET(user_display),
 +  AV_OPT_TYPE_INT64, { .i64 = 0 }, 0, UINTPTR_MAX },
 +{ AV_VAAPI_PIPELINE_PARAM_CONTEXT, VA context id, 
 OFFSET(user_context_id),
 +  AV_OPT_TYPE_INT, { .i64 = VA_INVALID_ID }, 0, UINT32_MAX },
 +{ NULL, }
 +};
 +#undef OFFSET
 +
 +static const AVClass FFVAContextClass = {
 +.class_name = FFVAContext,
 +.item_name  = av_default_item_name,
 +.option = FFVAContextOptions,
 +.version= LIBAVUTIL_VERSION_INT,
 +};
 +
 +int av_vaapi_set_pipeline_params(AVCodecContext *avctx, VADisplay display,
 + uint32_t flags, AVDictionary **params)
 +{
 +int ret;
 +
 +if (!display) {
 +av_log(avctx, AV_LOG_ERROR, No valid VA display supplied.\n);
 +return AVERROR(EINVAL);
 +}
 +
 +if (params  *params)
 +av_dict_copy(avctx-internal-hwaccel_config, *params, 0);
 +
 +ret = av_dict_set_int(avctx-internal-hwaccel_config,
 +  AV_VAAPI_PIPELINE_PARAM_FLAGS, flags, 0);
 +if (ret != 0)
 +return ret;
 +
 +return av_dict_set_int(avctx-internal-hwaccel_config,
 +   AV_VAAPI_PIPELINE_PARAM_DISPLAY,
 +   (int64_t)(intptr_t)display, 0);
 +}
 +
  int ff_vaapi_context_init(AVCodecContext *avctx)
  {
  FFVAContext * const vactx = ff_vaapi_get_context(avctx);
 -const struct vaapi_context * const user_vactx = avctx-hwaccel_context;
 +int ret;

 -if (!user_vactx) {
 -av_log(avctx, AV_LOG_ERROR, Hardware acceleration context 
 (hwaccel_context) does not exist.\n);
 -return AVERROR(ENOSYS);
 -}
 +vactx-klass = FFVAContextClass;
 +av_opt_set_defaults(vactx);

 -vactx-display  = user_vactx-display;
 -vactx-config_id= user_vactx-config_id;
 -vactx-context_id   = user_vactx-context_id;
 +#if FF_API_VAAPI_CONTEXT
 +FF_DISABLE_DEPRECATION_WARNINGS
 +if (avctx-hwaccel_context) {
 +const struct vaapi_context * const user_vactx = 
 avctx-hwaccel_context;
 +vactx-user_display = (uintptr_t)user_vactx-display;
 +vactx-user_context_id  = user_vactx-context_id;
 +}
 +FF_ENABLE_DEPRECATION_WARNINGS
 +#endif

 +vactx-context_id   = VA_INVALID_ID;
  vactx-pic_param_buf_id = VA_INVALID_ID;
  vactx-iq_matrix_buf_id

Re: [FFmpeg-devel] [RFC 3/4] vaapi: add new API to configure a VA pipeline.

[Gwenole Beauchesne]

2015-08-19 19:19 GMT+02:00 Gwenole Beauchesne gb.de...@gmail.com:
 Hi,

 2015-08-19 18:50 GMT+02:00 wm4 nfx...@googlemail.com:
 On Wed, 19 Aug 2015 18:01:36 +0200
 Gwenole Beauchesne gb.de...@gmail.com wrote:

 Add av_vaapi_set_pipeline_params() interface to initialize the internal
 FFVAContext with a valid VA display, and optional parameters including
 a user-supplied VA context id.

 This is preparatory work for delegating VA pipeline (decoder) creation
 to libavcodec. Meanwhile, if this new interface is used, the user shall
 provide the VA context id and a valid AVCodecContext.get_buffer2() hook.
 Otherwise, the older vaapi_context approach is still supported.

 This is an API change. The whole vaapi_context structure is no longer
 needed, and thus deprecated.

 Signed-off-by: Gwenole Beauchesne gwenole.beauche...@intel.com
 ---
  doc/APIchanges  |  6 ++--
  libavcodec/vaapi.c  | 87 
 -
  libavcodec/vaapi.h  | 49 +++--
  libavcodec/vaapi_internal.h |  4 +++
  4 files changed, 134 insertions(+), 12 deletions(-)

 diff --git a/doc/APIchanges b/doc/APIchanges
 index aa92b69..fcdaa26 100644
 --- a/doc/APIchanges
 +++ b/doc/APIchanges
 @@ -16,8 +16,10 @@ libavutil: 2014-08-09
  API changes, most recent first:

  2015-xx-xx - lavc 56.58.100 - vaapi.h
 -  Deprecate old VA-API context (vaapi_context) fields that were only
 -  set and used by libavcodec. They are all managed internally now.
 +  Add new API to configure the hwaccel/vaapi pipeline, currently
 +  useful for decoders: av_vaapi_set_pipeline_params()
 +  Deprecate old VA-API context (vaapi_context) structure, which is no
 +  longer used for initializing a VA-API decode pipeline.

  2015-xx-xx - lavu 54.31.100 - pixfmt.h
Add a unique pixel format for VA-API (AV_PIX_FMT_VAAPI) that
 diff --git a/libavcodec/vaapi.c b/libavcodec/vaapi.c
 index c081bb5..afddbb3 100644
 --- a/libavcodec/vaapi.c
 +++ b/libavcodec/vaapi.c
 @@ -41,24 +41,95 @@ static void destroy_buffers(VADisplay display, 
 VABufferID *buffers, unsigned int
  }
  }

 +/** @name VA-API pipeline parameters (internal) */
 +/**@{*/
 +/** Pipeline configuration flags 
 (AV_HWACCEL_FLAG_*|AV_VAAPI_PIPELINE_FLAG_*) */
 +#define AV_VAAPI_PIPELINE_PARAM_FLAGS   flags
 +/** User-supplied VA display handle */
 +#define AV_VAAPI_PIPELINE_PARAM_DISPLAY display
 +/**@}*/
 +
 +#define OFFSET(x) offsetof(FFVAContext, x)
 +static const AVOption FFVAContextOptions[] = {
 +{ AV_VAAPI_PIPELINE_PARAM_FLAGS, flags, OFFSET(flags),
 +  AV_OPT_TYPE_INT, { .i64 = 0 }, 0, UINT32_MAX },
 +{ AV_VAAPI_PIPELINE_PARAM_DISPLAY, VA display, OFFSET(user_display),
 +  AV_OPT_TYPE_INT64, { .i64 = 0 }, 0, UINTPTR_MAX },
 +{ AV_VAAPI_PIPELINE_PARAM_CONTEXT, VA context id, 
 OFFSET(user_context_id),
 +  AV_OPT_TYPE_INT, { .i64 = VA_INVALID_ID }, 0, UINT32_MAX },
 +{ NULL, }
 +};
 +#undef OFFSET
 +
 +static const AVClass FFVAContextClass = {
 +.class_name = FFVAContext,
 +.item_name  = av_default_item_name,
 +.option = FFVAContextOptions,
 +.version= LIBAVUTIL_VERSION_INT,
 +};
 +
 +int av_vaapi_set_pipeline_params(AVCodecContext *avctx, VADisplay display,
 + uint32_t flags, AVDictionary **params)
 +{
 +int ret;
 +
 +if (!display) {
 +av_log(avctx, AV_LOG_ERROR, No valid VA display supplied.\n);
 +return AVERROR(EINVAL);
 +}
 +
 +if (params  *params)
 +av_dict_copy(avctx-internal-hwaccel_config, *params, 0);
 +
 +ret = av_dict_set_int(avctx-internal-hwaccel_config,
 +  AV_VAAPI_PIPELINE_PARAM_FLAGS, flags, 0);
 +if (ret != 0)
 +return ret;
 +
 +return av_dict_set_int(avctx-internal-hwaccel_config,
 +   AV_VAAPI_PIPELINE_PARAM_DISPLAY,
 +   (int64_t)(intptr_t)display, 0);
 +}
 +
  int ff_vaapi_context_init(AVCodecContext *avctx)
  {
  FFVAContext * const vactx = ff_vaapi_get_context(avctx);
 -const struct vaapi_context * const user_vactx = avctx-hwaccel_context;
 +int ret;

 -if (!user_vactx) {
 -av_log(avctx, AV_LOG_ERROR, Hardware acceleration context 
 (hwaccel_context) does not exist.\n);
 -return AVERROR(ENOSYS);
 -}
 +vactx-klass = FFVAContextClass;
 +av_opt_set_defaults(vactx);

 -vactx-display  = user_vactx-display;
 -vactx-config_id= user_vactx-config_id;
 -vactx-context_id   = user_vactx-context_id;
 +#if FF_API_VAAPI_CONTEXT
 +FF_DISABLE_DEPRECATION_WARNINGS
 +if (avctx-hwaccel_context) {
 +const struct vaapi_context * const user_vactx = 
 avctx-hwaccel_context;
 +vactx-user_display = (uintptr_t)user_vactx-display;
 +vactx-user_context_id  = user_vactx-context_id;
 +}
 +FF_ENABLE_DEPRECATION_WARNINGS
 +#endif

 +vactx-context_id   = VA_INVALID_ID;
  vactx

Re: [FFmpeg-devel] [RFC 3/4] vaapi: add new API to configure a VA pipeline.

[Gwenole Beauchesne]

Hi,

2015-08-19 21:57 GMT+02:00 wm4 nfx...@googlemail.com:
 On Wed, 19 Aug 2015 19:32:27 +0200
 Gwenole Beauchesne gb.de...@gmail.com wrote:

 2015-08-19 19:19 GMT+02:00 Gwenole Beauchesne gb.de...@gmail.com:
  Hi,
 
  2015-08-19 18:50 GMT+02:00 wm4 nfx...@googlemail.com:
  On Wed, 19 Aug 2015 18:01:36 +0200
  Gwenole Beauchesne gb.de...@gmail.com wrote:
 
  Add av_vaapi_set_pipeline_params() interface to initialize the internal
  FFVAContext with a valid VA display, and optional parameters including
  a user-supplied VA context id.
 
  This is preparatory work for delegating VA pipeline (decoder) creation
  to libavcodec. Meanwhile, if this new interface is used, the user shall
  provide the VA context id and a valid AVCodecContext.get_buffer2() hook.
  Otherwise, the older vaapi_context approach is still supported.
 
  This is an API change. The whole vaapi_context structure is no longer
  needed, and thus deprecated.
 
  Signed-off-by: Gwenole Beauchesne gwenole.beauche...@intel.com
  ---
   doc/APIchanges  |  6 ++--
   libavcodec/vaapi.c  | 87 
  -
   libavcodec/vaapi.h  | 49 +++--
   libavcodec/vaapi_internal.h |  4 +++
   4 files changed, 134 insertions(+), 12 deletions(-)
 
  diff --git a/doc/APIchanges b/doc/APIchanges
  index aa92b69..fcdaa26 100644
  --- a/doc/APIchanges
  +++ b/doc/APIchanges
  @@ -16,8 +16,10 @@ libavutil: 2014-08-09
   API changes, most recent first:
 
   2015-xx-xx - lavc 56.58.100 - vaapi.h
  -  Deprecate old VA-API context (vaapi_context) fields that were only
  -  set and used by libavcodec. They are all managed internally now.
  +  Add new API to configure the hwaccel/vaapi pipeline, currently
  +  useful for decoders: av_vaapi_set_pipeline_params()
  +  Deprecate old VA-API context (vaapi_context) structure, which is no
  +  longer used for initializing a VA-API decode pipeline.
 
   2015-xx-xx - lavu 54.31.100 - pixfmt.h
 Add a unique pixel format for VA-API (AV_PIX_FMT_VAAPI) that
  diff --git a/libavcodec/vaapi.c b/libavcodec/vaapi.c
  index c081bb5..afddbb3 100644
  --- a/libavcodec/vaapi.c
  +++ b/libavcodec/vaapi.c
  @@ -41,24 +41,95 @@ static void destroy_buffers(VADisplay display, 
  VABufferID *buffers, unsigned int
   }
   }
 
  +/** @name VA-API pipeline parameters (internal) */
  +/**@{*/
  +/** Pipeline configuration flags 
  (AV_HWACCEL_FLAG_*|AV_VAAPI_PIPELINE_FLAG_*) */
  +#define AV_VAAPI_PIPELINE_PARAM_FLAGS   flags
  +/** User-supplied VA display handle */
  +#define AV_VAAPI_PIPELINE_PARAM_DISPLAY display
  +/**@}*/
  +
  +#define OFFSET(x) offsetof(FFVAContext, x)
  +static const AVOption FFVAContextOptions[] = {
  +{ AV_VAAPI_PIPELINE_PARAM_FLAGS, flags, OFFSET(flags),
  +  AV_OPT_TYPE_INT, { .i64 = 0 }, 0, UINT32_MAX },
  +{ AV_VAAPI_PIPELINE_PARAM_DISPLAY, VA display, 
  OFFSET(user_display),
  +  AV_OPT_TYPE_INT64, { .i64 = 0 }, 0, UINTPTR_MAX },
  +{ AV_VAAPI_PIPELINE_PARAM_CONTEXT, VA context id, 
  OFFSET(user_context_id),
  +  AV_OPT_TYPE_INT, { .i64 = VA_INVALID_ID }, 0, UINT32_MAX },
  +{ NULL, }
  +};
  +#undef OFFSET
  +
  +static const AVClass FFVAContextClass = {
  +.class_name = FFVAContext,
  +.item_name  = av_default_item_name,
  +.option = FFVAContextOptions,
  +.version= LIBAVUTIL_VERSION_INT,
  +};
  +
  +int av_vaapi_set_pipeline_params(AVCodecContext *avctx, VADisplay 
  display,
  + uint32_t flags, AVDictionary **params)
  +{
  +int ret;
  +
  +if (!display) {
  +av_log(avctx, AV_LOG_ERROR, No valid VA display supplied.\n);
  +return AVERROR(EINVAL);
  +}
  +
  +if (params  *params)
  +av_dict_copy(avctx-internal-hwaccel_config, *params, 0);
  +
  +ret = av_dict_set_int(avctx-internal-hwaccel_config,
  +  AV_VAAPI_PIPELINE_PARAM_FLAGS, flags, 0);
  +if (ret != 0)
  +return ret;
  +
  +return av_dict_set_int(avctx-internal-hwaccel_config,
  +   AV_VAAPI_PIPELINE_PARAM_DISPLAY,
  +   (int64_t)(intptr_t)display, 0);
  +}
  +
   int ff_vaapi_context_init(AVCodecContext *avctx)
   {
   FFVAContext * const vactx = ff_vaapi_get_context(avctx);
  -const struct vaapi_context * const user_vactx = 
  avctx-hwaccel_context;
  +int ret;
 
  -if (!user_vactx) {
  -av_log(avctx, AV_LOG_ERROR, Hardware acceleration context 
  (hwaccel_context) does not exist.\n);
  -return AVERROR(ENOSYS);
  -}
  +vactx-klass = FFVAContextClass;
  +av_opt_set_defaults(vactx);
 
  -vactx-display  = user_vactx-display;
  -vactx-config_id= user_vactx-config_id;
  -vactx-context_id   = user_vactx-context_id;
  +#if FF_API_VAAPI_CONTEXT
  +FF_DISABLE_DEPRECATION_WARNINGS
  +if (avctx-hwaccel_context) {
  +const struct vaapi_context

[FFmpeg-devel] [PATCH v2 0/3] vaapi: minor refinements fixes

[Gwenole Beauchesne]

Hi,

This is preparatory and minimal work in view to supporting other (WIP)
changes. I will push those by tomorrow if there is no other strong
objections.

For convenience, I have placed the code here:
https://github.com/gbeauchesne/FFmpeg/tree/10.vaapi.lavc.fixes

Regards,
Gwenole Beauchesne (3):
  vaapi: define a unique pixel format for VA-API (AV_PIX_FMT_VAAPI).
  vaapi: streamline public context structure.
  vaapi: fix usage of invalid buffer ids.

 doc/APIchanges  | 10 
 libavcodec/h263dec.c|  2 +-
 libavcodec/h264_slice.c |  2 +-
 libavcodec/mpeg12dec.c  |  2 +-
 libavcodec/vaapi.c  | 60 -
 libavcodec/vaapi.h  | 16 
 libavcodec/vaapi_h264.c | 12 ++---
 libavcodec/vaapi_internal.h | 42 ++-
 libavcodec/vaapi_mpeg2.c| 10 +---
 libavcodec/vaapi_mpeg4.c| 15 +---
 libavcodec/vaapi_vc1.c  | 15 +---
 libavcodec/vc1dec.c |  2 +-
 libavcodec/version.h|  3 +++
 libavutil/pixdesc.c |  9 +++
 libavutil/pixfmt.h  | 12 +
 libavutil/version.h |  3 +++
 16 files changed, 173 insertions(+), 42 deletions(-)

-- 
1.9.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH v2 1/3] vaapi: define a unique pixel format for VA-API (AV_PIX_FMT_VAAPI).

[Gwenole Beauchesne]

Deprecate older VA pixel formats (MOCO, IDCT) as it is now very unlikely
to ever be useful in the future. Only keep plain AV_PIX_FMT_VAAPI format
that is aliased to the older VLD variant.

This is an API change.

v2: fix build when FF_API_VAAPI=0, mark older pixel formats as
  deprecated until we reach lavu major+2, amend doc/APIchanges.

Signed-off-by: Gwenole Beauchesne gwenole.beauche...@intel.com
---
 doc/APIchanges   |  6 ++
 libavcodec/h263dec.c |  2 +-
 libavcodec/h264_slice.c  |  2 +-
 libavcodec/mpeg12dec.c   |  2 +-
 libavcodec/vaapi_h264.c  |  2 +-
 libavcodec/vaapi_mpeg2.c |  2 +-
 libavcodec/vaapi_mpeg4.c |  4 ++--
 libavcodec/vaapi_vc1.c   |  4 ++--
 libavcodec/vc1dec.c  |  2 +-
 libavutil/pixdesc.c  |  9 +
 libavutil/pixfmt.h   | 12 
 libavutil/version.h  |  3 +++
 12 files changed, 40 insertions(+), 10 deletions(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index cce2ddb..f5ba678 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,12 @@ libavutil: 2014-08-09
 
 API changes, most recent first:
 
+2015-xx-xx - lavc 54.30.0 - pixfmt.h
+  Add a unique pixel format for VA-API (AV_PIX_FMT_VAAPI) that
+  indicates the nature of the underlying storage: a VA surface.
+  Deprecate old VA-API related pixel formats: AV_PIX_FMT_VAAPI_MOCO,
+  AV_PIX_FMT_VAAPI_IDCT, AV_PIX_FMT_VAAPI_VLD.
+
 2015-xx-xx - lavu 54.30.0
   xxx -  Add av_blowfish_alloc().
   xxx -  Add av_rc4_alloc().
diff --git a/libavcodec/h263dec.c b/libavcodec/h263dec.c
index 8f28a94..c85ea9d 100644
--- a/libavcodec/h263dec.c
+++ b/libavcodec/h263dec.c
@@ -720,7 +720,7 @@ frame_end:
 
 const enum AVPixelFormat ff_h263_hwaccel_pixfmt_list_420[] = {
 #if CONFIG_H263_VAAPI_HWACCEL || CONFIG_MPEG4_VAAPI_HWACCEL
-AV_PIX_FMT_VAAPI_VLD,
+AV_PIX_FMT_VAAPI,
 #endif
 #if CONFIG_H263_VDPAU_HWACCEL || CONFIG_MPEG4_VDPAU_HWACCEL
 AV_PIX_FMT_VDPAU,
diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index e330489..5c116b0 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -946,7 +946,7 @@ static enum AVPixelFormat get_pixel_format(H264Context *h, 
int force_callback)
 *fmt++ = AV_PIX_FMT_D3D11VA_VLD;
 #endif
 #if CONFIG_H264_VAAPI_HWACCEL
-*fmt++ = AV_PIX_FMT_VAAPI_VLD;
+*fmt++ = AV_PIX_FMT_VAAPI;
 #endif
 #if CONFIG_H264_VDA_HWACCEL
 *fmt++ = AV_PIX_FMT_VDA_VLD;
diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
index 4f60a1c..3e5ef0e 100644
--- a/libavcodec/mpeg12dec.c
+++ b/libavcodec/mpeg12dec.c
@@ -1213,7 +1213,7 @@ static const enum AVPixelFormat 
mpeg2_hwaccel_pixfmt_list_420[] = {
 AV_PIX_FMT_D3D11VA_VLD,
 #endif
 #if CONFIG_MPEG2_VAAPI_HWACCEL
-AV_PIX_FMT_VAAPI_VLD,
+AV_PIX_FMT_VAAPI,
 #endif
 #if CONFIG_MPEG2_VIDEOTOOLBOX_HWACCEL
 AV_PIX_FMT_VIDEOTOOLBOX,
diff --git a/libavcodec/vaapi_h264.c b/libavcodec/vaapi_h264.c
index 151aca9..55ee2fc 100644
--- a/libavcodec/vaapi_h264.c
+++ b/libavcodec/vaapi_h264.c
@@ -359,7 +359,7 @@ AVHWAccel ff_h264_vaapi_hwaccel = {
 .name   = h264_vaapi,
 .type   = AVMEDIA_TYPE_VIDEO,
 .id = AV_CODEC_ID_H264,
-.pix_fmt= AV_PIX_FMT_VAAPI_VLD,
+.pix_fmt= AV_PIX_FMT_VAAPI,
 .start_frame= vaapi_h264_start_frame,
 .end_frame  = vaapi_h264_end_frame,
 .decode_slice   = vaapi_h264_decode_slice,
diff --git a/libavcodec/vaapi_mpeg2.c b/libavcodec/vaapi_mpeg2.c
index 87fab89..27c69cd 100644
--- a/libavcodec/vaapi_mpeg2.c
+++ b/libavcodec/vaapi_mpeg2.c
@@ -138,7 +138,7 @@ AVHWAccel ff_mpeg2_vaapi_hwaccel = {
 .name   = mpeg2_vaapi,
 .type   = AVMEDIA_TYPE_VIDEO,
 .id = AV_CODEC_ID_MPEG2VIDEO,
-.pix_fmt= AV_PIX_FMT_VAAPI_VLD,
+.pix_fmt= AV_PIX_FMT_VAAPI,
 .start_frame= vaapi_mpeg2_start_frame,
 .end_frame  = ff_vaapi_mpeg_end_frame,
 .decode_slice   = vaapi_mpeg2_decode_slice,
diff --git a/libavcodec/vaapi_mpeg4.c b/libavcodec/vaapi_mpeg4.c
index 9b283f7..5b2e9d4 100644
--- a/libavcodec/vaapi_mpeg4.c
+++ b/libavcodec/vaapi_mpeg4.c
@@ -141,7 +141,7 @@ AVHWAccel ff_mpeg4_vaapi_hwaccel = {
 .name   = mpeg4_vaapi,
 .type   = AVMEDIA_TYPE_VIDEO,
 .id = AV_CODEC_ID_MPEG4,
-.pix_fmt= AV_PIX_FMT_VAAPI_VLD,
+.pix_fmt= AV_PIX_FMT_VAAPI,
 .start_frame= vaapi_mpeg4_start_frame,
 .end_frame  = ff_vaapi_mpeg_end_frame,
 .decode_slice   = vaapi_mpeg4_decode_slice,
@@ -153,7 +153,7 @@ AVHWAccel ff_h263_vaapi_hwaccel = {
 .name   = h263_vaapi,
 .type   = AVMEDIA_TYPE_VIDEO,
 .id = AV_CODEC_ID_H263,
-.pix_fmt= AV_PIX_FMT_VAAPI_VLD,
+.pix_fmt= AV_PIX_FMT_VAAPI,
 .start_frame= vaapi_mpeg4_start_frame,
 .end_frame  = ff_vaapi_mpeg_end_frame,
 .decode_slice   = vaapi_mpeg4_decode_slice,
diff --git a/libavcodec/vaapi_vc1.c b

[FFmpeg-devel] [PATCH v2 2/3] vaapi: streamline public context structure.

[Gwenole Beauchesne]

Move libavcodec managed objects from the public struct vaapi_context
to a new privately owned FFVAContext. This is done so that to clean up
and streamline the public structure, but also to prepare for new codec
support, thus requiring new internal data to be added in there.

The AVCodecContext.hwaccel_context, that holds the public vaapi_context,
shall no longer be accessed from within vaapi_*.c codec support files.

v2: add one minor check for hwaccel_context existence, mark older
  vaapi_context fields as deprecated until we reach lavc major+2,
  amend doc/APIchanges.

Signed-off-by: Gwenole Beauchesne gwenole.beauche...@intel.com
---
 doc/APIchanges  |  4 
 libavcodec/vaapi.c  | 40 +++-
 libavcodec/vaapi.h  | 16 
 libavcodec/vaapi_h264.c | 10 +++---
 libavcodec/vaapi_internal.h | 42 --
 libavcodec/vaapi_mpeg2.c|  8 ++--
 libavcodec/vaapi_mpeg4.c| 11 +--
 libavcodec/vaapi_vc1.c  | 11 +--
 libavcodec/version.h|  3 +++
 9 files changed, 121 insertions(+), 24 deletions(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index f5ba678..7d339ac 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,10 @@ libavutil: 2014-08-09
 
 API changes, most recent first:
 
+2015-xx-xx - lavc 56.57.0 - vaapi.h
+  Deprecate old VA-API context (vaapi_context) fields that were only
+  set and used by libavcodec. They are all managed internally now.
+
 2015-xx-xx - lavc 54.30.0 - pixfmt.h
   Add a unique pixel format for VA-API (AV_PIX_FMT_VAAPI) that
   indicates the nature of the underlying storage: a VA surface.
diff --git a/libavcodec/vaapi.c b/libavcodec/vaapi.c
index 6ac22e6..5dc43e1 100644
--- a/libavcodec/vaapi.c
+++ b/libavcodec/vaapi.c
@@ -21,6 +21,7 @@
  * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
  */
 
+#include libavutil/log.h
 #include h264.h
 #include vaapi_internal.h
 
@@ -41,7 +42,28 @@ static void destroy_buffers(VADisplay display, VABufferID 
*buffers, unsigned int
 }
 }
 
-int ff_vaapi_render_picture(struct vaapi_context *vactx, VASurfaceID surface)
+int ff_vaapi_context_init(AVCodecContext *avctx)
+{
+FFVAContext * const vactx = ff_vaapi_get_context(avctx);
+const struct vaapi_context * const user_vactx = avctx-hwaccel_context;
+
+if (!user_vactx) {
+av_log(avctx, AV_LOG_ERROR, Hardware acceleration context 
(hwaccel_context) does not exist.\n);
+return AVERROR(ENOSYS);
+}
+
+vactx-display  = user_vactx-display;
+vactx-config_id= user_vactx-config_id;
+vactx-context_id   = user_vactx-context_id;
+return 0;
+}
+
+int ff_vaapi_context_fini(AVCodecContext *avctx)
+{
+return 0;
+}
+
+int ff_vaapi_render_picture(FFVAContext *vactx, VASurfaceID surface)
 {
 VABufferID va_buffers[3];
 unsigned int n_va_buffers = 0;
@@ -81,7 +103,7 @@ int ff_vaapi_render_picture(struct vaapi_context *vactx, 
VASurfaceID surface)
 return 0;
 }
 
-int ff_vaapi_commit_slices(struct vaapi_context *vactx)
+int ff_vaapi_commit_slices(FFVAContext *vactx)
 {
 VABufferID *slice_buf_ids;
 VABufferID slice_param_buf_id, slice_data_buf_id;
@@ -121,7 +143,7 @@ int ff_vaapi_commit_slices(struct vaapi_context *vactx)
 return 0;
 }
 
-static void *alloc_buffer(struct vaapi_context *vactx, int type, unsigned int 
size, uint32_t *buf_id)
+static void *alloc_buffer(FFVAContext *vactx, int type, unsigned int size, 
uint32_t *buf_id)
 {
 void *data = NULL;
 
@@ -133,22 +155,22 @@ static void *alloc_buffer(struct vaapi_context *vactx, 
int type, unsigned int si
 return data;
 }
 
-void *ff_vaapi_alloc_pic_param(struct vaapi_context *vactx, unsigned int size)
+void *ff_vaapi_alloc_pic_param(FFVAContext *vactx, unsigned int size)
 {
 return alloc_buffer(vactx, VAPictureParameterBufferType, size, 
vactx-pic_param_buf_id);
 }
 
-void *ff_vaapi_alloc_iq_matrix(struct vaapi_context *vactx, unsigned int size)
+void *ff_vaapi_alloc_iq_matrix(FFVAContext *vactx, unsigned int size)
 {
 return alloc_buffer(vactx, VAIQMatrixBufferType, size, 
vactx-iq_matrix_buf_id);
 }
 
-uint8_t *ff_vaapi_alloc_bitplane(struct vaapi_context *vactx, uint32_t size)
+uint8_t *ff_vaapi_alloc_bitplane(FFVAContext *vactx, uint32_t size)
 {
 return alloc_buffer(vactx, VABitPlaneBufferType, size, 
vactx-bitplane_buf_id);
 }
 
-VASliceParameterBufferBase *ff_vaapi_alloc_slice(struct vaapi_context *vactx, 
const uint8_t *buffer, uint32_t size)
+VASliceParameterBufferBase *ff_vaapi_alloc_slice(FFVAContext *vactx, const 
uint8_t *buffer, uint32_t size)
 {
 uint8_t *slice_params;
 VASliceParameterBufferBase *slice_param;
@@ -181,7 +203,7 @@ VASliceParameterBufferBase *ff_vaapi_alloc_slice(struct 
vaapi_context *vactx, co
 
 void ff_vaapi_common_end_frame(AVCodecContext *avctx)
 {
-struct vaapi_context * const vactx = avctx

[FFmpeg-devel] [PATCH v2 3/3] vaapi: fix usage of invalid buffer ids.

[Gwenole Beauchesne]

Invalid buffer ids are defined by VA_INVALID_ID. Use that through out
vaapi_*.c support files now that we have private data initialized and
managed by libavcodec. Previously, the only requirement for the public
vaapi_context struct was to be zero-initialized.

This fixes support for 3rdparty VA drivers that strictly conform to
the API whereby an invalid buffer id is VA_INVALID_ID and the first
valid buffer id can actually be zero.

Signed-off-by: Gwenole Beauchesne gwenole.beauche...@intel.com
---
 libavcodec/vaapi.c | 20 
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/libavcodec/vaapi.c b/libavcodec/vaapi.c
index 5dc43e1..d5f8fa2 100644
--- a/libavcodec/vaapi.c
+++ b/libavcodec/vaapi.c
@@ -35,9 +35,9 @@ static void destroy_buffers(VADisplay display, VABufferID 
*buffers, unsigned int
 {
 unsigned int i;
 for (i = 0; i  n_buffers; i++) {
-if (buffers[i]) {
+if (buffers[i] != VA_INVALID_ID) {
 vaDestroyBuffer(display, buffers[i]);
-buffers[i] = 0;
+buffers[i] = VA_INVALID_ID;
 }
 }
 }
@@ -55,6 +55,10 @@ int ff_vaapi_context_init(AVCodecContext *avctx)
 vactx-display  = user_vactx-display;
 vactx-config_id= user_vactx-config_id;
 vactx-context_id   = user_vactx-context_id;
+
+vactx-pic_param_buf_id = VA_INVALID_ID;
+vactx-iq_matrix_buf_id = VA_INVALID_ID;
+vactx-bitplane_buf_id  = VA_INVALID_ID;
 return 0;
 }
 
@@ -68,18 +72,18 @@ int ff_vaapi_render_picture(FFVAContext *vactx, VASurfaceID 
surface)
 VABufferID va_buffers[3];
 unsigned int n_va_buffers = 0;
 
-if (!vactx-pic_param_buf_id)
+if (vactx-pic_param_buf_id == VA_INVALID_ID)
 return 0;
 
 vaUnmapBuffer(vactx-display, vactx-pic_param_buf_id);
 va_buffers[n_va_buffers++] = vactx-pic_param_buf_id;
 
-if (vactx-iq_matrix_buf_id) {
+if (vactx-iq_matrix_buf_id != VA_INVALID_ID) {
 vaUnmapBuffer(vactx-display, vactx-iq_matrix_buf_id);
 va_buffers[n_va_buffers++] = vactx-iq_matrix_buf_id;
 }
 
-if (vactx-bitplane_buf_id) {
+if (vactx-bitplane_buf_id != VA_INVALID_ID) {
 vaUnmapBuffer(vactx-display, vactx-bitplane_buf_id);
 va_buffers[n_va_buffers++] = vactx-bitplane_buf_id;
 }
@@ -119,7 +123,7 @@ int ff_vaapi_commit_slices(FFVAContext *vactx)
 return -1;
 vactx-slice_buf_ids = slice_buf_ids;
 
-slice_param_buf_id = 0;
+slice_param_buf_id = VA_INVALID_ID;
 if (vaCreateBuffer(vactx-display, vactx-context_id,
VASliceParameterBufferType,
vactx-slice_param_size,
@@ -128,7 +132,7 @@ int ff_vaapi_commit_slices(FFVAContext *vactx)
 return -1;
 vactx-slice_count = 0;
 
-slice_data_buf_id = 0;
+slice_data_buf_id = VA_INVALID_ID;
 if (vaCreateBuffer(vactx-display, vactx-context_id,
VASliceDataBufferType,
vactx-slice_data_size,
@@ -147,7 +151,7 @@ static void *alloc_buffer(FFVAContext *vactx, int type, 
unsigned int size, uint3
 {
 void *data = NULL;
 
-*buf_id = 0;
+*buf_id = VA_INVALID_ID;
 if (vaCreateBuffer(vactx-display, vactx-context_id,
type, size, 1, NULL, buf_id) == VA_STATUS_SUCCESS)
 vaMapBuffer(vactx-display, *buf_id, data);
-- 
1.9.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/5] vaapi: define a single pixel format for VA-API (AV_PIX_FMT_VAAPI).

[Gwenole Beauchesne]

Hi,

2015-08-19 0:02 GMT+02:00 Andreas Cadhalpun andreas.cadhal...@googlemail.com:
 On 18.08.2015 17:26, Gwenole Beauchesne wrote:
 Deprecate older VA pixel formats (MOCO, IDCT) as it is now very unlikely
 to ever be useful in the future. Only keep plain AV_PIX_FMT_VAAPI format
 that is aliased to the older VLD variant.

 Signed-off-by: Gwenole Beauchesne gwenole.beauche...@intel.com
 ---
  libavcodec/h263dec.c |  2 +-
  libavcodec/h264_slice.c  |  2 +-
  libavcodec/mpeg12dec.c   |  2 +-
  libavcodec/vaapi_h264.c  |  2 +-
  libavcodec/vaapi_mpeg2.c |  2 +-
  libavcodec/vaapi_mpeg4.c |  4 ++--
  libavcodec/vaapi_vc1.c   |  4 ++--
  libavcodec/vc1dec.c  |  2 +-
  libavutil/pixdesc.c  |  9 +
  libavutil/pixfmt.h   | 12 
  libavutil/version.h  |  3 +++
  11 files changed, 34 insertions(+), 10 deletions(-)

 [...]
 --- a/libavutil/version.h
 +++ b/libavutil/version.h
 @@ -107,6 +107,9 @@
  #ifndef FF_API_AVFRAME_LAVC
  #define FF_API_AVFRAME_LAVC (LIBAVUTIL_VERSION_MAJOR  55)
  #endif
 +#ifndef FF_API_VAAPI
 +#define FF_API_VAAPI(LIBAVUTIL_VERSION_MAJOR  55)
 +#endif

 I think the deprecation should be at least in one release before it is 
 removed.
 Hence using ' 56' would be better.
 Also mentioning this change in doc/APIchanges would be good.

 The same goes for FF_API_VAAPI_CONTEXT from the second patch.

You are right. Thanks.

Regards,
-- 
Gwenole Beauchesne
Intel Corporation SAS / 2 rue de Paris, 92196 Meudon Cedex, France
Registration Number (RCS): Nanterre B 302 456 199
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/4] vaapi: define a single pixel format for VA-API (AV_PIX_FMT_VAAPI).

[Gwenole Beauchesne]

Hi,

2015-08-18 10:43 GMT+02:00 Hendrik Leppkes h.lepp...@gmail.com:
 On Tue, Aug 18, 2015 at 10:35 AM, Gwenole Beauchesne gb.de...@gmail.com 
 wrote:
 2015-08-17 21:53 GMT+02:00 wm4 nfx...@googlemail.com:
 On Mon, 17 Aug 2015 19:17:50 +0200
 Gwenole Beauchesne gb.de...@gmail.com wrote:

 Deprecate older VA pixel formats (MOCO, IDCT) as it is now very unlikely
 to ever be useful in the future. Only keep plain AV_PIX_FMT_VAAPI format
 that is aliased to the older VLD variant.

 Signed-off-by: Gwenole Beauchesne gwenole.beauche...@intel.com
 ---
  libavcodec/h263dec.c |  2 +-
  libavcodec/h264_slice.c  |  2 +-
  libavcodec/mpeg12dec.c   |  2 +-
  libavcodec/vaapi_h264.c  |  2 +-
  libavcodec/vaapi_mpeg2.c |  2 +-
  libavcodec/vaapi_mpeg4.c |  4 ++--
  libavcodec/vaapi_vc1.c   |  4 ++--
  libavcodec/vc1dec.c  |  2 +-
  libavutil/pixdesc.c  |  9 +
  libavutil/pixfmt.h   | 11 +++
  libavutil/version.h  |  3 +++
  11 files changed, 33 insertions(+), 10 deletions(-)

 diff --git a/libavcodec/h263dec.c b/libavcodec/h263dec.c
 index 7fa7090..e647e40 100644
 --- a/libavcodec/h263dec.c
 +++ b/libavcodec/h263dec.c
 @@ -718,7 +718,7 @@ frame_end:

  const enum AVPixelFormat ff_h263_hwaccel_pixfmt_list_420[] = {
  #if CONFIG_H263_VAAPI_HWACCEL || CONFIG_MPEG4_VAAPI_HWACCEL
 -AV_PIX_FMT_VAAPI_VLD,
 +AV_PIX_FMT_VAAPI,
  #endif
  #if CONFIG_H263_VDPAU_HWACCEL || CONFIG_MPEG4_VDPAU_HWACCEL
  AV_PIX_FMT_VDPAU,
 diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
 index 48f501b..7b35c08 100644
 --- a/libavcodec/h264_slice.c
 +++ b/libavcodec/h264_slice.c
 @@ -943,7 +943,7 @@ static enum AVPixelFormat get_pixel_format(H264Context 
 *h, int force_callback)
  *fmt++ = AV_PIX_FMT_D3D11VA_VLD;
  #endif
  #if CONFIG_H264_VAAPI_HWACCEL
 -*fmt++ = AV_PIX_FMT_VAAPI_VLD;
 +*fmt++ = AV_PIX_FMT_VAAPI;
  #endif
  #if CONFIG_H264_VDA_HWACCEL
  *fmt++ = AV_PIX_FMT_VDA_VLD;
 diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
 index c7a5701..d2bedbc 100644
 --- a/libavcodec/mpeg12dec.c
 +++ b/libavcodec/mpeg12dec.c
 @@ -1209,7 +1209,7 @@ static const enum AVPixelFormat 
 mpeg2_hwaccel_pixfmt_list_420[] = {
  AV_PIX_FMT_D3D11VA_VLD,
  #endif
  #if CONFIG_MPEG2_VAAPI_HWACCEL
 -AV_PIX_FMT_VAAPI_VLD,
 +AV_PIX_FMT_VAAPI,
  #endif
  #if CONFIG_MPEG2_VIDEOTOOLBOX_HWACCEL
  AV_PIX_FMT_VIDEOTOOLBOX,
 diff --git a/libavcodec/vaapi_h264.c b/libavcodec/vaapi_h264.c
 index 151aca9..55ee2fc 100644
 --- a/libavcodec/vaapi_h264.c
 +++ b/libavcodec/vaapi_h264.c
 @@ -359,7 +359,7 @@ AVHWAccel ff_h264_vaapi_hwaccel = {
  .name   = h264_vaapi,
  .type   = AVMEDIA_TYPE_VIDEO,
  .id = AV_CODEC_ID_H264,
 -.pix_fmt= AV_PIX_FMT_VAAPI_VLD,
 +.pix_fmt= AV_PIX_FMT_VAAPI,
  .start_frame= vaapi_h264_start_frame,
  .end_frame  = vaapi_h264_end_frame,
  .decode_slice   = vaapi_h264_decode_slice,
 diff --git a/libavcodec/vaapi_mpeg2.c b/libavcodec/vaapi_mpeg2.c
 index 87fab89..27c69cd 100644
 --- a/libavcodec/vaapi_mpeg2.c
 +++ b/libavcodec/vaapi_mpeg2.c
 @@ -138,7 +138,7 @@ AVHWAccel ff_mpeg2_vaapi_hwaccel = {
  .name   = mpeg2_vaapi,
  .type   = AVMEDIA_TYPE_VIDEO,
  .id = AV_CODEC_ID_MPEG2VIDEO,
 -.pix_fmt= AV_PIX_FMT_VAAPI_VLD,
 +.pix_fmt= AV_PIX_FMT_VAAPI,
  .start_frame= vaapi_mpeg2_start_frame,
  .end_frame  = ff_vaapi_mpeg_end_frame,
  .decode_slice   = vaapi_mpeg2_decode_slice,
 diff --git a/libavcodec/vaapi_mpeg4.c b/libavcodec/vaapi_mpeg4.c
 index 9b283f7..5b2e9d4 100644
 --- a/libavcodec/vaapi_mpeg4.c
 +++ b/libavcodec/vaapi_mpeg4.c
 @@ -141,7 +141,7 @@ AVHWAccel ff_mpeg4_vaapi_hwaccel = {
  .name   = mpeg4_vaapi,
  .type   = AVMEDIA_TYPE_VIDEO,
  .id = AV_CODEC_ID_MPEG4,
 -.pix_fmt= AV_PIX_FMT_VAAPI_VLD,
 +.pix_fmt= AV_PIX_FMT_VAAPI,
  .start_frame= vaapi_mpeg4_start_frame,
  .end_frame  = ff_vaapi_mpeg_end_frame,
  .decode_slice   = vaapi_mpeg4_decode_slice,
 @@ -153,7 +153,7 @@ AVHWAccel ff_h263_vaapi_hwaccel = {
  .name   = h263_vaapi,
  .type   = AVMEDIA_TYPE_VIDEO,
  .id = AV_CODEC_ID_H263,
 -.pix_fmt= AV_PIX_FMT_VAAPI_VLD,
 +.pix_fmt= AV_PIX_FMT_VAAPI,
  .start_frame= vaapi_mpeg4_start_frame,
  .end_frame  = ff_vaapi_mpeg_end_frame,
  .decode_slice   = vaapi_mpeg4_decode_slice,
 diff --git a/libavcodec/vaapi_vc1.c b/libavcodec/vaapi_vc1.c
 index 7ef9f2a..63d514d 100644
 --- a/libavcodec/vaapi_vc1.c
 +++ b/libavcodec/vaapi_vc1.c
 @@ -339,7 +339,7 @@ AVHWAccel ff_wmv3_vaapi_hwaccel = {
  .name   = wmv3_vaapi,
  .type   = AVMEDIA_TYPE_VIDEO,
  .id = AV_CODEC_ID_WMV3,
 -.pix_fmt= AV_PIX_FMT_VAAPI_VLD,
 +.pix_fmt= AV_PIX_FMT_VAAPI

Re: [FFmpeg-devel] [PATCH 1/4] vaapi: define a single pixel format for VA-API (AV_PIX_FMT_VAAPI).

[Gwenole Beauchesne]

2015-08-17 21:53 GMT+02:00 wm4 nfx...@googlemail.com:
 On Mon, 17 Aug 2015 19:17:50 +0200
 Gwenole Beauchesne gb.de...@gmail.com wrote:

 Deprecate older VA pixel formats (MOCO, IDCT) as it is now very unlikely
 to ever be useful in the future. Only keep plain AV_PIX_FMT_VAAPI format
 that is aliased to the older VLD variant.

 Signed-off-by: Gwenole Beauchesne gwenole.beauche...@intel.com
 ---
  libavcodec/h263dec.c |  2 +-
  libavcodec/h264_slice.c  |  2 +-
  libavcodec/mpeg12dec.c   |  2 +-
  libavcodec/vaapi_h264.c  |  2 +-
  libavcodec/vaapi_mpeg2.c |  2 +-
  libavcodec/vaapi_mpeg4.c |  4 ++--
  libavcodec/vaapi_vc1.c   |  4 ++--
  libavcodec/vc1dec.c  |  2 +-
  libavutil/pixdesc.c  |  9 +
  libavutil/pixfmt.h   | 11 +++
  libavutil/version.h  |  3 +++
  11 files changed, 33 insertions(+), 10 deletions(-)

 diff --git a/libavcodec/h263dec.c b/libavcodec/h263dec.c
 index 7fa7090..e647e40 100644
 --- a/libavcodec/h263dec.c
 +++ b/libavcodec/h263dec.c
 @@ -718,7 +718,7 @@ frame_end:

  const enum AVPixelFormat ff_h263_hwaccel_pixfmt_list_420[] = {
  #if CONFIG_H263_VAAPI_HWACCEL || CONFIG_MPEG4_VAAPI_HWACCEL
 -AV_PIX_FMT_VAAPI_VLD,
 +AV_PIX_FMT_VAAPI,
  #endif
  #if CONFIG_H263_VDPAU_HWACCEL || CONFIG_MPEG4_VDPAU_HWACCEL
  AV_PIX_FMT_VDPAU,
 diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
 index 48f501b..7b35c08 100644
 --- a/libavcodec/h264_slice.c
 +++ b/libavcodec/h264_slice.c
 @@ -943,7 +943,7 @@ static enum AVPixelFormat get_pixel_format(H264Context 
 *h, int force_callback)
  *fmt++ = AV_PIX_FMT_D3D11VA_VLD;
  #endif
  #if CONFIG_H264_VAAPI_HWACCEL
 -*fmt++ = AV_PIX_FMT_VAAPI_VLD;
 +*fmt++ = AV_PIX_FMT_VAAPI;
  #endif
  #if CONFIG_H264_VDA_HWACCEL
  *fmt++ = AV_PIX_FMT_VDA_VLD;
 diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
 index c7a5701..d2bedbc 100644
 --- a/libavcodec/mpeg12dec.c
 +++ b/libavcodec/mpeg12dec.c
 @@ -1209,7 +1209,7 @@ static const enum AVPixelFormat 
 mpeg2_hwaccel_pixfmt_list_420[] = {
  AV_PIX_FMT_D3D11VA_VLD,
  #endif
  #if CONFIG_MPEG2_VAAPI_HWACCEL
 -AV_PIX_FMT_VAAPI_VLD,
 +AV_PIX_FMT_VAAPI,
  #endif
  #if CONFIG_MPEG2_VIDEOTOOLBOX_HWACCEL
  AV_PIX_FMT_VIDEOTOOLBOX,
 diff --git a/libavcodec/vaapi_h264.c b/libavcodec/vaapi_h264.c
 index 151aca9..55ee2fc 100644
 --- a/libavcodec/vaapi_h264.c
 +++ b/libavcodec/vaapi_h264.c
 @@ -359,7 +359,7 @@ AVHWAccel ff_h264_vaapi_hwaccel = {
  .name   = h264_vaapi,
  .type   = AVMEDIA_TYPE_VIDEO,
  .id = AV_CODEC_ID_H264,
 -.pix_fmt= AV_PIX_FMT_VAAPI_VLD,
 +.pix_fmt= AV_PIX_FMT_VAAPI,
  .start_frame= vaapi_h264_start_frame,
  .end_frame  = vaapi_h264_end_frame,
  .decode_slice   = vaapi_h264_decode_slice,
 diff --git a/libavcodec/vaapi_mpeg2.c b/libavcodec/vaapi_mpeg2.c
 index 87fab89..27c69cd 100644
 --- a/libavcodec/vaapi_mpeg2.c
 +++ b/libavcodec/vaapi_mpeg2.c
 @@ -138,7 +138,7 @@ AVHWAccel ff_mpeg2_vaapi_hwaccel = {
  .name   = mpeg2_vaapi,
  .type   = AVMEDIA_TYPE_VIDEO,
  .id = AV_CODEC_ID_MPEG2VIDEO,
 -.pix_fmt= AV_PIX_FMT_VAAPI_VLD,
 +.pix_fmt= AV_PIX_FMT_VAAPI,
  .start_frame= vaapi_mpeg2_start_frame,
  .end_frame  = ff_vaapi_mpeg_end_frame,
  .decode_slice   = vaapi_mpeg2_decode_slice,
 diff --git a/libavcodec/vaapi_mpeg4.c b/libavcodec/vaapi_mpeg4.c
 index 9b283f7..5b2e9d4 100644
 --- a/libavcodec/vaapi_mpeg4.c
 +++ b/libavcodec/vaapi_mpeg4.c
 @@ -141,7 +141,7 @@ AVHWAccel ff_mpeg4_vaapi_hwaccel = {
  .name   = mpeg4_vaapi,
  .type   = AVMEDIA_TYPE_VIDEO,
  .id = AV_CODEC_ID_MPEG4,
 -.pix_fmt= AV_PIX_FMT_VAAPI_VLD,
 +.pix_fmt= AV_PIX_FMT_VAAPI,
  .start_frame= vaapi_mpeg4_start_frame,
  .end_frame  = ff_vaapi_mpeg_end_frame,
  .decode_slice   = vaapi_mpeg4_decode_slice,
 @@ -153,7 +153,7 @@ AVHWAccel ff_h263_vaapi_hwaccel = {
  .name   = h263_vaapi,
  .type   = AVMEDIA_TYPE_VIDEO,
  .id = AV_CODEC_ID_H263,
 -.pix_fmt= AV_PIX_FMT_VAAPI_VLD,
 +.pix_fmt= AV_PIX_FMT_VAAPI,
  .start_frame= vaapi_mpeg4_start_frame,
  .end_frame  = ff_vaapi_mpeg_end_frame,
  .decode_slice   = vaapi_mpeg4_decode_slice,
 diff --git a/libavcodec/vaapi_vc1.c b/libavcodec/vaapi_vc1.c
 index 7ef9f2a..63d514d 100644
 --- a/libavcodec/vaapi_vc1.c
 +++ b/libavcodec/vaapi_vc1.c
 @@ -339,7 +339,7 @@ AVHWAccel ff_wmv3_vaapi_hwaccel = {
  .name   = wmv3_vaapi,
  .type   = AVMEDIA_TYPE_VIDEO,
  .id = AV_CODEC_ID_WMV3,
 -.pix_fmt= AV_PIX_FMT_VAAPI_VLD,
 +.pix_fmt= AV_PIX_FMT_VAAPI,
  .start_frame= vaapi_vc1_start_frame,
  .end_frame  = ff_vaapi_mpeg_end_frame,
  .decode_slice   = vaapi_vc1_decode_slice,
 @@ -350,7

Re: [FFmpeg-devel] [PATCH 4/4] vaapi: add interfaces to properly initialize context.

[Gwenole Beauchesne]

Hi,

2015-08-17 22:26 GMT+02:00 wm4 nfx...@googlemail.com:
 On Mon, 17 Aug 2015 19:17:53 +0200
 Gwenole Beauchesne gb.de...@gmail.com wrote:

 Add av_vaapi_context_init() and av_vaapi_context_alloc() helper functions
 so that to properly initialize the vaapi_context structure, and allow for
 future extensions without breaking the API/ABI.

 The new version and flags fields are inserted after the last known user
 initialized field, and actually useful field at all, i.e. VA context_id.
 This is safe because the vaapi_context structure was required to be zero
 initialized in the past. And, since those new helper functions and changes
 cause the AV_VAAPI_CONTEXT_VERSION to be bumped, we can track older struct
 requirements from within libavcodec.

 Besides, it is now required by design, and actual usage, that the vaapi
 context structure be completely initialized once and for all before the
 AVCodecContext.get_format() function ever completes.

 Signed-off-by: Gwenole Beauchesne gwenole.beauche...@intel.com
 ---
  libavcodec/vaapi.c  | 30 +++
  libavcodec/vaapi.h  | 59 
 +
  libavcodec/vaapi_internal.h |  1 +
  3 files changed, 85 insertions(+), 5 deletions(-)

 diff --git a/libavcodec/vaapi.c b/libavcodec/vaapi.c
 index 1ae71a5..4d3e2f3 100644
 --- a/libavcodec/vaapi.c
 +++ b/libavcodec/vaapi.c
 @@ -41,11 +41,41 @@ static void destroy_buffers(VADisplay display, 
 VABufferID *buffers, unsigned int
  }
  }

 +/* Allocates a vaapi_context structure */
 +struct vaapi_context *av_vaapi_context_alloc(unsigned int flags)
 +{
 +struct vaapi_context *vactx;
 +
 +vactx = av_malloc(sizeof(*vactx));
 +if (!vactx)
 +return NULL;
 +
 +av_vaapi_context_init(vactx, AV_VAAPI_CONTEXT_VERSION, flags);
 +return vactx;
 +}
 +
 +/* Initializes a vaapi_context structure with safe defaults */
 +void av_vaapi_context_init(struct vaapi_context *vactx, unsigned int 
 version,
 +   unsigned int flags)
 +{
 +vactx-display  = NULL;
 +vactx-config_id= VA_INVALID_ID;
 +vactx-context_id   = VA_INVALID_ID;
 +
 +if (version  0) {
 +vactx-version  = version;
 +vactx-flags= flags;
 +}
 +}
 +
  int ff_vaapi_context_init(AVCodecContext *avctx)
  {
  FFVAContext * const vactx = ff_vaapi_get_context(avctx);
  const struct vaapi_context * const user_vactx = avctx-hwaccel_context;

 +if (user_vactx-version  0)
 +vactx-flags= user_vactx-flags;
 +
  vactx-display  = user_vactx-display;
  vactx-config_id= user_vactx-config_id;
  vactx-context_id   = user_vactx-context_id;
 diff --git a/libavcodec/vaapi.h b/libavcodec/vaapi.h
 index 4448a2e..1f032a0 100644
 --- a/libavcodec/vaapi.h
 +++ b/libavcodec/vaapi.h
 @@ -40,14 +40,16 @@
   * @{
   */

 +#define AV_VAAPI_CONTEXT_VERSION 1
 +
  /**
   * This structure is used to share data between the FFmpeg library and
   * the client video application.
 - * This shall be zero-allocated and available as
 - * AVCodecContext.hwaccel_context. All user members can be set once
 - * during initialization or through each AVCodecContext.get_buffer()
 - * function call. In any case, they must be valid prior to calling
 - * decoding functions.
 + *
 + * This shall be initialized with av_vaapi_context_init(), or
 + * indirectly through av_vaapi_context_alloc(), and made available as
 + * AVCodecContext.hwaccel_context. All user members must be properly
 + * initialized before AVCodecContext.get_format() completes.
   */
  struct vaapi_context {
  /**
 @@ -74,6 +76,29 @@ struct vaapi_context {
   */
  uint32_t context_id;

 +/**
 + * This field must be set to AV_VAAPI_CONTEXT_VERSION
 + *
 + * @since Version 1.
 + *
 + * - encoding: unused
 + * - decoding: Set by user, through av_vaapi_context_init()
 + */
 +unsigned int version;

 Not sure if I see any point in this. Normally, backwards-compatible ABI
 additions can add fields in FFmpeg, but the API user doesn't get a way
 to check whether a field is really there.

 Or in other words, the level of ABI compatibility we target is that
 newer libav* libs work with old application binaries, but not the other
 way around.

Yes, and I have reasons to see why this mechanism is needed.

Imagine some old application binaries doesn't allocate the context
through the supplied helper functions. Without knowing the original
layout of the user supplied vaapi_context, we could be in a situation
where we read past the end of the struct. The current patch series
doesn't present it, but future ones can enlarge the public
vaapi_context with various other needed fields for configuration.
Aside of hwaccel v2 plans, this is an interim solution to be free
here.

e.g. version 2 fields could include n_scratch_surfaces, version 3
fields could include pix_fmt (unless it is allowed to the user

[FFmpeg-devel] [PATCH 3/5] vaapi: fix usage of invalid buffer ids.

[Gwenole Beauchesne]

Invalid buffer ids are defined by VA_INVALID_ID. Use that through out
vaapi_*.c support files now that we have private data initialized and
managed by libavcodec. Previously, the only requirement for the public
vaapi_context struct was to be zero-initialized.

This fixes support for 3rdparty VA drivers that strictly conform to
the API whereby an invalid buffer id is VA_INVALID_ID and the first
valid buffer id can actually be zero.

Signed-off-by: Gwenole Beauchesne gwenole.beauche...@intel.com
---
 libavcodec/vaapi.c | 20 
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/libavcodec/vaapi.c b/libavcodec/vaapi.c
index 880e3d6..1ae71a5 100644
--- a/libavcodec/vaapi.c
+++ b/libavcodec/vaapi.c
@@ -34,9 +34,9 @@ static void destroy_buffers(VADisplay display, VABufferID 
*buffers, unsigned int
 {
 unsigned int i;
 for (i = 0; i  n_buffers; i++) {
-if (buffers[i]) {
+if (buffers[i] != VA_INVALID_ID) {
 vaDestroyBuffer(display, buffers[i]);
-buffers[i] = 0;
+buffers[i] = VA_INVALID_ID;
 }
 }
 }
@@ -49,6 +49,10 @@ int ff_vaapi_context_init(AVCodecContext *avctx)
 vactx-display  = user_vactx-display;
 vactx-config_id= user_vactx-config_id;
 vactx-context_id   = user_vactx-context_id;
+
+vactx-pic_param_buf_id = VA_INVALID_ID;
+vactx-iq_matrix_buf_id = VA_INVALID_ID;
+vactx-bitplane_buf_id  = VA_INVALID_ID;
 return 0;
 }
 
@@ -62,18 +66,18 @@ int ff_vaapi_render_picture(FFVAContext *vactx, VASurfaceID 
surface)
 VABufferID va_buffers[3];
 unsigned int n_va_buffers = 0;
 
-if (!vactx-pic_param_buf_id)
+if (vactx-pic_param_buf_id == VA_INVALID_ID)
 return 0;
 
 vaUnmapBuffer(vactx-display, vactx-pic_param_buf_id);
 va_buffers[n_va_buffers++] = vactx-pic_param_buf_id;
 
-if (vactx-iq_matrix_buf_id) {
+if (vactx-iq_matrix_buf_id != VA_INVALID_ID) {
 vaUnmapBuffer(vactx-display, vactx-iq_matrix_buf_id);
 va_buffers[n_va_buffers++] = vactx-iq_matrix_buf_id;
 }
 
-if (vactx-bitplane_buf_id) {
+if (vactx-bitplane_buf_id != VA_INVALID_ID) {
 vaUnmapBuffer(vactx-display, vactx-bitplane_buf_id);
 va_buffers[n_va_buffers++] = vactx-bitplane_buf_id;
 }
@@ -113,7 +117,7 @@ int ff_vaapi_commit_slices(FFVAContext *vactx)
 return -1;
 vactx-slice_buf_ids = slice_buf_ids;
 
-slice_param_buf_id = 0;
+slice_param_buf_id = VA_INVALID_ID;
 if (vaCreateBuffer(vactx-display, vactx-context_id,
VASliceParameterBufferType,
vactx-slice_param_size,
@@ -122,7 +126,7 @@ int ff_vaapi_commit_slices(FFVAContext *vactx)
 return -1;
 vactx-slice_count = 0;
 
-slice_data_buf_id = 0;
+slice_data_buf_id = VA_INVALID_ID;
 if (vaCreateBuffer(vactx-display, vactx-context_id,
VASliceDataBufferType,
vactx-slice_data_size,
@@ -141,7 +145,7 @@ static void *alloc_buffer(FFVAContext *vactx, int type, 
unsigned int size, uint3
 {
 void *data = NULL;
 
-*buf_id = 0;
+*buf_id = VA_INVALID_ID;
 if (vaCreateBuffer(vactx-display, vactx-context_id,
type, size, 1, NULL, buf_id) == VA_STATUS_SUCCESS)
 vaMapBuffer(vactx-display, *buf_id, data);
-- 
1.9.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/5] vaapi: streamline public context structure.

[Gwenole Beauchesne]

Move libavcodec managed objects from the public struct vaapi_context
to a new privately owned FFVAContext. This is done so that to clean up
and streamline the public structure, but also to prepare for new codec
support, thus requiring new internal data to be added in there.

The AVCodecContext.hwaccel_context, that holds the public vaapi_context,
shall no longer be accessed from within vaapi_*.c codec support files.

Signed-off-by: Gwenole Beauchesne gwenole.beauche...@intel.com
---
 libavcodec/vaapi.c  | 34 +-
 libavcodec/vaapi.h  | 16 
 libavcodec/vaapi_h264.c | 10 +++---
 libavcodec/vaapi_internal.h | 42 --
 libavcodec/vaapi_mpeg2.c|  8 ++--
 libavcodec/vaapi_mpeg4.c| 11 +--
 libavcodec/vaapi_vc1.c  | 11 +--
 libavcodec/version.h|  3 +++
 8 files changed, 111 insertions(+), 24 deletions(-)

diff --git a/libavcodec/vaapi.c b/libavcodec/vaapi.c
index 6ac22e6..880e3d6 100644
--- a/libavcodec/vaapi.c
+++ b/libavcodec/vaapi.c
@@ -41,7 +41,23 @@ static void destroy_buffers(VADisplay display, VABufferID 
*buffers, unsigned int
 }
 }
 
-int ff_vaapi_render_picture(struct vaapi_context *vactx, VASurfaceID surface)
+int ff_vaapi_context_init(AVCodecContext *avctx)
+{
+FFVAContext * const vactx = ff_vaapi_get_context(avctx);
+const struct vaapi_context * const user_vactx = avctx-hwaccel_context;
+
+vactx-display  = user_vactx-display;
+vactx-config_id= user_vactx-config_id;
+vactx-context_id   = user_vactx-context_id;
+return 0;
+}
+
+int ff_vaapi_context_fini(AVCodecContext *avctx)
+{
+return 0;
+}
+
+int ff_vaapi_render_picture(FFVAContext *vactx, VASurfaceID surface)
 {
 VABufferID va_buffers[3];
 unsigned int n_va_buffers = 0;
@@ -81,7 +97,7 @@ int ff_vaapi_render_picture(struct vaapi_context *vactx, 
VASurfaceID surface)
 return 0;
 }
 
-int ff_vaapi_commit_slices(struct vaapi_context *vactx)
+int ff_vaapi_commit_slices(FFVAContext *vactx)
 {
 VABufferID *slice_buf_ids;
 VABufferID slice_param_buf_id, slice_data_buf_id;
@@ -121,7 +137,7 @@ int ff_vaapi_commit_slices(struct vaapi_context *vactx)
 return 0;
 }
 
-static void *alloc_buffer(struct vaapi_context *vactx, int type, unsigned int 
size, uint32_t *buf_id)
+static void *alloc_buffer(FFVAContext *vactx, int type, unsigned int size, 
uint32_t *buf_id)
 {
 void *data = NULL;
 
@@ -133,22 +149,22 @@ static void *alloc_buffer(struct vaapi_context *vactx, 
int type, unsigned int si
 return data;
 }
 
-void *ff_vaapi_alloc_pic_param(struct vaapi_context *vactx, unsigned int size)
+void *ff_vaapi_alloc_pic_param(FFVAContext *vactx, unsigned int size)
 {
 return alloc_buffer(vactx, VAPictureParameterBufferType, size, 
vactx-pic_param_buf_id);
 }
 
-void *ff_vaapi_alloc_iq_matrix(struct vaapi_context *vactx, unsigned int size)
+void *ff_vaapi_alloc_iq_matrix(FFVAContext *vactx, unsigned int size)
 {
 return alloc_buffer(vactx, VAIQMatrixBufferType, size, 
vactx-iq_matrix_buf_id);
 }
 
-uint8_t *ff_vaapi_alloc_bitplane(struct vaapi_context *vactx, uint32_t size)
+uint8_t *ff_vaapi_alloc_bitplane(FFVAContext *vactx, uint32_t size)
 {
 return alloc_buffer(vactx, VABitPlaneBufferType, size, 
vactx-bitplane_buf_id);
 }
 
-VASliceParameterBufferBase *ff_vaapi_alloc_slice(struct vaapi_context *vactx, 
const uint8_t *buffer, uint32_t size)
+VASliceParameterBufferBase *ff_vaapi_alloc_slice(FFVAContext *vactx, const 
uint8_t *buffer, uint32_t size)
 {
 uint8_t *slice_params;
 VASliceParameterBufferBase *slice_param;
@@ -181,7 +197,7 @@ VASliceParameterBufferBase *ff_vaapi_alloc_slice(struct 
vaapi_context *vactx, co
 
 void ff_vaapi_common_end_frame(AVCodecContext *avctx)
 {
-struct vaapi_context * const vactx = avctx-hwaccel_context;
+FFVAContext * const vactx = ff_vaapi_get_context(avctx);
 
 ff_dlog(avctx, ff_vaapi_common_end_frame()\n);
 
@@ -202,7 +218,7 @@ void ff_vaapi_common_end_frame(AVCodecContext *avctx)
 CONFIG_VC1_VAAPI_HWACCEL   || CONFIG_WMV3_VAAPI_HWACCEL
 int ff_vaapi_mpeg_end_frame(AVCodecContext *avctx)
 {
-struct vaapi_context * const vactx = avctx-hwaccel_context;
+FFVAContext * const vactx = ff_vaapi_get_context(avctx);
 MpegEncContext *s = avctx-priv_data;
 int ret;
 
diff --git a/libavcodec/vaapi.h b/libavcodec/vaapi.h
index 815a27e..4448a2e 100644
--- a/libavcodec/vaapi.h
+++ b/libavcodec/vaapi.h
@@ -31,6 +31,8 @@
  */
 
 #include stdint.h
+#include libavutil/attributes.h
+#include version.h
 
 /**
  * @defgroup lavc_codec_hwaccel_vaapi VA API Decoding
@@ -72,12 +74,14 @@ struct vaapi_context {
  */
 uint32_t context_id;
 
+#if FF_API_VAAPI_CONTEXT
 /**
  * VAPictureParameterBuffer ID
  *
  * - encoding: unused
  * - decoding: Set by libavcodec
  */
+attribute_deprecated
 uint32_t pic_param_buf_id

[FFmpeg-devel] [PATCH 5/5] vaapi: add support for new config options.

[Gwenole Beauchesne]

Add support for modern and flexible config options for vaapi decoders.
Accessors are available to handle those:
- av_vaapi_set_display():
  Binds a user supplied VA display to a codec context
- av_vaapi_set_config():
  Configures the VA-API decoder with a key/value pair
- av_vaapi_set_config_int():
  Configures the VA-API decoder with a key/value pair(int).

The current set of config options is:
- display: the VA display handle (pointer)
- config: the VA config id (uint32_t)
- context: the VA context (pipeline) id (uint32_t)

The whole vaapi_context structure is now not needed, and thus deprecated.

Signed-off-by: Gwenole Beauchesne gwenole.beauche...@intel.com
---
 doc/APIchanges  |  6 
 libavcodec/vaapi.c  | 66 
 libavcodec/vaapi.h  | 73 +++--
 libavcodec/vaapi_internal.h |  1 +
 4 files changed, 139 insertions(+), 7 deletions(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index cce2ddb..6d05b8b 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,12 @@ libavutil: 2014-08-09
 
 API changes, most recent first:
 
+2015-xx-xx - lavc 56.58.0 - vaapi.h
+  Add new APIs to configure hwaccel/vaapi decoders: av_vaapi_set_display(),
+  av_vaapi_set_config(), av_vaapi_set_config_str().
+  Deprecate vaapi_context structure, which is no longer used for
+  initializing a VA-API decode pipeline.
+
 2015-xx-xx - lavu 54.30.0
   xxx -  Add av_blowfish_alloc().
   xxx -  Add av_rc4_alloc().
diff --git a/libavcodec/vaapi.c b/libavcodec/vaapi.c
index 1ae71a5..f73a42e 100644
--- a/libavcodec/vaapi.c
+++ b/libavcodec/vaapi.c
@@ -41,19 +41,75 @@ static void destroy_buffers(VADisplay display, VABufferID 
*buffers, unsigned int
 }
 }
 
+#define OFFSET(x) offsetof(FFVAContext, x)
+static const AVOption FFVAContextOptions[] = {
+{ AV_VAAPI_CONFIG_OPTION_DISPLAY, VA display handle, OFFSET(display),
+  AV_OPT_TYPE_INT64, { .i64 = 0 }, 0, UINTPTR_MAX },
+{ AV_VAAPI_CONFIG_OPTION_CONFIG, VA config id, OFFSET(config_id),
+  AV_OPT_TYPE_INT, { .i64 = VA_INVALID_ID }, 0, UINT32_MAX },
+{ AV_VAAPI_CONFIG_OPTION_CONTEXT, VA context id, OFFSET(context_id),
+  AV_OPT_TYPE_INT, { .i64 = VA_INVALID_ID }, 0, UINT32_MAX },
+{ NULL, }
+};
+#undef OFFSET
+
+static const AVClass FFVAContextClass = {
+.class_name = FFVAContext,
+.item_name  = av_default_item_name,
+.option = FFVAContextOptions,
+.version= LIBAVUTIL_VERSION_INT,
+};
+
+static const AVOption *get_option(const char *key, const char *unit)
+{
+const AVClass *klass = FFVAContextClass;
+
+return av_opt_find2(klass, key, unit, 0, AV_OPT_SEARCH_FAKE_OBJ, NULL);
+}
+
+int av_vaapi_set_display(AVCodecContext *avctx, VADisplay display)
+{
+return av_vaapi_set_config_int(avctx, AV_VAAPI_CONFIG_OPTION_DISPLAY,
+   (int64_t)(intptr_t)display);
+}
+
+int av_vaapi_set_config(AVCodecContext *avctx, const char *key,
+const char *value)
+{
+if (!get_option(key, NULL))
+return AVERROR(EINVAL);
+return av_dict_set(avctx-internal-hwaccel_config, key, value, 0);
+}
+
+int av_vaapi_set_config_int(AVCodecContext *avctx, const char *key,
+int64_t value)
+{
+if (!get_option(key, NULL))
+return AVERROR(EINVAL);
+return av_dict_set_int(avctx-internal-hwaccel_config, key, value, 0);
+}
+
 int ff_vaapi_context_init(AVCodecContext *avctx)
 {
 FFVAContext * const vactx = ff_vaapi_get_context(avctx);
-const struct vaapi_context * const user_vactx = avctx-hwaccel_context;
 
-vactx-display  = user_vactx-display;
-vactx-config_id= user_vactx-config_id;
-vactx-context_id   = user_vactx-context_id;
+vactx-klass = FFVAContextClass;
+av_opt_set_defaults(vactx);
+
+#if FF_API_VAAPI_CONTEXT
+if (avctx-hwaccel_context) {
+const struct vaapi_context * const user_vactx = avctx-hwaccel_context;
+vactx-display  = user_vactx-display;
+vactx-config_id= user_vactx-config_id;
+vactx-context_id   = user_vactx-context_id;
+}
+#endif
 
 vactx-pic_param_buf_id = VA_INVALID_ID;
 vactx-iq_matrix_buf_id = VA_INVALID_ID;
 vactx-bitplane_buf_id  = VA_INVALID_ID;
-return 0;
+
+return av_opt_set_dict(vactx, avctx-internal-hwaccel_config);
 }
 
 int ff_vaapi_context_fini(AVCodecContext *avctx)
diff --git a/libavcodec/vaapi.h b/libavcodec/vaapi.h
index 4448a2e..22b9336 100644
--- a/libavcodec/vaapi.h
+++ b/libavcodec/vaapi.h
@@ -32,7 +32,9 @@
 
 #include stdint.h
 #include libavutil/attributes.h
+#include va/va.h
 #include version.h
+#include avcodec.h
 
 /**
  * @defgroup lavc_codec_hwaccel_vaapi VA API Decoding
@@ -48,7 +50,12 @@
  * during initialization or through each AVCodecContext.get_buffer()
  * function call. In any case, they must be valid prior to calling
  * decoding

[FFmpeg-devel] [PATCH 4/5] hwaccel: add infrastructure to hold accelerator config options.

[Gwenole Beauchesne]

The options are live from AVHWaccel.init() to AVHWAccel.uninit(). As such,
they are specific to an active hwaccel and have a meaning to that hwaccel
only during initialization. Options can be initialized by the user during
AVCodecContext.get_format() with hwaccel-specific (public) helper functions.

This is an internal infrastructure change/addition only.

Signed-off-by: Gwenole Beauchesne gwenole.beauche...@intel.com
---
 libavcodec/internal.h | 14 ++
 libavcodec/utils.c|  2 ++
 2 files changed, 16 insertions(+)

diff --git a/libavcodec/internal.h b/libavcodec/internal.h
index 0daf669..866ed12 100644
--- a/libavcodec/internal.h
+++ b/libavcodec/internal.h
@@ -163,6 +163,20 @@ typedef struct AVCodecInternal {
  * hwaccel-specific private data
  */
 void *hwaccel_priv_data;
+
+/**
+ * Hardware acceleration config options.
+ *
+ * Those options are live from AVHWAccel.init() to AVHWAccel.uninit().
+ * As such, they are specific to an active hwaccel and have a meaning
+ * to that specific hwaccel only during initialization. Initialization
+ * occurs during AVCodecContext.get_format() through hwaccel-specific
+ * helper functions.
+ *
+ * Options are written by the user and read by the hwaccel. Exposing
+ * hwaccel options to the user is not permitted.
+ */
+AVDictionary *hwaccel_config;
 } AVCodecInternal;
 
 struct AVCodecDefault {
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index 22dcc82..338b6bf 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -1231,6 +1231,7 @@ int ff_get_format(AVCodecContext *avctx, const enum 
AVPixelFormat *fmt)
 if (avctx-hwaccel  avctx-hwaccel-uninit)
 avctx-hwaccel-uninit(avctx);
 av_freep(avctx-internal-hwaccel_priv_data);
+av_dict_free(avctx-internal-hwaccel_config);
 avctx-hwaccel = NULL;
 
 ret = avctx-get_format(avctx, choices);
@@ -2921,6 +2922,7 @@ av_cold int avcodec_close(AVCodecContext *avctx)
 if (avctx-hwaccel  avctx-hwaccel-uninit)
 avctx-hwaccel-uninit(avctx);
 av_freep(avctx-internal-hwaccel_priv_data);
+av_dict_free(avctx-internal-hwaccel_config);
 
 av_freep(avctx-internal);
 }
-- 
1.9.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/5] vaapi: define a single pixel format for VA-API (AV_PIX_FMT_VAAPI).

[Gwenole Beauchesne]

Deprecate older VA pixel formats (MOCO, IDCT) as it is now very unlikely
to ever be useful in the future. Only keep plain AV_PIX_FMT_VAAPI format
that is aliased to the older VLD variant.

Signed-off-by: Gwenole Beauchesne gwenole.beauche...@intel.com
---
 libavcodec/h263dec.c |  2 +-
 libavcodec/h264_slice.c  |  2 +-
 libavcodec/mpeg12dec.c   |  2 +-
 libavcodec/vaapi_h264.c  |  2 +-
 libavcodec/vaapi_mpeg2.c |  2 +-
 libavcodec/vaapi_mpeg4.c |  4 ++--
 libavcodec/vaapi_vc1.c   |  4 ++--
 libavcodec/vc1dec.c  |  2 +-
 libavutil/pixdesc.c  |  9 +
 libavutil/pixfmt.h   | 12 
 libavutil/version.h  |  3 +++
 11 files changed, 34 insertions(+), 10 deletions(-)

diff --git a/libavcodec/h263dec.c b/libavcodec/h263dec.c
index 7fa7090..e647e40 100644
--- a/libavcodec/h263dec.c
+++ b/libavcodec/h263dec.c
@@ -718,7 +718,7 @@ frame_end:
 
 const enum AVPixelFormat ff_h263_hwaccel_pixfmt_list_420[] = {
 #if CONFIG_H263_VAAPI_HWACCEL || CONFIG_MPEG4_VAAPI_HWACCEL
-AV_PIX_FMT_VAAPI_VLD,
+AV_PIX_FMT_VAAPI,
 #endif
 #if CONFIG_H263_VDPAU_HWACCEL || CONFIG_MPEG4_VDPAU_HWACCEL
 AV_PIX_FMT_VDPAU,
diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index 48f501b..7b35c08 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -943,7 +943,7 @@ static enum AVPixelFormat get_pixel_format(H264Context *h, 
int force_callback)
 *fmt++ = AV_PIX_FMT_D3D11VA_VLD;
 #endif
 #if CONFIG_H264_VAAPI_HWACCEL
-*fmt++ = AV_PIX_FMT_VAAPI_VLD;
+*fmt++ = AV_PIX_FMT_VAAPI;
 #endif
 #if CONFIG_H264_VDA_HWACCEL
 *fmt++ = AV_PIX_FMT_VDA_VLD;
diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
index c7a5701..d2bedbc 100644
--- a/libavcodec/mpeg12dec.c
+++ b/libavcodec/mpeg12dec.c
@@ -1209,7 +1209,7 @@ static const enum AVPixelFormat 
mpeg2_hwaccel_pixfmt_list_420[] = {
 AV_PIX_FMT_D3D11VA_VLD,
 #endif
 #if CONFIG_MPEG2_VAAPI_HWACCEL
-AV_PIX_FMT_VAAPI_VLD,
+AV_PIX_FMT_VAAPI,
 #endif
 #if CONFIG_MPEG2_VIDEOTOOLBOX_HWACCEL
 AV_PIX_FMT_VIDEOTOOLBOX,
diff --git a/libavcodec/vaapi_h264.c b/libavcodec/vaapi_h264.c
index 151aca9..55ee2fc 100644
--- a/libavcodec/vaapi_h264.c
+++ b/libavcodec/vaapi_h264.c
@@ -359,7 +359,7 @@ AVHWAccel ff_h264_vaapi_hwaccel = {
 .name   = h264_vaapi,
 .type   = AVMEDIA_TYPE_VIDEO,
 .id = AV_CODEC_ID_H264,
-.pix_fmt= AV_PIX_FMT_VAAPI_VLD,
+.pix_fmt= AV_PIX_FMT_VAAPI,
 .start_frame= vaapi_h264_start_frame,
 .end_frame  = vaapi_h264_end_frame,
 .decode_slice   = vaapi_h264_decode_slice,
diff --git a/libavcodec/vaapi_mpeg2.c b/libavcodec/vaapi_mpeg2.c
index 87fab89..27c69cd 100644
--- a/libavcodec/vaapi_mpeg2.c
+++ b/libavcodec/vaapi_mpeg2.c
@@ -138,7 +138,7 @@ AVHWAccel ff_mpeg2_vaapi_hwaccel = {
 .name   = mpeg2_vaapi,
 .type   = AVMEDIA_TYPE_VIDEO,
 .id = AV_CODEC_ID_MPEG2VIDEO,
-.pix_fmt= AV_PIX_FMT_VAAPI_VLD,
+.pix_fmt= AV_PIX_FMT_VAAPI,
 .start_frame= vaapi_mpeg2_start_frame,
 .end_frame  = ff_vaapi_mpeg_end_frame,
 .decode_slice   = vaapi_mpeg2_decode_slice,
diff --git a/libavcodec/vaapi_mpeg4.c b/libavcodec/vaapi_mpeg4.c
index 9b283f7..5b2e9d4 100644
--- a/libavcodec/vaapi_mpeg4.c
+++ b/libavcodec/vaapi_mpeg4.c
@@ -141,7 +141,7 @@ AVHWAccel ff_mpeg4_vaapi_hwaccel = {
 .name   = mpeg4_vaapi,
 .type   = AVMEDIA_TYPE_VIDEO,
 .id = AV_CODEC_ID_MPEG4,
-.pix_fmt= AV_PIX_FMT_VAAPI_VLD,
+.pix_fmt= AV_PIX_FMT_VAAPI,
 .start_frame= vaapi_mpeg4_start_frame,
 .end_frame  = ff_vaapi_mpeg_end_frame,
 .decode_slice   = vaapi_mpeg4_decode_slice,
@@ -153,7 +153,7 @@ AVHWAccel ff_h263_vaapi_hwaccel = {
 .name   = h263_vaapi,
 .type   = AVMEDIA_TYPE_VIDEO,
 .id = AV_CODEC_ID_H263,
-.pix_fmt= AV_PIX_FMT_VAAPI_VLD,
+.pix_fmt= AV_PIX_FMT_VAAPI,
 .start_frame= vaapi_mpeg4_start_frame,
 .end_frame  = ff_vaapi_mpeg_end_frame,
 .decode_slice   = vaapi_mpeg4_decode_slice,
diff --git a/libavcodec/vaapi_vc1.c b/libavcodec/vaapi_vc1.c
index 7ef9f2a..63d514d 100644
--- a/libavcodec/vaapi_vc1.c
+++ b/libavcodec/vaapi_vc1.c
@@ -339,7 +339,7 @@ AVHWAccel ff_wmv3_vaapi_hwaccel = {
 .name   = wmv3_vaapi,
 .type   = AVMEDIA_TYPE_VIDEO,
 .id = AV_CODEC_ID_WMV3,
-.pix_fmt= AV_PIX_FMT_VAAPI_VLD,
+.pix_fmt= AV_PIX_FMT_VAAPI,
 .start_frame= vaapi_vc1_start_frame,
 .end_frame  = ff_vaapi_mpeg_end_frame,
 .decode_slice   = vaapi_vc1_decode_slice,
@@ -350,7 +350,7 @@ AVHWAccel ff_vc1_vaapi_hwaccel = {
 .name   = vc1_vaapi,
 .type   = AVMEDIA_TYPE_VIDEO,
 .id = AV_CODEC_ID_VC1,
-.pix_fmt= AV_PIX_FMT_VAAPI_VLD,
+.pix_fmt= AV_PIX_FMT_VAAPI

[FFmpeg-devel] [PATCH 2/4] vaapi: streamline public context structure.

[Gwenole Beauchesne]

Move libavcodec managed objects from the public struct vaapi_context
to a new privately owned FFVAContext. This is done so that to clean up
and streamline the public structure, but also to prepare for new codec
support, thus requiring new internal data to be added in there.

The AVCodecContext.hwaccel_context, that holds the public vaapi_context,
shall no longer be accessed from within vaapi_*.c codec support files.

Signed-off-by: Gwenole Beauchesne gwenole.beauche...@intel.com
---
 libavcodec/vaapi.c  | 34 +-
 libavcodec/vaapi.h  | 16 
 libavcodec/vaapi_h264.c | 10 +++---
 libavcodec/vaapi_internal.h | 42 --
 libavcodec/vaapi_mpeg2.c|  8 ++--
 libavcodec/vaapi_mpeg4.c| 11 +--
 libavcodec/vaapi_vc1.c  | 11 +--
 libavcodec/version.h|  3 +++
 8 files changed, 111 insertions(+), 24 deletions(-)

diff --git a/libavcodec/vaapi.c b/libavcodec/vaapi.c
index 6ac22e6..880e3d6 100644
--- a/libavcodec/vaapi.c
+++ b/libavcodec/vaapi.c
@@ -41,7 +41,23 @@ static void destroy_buffers(VADisplay display, VABufferID 
*buffers, unsigned int
 }
 }
 
-int ff_vaapi_render_picture(struct vaapi_context *vactx, VASurfaceID surface)
+int ff_vaapi_context_init(AVCodecContext *avctx)
+{
+FFVAContext * const vactx = ff_vaapi_get_context(avctx);
+const struct vaapi_context * const user_vactx = avctx-hwaccel_context;
+
+vactx-display  = user_vactx-display;
+vactx-config_id= user_vactx-config_id;
+vactx-context_id   = user_vactx-context_id;
+return 0;
+}
+
+int ff_vaapi_context_fini(AVCodecContext *avctx)
+{
+return 0;
+}
+
+int ff_vaapi_render_picture(FFVAContext *vactx, VASurfaceID surface)
 {
 VABufferID va_buffers[3];
 unsigned int n_va_buffers = 0;
@@ -81,7 +97,7 @@ int ff_vaapi_render_picture(struct vaapi_context *vactx, 
VASurfaceID surface)
 return 0;
 }
 
-int ff_vaapi_commit_slices(struct vaapi_context *vactx)
+int ff_vaapi_commit_slices(FFVAContext *vactx)
 {
 VABufferID *slice_buf_ids;
 VABufferID slice_param_buf_id, slice_data_buf_id;
@@ -121,7 +137,7 @@ int ff_vaapi_commit_slices(struct vaapi_context *vactx)
 return 0;
 }
 
-static void *alloc_buffer(struct vaapi_context *vactx, int type, unsigned int 
size, uint32_t *buf_id)
+static void *alloc_buffer(FFVAContext *vactx, int type, unsigned int size, 
uint32_t *buf_id)
 {
 void *data = NULL;
 
@@ -133,22 +149,22 @@ static void *alloc_buffer(struct vaapi_context *vactx, 
int type, unsigned int si
 return data;
 }
 
-void *ff_vaapi_alloc_pic_param(struct vaapi_context *vactx, unsigned int size)
+void *ff_vaapi_alloc_pic_param(FFVAContext *vactx, unsigned int size)
 {
 return alloc_buffer(vactx, VAPictureParameterBufferType, size, 
vactx-pic_param_buf_id);
 }
 
-void *ff_vaapi_alloc_iq_matrix(struct vaapi_context *vactx, unsigned int size)
+void *ff_vaapi_alloc_iq_matrix(FFVAContext *vactx, unsigned int size)
 {
 return alloc_buffer(vactx, VAIQMatrixBufferType, size, 
vactx-iq_matrix_buf_id);
 }
 
-uint8_t *ff_vaapi_alloc_bitplane(struct vaapi_context *vactx, uint32_t size)
+uint8_t *ff_vaapi_alloc_bitplane(FFVAContext *vactx, uint32_t size)
 {
 return alloc_buffer(vactx, VABitPlaneBufferType, size, 
vactx-bitplane_buf_id);
 }
 
-VASliceParameterBufferBase *ff_vaapi_alloc_slice(struct vaapi_context *vactx, 
const uint8_t *buffer, uint32_t size)
+VASliceParameterBufferBase *ff_vaapi_alloc_slice(FFVAContext *vactx, const 
uint8_t *buffer, uint32_t size)
 {
 uint8_t *slice_params;
 VASliceParameterBufferBase *slice_param;
@@ -181,7 +197,7 @@ VASliceParameterBufferBase *ff_vaapi_alloc_slice(struct 
vaapi_context *vactx, co
 
 void ff_vaapi_common_end_frame(AVCodecContext *avctx)
 {
-struct vaapi_context * const vactx = avctx-hwaccel_context;
+FFVAContext * const vactx = ff_vaapi_get_context(avctx);
 
 ff_dlog(avctx, ff_vaapi_common_end_frame()\n);
 
@@ -202,7 +218,7 @@ void ff_vaapi_common_end_frame(AVCodecContext *avctx)
 CONFIG_VC1_VAAPI_HWACCEL   || CONFIG_WMV3_VAAPI_HWACCEL
 int ff_vaapi_mpeg_end_frame(AVCodecContext *avctx)
 {
-struct vaapi_context * const vactx = avctx-hwaccel_context;
+FFVAContext * const vactx = ff_vaapi_get_context(avctx);
 MpegEncContext *s = avctx-priv_data;
 int ret;
 
diff --git a/libavcodec/vaapi.h b/libavcodec/vaapi.h
index 815a27e..4448a2e 100644
--- a/libavcodec/vaapi.h
+++ b/libavcodec/vaapi.h
@@ -31,6 +31,8 @@
  */
 
 #include stdint.h
+#include libavutil/attributes.h
+#include version.h
 
 /**
  * @defgroup lavc_codec_hwaccel_vaapi VA API Decoding
@@ -72,12 +74,14 @@ struct vaapi_context {
  */
 uint32_t context_id;
 
+#if FF_API_VAAPI_CONTEXT
 /**
  * VAPictureParameterBuffer ID
  *
  * - encoding: unused
  * - decoding: Set by libavcodec
  */
+attribute_deprecated
 uint32_t pic_param_buf_id

[FFmpeg-devel] [PATCH 1/4] vaapi: define a single pixel format for VA-API (AV_PIX_FMT_VAAPI).

[Gwenole Beauchesne]

Deprecate older VA pixel formats (MOCO, IDCT) as it is now very unlikely
to ever be useful in the future. Only keep plain AV_PIX_FMT_VAAPI format
that is aliased to the older VLD variant.

Signed-off-by: Gwenole Beauchesne gwenole.beauche...@intel.com
---
 libavcodec/h263dec.c |  2 +-
 libavcodec/h264_slice.c  |  2 +-
 libavcodec/mpeg12dec.c   |  2 +-
 libavcodec/vaapi_h264.c  |  2 +-
 libavcodec/vaapi_mpeg2.c |  2 +-
 libavcodec/vaapi_mpeg4.c |  4 ++--
 libavcodec/vaapi_vc1.c   |  4 ++--
 libavcodec/vc1dec.c  |  2 +-
 libavutil/pixdesc.c  |  9 +
 libavutil/pixfmt.h   | 11 +++
 libavutil/version.h  |  3 +++
 11 files changed, 33 insertions(+), 10 deletions(-)

diff --git a/libavcodec/h263dec.c b/libavcodec/h263dec.c
index 7fa7090..e647e40 100644
--- a/libavcodec/h263dec.c
+++ b/libavcodec/h263dec.c
@@ -718,7 +718,7 @@ frame_end:
 
 const enum AVPixelFormat ff_h263_hwaccel_pixfmt_list_420[] = {
 #if CONFIG_H263_VAAPI_HWACCEL || CONFIG_MPEG4_VAAPI_HWACCEL
-AV_PIX_FMT_VAAPI_VLD,
+AV_PIX_FMT_VAAPI,
 #endif
 #if CONFIG_H263_VDPAU_HWACCEL || CONFIG_MPEG4_VDPAU_HWACCEL
 AV_PIX_FMT_VDPAU,
diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index 48f501b..7b35c08 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -943,7 +943,7 @@ static enum AVPixelFormat get_pixel_format(H264Context *h, 
int force_callback)
 *fmt++ = AV_PIX_FMT_D3D11VA_VLD;
 #endif
 #if CONFIG_H264_VAAPI_HWACCEL
-*fmt++ = AV_PIX_FMT_VAAPI_VLD;
+*fmt++ = AV_PIX_FMT_VAAPI;
 #endif
 #if CONFIG_H264_VDA_HWACCEL
 *fmt++ = AV_PIX_FMT_VDA_VLD;
diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
index c7a5701..d2bedbc 100644
--- a/libavcodec/mpeg12dec.c
+++ b/libavcodec/mpeg12dec.c
@@ -1209,7 +1209,7 @@ static const enum AVPixelFormat 
mpeg2_hwaccel_pixfmt_list_420[] = {
 AV_PIX_FMT_D3D11VA_VLD,
 #endif
 #if CONFIG_MPEG2_VAAPI_HWACCEL
-AV_PIX_FMT_VAAPI_VLD,
+AV_PIX_FMT_VAAPI,
 #endif
 #if CONFIG_MPEG2_VIDEOTOOLBOX_HWACCEL
 AV_PIX_FMT_VIDEOTOOLBOX,
diff --git a/libavcodec/vaapi_h264.c b/libavcodec/vaapi_h264.c
index 151aca9..55ee2fc 100644
--- a/libavcodec/vaapi_h264.c
+++ b/libavcodec/vaapi_h264.c
@@ -359,7 +359,7 @@ AVHWAccel ff_h264_vaapi_hwaccel = {
 .name   = h264_vaapi,
 .type   = AVMEDIA_TYPE_VIDEO,
 .id = AV_CODEC_ID_H264,
-.pix_fmt= AV_PIX_FMT_VAAPI_VLD,
+.pix_fmt= AV_PIX_FMT_VAAPI,
 .start_frame= vaapi_h264_start_frame,
 .end_frame  = vaapi_h264_end_frame,
 .decode_slice   = vaapi_h264_decode_slice,
diff --git a/libavcodec/vaapi_mpeg2.c b/libavcodec/vaapi_mpeg2.c
index 87fab89..27c69cd 100644
--- a/libavcodec/vaapi_mpeg2.c
+++ b/libavcodec/vaapi_mpeg2.c
@@ -138,7 +138,7 @@ AVHWAccel ff_mpeg2_vaapi_hwaccel = {
 .name   = mpeg2_vaapi,
 .type   = AVMEDIA_TYPE_VIDEO,
 .id = AV_CODEC_ID_MPEG2VIDEO,
-.pix_fmt= AV_PIX_FMT_VAAPI_VLD,
+.pix_fmt= AV_PIX_FMT_VAAPI,
 .start_frame= vaapi_mpeg2_start_frame,
 .end_frame  = ff_vaapi_mpeg_end_frame,
 .decode_slice   = vaapi_mpeg2_decode_slice,
diff --git a/libavcodec/vaapi_mpeg4.c b/libavcodec/vaapi_mpeg4.c
index 9b283f7..5b2e9d4 100644
--- a/libavcodec/vaapi_mpeg4.c
+++ b/libavcodec/vaapi_mpeg4.c
@@ -141,7 +141,7 @@ AVHWAccel ff_mpeg4_vaapi_hwaccel = {
 .name   = mpeg4_vaapi,
 .type   = AVMEDIA_TYPE_VIDEO,
 .id = AV_CODEC_ID_MPEG4,
-.pix_fmt= AV_PIX_FMT_VAAPI_VLD,
+.pix_fmt= AV_PIX_FMT_VAAPI,
 .start_frame= vaapi_mpeg4_start_frame,
 .end_frame  = ff_vaapi_mpeg_end_frame,
 .decode_slice   = vaapi_mpeg4_decode_slice,
@@ -153,7 +153,7 @@ AVHWAccel ff_h263_vaapi_hwaccel = {
 .name   = h263_vaapi,
 .type   = AVMEDIA_TYPE_VIDEO,
 .id = AV_CODEC_ID_H263,
-.pix_fmt= AV_PIX_FMT_VAAPI_VLD,
+.pix_fmt= AV_PIX_FMT_VAAPI,
 .start_frame= vaapi_mpeg4_start_frame,
 .end_frame  = ff_vaapi_mpeg_end_frame,
 .decode_slice   = vaapi_mpeg4_decode_slice,
diff --git a/libavcodec/vaapi_vc1.c b/libavcodec/vaapi_vc1.c
index 7ef9f2a..63d514d 100644
--- a/libavcodec/vaapi_vc1.c
+++ b/libavcodec/vaapi_vc1.c
@@ -339,7 +339,7 @@ AVHWAccel ff_wmv3_vaapi_hwaccel = {
 .name   = wmv3_vaapi,
 .type   = AVMEDIA_TYPE_VIDEO,
 .id = AV_CODEC_ID_WMV3,
-.pix_fmt= AV_PIX_FMT_VAAPI_VLD,
+.pix_fmt= AV_PIX_FMT_VAAPI,
 .start_frame= vaapi_vc1_start_frame,
 .end_frame  = ff_vaapi_mpeg_end_frame,
 .decode_slice   = vaapi_vc1_decode_slice,
@@ -350,7 +350,7 @@ AVHWAccel ff_vc1_vaapi_hwaccel = {
 .name   = vc1_vaapi,
 .type   = AVMEDIA_TYPE_VIDEO,
 .id = AV_CODEC_ID_VC1,
-.pix_fmt= AV_PIX_FMT_VAAPI_VLD,
+.pix_fmt= AV_PIX_FMT_VAAPI

[FFmpeg-devel] [PATCH 3/4] vaapi: fix usage of invalid buffer ids.

[Gwenole Beauchesne]

Invalid buffer ids are defined by VA_INVALID_ID. Use that through out
vaapi_*.c support files now that we have private data initialized and
managed by libavcodec. Previously, the only requirement for the public
vaapi_context struct was to be zero-initialized.

This fixes support for 3rdparty VA drivers that strictly conform to
the API whereby an invalid buffer id is VA_INVALID_ID and the first
valid buffer id can actually be zero.

Signed-off-by: Gwenole Beauchesne gwenole.beauche...@intel.com
---
 libavcodec/vaapi.c | 20 
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/libavcodec/vaapi.c b/libavcodec/vaapi.c
index 880e3d6..1ae71a5 100644
--- a/libavcodec/vaapi.c
+++ b/libavcodec/vaapi.c
@@ -34,9 +34,9 @@ static void destroy_buffers(VADisplay display, VABufferID 
*buffers, unsigned int
 {
 unsigned int i;
 for (i = 0; i  n_buffers; i++) {
-if (buffers[i]) {
+if (buffers[i] != VA_INVALID_ID) {
 vaDestroyBuffer(display, buffers[i]);
-buffers[i] = 0;
+buffers[i] = VA_INVALID_ID;
 }
 }
 }
@@ -49,6 +49,10 @@ int ff_vaapi_context_init(AVCodecContext *avctx)
 vactx-display  = user_vactx-display;
 vactx-config_id= user_vactx-config_id;
 vactx-context_id   = user_vactx-context_id;
+
+vactx-pic_param_buf_id = VA_INVALID_ID;
+vactx-iq_matrix_buf_id = VA_INVALID_ID;
+vactx-bitplane_buf_id  = VA_INVALID_ID;
 return 0;
 }
 
@@ -62,18 +66,18 @@ int ff_vaapi_render_picture(FFVAContext *vactx, VASurfaceID 
surface)
 VABufferID va_buffers[3];
 unsigned int n_va_buffers = 0;
 
-if (!vactx-pic_param_buf_id)
+if (vactx-pic_param_buf_id == VA_INVALID_ID)
 return 0;
 
 vaUnmapBuffer(vactx-display, vactx-pic_param_buf_id);
 va_buffers[n_va_buffers++] = vactx-pic_param_buf_id;
 
-if (vactx-iq_matrix_buf_id) {
+if (vactx-iq_matrix_buf_id != VA_INVALID_ID) {
 vaUnmapBuffer(vactx-display, vactx-iq_matrix_buf_id);
 va_buffers[n_va_buffers++] = vactx-iq_matrix_buf_id;
 }
 
-if (vactx-bitplane_buf_id) {
+if (vactx-bitplane_buf_id != VA_INVALID_ID) {
 vaUnmapBuffer(vactx-display, vactx-bitplane_buf_id);
 va_buffers[n_va_buffers++] = vactx-bitplane_buf_id;
 }
@@ -113,7 +117,7 @@ int ff_vaapi_commit_slices(FFVAContext *vactx)
 return -1;
 vactx-slice_buf_ids = slice_buf_ids;
 
-slice_param_buf_id = 0;
+slice_param_buf_id = VA_INVALID_ID;
 if (vaCreateBuffer(vactx-display, vactx-context_id,
VASliceParameterBufferType,
vactx-slice_param_size,
@@ -122,7 +126,7 @@ int ff_vaapi_commit_slices(FFVAContext *vactx)
 return -1;
 vactx-slice_count = 0;
 
-slice_data_buf_id = 0;
+slice_data_buf_id = VA_INVALID_ID;
 if (vaCreateBuffer(vactx-display, vactx-context_id,
VASliceDataBufferType,
vactx-slice_data_size,
@@ -141,7 +145,7 @@ static void *alloc_buffer(FFVAContext *vactx, int type, 
unsigned int size, uint3
 {
 void *data = NULL;
 
-*buf_id = 0;
+*buf_id = VA_INVALID_ID;
 if (vaCreateBuffer(vactx-display, vactx-context_id,
type, size, 1, NULL, buf_id) == VA_STATUS_SUCCESS)
 vaMapBuffer(vactx-display, *buf_id, data);
-- 
1.9.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 0/4] vaapi: improvements fixes to common infrastructure

[Gwenole Beauchesne]

Hi,

This patch series contains a few changes I was wondering for some time
now and had finally some time to work on recently. This is preparatory
and minimal work in view to supporting other (WIP) changes.

For convenience, I have placed the code here:
https://github.com/gbeauchesne/FFmpeg/tree/10.vaapi.lavc.fixes

Regards,
Gwenole Beauchesne (4):
  vaapi: define a single pixel format for VA-API (AV_PIX_FMT_VAAPI).
  vaapi: streamline public context structure.
  vaapi: fix usage of invalid buffer ids.
  vaapi: add interfaces to properly initialize context.

 libavcodec/h263dec.c|  2 +-
 libavcodec/h264_slice.c |  2 +-
 libavcodec/mpeg12dec.c  |  2 +-
 libavcodec/vaapi.c  | 84 -
 libavcodec/vaapi.h  | 75 +---
 libavcodec/vaapi_h264.c | 12 ---
 libavcodec/vaapi_internal.h | 43 +++
 libavcodec/vaapi_mpeg2.c| 10 --
 libavcodec/vaapi_mpeg4.c| 15 +---
 libavcodec/vaapi_vc1.c  | 15 +---
 libavcodec/vc1dec.c |  2 +-
 libavcodec/version.h|  3 ++
 libavutil/pixdesc.c |  9 +
 libavutil/pixfmt.h  | 11 ++
 libavutil/version.h |  3 ++
 15 files changed, 241 insertions(+), 47 deletions(-)

-- 
1.9.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 4/4] vaapi: add interfaces to properly initialize context.

[Gwenole Beauchesne]

Hi,

2015-08-17 19:17 GMT+02:00 Gwenole Beauchesne gb.de...@gmail.com:
 Add av_vaapi_context_init() and av_vaapi_context_alloc() helper functions
 so that to properly initialize the vaapi_context structure, and allow for
 future extensions without breaking the API/ABI.

 The new version and flags fields are inserted after the last known user
 initialized field, and actually useful field at all, i.e. VA context_id.
 This is safe because the vaapi_context structure was required to be zero
 initialized in the past. And, since those new helper functions and changes
 cause the AV_VAAPI_CONTEXT_VERSION to be bumped, we can track older struct
 requirements from within libavcodec.

 Besides, it is now required by design, and actual usage, that the vaapi
 context structure be completely initialized once and for all before the
 AVCodecContext.get_format() function ever completes.

 Signed-off-by: Gwenole Beauchesne gwenole.beauche...@intel.com
 ---
  libavcodec/vaapi.c  | 30 +++
  libavcodec/vaapi.h  | 59 
 +
  libavcodec/vaapi_internal.h |  1 +
  3 files changed, 85 insertions(+), 5 deletions(-)

 diff --git a/libavcodec/vaapi.c b/libavcodec/vaapi.c
 index 1ae71a5..4d3e2f3 100644
 --- a/libavcodec/vaapi.c
 +++ b/libavcodec/vaapi.c
 @@ -41,11 +41,41 @@ static void destroy_buffers(VADisplay display, VABufferID 
 *buffers, unsigned int
  }
  }

 +/* Allocates a vaapi_context structure */
 +struct vaapi_context *av_vaapi_context_alloc(unsigned int flags)
 +{
 +struct vaapi_context *vactx;
 +
 +vactx = av_malloc(sizeof(*vactx));
 +if (!vactx)
 +return NULL;
 +
 +av_vaapi_context_init(vactx, AV_VAAPI_CONTEXT_VERSION, flags);
 +return vactx;
 +}
 +
 +/* Initializes a vaapi_context structure with safe defaults */
 +void av_vaapi_context_init(struct vaapi_context *vactx, unsigned int version,
 +   unsigned int flags)
 +{
 +vactx-display  = NULL;
 +vactx-config_id= VA_INVALID_ID;
 +vactx-context_id   = VA_INVALID_ID;
 +
 +if (version  0) {
 +vactx-version  = version;
 +vactx-flags= flags;
 +}
 +}
 +
  int ff_vaapi_context_init(AVCodecContext *avctx)
  {
  FFVAContext * const vactx = ff_vaapi_get_context(avctx);
  const struct vaapi_context * const user_vactx = avctx-hwaccel_context;

 +if (user_vactx-version  0)
 +vactx-flags= user_vactx-flags;
 +
  vactx-display  = user_vactx-display;
  vactx-config_id= user_vactx-config_id;
  vactx-context_id   = user_vactx-context_id;
 diff --git a/libavcodec/vaapi.h b/libavcodec/vaapi.h
 index 4448a2e..1f032a0 100644
 --- a/libavcodec/vaapi.h
 +++ b/libavcodec/vaapi.h
 @@ -40,14 +40,16 @@
   * @{
   */

 +#define AV_VAAPI_CONTEXT_VERSION 1
 +
  /**
   * This structure is used to share data between the FFmpeg library and
   * the client video application.
 - * This shall be zero-allocated and available as
 - * AVCodecContext.hwaccel_context. All user members can be set once
 - * during initialization or through each AVCodecContext.get_buffer()
 - * function call. In any case, they must be valid prior to calling
 - * decoding functions.
 + *
 + * This shall be initialized with av_vaapi_context_init(), or
 + * indirectly through av_vaapi_context_alloc(), and made available as
 + * AVCodecContext.hwaccel_context. All user members must be properly
 + * initialized before AVCodecContext.get_format() completes.
   */
  struct vaapi_context {
  /**
 @@ -74,6 +76,29 @@ struct vaapi_context {
   */
  uint32_t context_id;

 +/**
 + * This field must be set to AV_VAAPI_CONTEXT_VERSION
 + *
 + * @since Version 1.
 + *
 + * - encoding: unused
 + * - decoding: Set by user, through av_vaapi_context_init()
 + */
 +unsigned int version;
 +
 +/**
 + * A bit field configuring the internal context used by libavcodec
 + *
 + * This is a combination of flags from common AV_HWACCEL_FLAG_xxx and
 + * from VA-API specific AV_VAAPI_FLAG_xxx.
 + *
 + * @since Version 1.
 + *
 + * - encoding: unused
 + * - decoding: Set by user, through av_vaapi_context_init()
 + */
 +unsigned int flags;
 +
  #if FF_API_VAAPI_CONTEXT
  /**
   * VAPictureParameterBuffer ID
 @@ -184,6 +209,30 @@ struct vaapi_context {
  #endif
  };

 +/**
 + * Allocates a vaapi_context structure.
 + *
 + * This function allocates and initializes a vaapi_context with safe
 + * defaults, e.g. with proper invalid ids for VA config and context.
 + *
 + * The resulting structure can be deallocated with av_freep().
 + *
 + * @param[in]  flagszero, or a combination of AV_HWACCEL_FLAG_xxx or
 + * AV_VAAPI_FLAG_xxx flags OR'd altogether.
 + * @return Newly-allocated struct vaapi_context, or NULL on failure
 + */
 +struct vaapi_context *av_vaapi_context_alloc(unsigned int flags

[FFmpeg-devel] [PATCH 4/4] vaapi: add interfaces to properly initialize context.

[Gwenole Beauchesne]

Add av_vaapi_context_init() and av_vaapi_context_alloc() helper functions
so that to properly initialize the vaapi_context structure, and allow for
future extensions without breaking the API/ABI.

The new version and flags fields are inserted after the last known user
initialized field, and actually useful field at all, i.e. VA context_id.
This is safe because the vaapi_context structure was required to be zero
initialized in the past. And, since those new helper functions and changes
cause the AV_VAAPI_CONTEXT_VERSION to be bumped, we can track older struct
requirements from within libavcodec.

Besides, it is now required by design, and actual usage, that the vaapi
context structure be completely initialized once and for all before the
AVCodecContext.get_format() function ever completes.

Signed-off-by: Gwenole Beauchesne gwenole.beauche...@intel.com
---
 libavcodec/vaapi.c  | 30 +++
 libavcodec/vaapi.h  | 59 +
 libavcodec/vaapi_internal.h |  1 +
 3 files changed, 85 insertions(+), 5 deletions(-)

diff --git a/libavcodec/vaapi.c b/libavcodec/vaapi.c
index 1ae71a5..4d3e2f3 100644
--- a/libavcodec/vaapi.c
+++ b/libavcodec/vaapi.c
@@ -41,11 +41,41 @@ static void destroy_buffers(VADisplay display, VABufferID 
*buffers, unsigned int
 }
 }
 
+/* Allocates a vaapi_context structure */
+struct vaapi_context *av_vaapi_context_alloc(unsigned int flags)
+{
+struct vaapi_context *vactx;
+
+vactx = av_malloc(sizeof(*vactx));
+if (!vactx)
+return NULL;
+
+av_vaapi_context_init(vactx, AV_VAAPI_CONTEXT_VERSION, flags);
+return vactx;
+}
+
+/* Initializes a vaapi_context structure with safe defaults */
+void av_vaapi_context_init(struct vaapi_context *vactx, unsigned int version,
+   unsigned int flags)
+{
+vactx-display  = NULL;
+vactx-config_id= VA_INVALID_ID;
+vactx-context_id   = VA_INVALID_ID;
+
+if (version  0) {
+vactx-version  = version;
+vactx-flags= flags;
+}
+}
+
 int ff_vaapi_context_init(AVCodecContext *avctx)
 {
 FFVAContext * const vactx = ff_vaapi_get_context(avctx);
 const struct vaapi_context * const user_vactx = avctx-hwaccel_context;
 
+if (user_vactx-version  0)
+vactx-flags= user_vactx-flags;
+
 vactx-display  = user_vactx-display;
 vactx-config_id= user_vactx-config_id;
 vactx-context_id   = user_vactx-context_id;
diff --git a/libavcodec/vaapi.h b/libavcodec/vaapi.h
index 4448a2e..1f032a0 100644
--- a/libavcodec/vaapi.h
+++ b/libavcodec/vaapi.h
@@ -40,14 +40,16 @@
  * @{
  */
 
+#define AV_VAAPI_CONTEXT_VERSION 1
+
 /**
  * This structure is used to share data between the FFmpeg library and
  * the client video application.
- * This shall be zero-allocated and available as
- * AVCodecContext.hwaccel_context. All user members can be set once
- * during initialization or through each AVCodecContext.get_buffer()
- * function call. In any case, they must be valid prior to calling
- * decoding functions.
+ *
+ * This shall be initialized with av_vaapi_context_init(), or
+ * indirectly through av_vaapi_context_alloc(), and made available as
+ * AVCodecContext.hwaccel_context. All user members must be properly
+ * initialized before AVCodecContext.get_format() completes.
  */
 struct vaapi_context {
 /**
@@ -74,6 +76,29 @@ struct vaapi_context {
  */
 uint32_t context_id;
 
+/**
+ * This field must be set to AV_VAAPI_CONTEXT_VERSION
+ *
+ * @since Version 1.
+ *
+ * - encoding: unused
+ * - decoding: Set by user, through av_vaapi_context_init()
+ */
+unsigned int version;
+
+/**
+ * A bit field configuring the internal context used by libavcodec
+ *
+ * This is a combination of flags from common AV_HWACCEL_FLAG_xxx and
+ * from VA-API specific AV_VAAPI_FLAG_xxx.
+ *
+ * @since Version 1.
+ *
+ * - encoding: unused
+ * - decoding: Set by user, through av_vaapi_context_init()
+ */
+unsigned int flags;
+
 #if FF_API_VAAPI_CONTEXT
 /**
  * VAPictureParameterBuffer ID
@@ -184,6 +209,30 @@ struct vaapi_context {
 #endif
 };
 
+/**
+ * Allocates a vaapi_context structure.
+ *
+ * This function allocates and initializes a vaapi_context with safe
+ * defaults, e.g. with proper invalid ids for VA config and context.
+ *
+ * The resulting structure can be deallocated with av_freep().
+ *
+ * @param[in]  flagszero, or a combination of AV_HWACCEL_FLAG_xxx or
+ * AV_VAAPI_FLAG_xxx flags OR'd altogether.
+ * @return Newly-allocated struct vaapi_context, or NULL on failure
+ */
+struct vaapi_context *av_vaapi_context_alloc(unsigned int flags);
+
+/**
+ * Initializes a vaapi_context structure with safe defaults.
+ *
+ * @param[in]  version  this must be set to AV_VAAPI_CONTEXT_VERSION
+ * @param[in]  flagszero, or a combination of AV_HWACCEL_FLAG_xxx

Re: [FFmpeg-devel] [PATCH] libavcodec/qsv.c: Issue fixed: QSV engine does not release display handler under linux platform.

[Gwenole Beauchesne]

Hi,

2015-07-13 16:22 GMT+02:00 Ivan Uskov ivan.us...@nablet.com:
 Hello All,

 Current QSV engine implementation does allocate but never does release
 a display handler under linux platforms.
 The attached patch solved this issue, please review.

LGTM. However, missing newline IMHO before
ff_qsv_close_internal_session() and after QSVSession definition.

Note it would also be interesting to provide a means to import a
VADisplay from the user through an additional function. e.g. in view
to interop VA decode to MSDK encode and/or video processing.

Regards,
-- 
Gwenole Beauchesne
Intel Corporation SAS / 2 rue de Paris, 92196 Meudon Cedex, France
Registration Number (RCS): Nanterre B 302 456 199
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] vaapi_h264: fix RefPicList[] field flags.

[Gwenole Beauchesne]

2015-06-23 13:10 GMT+02:00 Michael Niedermayer michae...@gmx.at:
 On Tue, Jun 23, 2015 at 11:50:52AM +0200, Gwenole Beauchesne wrote:
 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 gwenole.beauche...@intel.com
 ---
  libavcodec/vaapi_h264.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

 LGTM

Pushed to git master and release/2.7, in case a 2.7.2 is planned. 2.6 was fine.

All H.264 conformance tests now pass again. Exceptions are:
- CVFC1_Sony_C: usual crop issues ;
- BA3_SVA_C: probably driver issue. Usually disabled since this is
extended profile with main profile only coding tools.

Regards,
-- 
Gwenole Beauchesne
Intel Corporation SAS / 2 rue de Paris, 92196 Meudon Cedex, France
Registration Number (RCS): Nanterre B 302 456 199
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] vaapi_h264: fix RefPicList[] field flags.

[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 gwenole.beauche...@intel.com
---
 libavcodec/vaapi_h264.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavcodec/vaapi_h264.c b/libavcodec/vaapi_h264.c
index eef3c29..151aca9 100644
--- a/libavcodec/vaapi_h264.c
+++ b/libavcodec/vaapi_h264.c
@@ -162,7 +162,8 @@ static void fill_vaapi_RefPicList(VAPictureH264 
RefPicList[32],
 unsigned int i, n = 0;
 for (i = 0; i  ref_count; i++)
 if (ref_list[i].reference)
-fill_vaapi_pic(RefPicList[n++], ref_list[i].parent, 0);
+fill_vaapi_pic(RefPicList[n++], ref_list[i].parent,
+   ref_list[i].reference);
 
 for (; n  32; n++)
 init_vaapi_pic(RefPicList[n]);
-- 
1.9.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC] DXVA2 decoding and FFmpeg

[Gwenole Beauchesne]

Hi,

2015-06-16 10:35 GMT+02:00 Stefano Sabatini stefa...@gmail.com:
 On date Tuesday 2015-06-16 10:20:31 +0200, wm4 encoded:
 On Mon, 15 Jun 2015 17:55:35 +0200
 Stefano Sabatini stefa...@gmail.com wrote:

  On date Monday 2015-06-15 11:56:13 +0200, Stefano Sabatini encoded:
  [...]
   From 3a75ef1e86360cd6f30b8e550307404d0d1c1dba Mon Sep 17 00:00:00 2001
   From: Stefano Sabatini stefa...@gmail.com
   Date: Mon, 15 Jun 2015 11:02:50 +0200
   Subject: [PATCH] lavu/mem: add av_memcpynt() function with x86 
   optimizations
  
   Assembly based on code from vlc dxva2.c, commit 62107e56 by Laurent Aimar
   fen...@videolan.org.
  
   TODO: bump minor, update APIchanges
   ---
libavutil/mem.c  |  9 +
libavutil/mem.h  | 14 
libavutil/mem_internal.h | 26 +++
libavutil/x86/Makefile   |  1 +
libavutil/x86/mem.c  | 85 
   
5 files changed, 135 insertions(+)
create mode 100644 libavutil/mem_internal.h
create mode 100644 libavutil/x86/mem.c
  
   diff --git a/libavutil/mem.c b/libavutil/mem.c
   index da291fb..0e1eb01 100644
   --- a/libavutil/mem.c
   +++ b/libavutil/mem.c
   @@ -42,6 +42,7 @@
#include dynarray.h
#include intreadwrite.h
#include mem.h
   +#include mem_internal.h
  
#ifdef MALLOC_PREFIX
  
   @@ -515,3 +516,11 @@ void av_fast_malloc(void *ptr, unsigned int *size, 
   size_t min_size)
ff_fast_malloc(ptr, size, min_size, 0);
}
  
   +void av_memcpynt(void *dst, const void *src, size_t size, int cpu_flags)
   +{
   +#if ARCH_X86
   +ff_memcpynt_x86(dst, src, size, cpu_flags);
   +#else
   +memcpy(dst, src, size, cpu_flags);
   +#endif
   +}
 
  Alternatively, what about something like:
 
  av_memcpynt_fn av_memcpynt_get_fn(void);
 
  modeled after av_pixelutils_get_sad_fn()? This would skip the need for
  a wrapper calling the right function.


 I don't see much value in this, unless determining the right function
 causes too much overhead.

 I see two advantages, 1. no branch and function call when the function
 is called, 2. the cpu_flags must not be passed around, so it's somehow
 safer.

Interesting approach. You probably could also use something similar to
sws context you build up based on surface size, and other
characteristics (flags)?

Regards,
-- 
Gwenole Beauchesne
Intel Corporation SAS / 2 rue de Paris, 92196 Meudon Cedex, France
Registration Number (RCS): Nanterre B 302 456 199
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC] DXVA2 decoding and FFmpeg

[Gwenole Beauchesne]

, as these allow gcc to put
 SSE instructions directly in the code where it likes

 The way out of this design is not to tell gcc that it passes
 a string with SSE code to the assembler
 that is not to use SSE registers in operands and not to put them
 on the clobber list unless gcc actually is in SSE mode and can use and
 need them there.
 see XMM_CLOBBERS*

Well, from past experience, lying to gcc is generally not a good thing
either. There are multiple interesting ways it could fail from time to
time. :)

Other approaches:
- With GCC = 4.4, you can use __attribute__((target(T))) where T =
ssse3, sse4.1, etc. This is the easiest way ;
- Split into several separate files per target. Though, one would then
argue that while we are at it why not just start moving to yasm.

The former approach looks more appealing to me, considering there may
be an effort to migrate to yasm afterwards.

Regards,
-- 
Gwenole Beauchesne
Intel Corporation SAS / 2 rue de Paris, 92196 Meudon Cedex, France
Registration Number (RCS): Nanterre B 302 456 199
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel