Re: [libav-devel] [PATCH] d3d11va: Check WINAPI_FAMILY instead of HAVE_LOADLIBRARY

On Tue, 4 Jul 2017 22:18:21 +0300 Martin Storsjö wrote: > If using the winstore compat library, a fallback LoadLibrary > function does exist, that only calls LoadPackagedLibrary though > (which doesn't work for dynamically loading d3d11 DLLs). > > Therefore explicitly check

Re: [libav-devel] [PATCH] Add a new channel layout API

On Thu, 29 Jun 2017 17:28:51 -0400 Vittorio Giovara wrote: > From: Anton Khirnov > > The new API is more extensible and allows for custom layouts. > More accurate information is exported, eg for decoders that do not > set a channel layout, lavc

Re: [libav-devel] [PATCH 12/25] lavc: switch to the new channel layout API

On Thu, 29 Jun 2017 14:44:52 -0400 Vittorio Giovara <vittorio.giov...@gmail.com> wrote: > On Thu, Jun 29, 2017 at 5:18 AM, wm4 <nfx...@googlemail.com> wrote: > > On Wed, 28 Jun 2017 18:10:56 -0400 > > Vittorio Giovara <vittorio.giov...@gmail.com> wrote: > >

Re: [libav-devel] [PATCH 07/12] lavfi: Add some common code for OpenCL filtering

On Thu, 29 Jun 2017 10:25:09 +0100 Mark Thompson wrote: > This does actually work already by magic :) > > Both NV12 and P010 surfaces become UNORM R and RG planes, just with a > different size of sample underneath. Use in OpenCL then sees them > identically as planes of

Re: [libav-devel] [PATCH 18/25] lavr: Only let pass-through ambisonic channel layouts

On Wed, 28 Jun 2017 18:11:02 -0400 Vittorio Giovara wrote: > Resampling or conversion to/from ambisonic audio are currently > unsupported features. > > Signed-off-by: Vittorio Giovara > --- > libavresample/utils.c | 8 > 1 file

Re: [libav-devel] [PATCH 17/25] channel_layout: Add Ambisonic components and channel order

On Wed, 28 Jun 2017 18:11:01 -0400 Vittorio Giovara wrote: > Signed-off-by: Vittorio Giovara > --- > libavutil/channel_layout.c | 86 > -- > libavutil/channel_layout.h | 33 ++ >

Re: [libav-devel] [PATCH 12/25] lavc: switch to the new channel layout API

On Wed, 28 Jun 2017 18:10:56 -0400 Vittorio Giovara wrote: > Since the request_channel_layout is used only by a handful of codecs, > move the option to codec private contexts. Not sure if that is justified... ___

Re: [libav-devel] [PATCH 01/25] Add a new channel layout API

On Wed, 28 Jun 2017 18:10:45 -0400 Vittorio Giovara wrote: > From: Anton Khirnov > > The new API is more extensible and allows for custom layouts. > More accurate information is exported, eg for decoders that do not > set a channel layout, lavc

Re: [libav-devel] [PATCH 12/12] test-only: Create D3D11 textures with D3D11_RESOURCE_MISC_SHARED

On Wed, 28 Jun 2017 13:51:26 +0100 Mark Thompson <s...@jkqxz.net> wrote: > On 28/06/17 12:13, wm4 wrote: > > On Tue, 27 Jun 2017 22:50:54 +0100 > > Mark Thompson <s...@jkqxz.net> wrote: > > > >> --- > >> libavutil/hwcontext_d3d11va.c | 2

Re: [libav-devel] [PATCH 03/12] hwcontext_opencl: VAAPI to OpenCL mapping for Intel i965+beignet

On Wed, 28 Jun 2017 13:49:28 +0100 Mark Thompson <s...@jkqxz.net> wrote: > On 28/06/17 12:09, wm4 wrote: > > On Tue, 27 Jun 2017 22:50:45 +0100 > > Mark Thompson <s...@jkqxz.net> wrote: > > > >> Supports all surface formats in common

Re: [libav-devel] [PATCH 02/12] lavu: OpenCL hwcontext implementation

On Wed, 28 Jun 2017 13:36:30 +0100 Mark Thompson <s...@jkqxz.net> wrote: > On 28/06/17 12:03, wm4 wrote: > > On Tue, 27 Jun 2017 22:50:44 +0100 > > Mark Thompson <s...@jkqxz.net> wrote: > > > >> --- > >> configure |

Re: [libav-devel] [PATCH 12/12] test-only: Create D3D11 textures with D3D11_RESOURCE_MISC_SHARED

On Tue, 27 Jun 2017 22:50:54 +0100 Mark Thompson wrote: > --- > libavutil/hwcontext_d3d11va.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavutil/hwcontext_d3d11va.c b/libavutil/hwcontext_d3d11va.c > index 75f78d866..543f90d6c 100644 > ---

Re: [libav-devel] [PATCH 07/12] lavfi: Add some common code for OpenCL filtering

