On Fri, 13 Apr 2018 09:22:30 +0900
Luca Barbato wrote:
> On 13/04/2018 06:44, Vittorio Giovara wrote:
> > -if (new_extradata && 0) {
>
> Uh?
faa2930f191099621e03c55cca32662467d3cc15
flvdec: reenable extradata passing code
___
libav-devel maili
On Thu, 22 Mar 2018 14:42:40 +0100
"Sven Dueking" wrote:
> > -Ursprüngliche Nachricht-
> > Von: libav-devel [mailto:libav-devel-boun...@libav.org] Im Auftrag von
> > wm4
> > Gesendet: Donnerstag, 22. März 2018 14:38
> > An: libav-devel@libav.org
&g
On Thu, 22 Mar 2018 14:24:08 +0100
"Sven Dueking" wrote:
> > -Ursprüngliche Nachricht-
> > Von: libav-devel [mailto:libav-devel-boun...@libav.org] Im Auftrag von
> > wm4
> > Gesendet: Donnerstag, 22. März 2018 14:03
> > An: libav-devel@libav.org
&g
On Thu, 22 Mar 2018 13:17:16 +0100
Diego Biurrun wrote:
> On Thu, Mar 22, 2018 at 12:34:29PM +0100, Sven Dueking wrote:
> > > On Wed, Mar 21, 2018 at 04:03:18PM +0100, Sven Dueking wrote:
> > > > > On Wed, Mar 21, 2018 at 03:00:37PM +0100, Luca Barbato wrote:
> > > > > > On 21/03/2018 11:46,
On Fri, 16 Feb 2018 18:02:05 +0100
Luca Barbato wrote:
> Unbreaks the rate-control behaviour.
> ---
> libavcodec/libx265.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
> index fd5452193b..73aff2caef 100644
> --- a/libav
On Tue, 13 Feb 2018 17:31:56 +0100
Hendrik Leppkes wrote:
> On Tue, Feb 13, 2018 at 5:16 PM, Sean McGovern wrote:
> >
> > I discovered this while doing a full valgrind FATE run on a POWER7
> > machine -- among others, fate-noproxy failed.
> >
> > The result for the noproxy test in this case make
On Sun, 11 Feb 2018 23:09:51 +
Mark Thompson wrote:
> On 11/02/18 07:21, Song, Ruiling wrote:
> > I have run some test against the patches. It works as described.
>
> Great - there is general agreement on that part now so I've applied that
> series.
>
> > Are you still against setting a
On Sun, 11 Feb 2018 18:14:34 +
Mark Thompson wrote:
> ---
> libavcodec/cbs.c | 168 +---
> libavcodec/cbs.h | 51 -
> libavcodec/cbs_h264.h | 4 +
> libavcodec/cbs_h2645.c | 341
> +++
On Sun, 11 Feb 2018 18:44:44 +
Mark Thompson wrote:
> On 10/02/18 16:29, Luca Barbato wrote:
> > On 10/02/2018 16:59, Diego Biurrun wrote:
> >> Looks OK in general.
> >>
> >> On Fri, Feb 09, 2018 at 10:51:36AM +0100, Luca Barbato wrote:
> >>> --- /dev/null
> >>> +++ b/libavcodec/libaom.c
On Sun, 11 Feb 2018 18:44:44 +
Mark Thompson wrote:
> On 10/02/18 16:29, Luca Barbato wrote:
> > On 10/02/2018 16:59, Diego Biurrun wrote:
> >> Looks OK in general.
> >>
> >> On Fri, Feb 09, 2018 at 10:51:36AM +0100, Luca Barbato wrote:
> >>> --- /dev/null
> >>> +++ b/libavcodec/libaom.c
On Sun, 11 Feb 2018 18:44:44 +
Mark Thompson wrote:
> On 10/02/18 16:29, Luca Barbato wrote:
> > On 10/02/2018 16:59, Diego Biurrun wrote:
> >> Looks OK in general.
> >>
> >> On Fri, Feb 09, 2018 at 10:51:36AM +0100, Luca Barbato wrote:
> >>> --- /dev/null
> >>> +++ b/libavcodec/libaom.c
On Wed, 7 Feb 2018 19:35:05 +
"Mironov, Mikhail" wrote:
> Regarding PRId64 macro:
> Started to look into this and found that at least in Microsoft's version of
> inttypes.h there no definitions for Unicode strings. All AMF tracing /logging
> is Unicode.
> So the thought was to have a full
On Sun, 4 Feb 2018 14:27:10 +
Mark Thompson wrote:
> AVCodecContext.extra_hw_frames is added to the size of hardware frame
> pools created by libavcodec for APIs which require fixed-size pools.
> This allows the user to keep references to a greater number of frames
> after decode, which may
On Sun, 4 Feb 2018 14:26:51 +
Mark Thompson wrote:
> On 30/01/18 05:34, wm4 wrote:
> > On Mon, 29 Jan 2018 23:01:25 +
> > Mark Thompson wrote:
> >
> >> These filters do not directly know whether the API they are using will
> >> support dynamic
On Thu, 1 Feb 2018 15:02:37 +0200
Martin Storsjö wrote:
> This makes sure that consumers of the side data actually can
> rely on the padding as intended, without having the callers of
> av_packet_new_side_data to explicitly zero initialize it.
> ---
> libavcodec/avpacket.c | 1 +
> 1 file chang
e, which may be necessary for some use-cases.
>
> It is also added to the initial_pool_size value returned by
> avcodec_get_hw_frames_parameters() if a fixed-size pool is required.
> ---
> On 26/01/18 23:39, wm4 wrote:
> > On Fri, 26 Jan 2018 23:30:48 +
> > Mark Thom
On Mon, 29 Jan 2018 23:01:25 +
Mark Thompson wrote:
> These filters do not directly know whether the API they are using will
> support dynamic frame pools, so this is somewhat tricky. If the user
> set extra_hw_frames, we assume that they are aware of the problem and
> set a fixed size based
On Mon, 29 Jan 2018 23:01:21 +
Mark Thompson wrote:
> This is already accounted for in the generic code, so it shouldn't also
> be added here.
> ---
> libavcodec/dxva2.c | 4
> 1 file changed, 4 deletions(-)
>
> diff --git a/libavcodec/dxva2.c b/libavcodec/dxva2.c
> index edc8ade96..f1
On Fri, 26 Jan 2018 23:30:48 +
Mark Thompson wrote:
> On 26/01/18 23:13, Mark Thompson wrote:
> > AVFilterContext.extra_hw_frames functions identically to the field of
> > the same name in AVCodecContext.
>
> Of course, that field doesn't actually exist before this patch now. Updated
> t
On Fri, 26 Jan 2018 23:13:36 +
Mark Thompson wrote:
> AVFilterContext.extra_hw_frames functions identically to the field of
> the same name in AVCodecContext.
> ---
> doc/APIchanges | 3 +++
> libavfilter/avfilter.c | 23 +++
> libavfilter/avfilter.h | 13 +++
es the software decoder for the parsing and a little more.
> >
> > In my opinion it boils down to either have a uniform behavior in parsing and
> > formatting the input with its many quirks or using more of the hwaccel/sdk.
> >
> > I do not have a strong opinion in this regar
On Fri, 26 Jan 2018 11:04:12 +
Mark Thompson wrote:
> On 26/01/18 09:15, wm4 wrote:
> > On Fri, 26 Jan 2018 05:56:46 +
> > "Li, Zhong" wrote:
> >
> >>> From: libav-devel [mailto:libav-devel-boun...@libav.org] On Behalf Of
> >>>
On Fri, 26 Jan 2018 05:56:46 +
"Li, Zhong" wrote:
> > From: libav-devel [mailto:libav-devel-boun...@libav.org] On Behalf Of
> > Ruiling Song
> > Sent: Friday, January 26, 2018 9:17 AM
> > To: libav-devel@libav.org
> > Subject: [libav-devel] [PATCH] hwcontext_qsv: Fix qsv hwupload failure issu
On Tue, 23 Jan 2018 05:28:35 +
"Li, Zhong" wrote:
> > wm4 wrote:
> >
> > > > Appreciated for any comment. If we are agree with that, patches will
> > be sent soon (about following next two weeks).
> > >
> > > I don'
On Mon, 22 Jan 2018 14:52:00 +0100
wm4 wrote:
> > Appreciated for any comment. If we are agree with that, patches will be
> > sent soon (about following next two weeks).
>
> I don't know how qsvdec works in particular (doesn't it pretty much
> parse all th
On Mon, 22 Jan 2018 11:20:08 +
"Li, Zhong" wrote:
> MSDK provides an API (MFXVideoDECODE_DecodeHeader) to parse video
> parameters. Currently it hasn't been used.
> Instead, software parsers are used. It works well for h264 decoder, and
> basically works well for hevc decoder (some issues
ited type to represent this type of data, in a way that it is
> atomically changed at the version bump.
> ---
>
> This is a work in progress change that I was preparing and briefly discussed
> on IRC today, based on suggestion by wm4. I wanted to share this early to
> thread wate
On Wed, 20 Dec 2017 09:45:37 +0200
Martin Storsjö wrote:
> ---
> libavcodec/mmaldec.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/mmaldec.c b/libavcodec/mmaldec.c
> index 10a48d3e0f..504e765d07 100644
> --- a/libavcodec/mmaldec.c
> +++ b/libavcodec/mmalde
On Sun, 17 Dec 2017 16:17:47 +0200
Rémi Denis-Courmont wrote:
> Le sunnuntaina 17. joulukuuta 2017, 14.35.13 EET Luca Barbato a écrit :
> > On 11/12/2017 14:48, wm4 wrote:
> > > The log callback, set with av_log_set_callback(), is global mutable
> > > state, and as
Explicitly identify decoder/encoder wrappers with a common name. This
saves API users from guessing by the name suffix. For example, they
don't have to guess that "h264_qsv" is the h264 QSV implementation, and
instead they can just check the AVCodec .codec and .wrapper_name fields.
Explicitly mark
On Sun, 10 Dec 2017 23:05:39 +
Mark Thompson wrote:
> ---
> doc/APIchanges | 3 +++
> libavcodec/avcodec.h | 74
>
> libavcodec/hwaccel.h | 18 +
> libavcodec/utils.c | 12 +
> 4 files changed, 107 insertions(
Explicitly identify decoder/encoder wrappers with a common name. This
saves API users from guessing by the name suffix. For example, they
don't have to guess that "h264_qsv" is the h264 QSV implementation, and
instead they can just check the AVCodec .codec and .wrapper_name fields.
Explicitly mark
The log callback, set with av_log_set_callback(), is global mutable
state, and as such not something we want in Libav, at all. but getting
rid of it is very complicated, because in most cases, av_log() does not
have enough context available to find per-context log callbacks.
av_log() has a context
On Thu, 7 Dec 2017 13:25:10 +0100
Luca Barbato wrote:
> On 07/12/2017 08:26, Zhong Li wrote:
> > Signed-off-by: Zhong Li
> > ---
> > libavcodec/qsvdec_other.c | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/libavcodec/qsvdec_other.c b/libavcodec/qsvdec_other.c
> > index 1
On Mon, 30 Oct 2017 15:50:58 +
James Cowgill wrote:
> Hi,
>
> This is an issue which was reported in a number of places. I'm asking
> here since libav was the origin of the commit which broke things and
> hopefully someone here has an answer.
>
> https://trac.ffmpeg.org/ticket/6775
> https:
On Fri, 27 Oct 2017 12:37:18 +0100
Mark Thompson wrote:
> >> Can you suggest the sort of names you're thinking of here? I think this
> >> might depend on (3) as well to be useful.
> >
> > I was thinking maybe "hwaccel_vaapi" etc.
>
> I feel like this sort of name is trivially generated fr
On Thu, 26 Oct 2017 13:27:01 +0100
Mark Thompson wrote:
> On 26/10/17 11:36, wm4 wrote:
> > On Thu, 26 Oct 2017 00:18:39 +0100
> > Mark Thompson wrote:
> >
> >> ---
> >> Rebased on the frame parameter changes, and incorporating all review
> >&
On Thu, 26 Oct 2017 00:18:39 +0100
Mark Thompson wrote:
> ---
> Rebased on the frame parameter changes, and incorporating all review comments
> from last time.
>
>
> doc/APIchanges | 3 +++
> libavcodec/avcodec.h | 74
>
> libavcode
On Sun, 22 Oct 2017 07:57:42 +0200
Diego Biurrun wrote:
> ---
> libavcodec/decode.c | 11 +++
> libavcodec/version.h | 3 +++
> libavfilter/vsrc_movie.c | 5 +
> 3 files changed, 19 insertions(+)
>
> diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> index b74c163f9
Commit b46a77f19d accidentally broke this (requested change that was
added to the patch later and which was not fully tested).
---
Tested/confirmed by jkqxz on IRC.
---
libavcodec/decode.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/libavcodec/decode.c b/libavcodec/de
On Sun, 22 Oct 2017 02:15:07 +0200
Diego Biurrun wrote:
> On Thu, Oct 19, 2017 at 05:25:17PM +0200, wm4 wrote:
> > Module: libav
> > Author:wm4
> > Committer: Anton Khirnov
> > Date: Thu Oct 19 16:38:20 2017 +0200
> >
> > lavc: exte
This adds a new API, which allows the API user to query the required
AVHWFramesContext parameters. This also reduces code duplication across
the hwaccels by introducing ff_decode_get_hw_frames_ctx(), which uses
the new API function. It takes care of initializing the hw_frames_ctx
if needed, and doe
This adds a new API, which allows the API user to query the required
AVHWFramesContext parameters. This also reduces code duplication across
the hwaccels by introducing ff_decode_get_hw_frames_ctx(), which uses
the new API function. It takes care of initializing the hw_frames_ctx
if needed, and doe
On Thu, 12 Oct 2017 19:17:32 +0200
Diego Biurrun wrote:
> On Thu, Oct 12, 2017 at 01:02:57AM -0300, James Almer wrote:
> > libxavs may require pthreads and libm at link time, and without
> > said ldflags available as global extralibs, the check will fail.
> >
> > Regression since 7cb1d9e2dbbe5bf
On Wed, 11 Oct 2017 01:48:51 +0200
Anton Khirnov wrote:
> Quoting wm4 (2017-09-26 17:09:56)
> > From: wm4
> >
> > This adds a new API, which allows the API user to query the required
> > AVHWFramesContext parameters. This also reduces code duplication across
>
On Wed, 4 Oct 2017 23:27:18 +0100
Mark Thompson wrote:
> On 04/10/17 23:16, wm4 wrote:
> > On Wed, 4 Oct 2017 23:01:47 +0100
> > Mark Thompson wrote:
> >>>
> >>> In addition to this, should there be an AVCodec flag that tells the API
> >>>
On Thu, 5 Oct 2017 08:47:59 +0100
Mark Thompson wrote:
> On 05/10/17 08:43, wm4 wrote:
> > On Wed, 4 Oct 2017 23:30:52 +0100
> > Mark Thompson wrote:
> >
> >> These are needed for the config structures in the following patch.
> >> ---
> >&g
On Wed, 4 Oct 2017 23:30:51 +0100
Mark Thompson wrote:
> ---
> Bikeshed painters welcome for naming.
> /**
> + * Retrieve supported hardware configurations for a codec.
> + */
> +const AVCodecHWConfig *avcodec_get_hw_config(const AVCodec *codec, int
> index);
Should explicitly say that ou
On Wed, 4 Oct 2017 23:30:52 +0100
Mark Thompson wrote:
> These are needed for the config structures in the following patch.
> ---
> Fake hwaccels are omitted, they would just be deleted in a later patch
> without ever being used.
>
>
> libavcodec/hwaccels.h | 59
> ++
On Wed, 4 Oct 2017 23:01:47 +0100
Mark Thompson wrote:
> >
> > In addition to this, should there be an AVCodec flag that tells the API
> > user whether this decoder can do half-transparent software fallback?
> > Half-transparent as in it can call get_format mid-stream to reconfigure
> > it to s
On Wed, 4 Oct 2017 23:04:04 +0100
Mark Thompson wrote:
> On 04/10/17 09:54, wm4 wrote:
> > On Wed, 4 Oct 2017 09:07:11 +0100
> > Mark Thompson wrote:
> >
> >> ---
> >> libavcodec/h263dec.c | 10 ++
> >> libavcodec/h264dec.c
On Wed, 4 Oct 2017 09:07:16 +0100
Mark Thompson wrote:
> ---
> libavcodec/avcodec.h | 6 ++
> libavcodec/decode.c | 2 +-
> libavcodec/internal.h | 2 ++
> libavcodec/utils.c| 9 -
> libavcodec/version.h | 3 +++
> 5 files changed, 20 insertions(+), 2 deletions(-)
>
LGTM,
On Wed, 4 Oct 2017 09:07:11 +0100
Mark Thompson wrote:
> ---
> libavcodec/h263dec.c | 10 ++
> libavcodec/h264dec.c | 19 +++
> libavcodec/hevcdec.c | 19 +++
> libavcodec/hwaccel.h | 27 +++
> libavcodec/mm
On Wed, 4 Oct 2017 09:07:10 +0100
Mark Thompson wrote:
> ---
> doc/APIchanges | 3 +++
> libavcodec/avcodec.h | 74
>
> libavcodec/utils.c | 11
> 3 files changed, 88 insertions(+)
>
> diff --git a/doc/APIchanges b/doc/API
On Tue, 3 Oct 2017 09:26:39 -0400
Vittorio Giovara wrote:
> Implement detection in h264 and hevc and insertion in framepack filter.
>
> Signed-off-by: Vittorio Giovara
> ---
> doc/APIchanges | 3 +++
> libavcodec/h264_sei.c | 7 ---
> libavcodec/h264_sei.h | 1 +
>
From: wm4
This adds a new API, which allows the API user to query the required
AVHWFramesContext parameters. This also reduces code duplication across
the hwaccels by introducing ff_decode_get_hw_frames_ctx(), which uses
the new API function. It takes care of initializing the hw_frames_ctx
if
From: wm4
This adds a new API, which allows the API user to query the required
AVHWFramesContext parameters. This also reduces code duplication across
the hwaccels by introducing ff_decode_get_hw_frames_ctx(), which uses
the new API function.
TODO:
- reindent that block of code in
From: wm4
I feel like this has been beaten to death, but let's do it one more
time.
No code, this is just about the API itself.
I also found a way to make one of Mark T.'s RFCs do what I want, so
another proposal is included in the doxygen comments.
---
libavcodec/avco
On Thu, 21 Sep 2017 19:15:37 +0200
Vittorio Giovara wrote:
> On Thu, Sep 21, 2017 at 5:40 PM, Steve Lhomme wrote:
>
> > On Thu, Sep 21, 2017 at 4:58 PM, Vittorio Giovara
> > wrote:
> > > On Thu, Sep 21, 2017 at 4:03 PM, Steve Lhomme wrote:
> > >
> > >> From: "Mohammed (Shaan) Huzaifa Dani
On Wed, 20 Sep 2017 13:33:13 +0200
Vittorio Giovara wrote:
> Signed-off-by: Vittorio Giovara
> ---
> TODO: version bump, APIdoc entry.
> Vittorio
>
Suggestion: create a table with int/string pairs, and a shared lookup
function, so that you don't need to recreate the boilerplate over and
over?
On Fri, 8 Sep 2017 10:16:51 +0200
Hendrik Leppkes wrote:
> On Fri, Sep 8, 2017 at 6:28 AM, Luca Barbato wrote:
> > On 07/09/2017 21:49, Mark Thompson wrote:
> >>
> >> + * The array is terminated by a configuration with a pix_fmt of
> >> + * AV_PIX_FMT_NONE.
> >
> >
> > why not NULL-t
On Thu, 7 Sep 2017 20:49:04 +0100
Mark Thompson wrote:
> ---
> (Also version bump.)
>
> Written intending to also be useful for encoders, but there won't actually be
> any implementations.
>
>
> doc/APIchanges | 3 +++
> libavcodec/avcodec.h | 69
> ++
On Thu, 7 Sep 2017 21:04:16 +0100
Mark Thompson wrote:
> On 06/09/17 21:28, wm4 wrote:
> > On Wed, 6 Sep 2017 21:07:53 +0100
> > Mark Thompson wrote:
> >
> >> On 06/09/17 17:27, wm4 wrote:
> >>> On Wed, 6 Sep 2017 16:49:11 +0100
> >>>
On Wed, 6 Sep 2017 21:07:53 +0100
Mark Thompson wrote:
> On 06/09/17 17:27, wm4 wrote:
> > On Wed, 6 Sep 2017 16:49:11 +0100
> > Mark Thompson wrote:
> >
> >> On 06/09/17 15:33, wm4 wrote:
> >>> On Tue, 5 Sep 2017
On Wed, 6 Sep 2017 20:18:19 +0100
Mark Thompson wrote:
> On 06/09/17 19:14, wm4 wrote:
> > On Wed, 6 Sep 2017 18:55:46 +0100
> > Mark Thompson wrote:
> >
> >> On 06/09/17 17:29, wm4 wrote:
> >>> On Wed, 6 Sep 2017 16:53:04 +0100
> >>>
On Wed, 6 Sep 2017 18:55:46 +0100
Mark Thompson wrote:
> On 06/09/17 17:29, wm4 wrote:
> > On Wed, 6 Sep 2017 16:53:04 +0100
> > Mark Thompson wrote:
> >
> >> On 06/09/17 15:37, wm4 wrote:
> >>> On Tue, 5 Sep 2017
On Wed, 6 Sep 2017 16:53:04 +0100
Mark Thompson wrote:
> On 06/09/17 15:37, wm4 wrote:
> > On Tue, 5 Sep 2017 23:59:31 +0100
> > Mark Thompson wrote:
> >
> >> ---
> >> doc/APIchanges | 3 +++
> >> libavcodec/avcodec.h | 23
On Wed, 6 Sep 2017 16:49:11 +0100
Mark Thompson wrote:
> On 06/09/17 15:33, wm4 wrote:
> > On Tue, 5 Sep 2017 23:59:30 +0100
> > Mark Thompson wrote:
> >
> >> ---
> >> Saves the VA config, the frame pool, and the VA context (in that order).
&g
On Tue, 5 Sep 2017 23:59:31 +0100
Mark Thompson wrote:
> ---
> doc/APIchanges | 3 +++
> libavcodec/avcodec.h | 23 +++
> 2 files changed, 26 insertions(+)
>
> diff --git a/doc/APIchanges b/doc/APIchanges
> index 6f70f3c96..f21dc4db0 100644
> --- a/doc/APIchanges
> +
On Tue, 5 Sep 2017 23:59:30 +0100
Mark Thompson wrote:
> ---
> Saves the VA config, the frame pool, and the VA context (in that order). The
> device reference is held so that freeing the persistent data is possible (the
> transient context is already gone when it happens).
>
>
> libavcodec
On Tue, 5 Sep 2017 23:59:22 +0100
Mark Thompson wrote:
> ---
> libavcodec/vaapi_decode.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/libavcodec/vaapi_decode.c b/libavcodec/vaapi_decode.c
> index a63c4c62e..847db1a42 100644
> --- a/libavcodec/vaapi_decode.c
> +++ b/libavcod
On Mon, 28 Aug 2017 12:53:09 -0300
James Almer wrote:
> On 8/28/2017 12:08 PM, wm4 wrote:
> > On Mon, 28 Aug 2017 11:52:52 -0300
> > James Almer wrote:
> >
> >> AV_CPU_FLAG_MMX == AV_CPU_FLAG_ARMV6 == AV_CPU_FLAG_ALTIVEC
> >> AV_CPU_FLAG_3DNOWEXT =
On Mon, 28 Aug 2017 11:52:52 -0300
James Almer wrote:
> AV_CPU_FLAG_MMX == AV_CPU_FLAG_ARMV6 == AV_CPU_FLAG_ALTIVEC
> AV_CPU_FLAG_3DNOWEXT == AV_CPU_FLAG_NEON
> AV_CPU_FLAG_SSE == AV_CPU_FLAG_VFP
>
> Signed-off-by: James Almer
> ---
> libavutil/cpu.c | 13 +++--
> 1 file chan
On Fri, 25 Aug 2017 10:46:40 +0300
Martin Storsjö wrote:
> We currently only have exported data symbols within libavcodec, but
> the concept is easy to extend to other libraries if necessary.
> The attribute declaration needs to be in a private header though,
> since we can't use CONFIG_SHARED in
On Thu, 24 Aug 2017 22:20:19 +0300
Martin Storsjö wrote:
> This fixes shared WinRT/UWP builds with d3d11va enabled.
> ---
> configure | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/configure b/configure
> index 3e5784f..6bbde1e 100755
> --- a/configure
> +++ b/configur
On Fri, 18 Aug 2017 15:22:28 +0200
Anton Khirnov wrote:
> Quoting wm4 (2017-08-18 14:44:45)
> > On Fri, 18 Aug 2017 15:40:32 +0300 (EEST)
> > Martin Storsjö wrote:
> >
> > > On Fri, 18 Aug 2017, Anton Khirnov wrote:
> > >
> > > > Quot
On Fri, 18 Aug 2017 15:40:32 +0300 (EEST)
Martin Storsjö wrote:
> On Fri, 18 Aug 2017, Anton Khirnov wrote:
>
> > Quoting wm4 (2017-08-17 15:01:44)
> >> Main use-case is proxying avio through a foreign I/O layer and a custom
> >> AVIO context, without
Main use-case is proxying avio through a foreign I/O layer and a custom
AVIO context, without losing latency and performance characteristics.
---
doc/APIchanges | 3 +++
libavformat/avio.h | 9 +
libavformat/avio_internal.h | 8
libavformat/aviobuf.c |
On Mon, 31 Jul 2017 09:25:08 +0800
"Huang, Zhengxu" wrote:
>
Wasn't the plan to use slightly more portable APIs like OpenCL instead
for such things?
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-deve
On Sat, 5 Aug 2017 23:53:11 +0100
Mark Thompson wrote:
> ---
> This is several patches squashed together to invite thoughts.
>
> The idea here is that we add a new array of possible hardware configurations
> to codec definitions, expressed as a hardware device type and the matching
> pixel fo
On Sat, 5 Aug 2017 23:53:07 +0100
Mark Thompson wrote:
> AVFilterContext.extra_hw_frames functions identically to the field of
> the same name in AVCodecContext.
> ---
> Implemented in such a way that an init_hw_frames callback could be added here
> as well, if anyone had a use-case for it.
>
On Sat, 5 Aug 2017 23:53:02 +0100
Mark Thompson wrote:
> This can be used to refine the parameters of lavc-created hardware frames
> contexts - this is useful for APIs which require some use information to
> to be supplied at create time, such as DXVA2 and D3D11VA. (Suggested
---
doc/APIchanges | 3 ++
libavcodec/decode.c | 89 ++
libavutil/frame.c | 100
libavutil/frame.h | 34 ++
libavutil/version.h | 2 +-
5 files changed, 140 insertions(+)
Black isn't always just memset(ptr, 0, size). Limited YUV in particular
requires relatively non-obvious values, and filling a frame with
repeating 0 bytes is disallowed in some contexts. With component sizes
larger than 8 or packed YUV, this can become relatively complicated. So
having a generic fu
On Fri, 21 Jul 2017 23:02:12 +0200
Anton Khirnov wrote:
> Quoting wm4 (2017-07-21 22:56:43)
> > On Fri, 21 Jul 2017 22:32:43 +0200
> > Anton Khirnov wrote:
> >
> > > Quoting wm4 (2017-07-12 17:02:49)
> > > > +int av_fram
On Fri, 21 Jul 2017 22:32:43 +0200
Anton Khirnov wrote:
> Quoting wm4 (2017-07-12 17:02:49)
> > +int av_frame_apply_cropping(AVFrame *frame, int flags)
> > +{
> > +const AVPixFmtDescriptor *desc;
> > +size_t offsets[4];
> > +int i;
> > +
&
On Fri, 21 Jul 2017 22:09:03 +0200
Anton Khirnov wrote:
> Quoting wm4 (2017-07-16 12:43:09)
> > Behaves more like FFmpeg, makes some API users not crash on exit.
> > ---
> > libavformat/utils.c | 7 ++-
> > 1 file changed, 6 insertions(+), 1 deletion(-)
> &
On Sun, 16 Jul 2017 14:27:50 +0200
Luca Barbato wrote:
> On 7/16/17 2:12 PM, wm4 wrote:
> > On Sun, 16 Jul 2017 13:46:19 +0200
> > Luca Barbato wrote:
> >
> >> ---
> >> libavcodec/pngdec.c | 2 ++
> >> 1 file changed, 2 insertions(+)
> &g
On Sun, 16 Jul 2017 13:46:19 +0200
Luca Barbato wrote:
> ---
> libavcodec/pngdec.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c
> index 927248f2e3..6be463344a 100644
> --- a/libavcodec/pngdec.c
> +++ b/libavcodec/pngdec.c
> @@ -521,6 +521,
Behaves more like FFmpeg, makes some API users not crash on exit.
---
libavformat/utils.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/libavformat/utils.c b/libavformat/utils.c
index eaba473914..24a4335016 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -
Black isn't always just memset(ptr, 0, size). Limited YUV in particular
requires relatively non-obvious values, and filling a frame with
repeating 0 bytes is disallowed in some contexts. With component sizes
larger than 8 or packed YUV, this can become relatively complicated. So
having a generic fu
On Sun, 16 Jul 2017 01:08:37 +0200
Luca Barbato wrote:
> On 7/14/17 7:14 PM, wm4 wrote:
> > +} else if (clear_size == 4) {
> > +uint32_t val = AV_RN32(clear);
> > +for (; dst_size >= 4; dst_size -= 4) {
> > +AV_WN32(dst, v
Black isn't always just memset(ptr, 0, size). Limited YUV in particular
requires relatively non-obvious values, and filling a frame with
repeating 0 bytes is disallowed in some contexts. With component sizes
larger than 8 or packed YUV, this can become relatively complicated. So
having a generic fu
TODO: APIchanges entry, version bump.
---
Now with flags instead of a bool parameter.
---
libavcodec/decode.c | 89 ++---
libavutil/frame.c | 101
libavutil/frame.h | 32 +
3 files ch
TODO: APIchanges entry, version bump.
---
libavcodec/decode.c | 88 +
libavutil/frame.c | 101
libavutil/frame.h | 20 +++
3 files changed, 122 insertions(+), 87 deletions(-)
diff --git
This mode apparently does not support decoding of HEVC Main (8 bit).
With D3D11 and Intel drivers on Windows 10 I get green corruption, while
using DXVA2_ModeHEVC_VLD_Main works.
---
libavcodec/dxva2.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/libavcodec/dxva2.c b/libav
On Fri, 30 Jun 2017 12:51:16 -0400
Vittorio Giovara wrote:
> On Fri, Jun 30, 2017 at 4:38 AM, wm4 wrote:
> > On Thu, 29 Jun 2017 17:28:51 -0400
> > Vittorio Giovara wrote:
> >
> >> From: Anton Khirnov
> >>
> >> The new API is more extensible a
On Wed, 5 Jul 2017 12:42:22 +0300
Martin Storsjö wrote:
> ---
> libavformat/os_support.h | 14 +-
> 1 file changed, 1 insertion(+), 13 deletions(-)
>
> diff --git a/libavformat/os_support.h b/libavformat/os_support.h
> index 965e16f..55c2fdb 100644
> --- a/libavformat/os_support.h
On Wed, 5 Jul 2017 12:42: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 the targeted API fam
On Tue, 4 Jul 2017 22:57:41 +0300 (EEST)
Martin Storsjö wrote:
> On Tue, 4 Jul 2017, wm4 wrote:
>
> > On Tue, 4 Jul 2017 22:18:21 +0300
> > Martin Storsjö wrote:
> >
> >> If using the winstore compat library, a fallback LoadLibrary
> >
1 - 100 of 822 matches
Mail list logo