On Tue, 27 Jun 2017 22:50:49 +0100 Mark Thompson wrote: > --- > libavfilter/Makefile | 6 + > libavfilter/opencl.c | 285 > +++ > libavfilter/opencl.h | 74 +++ > libavfilter/opencl/rgbyuv.cl | 117

Re: [libav-devel] [PATCH 03/12] hwcontext_opencl: VAAPI to OpenCL mapping for Intel i965+beignet

On Tue, 27 Jun 2017 22:50:45 +0100 Mark Thompson wrote: > Supports all surface formats in common between the two. > --- > configure | 6 + > libavutil/hwcontext_internal.h | 3 + > libavutil/hwcontext_opencl.c | 298 >

Re: [libav-devel] [PATCH 02/12] lavu: OpenCL hwcontext implementation

On Tue, 27 Jun 2017 22:50:44 +0100 Mark Thompson wrote: > --- > configure |5 +- > doc/APIchanges |4 + > libavutil/Makefile |2 + > libavutil/hwcontext.c |4 + > libavutil/hwcontext.h |1 + >

Re: [libav-devel] [PATCH] lavu: Add DRM hwcontext

On Wed, 28 Jun 2017 11:37:57 +0200 Luca Barbato <lu_z...@gentoo.org> wrote: > On 6/28/17 11:36 AM, wm4 wrote: > > Or maybe we should get back to your old nested arrays, but I'm worried > > about excessive memory usage. > > The alternative is malloc it with all

Re: [libav-devel] [PATCH] lavu: Add DRM hwcontext

On Sun, 18 Jun 2017 19:08:02 +0100 Mark Thompson wrote: > --- > The intent of this is to have a common structure which can be used in all > cases where DRM objects need to be shared between components. It would be > helpful if anyone familiar with specific drivers or use-cases

Re: [libav-devel] [PATCH] hwframe: Support cropping in the default allocator

On Sun, 25 Jun 2017 14:50:32 -0400 Vittorio Giovara <vittorio.giov...@gmail.com> wrote: > On Sat, Jun 24, 2017 at 12:18 PM, wm4 <nfx...@googlemail.com> wrote: > > On Sat, 24 Jun 2017 15:51:20 +0200 > > Luca Barbato <lu_z...@gentoo.org> wrote: > > >

Re: [libav-devel] [PATCH] hwframe: Support cropping in the default allocator

On Sat, 24 Jun 2017 15:51:20 +0200 Luca Barbato <lu_z...@gentoo.org> wrote: > From: Anton Khirnov <an...@khirnov.net> > > --- > > Better subject welcome. It is currently folded in wm4 mix fixes set. > > libavcodec/decode.c | 8 ++-- > 1 file c

Re: [libav-devel] [PATCH 6/8] hwcontext_d3d11va: add option to enable debug mode

On Thu, 22 Jun 2017 16:02:10 +0300 (EEST) Martin Storsjö <mar...@martin.st> wrote: > On Thu, 22 Jun 2017, wm4 wrote: > > > Basically copied from VLC (LGPL): > > > > http://git.videolan.org/?p=vlc.git;a=blob;f=modules/video_output/win32/direct3d11.c;h=e9fcb83dcabfe

[libav-devel] [PATCH 8/8] dxva: verbose-log decoder GUID list

Helpful for debugging. --- libavcodec/dxva2.c | 47 +++ 1 file changed, 47 insertions(+) diff --git a/libavcodec/dxva2.c b/libavcodec/dxva2.c index 79b77150d0..a60604a84f 100644 --- a/libavcodec/dxva2.c +++ b/libavcodec/dxva2.c @@ -196,12 +196,59 @@

[libav-devel] [PATCH 7/8] hevcdec: fix cropping with new hwaccel API

Affects in particular DXVA2/D3D11VA, which asks for 128 pixels alignment. The AVHWFramesContext will return AVFrames with that larger size set. We need to crop it back in the decoder. --- libavcodec/hevc_refs.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/libavcodec/hevc_refs.c

[libav-devel] [PATCH 2/8] dxva: fix some warnings

Some existed since forever, some are new. The cast in get_surface() is silly, but unless we change the av_log function signature, or all callers of ff_dxva2_get_surface_index(), it's needed to remove the const warning. --- libavcodec/dxva2.c | 16 +++- 1 file changed, 7

[libav-devel] [PATCH 3/8] hwcontext_d3d11va: fix crash on frames_init failure

It appears in this case, frames_ininit is called twice (once by av_hwframe_ctx_init(), and again by unreffing the frames ctx ref). --- libavutil/hwcontext_d3d11va.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/libavutil/hwcontext_d3d11va.c b/libavutil/hwcontext_d3d11va.c index

[libav-devel] [PATCH 5/8] dxva: support DXGI_FORMAT_420_OPAQUE decoding

Some devices (some phones, apparently) will support only this opaque format. Of course this won't work with CLI, because copying data directly is not supported. Automatic frame allocation (setting AVCodecContext.hw_device_ctx) does not support this mode, even if it's the only supported mode. But

[libav-devel] [PATCH 1/8] dxva: add declarative profile checks

Make supported codec profiles part of each dxva_modes entry. Every DXVA2 mode is representative for a codec with a subset of supported profiles, so reflecting that in dxva_modes seems appropriate. In practice, this will more strictly check MPEG2 profiles, will stop relying on the surface format

[libav-devel] [PATCH 4/8] hwcontext_d3d11va: allocate staging texture lazily

Makes dealing with formats that can not be used for staging textures easier (DXGI_FORMAT_420_OPAQUE). It also saves memory if the staging texture is never needed, so this is a good thing. --- libavutil/hwcontext_d3d11va.c | 46 --- 1 file changed, 34

[libav-devel] [PATCH 6/8] hwcontext_d3d11va: add option to enable debug mode

Basically copied from VLC (LGPL): http://git.videolan.org/?p=vlc.git;a=blob;f=modules/video_output/win32/direct3d11.c;h=e9fcb83dcabfe778f26e63d19f218caf06a7c3ae;hb=HEAD#l1482

Re: [libav-devel] [PATCH 6/8] hwcontext_d3d11va: add option to enable debug mode

On Mon, 19 Jun 2017 11:56:04 +0200 Luca Barbato <lu_z...@gentoo.org> wrote: > On 6/9/17 4:27 PM, wm4 wrote: > > > #include "avassert.h" > > #include "common.h" > > #include "hwcontext.h" > > @@ -446,6 +452,14 @@ static int d3d

Re: [libav-devel] [PATCH] d3d11va: Link directly to dxgi.dll and d3d11.dll functions if LoadLibrary is unavailable

s > in the DLLs instead of trying to load them dynamically at runtime. > --- > Requiring both d3d11.dll and dxgi.dll now, simplifying it slightly. > > Moved the configure check as suggested by Diego, and renamed the > createD3D function as suggested by wm4. > > Still untest

Re: [libav-devel] [PATCH] d3d11va: Link directly to dxgi.dll and d3d11.dll functions if LoadLibrary is unavailable

On Tue, 13 Jun 2017 15:59:00 +0300 (EEST) Martin Storsjö <mar...@martin.st> wrote: > On Tue, 13 Jun 2017, wm4 wrote: > > > On Tue, 13 Jun 2017 15:31:12 +0300 > > Martin Storsjö <mar...@martin.st> wrote: > > > >> +static AVOnce functio

Re: [libav-devel] [PATCH] d3d11va: Link directly to dxgi.dll and d3d11.dll functions if LoadLibrary is unavailable

On Tue, 13 Jun 2017 15:31:12 +0300 Martin Storsjö wrote: > When targeting the UWP API subset, the LoadLibrary function is not > available (and the fallback, LoadPackagedLibrary, can't be used to > load system DLLs). In these cases, link directly to the functions > in the DLLs

Re: [libav-devel] [PATCH] mmal: Add missing .item_name to AVClass declaration

On Tue, 13 Jun 2017 12:33:07 +0200 Diego Biurrun wrote: > --- > libavcodec/mmaldec.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/libavcodec/mmaldec.c b/libavcodec/mmaldec.c > index e64ddba..023ebe8 100644 > --- a/libavcodec/mmaldec.c > +++ b/libavcodec/mmaldec.c

Re: [libav-devel] [PATCH 2/2] log: const correctness for av_log()

On Tue, 13 Jun 2017 10:59:31 +0200 Diego Biurrun wrote: > On Mon, Jun 12, 2017 at 04:06:40PM +0200, Hendrik Leppkes wrote: > > On Mon, Jun 12, 2017 at 3:29 PM, Diego Biurrun wrote: > > > On Sun, Jun 11, 2017 at 11:49:45PM +0200, Hendrik Leppkes wrote: > >

Re: [libav-devel] [PATCH 2/8] dxva: fix some warnings

On Sat, 10 Jun 2017 23:44:32 +0200 Hendrik Leppkes <h.lepp...@gmail.com> wrote: > On Sat, Jun 10, 2017 at 3:58 PM, Diego Biurrun <di...@biurrun.de> wrote: > > On Fri, Jun 09, 2017 at 04:27:35PM +0200, wm4 wrote: > >> The cast in get_surface() is silly, b

Re: [libav-devel] [PATCH 3/8] hwcontext_d3d11va: fix crash on frames_init failure

On Fri, 9 Jun 2017 17:26:22 +0200 Luca Barbato <lu_z...@gentoo.org> wrote: > On 6/9/17 4:27 PM, wm4 wrote: > > It appears in this case, frames_ininit is called twice (once by > > av_hwframe_ctx_init(), and again by unreffing the frames ctx ref). > > --- >

[libav-devel] [PATCH 8/8] dxva: verbose-log decoder GUID list

Helpful for debugging. Should I extend this (maybe with nice names in the dxva_modes[] list and matching/printing them), or drop it? --- libavcodec/dxva2.c | 47 +++ 1 file changed, 47 insertions(+) diff --git a/libavcodec/dxva2.c b/libavcodec/dxva2.c

[libav-devel] [PATCH 7/8] hevcdec: fix cropping with new hwaccel API

Affects in particular DXVA2/D3D11VA, which asks for 128 pixels alignment. The AVHWFramesContext will return AVFrames with that larger size set. We need to crop it back in the decoder. --- libavcodec/hevc_refs.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/libavcodec/hevc_refs.c

[libav-devel] [PATCH 5/8] dxva: support DXGI_FORMAT_420_OPAQUE decoding

Some devices (some phones, apparently) will support only this opaque format. Of course this won't work with CLI, because copying data directly is not supported. Automatic frame allocation (setting AVCodecContext.hw_device_ctx) does not support this mode, even if it's the only supported mode. But

[libav-devel] [PATCH 6/8] hwcontext_d3d11va: add option to enable debug mode

Basically copied from VLC (LGPL): http://git.videolan.org/?p=vlc.git;a=blob;f=modules/video_output/win32/direct3d11.c;h=e9fcb83dcabfe778f26e63d19f218caf06a7c3ae;hb=HEAD#l1482

[libav-devel] [PATCH 3/8] hwcontext_d3d11va: fix crash on frames_init failure

It appears in this case, frames_ininit is called twice (once by av_hwframe_ctx_init(), and again by unreffing the frames ctx ref). --- Not sure if that's correct. Or if it could happen with certain other decoders. --- libavutil/hwcontext_d3d11va.c | 2 ++ 1 file changed, 2 insertions(+) diff

[libav-devel] [PATCH 4/8] hwcontext_d3d11va: allocate staging texture lazily

Makes dealing with formats that can not be used for staging textures easier (DXGI_FORMAT_420_OPAQUE). It also saves memory if the staging texture is never needed, so this is a good thing. --- libavutil/hwcontext_d3d11va.c | 46 --- 1 file changed, 34

[libav-devel] [PATCH 2/8] dxva: fix some warnings

Some existed since forever, some are new. The cast in get_surface() is silly, but unless we change the av_log function signature, or all callers of ff_dxva2_get_surface_index(), it's needed to remove the const warning. --- libavcodec/dxva2.c | 16 +++- 1 file changed, 7

[libav-devel] [PATCH 1/8] dxva: add declarative profile checks

Make supported codec profiles part of each dxva_modes entry. Every DXVA2 mode is representative for a codec with a subset of supported profiles, so reflecting that in dxva_modes seems appropriate. In practice, this will more strictly check MPEG2 profiles, will stop relying on the surface format

[libav-devel] [PATCH 0/8] dxva fixes etc.

wm4 (8): dxva: add declarative profile checks dxva: fix some warnings hwcontext_d3d11va: fix crash on frames_init failure hwcontext_d3d11va: allocate staging texture lazily dxva: support DXGI_FORMAT_420_OPAQUE decoding hwcontext_d3d11va: add option to enable debug mode hevcdec: fix

Re: [libav-devel] [RFC] [PATCH] d3d11va: Link directly to dxgi.dll and d3d11.dll functions on UWP

On Fri, 9 Jun 2017 12:07:59 +0300 Martin Storsjö wrote: > When targeting the UWP API subset, the LoadLibrary function is not > available (and the fallback, LoadPackagedLibrary, can't be used to > load system DLLs). In these cases, link directly to the functions > in the DLLs

Re: [libav-devel] New Channel Layout API - third phase

On Wed, 7 Jun 2017 14:03:30 -0400 Vittorio Giovara <vittorio.giov...@gmail.com> wrote: > On Wed, Jun 7, 2017 at 12:26 PM, wm4 <nfx...@googlemail.com> wrote: > > On Wed, 7 Jun 2017 11:46:17 -0400 > > Vittorio Giovara <vittorio.giov...@gmail.com> wrote: &g

Re: [libav-devel] New Channel Layout API - third phase

On Wed, 7 Jun 2017 11:46:17 -0400 Vittorio Giovara wrote: > Hello, > assuming the previous conversions are ok, this chunk starts > modifying AVCodecParameters, in particular affecting libavformat. > The first 10 or so containers are modified to support the new

Re: [libav-devel] [PATCH v3 5/6] dxva: add support for new dxva2 and d3d11 hwaccel APIs

On Wed, 7 Jun 2017 16:58:58 +0200 Diego Biurrun <di...@biurrun.de> wrote: > On Wed, Jun 07, 2017 at 04:50:43PM +0200, wm4 wrote: > > On Wed, 7 Jun 2017 16:41:21 +0200 Diego Biurrun <di...@biurrun.de> wrote: > > > > > On Tue, Jun 06,

Re: [libav-devel] [PATCH v3 1/6] lavu: add new D3D11 pixfmt and hwcontext

On Wed, 7 Jun 2017 16:42:32 +0200 Steve Lhomme <rob...@gmail.com> wrote: > On Wed, Jun 7, 2017 at 12:06 PM, wm4 <nfx...@googlemail.com> wrote: > > On Wed, 7 Jun 2017 08:59:24 +0200 > > Steve Lhomme <rob...@gmail.com> wrote: > > > >> On Tue, Ju

Re: [libav-devel] [PATCH v3 5/6] dxva: add support for new dxva2 and d3d11 hwaccel APIs

On Wed, 7 Jun 2017 16:41:21 +0200 Diego Biurrun <di...@biurrun.de> wrote: > On Tue, Jun 06, 2017 at 06:51:11PM +0200, wm4 wrote: > > --- a/configure > > +++ b/configure > > @@ -4673,6 +4682,7 @@ check_builtin stdatomic_h stdatomic.h "atomic_int > > foo; ato

Re: [libav-devel] [PATCH v3 5/6] dxva: add support for new dxva2 and d3d11 hwaccel APIs

On Wed, 7 Jun 2017 16:34:46 +0200 Steve Lhomme <rob...@gmail.com> wrote: > On Wed, Jun 7, 2017 at 12:13 PM, Hendrik Leppkes <h.lepp...@gmail.com> wrote: > > On Wed, Jun 7, 2017 at 9:10 AM, Steve Lhomme <rob...@gmail.com> wrote: > >> On Tue, Jun 6, 2017 at

Re: [libav-devel] [PATCH v3 1/6] lavu: add new D3D11 pixfmt and hwcontext

On Wed, 7 Jun 2017 13:28:16 +0200 Diego Biurrun <di...@biurrun.de> wrote: > On Wed, Jun 07, 2017 at 01:18:19PM +0200, wm4 wrote: > > On Wed, 7 Jun 2017 13:09:15 +0200 > > Diego Biurrun <di...@biurrun.de> wrote: > > > > > On Tue, J

Re: [libav-devel] [PATCH v3 1/6] lavu: add new D3D11 pixfmt and hwcontext

On Wed, 7 Jun 2017 13:09:15 +0200 Diego Biurrun <di...@biurrun.de> wrote: > On Tue, Jun 06, 2017 at 06:51:07PM +0200, wm4 wrote: > > --- a/configure > > +++ b/configure > > @@ -2166,7 +2166,7 @@ zmbv_encoder_deps="zlib" > > > > # hardwa

Re: [libav-devel] [PATCH v3 5/6] dxva: add support for new dxva2 and d3d11 hwaccel APIs

On Wed, 7 Jun 2017 09:10:17 +0200 Steve Lhomme <rob...@gmail.com> wrote: > On Tue, Jun 6, 2017 at 6:51 PM, wm4 <nfx...@googlemail.com> wrote: > > +// (avctx->pix_fmt is not updated yet at this point) > > +sctx->pix_fmt = avctx->hwaccel->pix_

Re: [libav-devel] [PATCH v3 4/6] dxva: move d3d11 locking/unlocking to functions

On Wed, 7 Jun 2017 09:01:07 +0200 Steve Lhomme <rob...@gmail.com> wrote: > On Tue, Jun 6, 2017 at 6:51 PM, wm4 <nfx...@googlemail.com> wrote: > > do { > > +ff_dxva2_lock(avctx); > > #if CONFIG_D3D11VA > > -if (ff_dxva2_is_d3d11(avctx))

Re: [libav-devel] [PATCH v3 1/6] lavu: add new D3D11 pixfmt and hwcontext

On Wed, 7 Jun 2017 08:59:24 +0200 Steve Lhomme <rob...@gmail.com> wrote: > On Tue, Jun 6, 2017 at 6:51 PM, wm4 <nfx...@googlemail.com> wrote: > > +static int d3d11va_device_create(AVHWDeviceContext *ctx, const char > > *device, > > +

[libav-devel] [PATCH v3 6/6] avconv: remove old avconv_dxva2

This is done by the generic code now. It was not removed earlier to reduce the diff in the commit adding the new code. --- avtools/Makefile | 1 - avtools/avconv.h | 1 - avtools/avconv_dxva2.c | 440 - avtools/avconv_opt.c | 4

[libav-devel] [PATCH v3 5/6] dxva: add support for new dxva2 and d3d11 hwaccel APIs

This also adds support to avconv (which is trivial due to the new hwaccel API being generic enough). For now, this keeps avconv_dxva2.c as "dxva2-old", although it doesn't work as avconv.c can't handle multiple hwaccels with the same pixfmt. It will be removed in a later commit. The new decoder

[libav-devel] [PATCH v3 2/6] lavc: set avctx->hwaccel before init

So a hwaccel can access avctx->hwaccel in init for whatever reason. This is for the new d3d hwaccel API. We could create separate entrypoints for each of the 3 hwaccel types (dxva2, d3d11va, new d3d11va), but this seems nicer. --- libavcodec/decode.c | 4 ++-- 1 file changed, 2 insertions(+), 2

[libav-devel] [PATCH v3 3/6] dxva: preparations for new hwaccel API

The actual hwaccel code will need to access an internal context instead of avctx->hwaccel_context, so add a new DXVA_CONTEXT() macro, that will dispatch between the "old" external and the new internal context. Also, the new API requires a new D3D11 pixfmt, so all places which check for the pixfmt

[libav-devel] [PATCH v3 4/6] dxva: move d3d11 locking/unlocking to functions

I want to make it non-mandatory to set a mutex in the D3D11 device context, and replacing it with user callbacks seems like the best solution. This is preparation for it. Also makes the code slightly more readable. --- libavcodec/dxva2.c | 46 -- 1 file

[libav-devel] [PATCH v3 1/6] lavu: add new D3D11 pixfmt and hwcontext

To be used with the new d3d11 hwaccel decode API. With the new hwaccel API, we don't want surfaces to depend on the decoder (other than the required dimension and format). The old D3D11VA pixfmt uses ID3D11VideoDecoderOutputView pointers, which include the decoder configuration, and thus is

[libav-devel] [PATCH v3 0/6] New D3D hwaccel API stuff

Just resending it again. I'm not aware of any other things to fix. Although I think I fixed a botched av_freep(), which was probably introduced due to a review comment saying av_freep() is "safer". wm4 (6): lavu: add new D3D11 pixfmt and hwcontext lavc: set avctx->hwaccel befor

Re: [libav-devel] [PATCH] tls: Hide backend implementation details from users

configure stage of a > build. Hide those details behind a generically-named declaration for the > TLS protocol to avoid leaking those details into the configuration stage. > --- > > Now keeping the global ff_tls_(de)init functions according to wm4's > preference. >

Re: [libav-devel] [PATCH] [RFC] [v4] tls: Hide backend implementation details from users

On Wed, 31 May 2017 14:57:54 +0200 Diego Biurrun wrote: > TLS is currently implemented over either OpenSSL or GnuTLS, with more > backends likely to appear in the future. Currently, those backend libraries > are part of the protocol names used during e.g. the configure stage of

Re: [libav-devel] [PATCH 1/2] configure: Default to _WIN32_WINNT=0x0501 as minimum, for legacy mingw

On Wed, 31 May 2017 13:21:42 +0300 Martin Storsjö wrote: > This makes the getaddrinfo functions visible, which aren't normally > by default on legacy mingw. > > We already force __MSVCRT_VERSION__ to an XP version. > --- > configure | 2 ++ > 1 file changed, 2 insertions(+) >

Re: [libav-devel] [PATCH] avconv: Always initialize the opkt struct on streamcopy

On Tue, 30 May 2017 08:13:38 +0200 Anton Khirnov <an...@khirnov.net> wrote: > Quoting Luca Barbato (2017-05-29 15:31:34) > > On 5/29/17 2:43 PM, wm4 wrote: > > > On Mon, 29 May 2017 13:59:40 +0200 > > > Luca Barbato <lu_z...@gentoo.org> wrote: > >

Re: [libav-devel] [PATCH v2 0/6] New D3D hwaccel API stuff

On Mon, 29 May 2017 17:53:59 +0200 Steve Lhomme wrote: > LGTM. > > I haven't tested the patches so I'm not sure it works as expected. But > just looking at the code it seems to do the job. Thanks for reviewing. > There doesn't seem to be support for decoding to >

Re: [libav-devel] [PATCH] avconv: Always initialize the opkt struct on streamcopy

On Mon, 29 May 2017 13:59:40 +0200 Luca Barbato wrote: > --- > avtools/avconv.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/avtools/avconv.c b/avtools/avconv.c > index 719d289ff9..c30e1953ed 100644 > --- a/avtools/avconv.c > +++

Re: [libav-devel] [PATCH] [RFC] [v2] tls: Hide backend implementation details from users

On Mon, 29 May 2017 12:39:12 +0200 Diego Biurrun <di...@biurrun.de> wrote: > On Mon, May 29, 2017 at 12:18:22PM +0200, wm4 wrote: > > On Mon, 29 May 2017 12:03:26 +0200 > > Diego Biurrun <di...@biurrun.de> wrote: > > > On Mon, May 29, 2017 at 11:32:49AM +0

Re: [libav-devel] [PATCH] [RFC] [v2] tls: Hide backend implementation details from users

On Mon, 29 May 2017 12:03:26 +0200 Diego Biurrun <di...@biurrun.de> wrote: > *PLEASE* do not bottom-post. > > On Mon, May 29, 2017 at 11:32:49AM +0200, wm4 wrote: > > On Mon, 29 May 2017 10:56:36 +0200 > > Diego Biurrun <di...@biurrun.de> wrote: > &g

Re: [libav-devel] [PATCH] [RFC] [v2] tls: Hide backend implementation details from users

On Mon, 29 May 2017 10:56:36 +0200 Diego Biurrun wrote: > TLS is currently implemented over either OpenSSL or GnuTLS, with more > backends likely to appear in the future. Currently, those backend libraries > are part of the protocol names used during e.g. the configure stage of

Re: [libav-devel] [PATCH 002/200] lavu: support AVChannelLayout AVOptions

On Fri, 26 May 2017 19:30:40 +0200 Anton Khirnov wrote: > Quoting Luca Barbato (2017-05-23 22:08:49) > > On 5/17/17 7:46 PM, Vittorio Giovara wrote: > > > +av_channel_layout_uninit(dst); > > > +return av_channel_layout_copy(dst, channel_layout); > > > > Maybe put

Re: [libav-devel] [PATCH] [RFC] Disentangle TLS protocol

On Fri, 26 May 2017 13:56:13 +0200 Diego Biurrun wrote: > --- > TLS is not handled like other protocols. Instead the implementation details > of which crypto library is used get exposed to the user. Hiding those > details allows simplifying and refactoring some code and

Re: [libav-devel] [PATCH 1/2] configure: Bail out if both GnuTLS and OpenSSL are enabled

On Fri, 26 May 2017 13:50:11 +0200 Diego Biurrun wrote: > Both libraries provide similar functionality and cannot be used together. > When both are enabled one is used and the other ignored arbitrarily. Error > out instead and have the user choose which library to use. > --- >

[libav-devel] [PATCH v2 5/6] dxva: add support for new dxva2 and d3d11 hwaccel APIs

This also adds support to avconv (which is trivial due to the new hwaccel API being generic enough). For now, this keeps avconv_dxva2.c as "dxva2-old", although it doesn't work as avconv.c can't handle multiple hwaccels with the same pixfmt. It will be removed in a later commit. The new decoder

[libav-devel] [PATCH v2 2/6] lavc: set avctx->hwaccel before init

So a hwaccel can access avctx->hwaccel in init for whatever reason. This is for the new d3d hwaccel API. We could create separate entrypoints for each of the 3 hwaccel types (dxva2, d3d11va, new d3d11va), but this seems nicer. --- libavcodec/decode.c | 4 ++-- 1 file changed, 2 insertions(+), 2

[libav-devel] [PATCH v2 1/6] lavu: add new D3D11 pixfmt and hwcontext

To be used with the new d3d11 hwaccel decode API. With the new hwaccel API, we don't want surfaces to depend on the decoder (other than the required dimension and format). The old D3D11VA pixfmt uses ID3D11VideoDecoderOutputView pointers, which include the decoder configuration, and thus is

[libav-devel] [PATCH v2 6/6] avconv: remove old avconv_dxva2

This is done by the generic code now. It was not removed earlier to reduce the diff in the commit adding the new code. --- This also hopefully fixes all aspects of dxva2 in configure. --- avtools/Makefile | 1 - avtools/avconv.h | 1 - avtools/avconv_dxva2.c | 440

[libav-devel] [PATCH v2 4/6] dxva: move d3d11 locking/unlocking to functions

I want to make it non-mandatory to set a mutex in the D3D11 device context, and replacing it with user callbacks seems like the best solution. This is preparation for it. Also makes the code slightly more readable. --- libavcodec/dxva2.c | 46 -- 1 file

[libav-devel] [PATCH v2 3/6] dxva: preparations for new hwaccel API

The actual hwaccel code will need to access an internal context instead of avctx->hwaccel_context, so add a new DXVA_CONTEXT() macro, that will dispatch between the "old" external and the new internal context. Also, the new API requires a new D3D11 pixfmt, so all places which check for the pixfmt

[libav-devel] [PATCH v2 0/6] New D3D hwaccel API stuff

Hopefully addresses most of the review comments. wm4 (6): lavu: add new D3D11 pixfmt and hwcontext lavc: set avctx->hwaccel before init dxva: preparations for new hwaccel API dxva: move d3d11 locking/unlocking to functions dxva: add support for new dxva2 and d3d11 hwaccel APIs avc

Re: [libav-devel] [PATCH 001/200] Add a new channel layout API

On Fri, 19 May 2017 11:25:59 -0400 Vittorio Giovara wrote: > >> > Also, why is this only 1 byte per channel? Seems a little short-sighted. > >> > > >> > >> Probably because even in the long run there won't be more than 255 > >> different channels so 1 byte should

Re: [libav-devel] [PATCH 001/200] Add a new channel layout API

On Thu, 18 May 2017 15:01:54 -0400 Vittorio Giovara <vittorio.giov...@gmail.com> wrote: > On Thu, May 18, 2017 at 11:16 AM, wm4 <nfx...@googlemail.com> wrote: > > On Wed, 17 May 2017 13:46:51 -0400 > > Vittorio Giovara <vittorio.giov...@gmail.com> wrot

Re: [libav-devel] [PATCH 001/200] Add a new channel layout API

On Wed, 17 May 2017 13:46:51 -0400 Vittorio Giovara wrote: > From: Anton Khirnov > > The new API is more extensible and allows for custom layouts. > More accurate information is exported, eg for decoders that do not > set a channel layout, lavc

Re: [libav-devel] [PATCH 5/5] dxva: add support for new dxva2 and d3d11 hwaccel APIs

On Sat, 13 May 2017 12:09:45 +0200 Anton Khirnov wrote: > Generally looks good, though I'm not very familiar with this hwaccel. > Are you planning to deprecate the old-style hwaccels? I would, but that's not up to me, but to important API users like VLC and lavfilters. > > +

Re: [libav-devel] [PATCH 1/5] lavu: add new D3D11 pixfmt and hwcontext

On Tue, 9 May 2017 10:34:50 +0100 Mark Thompson wrote: > > How so? For dxva2, we do use a magic memcpy for uncached memory. > > Well, I assume the copy from surface to staging texture is driven by the GPU > (i.e. like the vaGetImage() case in VAAPI). Since magic memcpy sucks

Re: [libav-devel] [PATCH 1/5] lavu: add new D3D11 pixfmt and hwcontext

On Tue, 9 May 2017 08:48:45 +0100 Mark Thompson <s...@jkqxz.net> wrote: > On 09/05/17 06:07, wm4 wrote: > > On Mon, 8 May 2017 22:59:11 +0100 > > Mark Thompson <s...@jkqxz.net> wrote: > >> On 04/05/17 07:44, wm4 wrote: > >>>

Re: [libav-devel] [PATCH 194/200] lavf: Add non diegetic stream disposition flag

On Mon, 8 May 2017 12:28:45 -0400 Vittorio Giovara wrote: > Signed-off-by: Vittorio Giovara > --- > libavformat/avformat.h | 6 ++ > libavformat/dump.c | 2 ++ > 2 files changed, 8 insertions(+) > > diff --git

Re: [libav-devel] [PATCH 192/200] lavr: Disable resampling ambisonic channel layouts

On Mon, 8 May 2017 12:28:43 -0400 Vittorio Giovara wrote: > This is currently an unsupported feature, only passthrough is allowed. > > Signed-off-by: Vittorio Giovara > --- > libavresample/utils.c | 8 > 1 file changed, 8

Re: [libav-devel] [PATCH 1/200] Add a new channel layout API

On Mon, 8 May 2017 12:21:28 -0400 Vittorio Giovara <vittorio.giov...@gmail.com> wrote: > On Mon, May 8, 2017 at 11:58 AM, wm4 <nfx...@googlemail.com> wrote: > > It would avoid the requirement for copy and free functions, so if the > > reordering isn't seen as a big ad

Re: [libav-devel] [PATCH 0/5] New D3D hwaccel API stuff

On Mon, 8 May 2017 22:38:55 +0100 Mark Thompson <s...@jkqxz.net> wrote: > On 04/05/17 07:44, wm4 wrote: > > Radically rebased, and omits a few in-between commits that are > > unnecessary for the end result. avconv_dxva2.c should probably > > also be deleted, but for now

Re: [libav-devel] [PATCH 5/5] dxva: add support for new dxva2 and d3d11 hwaccel APIs

On Mon, 8 May 2017 23:45:24 +0100 Mark Thompson <s...@jkqxz.net> wrote: > On 04/05/17 07:44, wm4 wrote: > > This also adds support to avconv (which is trivial due to the new > > hwaccel API being generic enough). For now, this keeps avconv_dxva2.c as > > "dxva

Re: [libav-devel] [PATCH 4/5] dxva: move d3d11 locking/unlocking to functions

On Mon, 8 May 2017 23:24:33 +0100 Mark Thompson wrote: > > +ff_dxva2_unlock(avctx); > > av_usleep(2000); > > Omgwtf? I think I preferred the illusion that this API was sane, which is > now forever ruined. Indeed, this is a sad thing.

Re: [libav-devel] [PATCH 1/5] lavu: add new D3D11 pixfmt and hwcontext

On Mon, 8 May 2017 22:59:11 +0100 Mark Thompson <s...@jkqxz.net> wrote: > On 04/05/17 07:44, wm4 wrote: > > To be used with the new d3d11 hwaccel decode API. > > > > With the new hwaccel API, we don't want surfaces to depend on the > > decoder (other than

Re: [libav-devel] [PATCH 1/200] Add a new channel layout API

On Mon, 8 May 2017 11:41:57 -0400 Vittorio Giovara <vittorio.giov...@gmail.com> wrote: > On Fri, May 5, 2017 at 11:13 PM, wm4 <nfx...@googlemail.com> wrote: > > On Fri, 5 May 2017 22:20:18 -0400 > > Vittorio Giovara <vittorio.giov...@gmail.com> wrote: &g

[libav-devel] [PATCH] [RFC] hwcontext API for native surface type <-> AV_PIX_FMT_ conversion

This is mostly for convenience, so that API users (including possibly libavcodec) don't have to duplicate native format mapping tables. Not sure if these should really have a device_ctx as argument. hw_format is probably enough, but I wasn't sure whether future implementations might possibly

Re: [libav-devel] [PATCH 1/200] Add a new channel layout API

On Sat, 6 May 2017 16:21:14 +0200 Luca Barbato <lu_z...@gentoo.org> wrote: > On 5/6/17 3:46 PM, wm4 wrote: > > I'd still like to see it. > > have a look at github, the set should be there already. And it can't be posted as a patch here why? How are we supposed to di

Re: [libav-devel] [PATCH 1/200] Add a new channel layout API

On Sat, 6 May 2017 15:30:35 +0200 Luca Barbato <lu_z...@gentoo.org> wrote: > On 5/6/17 5:13 AM, wm4 wrote: > > On Fri, 5 May 2017 22:20:18 -0400 > > Vittorio Giovara <vittorio.giov...@gmail.com> wrote: > > > > > >> +enum AVChannelOrder { >

<    1   2   3   4   5   6   7   8   9   >