Re: [libav-devel] [PATCH] http: Check for negative chunk sizes

2016-12-19 Thread Vittorio Giovara 
On Mon, Dec 19, 2016 at 9:56 PM, Martin Storsjö  wrote:
> A negative chunk size is illegal and would end up used as
> length for memcpy, where it would lead to memory accesses
> out of bounds.
>
> Found-by: Paul Cher 
>
> CC: libav-sta...@libav.org
> ---
>  libavformat/http.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/libavformat/http.c b/libavformat/http.c
> index 8fe8d11..7e3708e 100644
> --- a/libavformat/http.c
> +++ b/libavformat/http.c
> @@ -784,6 +784,8 @@ static int http_read_stream(URLContext *h, uint8_t *buf, 
> int size)
>
>  av_log(NULL, AV_LOG_TRACE, "Chunked encoding data size: 
> %"PRId64"'\n",
>  s->chunksize);
> +if (s->chunksize < 0)
> +return AVERROR_INVALIDDATA;
>
>  if (!s->chunksize)
>  return 0;

This is mostly a nit, but would it make sense to coalesce the second
`if` into a `else if`?
Ok with me either way.
-- 
Vittorio
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

[libav-devel] [PATCH] http: Check for negative chunk sizes

2016-12-19 Thread Martin Storsjö 
A negative chunk size is illegal and would end up used as
length for memcpy, where it would lead to memory accesses
out of bounds.

Found-by: Paul Cher 

CC: libav-sta...@libav.org
---
 libavformat/http.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavformat/http.c b/libavformat/http.c
index 8fe8d11..7e3708e 100644
--- a/libavformat/http.c
+++ b/libavformat/http.c
@@ -784,6 +784,8 @@ static int http_read_stream(URLContext *h, uint8_t *buf, 
int size)
 
 av_log(NULL, AV_LOG_TRACE, "Chunked encoding data size: 
%"PRId64"'\n",
 s->chunksize);
+if (s->chunksize < 0)
+return AVERROR_INVALIDDATA;
 
 if (!s->chunksize)
 return 0;
-- 
2.10.1 (Apple Git-78)

___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 1/1] NVENC: Update check for Lookahead

2016-12-19 Thread Luca Barbato 
On 19/12/2016 15:36, Yogender Gupta wrote:
> I found one small bug in NVENC, the value of rc_lookahead is initialized to 
> -1 but the check in nvenc.c checks for if (ctx->rc_lookahead) rather than if 
> (ctx->rc_lookahead > 0) , thereby considering lookahead enabled all the time.
> 

Looks fine, thank you!

lu

___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

[libav-devel] [PATCH 1/1] NVENC: Update check for Lookahead

2016-12-19 Thread Yogender Gupta 
I found one small bug in NVENC, the value of rc_lookahead is initialized to -1 
but the check in nvenc.c checks for if (ctx->rc_lookahead) rather than if 
(ctx->rc_lookahead > 0) , thereby considering lookahead enabled all the time.

Thanks,


---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---


0001-NVENC-Update-check-for-Lookahead.patch
Description: 0001-NVENC-Update-check-for-Lookahead.patch
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] Skipping checkasm on MSVC DLL setups?

2016-12-19 Thread Luca Barbato 
On 19/12/2016 10:51, Martin Storsjö wrote:
> Since checkasm in MSVC DLL builds isn't that important, since it's
> covered pretty well in other test setups anyway, I would suggest to just
> disable checkasm in this case. We easily have got CONFIG_SHARED
> available in makefile, but I guess we'd need to add something else to
> identify MSVC. Or just a "disable checkasm" or similar, somewhere in
> configure?

disable checkasm is an option or just tell fate to ignore checkasm
explicitly.
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] aarch64: vp9itxfm: Use the offset parameter to movrel

2016-12-19 Thread Luca Barbato 
On 19/12/2016 09:42, Martin Storsjö wrote:
> This fixes build failures for iOS, broken since cad42fadcd2c.
> ---
>  libavcodec/aarch64/vp9itxfm_neon.S | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavcodec/aarch64/vp9itxfm_neon.S 
> b/libavcodec/aarch64/vp9itxfm_neon.S
> index 053d46f..7ce6df0 100644
> --- a/libavcodec/aarch64/vp9itxfm_neon.S
> +++ b/libavcodec/aarch64/vp9itxfm_neon.S
> @@ -1108,7 +1108,7 @@ function ff_vp9_idct_idct_32x32_add_neon, export=1
>  
>  movrel  x10, idct_coeffs
>  add x11, x10, #32
> -movrel  x12, min_eob_idct_idct_32 + 2
> +movrel  x12, min_eob_idct_idct_32, 2
>  
>  mov x15, x30
>  
> 

Ok.
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 1/4] frame: add left/top cropping fields to AVFrame

2016-12-19 Thread Vittorio Giovara 
On Mon, Dec 19, 2016 at 1:02 PM, Anton Khirnov  wrote:
> Quoting Vittorio Giovara (2016-12-19 10:11:29)
>> I have a couple of points about this, in random order:
>>
>> 1. I had thought agreement was more towards a side data type rather
>> than full types, is there any advantage with this approach?
>
> CertainPeople(tm) claim that this is such an essential information about
> the frame that it should live directly in it. I do not have a strong
> opinion on the matter, so whatever is least objectionable to most people
> is fine with me.

OK, I wasn't too sure about it, I'm fine either way.

>> 2. I would agree about having a full rectangle not two directions
>> only. Possibly I would keep naming consistent with coded_width and
>> coded_height as fields for uncropped size, and width and height for
>> cropped size. Optionally left and top could be marked as offset.
>
> Others seems to prefer that width/height are the pure original coded
> values, with a full cropping rectangle.

The same CertainPeople(tm)? I do think changing semantics between
avctx and avframe is a BadIdea(c).

>> 3. What about container cropping? eg mov
>
> The caller's job.

Yes, but this is currently handled by the demuxer overriding the size
of avcodeccontext, it would be nice to unify this behaviour once and
for all.

>> 4. Does this support unaligned cropping? If not what happens to the
>> options about it?
>
> Read the following patches to find out.

This point is important enough that it should be mentioned in the
commit log of this patch.

>> 5. What about Theora?
>
> What about it?

You can have cropping in it, see theora.pdf § 2.2, our decoder
currently supports it.

>> 6. Regarding 2/4, can you add a "third" way for apply_cropping so that
>> it exports uncropped values but automatically adds the crop filter
>> (kinda like we do for autorotate) and returns the filtered image at
>> the cropped dimensions?
>
> avcodec is unable to add any filters. If you wanted to call lavfi from
> lavc, j-b would personally strangle you.

no no, sorry I meant from avconv, similar to how the transpose and
other filters are added.
-- 
Vittorio
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 01/41] Bump major versions of all libraries

2016-12-19 Thread Anton Khirnov 
Quoting Diego Biurrun (2016-12-19 13:11:24)
> On Mon, Dec 19, 2016 at 12:57:23PM +0100, Anton Khirnov wrote:
> > Quoting Diego Biurrun (2016-12-06 23:15:48)
> > > On Tue, Dec 06, 2016 at 04:23:09PM -0500, Vittorio Giovara wrote:
> > > > On Tue, Dec 6, 2016 at 2:43 AM, Diego Biurrun  wrote:
> > > > > On Tue, Dec 06, 2016 at 12:27:22AM -0500, Vittorio Giovara wrote:
> > > > >> --- a/libavdevice/version.h
> > > > >> +++ b/libavdevice/version.h
> > > > >> @@ -27,8 +27,8 @@
> > > > >>
> > > > >> -#define LIBAVDEVICE_VERSION_MAJOR 56
> > > > >> -#define LIBAVDEVICE_VERSION_MINOR  1
> > > > >> +#define LIBAVDEVICE_VERSION_MAJOR 57
> > > > >> +#define LIBAVDEVICE_VERSION_MINOR  0
> > > > >>  #define LIBAVDEVICE_VERSION_MICRO  0
> > > > >>
> > > > >> --- a/libavresample/version.h
> > > > >> +++ b/libavresample/version.h
> > > > >> @@ -27,7 +27,7 @@
> > > > >>
> > > > >> -#define LIBAVRESAMPLE_VERSION_MAJOR  3
> > > > >> +#define LIBAVRESAMPLE_VERSION_MAJOR  4
> > > > >>  #define LIBAVRESAMPLE_VERSION_MINOR  0
> > > > >>  #define LIBAVRESAMPLE_VERSION_MICRO  0
> > > > >>
> > > > >> --- a/libswscale/version.h
> > > > >> +++ b/libswscale/version.h
> > > > >> @@ -26,7 +26,7 @@
> > > > >>
> > > > >> -#define LIBSWSCALE_VERSION_MAJOR 4
> > > > >> +#define LIBSWSCALE_VERSION_MAJOR 5
> > > > >>  #define LIBSWSCALE_VERSION_MINOR 0
> > > > >>  #define LIBSWSCALE_VERSION_MICRO 0
> > > > >
> > > > > These bumps seem gratuitous, there are no deprecated APIs in these 
> > > > > libraries.
> > > > 
> > > > I'm aware there are not ABI-changes in those libs, but historically
> > > > we've always bumped every library to avoid any possible version
> > > > conflict. See for example 6d3ea1957f681b3bf9c752e6d21a501cc8d4180d or
> > > > 3bc2e89c76e88ae6f1fd5287e0b11abcfc3c601c. While most of the root
> > > > causes for those incompatibilities have been long resolved, it's still
> > > > a good practice and relatively harmless to do.
> > > 
> > > There was this idea of a single version number for all libraries.
> > > Maybe it's time to revisit it?
> > 
> > I do not think it is a good idea. IMO the libraries should be growing more
> > separate, not less.
> 
> But still be bumped all in lockstep?

Only when appropriate. Everything depends on lavu, so a lavu bump means
everything else has to be bumped too. But if lavu happens to have no
deprecated stuff to remove, then there's no reason to break ABI
compatibility for all the libs.

-- 
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 01/41] Bump major versions of all libraries

2016-12-19 Thread Diego Biurrun 
On Mon, Dec 19, 2016 at 12:57:23PM +0100, Anton Khirnov wrote:
> Quoting Diego Biurrun (2016-12-06 23:15:48)
> > On Tue, Dec 06, 2016 at 04:23:09PM -0500, Vittorio Giovara wrote:
> > > On Tue, Dec 6, 2016 at 2:43 AM, Diego Biurrun  wrote:
> > > > On Tue, Dec 06, 2016 at 12:27:22AM -0500, Vittorio Giovara wrote:
> > > >> --- a/libavdevice/version.h
> > > >> +++ b/libavdevice/version.h
> > > >> @@ -27,8 +27,8 @@
> > > >>
> > > >> -#define LIBAVDEVICE_VERSION_MAJOR 56
> > > >> -#define LIBAVDEVICE_VERSION_MINOR  1
> > > >> +#define LIBAVDEVICE_VERSION_MAJOR 57
> > > >> +#define LIBAVDEVICE_VERSION_MINOR  0
> > > >>  #define LIBAVDEVICE_VERSION_MICRO  0
> > > >>
> > > >> --- a/libavresample/version.h
> > > >> +++ b/libavresample/version.h
> > > >> @@ -27,7 +27,7 @@
> > > >>
> > > >> -#define LIBAVRESAMPLE_VERSION_MAJOR  3
> > > >> +#define LIBAVRESAMPLE_VERSION_MAJOR  4
> > > >>  #define LIBAVRESAMPLE_VERSION_MINOR  0
> > > >>  #define LIBAVRESAMPLE_VERSION_MICRO  0
> > > >>
> > > >> --- a/libswscale/version.h
> > > >> +++ b/libswscale/version.h
> > > >> @@ -26,7 +26,7 @@
> > > >>
> > > >> -#define LIBSWSCALE_VERSION_MAJOR 4
> > > >> +#define LIBSWSCALE_VERSION_MAJOR 5
> > > >>  #define LIBSWSCALE_VERSION_MINOR 0
> > > >>  #define LIBSWSCALE_VERSION_MICRO 0
> > > >
> > > > These bumps seem gratuitous, there are no deprecated APIs in these 
> > > > libraries.
> > > 
> > > I'm aware there are not ABI-changes in those libs, but historically
> > > we've always bumped every library to avoid any possible version
> > > conflict. See for example 6d3ea1957f681b3bf9c752e6d21a501cc8d4180d or
> > > 3bc2e89c76e88ae6f1fd5287e0b11abcfc3c601c. While most of the root
> > > causes for those incompatibilities have been long resolved, it's still
> > > a good practice and relatively harmless to do.
> > 
> > There was this idea of a single version number for all libraries.
> > Maybe it's time to revisit it?
> 
> I do not think it is a good idea. IMO the libraries should be growing more
> separate, not less.

But still be bumped all in lockstep?

Diego
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 03/41] lavfi: Drop deprecated functions to open a filter or a filterchain

2016-12-19 Thread Anton Khirnov 
Quoting Vittorio Giovara (2016-12-06 06:27:24)
> Deprecated in 03/2013.
> ---
>  libavfilter/avfilter.c  |  8 
>  libavfilter/avfilter.h  | 30 --
>  libavfilter/avfiltergraph.c | 17 -
>  libavfilter/version.h   |  3 ---
>  4 files changed, 58 deletions(-)

Ok

-- 
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 01/41] Bump major versions of all libraries

2016-12-19 Thread Anton Khirnov 
Quoting Vittorio Giovara (2016-12-06 06:27:22)
> This disable everything that was deprecated in the past 18 months,
> with a couple of minor (but sensible) exceptions.
> Postpone any API-incompatible changes until the next bump.
> 
> Signed-off-by: Vittorio Giovara 
> ---

LGTM

-- 
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 04/41] lavfi: Drop deprecated filter initialization

2016-12-19 Thread Anton Khirnov 
Quoting Vittorio Giovara (2016-12-06 06:27:25)
> Deprecated in 03/2013.
> ---
>  libavfilter/avfilter.c |  7 ---
>  libavfilter/avfilter.h | 15 ---
>  libavfilter/version.h  |  3 ---
>  3 files changed, 25 deletions(-)

Ok

-- 
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 06/41] lavfi: Drop deprecated non-const filter retrieval

2016-12-19 Thread Anton Khirnov 
Quoting Vittorio Giovara (2016-12-06 06:27:27)
> Deprecated in 10/2013.
> ---
>  libavfilter/avfilter.c | 5 +
>  libavfilter/avfilter.h | 5 +
>  libavfilter/version.h  | 3 ---
>  3 files changed, 2 insertions(+), 11 deletions(-)
> 

Ok

-- 
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 09/41] lavf: Drop deprecated hint to set muxer timebase

2016-12-19 Thread Anton Khirnov 
Quoting Vittorio Giovara (2016-12-06 06:27:30)
> Deprecated in 05/2014.
> ---
>  libavformat/mux.c | 11 ---
>  libavformat/version.h |  4 +---
>  2 files changed, 1 insertion(+), 14 deletions(-)
> 

Ok

-- 
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] unary: Convert to the new bitstream reader

2016-12-19 Thread Anton Khirnov 
Quoting Diego Biurrun (2016-12-09 09:42:02)
> From: Alexandra Hájková 
> 
> ---
> 
> Sending now because it is a prerequisite for the already approved tta patch.
> 
>  libavcodec/aic.c   |  2 +-
>  libavcodec/alac.c  |  2 +-
>  libavcodec/alsdec.c|  3 ++-
>  libavcodec/apedec.c|  2 +-
>  libavcodec/dca_xll.c   |  2 +-
>  libavcodec/dxtory.c|  2 +-
>  libavcodec/ituh263dec.c|  2 +-
>  libavcodec/mss4.c  |  2 +-
>  libavcodec/ralf.c  |  2 +-
>  libavcodec/takdec.c|  2 +-
>  libavcodec/tta.c   |  2 +-
>  libavcodec/unary.h | 19 ++-
>  libavcodec/{unary.h => unary_legacy.h} |  0
>  libavcodec/vc1.c   |  2 +-
>  libavcodec/vc1_block.c |  2 +-
>  libavcodec/wavpack.c   |  2 +-
>  libavformat/mpc8.c |  3 ++-
>  17 files changed, 27 insertions(+), 24 deletions(-)
>  copy libavcodec/{unary.h => unary_legacy.h} (100%)
> 

Ok

-- 
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 05/41] lavfi: Drop deprecated filter registration

2016-12-19 Thread Anton Khirnov 
Quoting Vittorio Giovara (2016-12-06 06:27:26)
> Deprecated in 04/2013.
> ---
>  libavfilter/avfilter.c | 11 ---
>  libavfilter/avfilter.h | 18 --
>  libavfilter/version.h  |  3 ---
>  3 files changed, 32 deletions(-)

Ok

-- 
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 1/4] frame: add left/top cropping fields to AVFrame

2016-12-19 Thread Anton Khirnov 
Quoting Hendrik Leppkes (2016-12-18 21:37:44)
> On Sun, Dec 18, 2016 at 9:27 PM, Anton Khirnov  wrote:
> > ---
> >  doc/APIchanges  |  4 
> >  libavutil/frame.c   |  2 ++
> >  libavutil/frame.h   | 14 ++
> >  libavutil/version.h |  2 +-
> >  4 files changed, 21 insertions(+), 1 deletion(-)
> >
> > diff --git a/doc/APIchanges b/doc/APIchanges
> > index 7633c99..ca95308 100644
> > --- a/doc/APIchanges
> > +++ b/doc/APIchanges
> > @@ -13,6 +13,10 @@ libavutil: 2015-08-28
> >
> >  API changes, most recent first:
> >
> > +2016-xx-xx - xxx - lavu 55.30.0 - frame.h
> > +  Add AVFrame.crop_left/crop_top fields for attaching cropping information 
> > to
> > +  video frames.
> > +
> >  2016-xx-xx - xxx - lavc 57.29.0 - avcodec.h
> >Add AV_PKT_DATA_SPHERICAL packet side data to export AVSphericalMapping
> >information from containers.
> > diff --git a/libavutil/frame.c b/libavutil/frame.c
> > index 1c14f5f..935c281 100644
> > --- a/libavutil/frame.c
> > +++ b/libavutil/frame.c
> > @@ -390,6 +390,8 @@ int av_frame_copy_props(AVFrame *dst, const AVFrame 
> > *src)
> >  dst->key_frame  = src->key_frame;
> >  dst->pict_type  = src->pict_type;
> >  dst->sample_aspect_ratio= src->sample_aspect_ratio;
> > +dst->crop_left  = src->crop_left;
> > +dst->crop_top   = src->crop_top;
> >  dst->pts= src->pts;
> >  dst->repeat_pict= src->repeat_pict;
> >  dst->interlaced_frame   = src->interlaced_frame;
> > diff --git a/libavutil/frame.h b/libavutil/frame.h
> > index 4052199..744d8d2 100644
> > --- a/libavutil/frame.h
> > +++ b/libavutil/frame.h
> > @@ -25,6 +25,7 @@
> >  #ifndef AVUTIL_FRAME_H
> >  #define AVUTIL_FRAME_H
> >
> > +#include 
> >  #include 
> >
> >  #include "avutil.h"
> > @@ -369,6 +370,19 @@ typedef struct AVFrame {
> >   * AVHWFramesContext describing the frame.
> >   */
> >  AVBufferRef *hw_frames_ctx;
> > +
> > +/**
> > + * Video frames only.
> > + * The number of pixels to discard from the left border of the frame to
> > + * obtain the part of the frame intended for presentation.
> > + */
> > +size_t crop_left;
> > +/**
> > + * Video frames only.
> > + * The number of pixels to discard from the top border of the frame to
> > + * obtain the part of the frame intended for presentation.
> > + */
> > +size_t crop_top;
> 
> If you start exporting cropping info, it should imho be a full rect,
> so you can eg. export 1px crop for 4:2:0 formats and whatnot, and not
> be limited to one  specific use-case.

Unless I'm missing something, you can certainly export 1 pixel cropping
here. It's up to the caller to interpret what that means.

-- 
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 2/5] libautil: add support for AV_HWDEVICE_TYPE_D3D11VA

2016-12-19 Thread Anton Khirnov 
Quoting Steve Lhomme (2016-12-16 11:05:40)
> From: Steve Lhomme 
> 
> ---
>  libavutil/Makefile |   3 +
>  libavutil/hwcontext.c  |   3 +
>  libavutil/hwcontext.h  |   1 +
>  libavutil/hwcontext_d3d11va.c  | 456 
> +
>  libavutil/hwcontext_d3d11va.h  |  81 
>  libavutil/hwcontext_internal.h |   1 +
>  libavutil/version.h|   2 +-
>  7 files changed, 546 insertions(+), 1 deletion(-)
>  create mode 100644 libavutil/hwcontext_d3d11va.c
>  create mode 100644 libavutil/hwcontext_d3d11va.h
> 
> diff --git a/libavutil/Makefile b/libavutil/Makefile
> index f34c799..962dcf2 100644
> --- a/libavutil/Makefile
> +++ b/libavutil/Makefile
> @@ -26,6 +26,7 @@ HEADERS = adler32.h 
> \
>hmac.h\
>hwcontext.h   \
>hwcontext_cuda.h  \
> +  hwcontext_d3d11va.h   \
>hwcontext_dxva2.h \
>hwcontext_qsv.h   \
>hwcontext_vaapi.h \
> @@ -111,6 +112,7 @@ OBJS = adler32.o  
>   \
> xtea.o   \
>  
>  OBJS-$(CONFIG_CUDA) += hwcontext_cuda.o
> +OBJS-$(CONFIG_D3D11VA)  += hwcontext_d3d11va.o
>  OBJS-$(CONFIG_DXVA2)+= hwcontext_dxva2.o
>  OBJS-$(CONFIG_LIBMFX)   += hwcontext_qsv.o
>  OBJS-$(CONFIG_LZO)  += lzo.o
> @@ -120,6 +122,7 @@ OBJS-$(CONFIG_VDPAU)+= 
> hwcontext_vdpau.o
>  OBJS += $(COMPAT_OBJS:%=../compat/%)
>  
>  SKIPHEADERS-$(CONFIG_CUDA) += hwcontext_cuda.h
> +SKIPHEADERS-$(CONFIG_D3D11VA)  += hwcontext_d3d11va.h
>  SKIPHEADERS-$(CONFIG_DXVA2)+= hwcontext_dxva2.h
>  SKIPHEADERS-$(CONFIG_LIBMFX)   += hwcontext_qsv.h
>  SKIPHEADERS-$(CONFIG_VAAPI)+= hwcontext_vaapi.h
> diff --git a/libavutil/hwcontext.c b/libavutil/hwcontext.c
> index 83f733e..ae27c51 100644
> --- a/libavutil/hwcontext.c
> +++ b/libavutil/hwcontext.c
> @@ -32,6 +32,9 @@ static const HWContextType *hw_table[] = {
>  #if CONFIG_CUDA
>  _hwcontext_type_cuda,
>  #endif
> +#if CONFIG_D3D11VA
> +_hwcontext_type_d3d11va,
> +#endif
>  #if CONFIG_DXVA2
>  _hwcontext_type_dxva2,
>  #endif
> diff --git a/libavutil/hwcontext.h b/libavutil/hwcontext.h
> index 037ca64..d64b2da 100644
> --- a/libavutil/hwcontext.h
> +++ b/libavutil/hwcontext.h
> @@ -30,6 +30,7 @@ enum AVHWDeviceType {
>  AV_HWDEVICE_TYPE_VAAPI,
>  AV_HWDEVICE_TYPE_DXVA2,
>  AV_HWDEVICE_TYPE_QSV,
> +AV_HWDEVICE_TYPE_D3D11VA,
>  };
>  
>  typedef struct AVHWDeviceInternal AVHWDeviceInternal;
> diff --git a/libavutil/hwcontext_d3d11va.c b/libavutil/hwcontext_d3d11va.c
> new file mode 100644
> index 000..db5ec03
> --- /dev/null
> +++ b/libavutil/hwcontext_d3d11va.c
> @@ -0,0 +1,456 @@
> +/*
> + * This file is part of Libav.
> + *
> + * Libav 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.
> + *
> + * Libav 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 Libav; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
> USA
> + */
> +
> +#include 
> +
> +#if !defined(_WIN32_WINNT) || _WIN32_WINNT < 0x0600
> +#undef _WIN32_WINNT
> +#define _WIN32_WINNT 0x0600
> +#endif
> +#define COBJMACROS
> +
> +#include 
> +#include 
> +#include 
> +
> +#include "avassert.h"
> +#include "common.h"
> +#include "hwcontext.h"
> +#include "hwcontext_d3d11va.h"
> +#include "hwcontext_internal.h"
> +#include "imgutils.h"
> +#include "pixdesc.h"
> +#include "pixfmt.h"
> +
> +typedef HRESULT(WINAPI *PFN_CREATE_DXGI_FACTORY)(REFIID riid, void 
> **ppFactory);
> +
> +typedef struct D3D11VAFramesContext {
> +ID3D11VideoDecoderOutputView **surfaces_internal;
> +int  nb_surfaces_used;
> +
> +ID3D11DeviceContext *d3d11_context;
> +
> +DXGI_FORMAT format;
> +} D3D11VAFramesContext;
> +
> +typedef struct D3D11VADevicePriv {
> +HMODULE d3dlib;
> +} D3D11VADevicePriv;
> +
> +static const struct {
> +

Re: [libav-devel] [PATCH 01/31] Bump major versions of all libraries

2016-12-19 Thread Anton Khirnov 
Quoting Vittorio Giovara (2016-12-17 09:31:05)
> This disables everything that was deprecated in the past 18 months,
> with a couple of minor (but sensible) exceptions.
> 
> Every major version number is aligned to 60, to facilitate distributions
> and downstream users in identifying which release number corresponds to
> any given library version.

I don't undertand this argument.

I also do not agree with this change, as I said earlier.

-- 
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 07/41] lavf: Drop deprecated bitexact functionality

2016-12-19 Thread Anton Khirnov 
Quoting Vittorio Giovara (2016-12-06 06:27:28)
> Deprecated in 05/2014.
> ---
>  libavformat/mux.c | 7 ---
>  libavformat/version.h | 3 ---
>  2 files changed, 10 deletions(-)
> 

Ok

-- 
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 07/12] mlp: Convert to the new bitstream reader

2016-12-19 Thread Anton Khirnov 
Quoting Diego Biurrun (2016-11-27 17:32:38)
> From: Alexandra Hájková 
> 
> ---
>  libavcodec/mlp_parser.c |  63 +++
>  libavcodec/mlp_parser.h |   4 +-
>  libavcodec/mlpdec.c | 201 
> 
>  3 files changed, 136 insertions(+), 132 deletions(-)
> 

LGTM

-- 
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 1/4] frame: add left/top cropping fields to AVFrame

2016-12-19 Thread Anton Khirnov 
Quoting Vittorio Giovara (2016-12-19 10:11:29)
> On Sun, Dec 18, 2016 at 9:27 PM, Anton Khirnov  wrote:
> > ---
> >  doc/APIchanges  |  4 
> >  libavutil/frame.c   |  2 ++
> >  libavutil/frame.h   | 14 ++
> >  libavutil/version.h |  2 +-
> >  4 files changed, 21 insertions(+), 1 deletion(-)
> >
> > diff --git a/doc/APIchanges b/doc/APIchanges
> > index 7633c99..ca95308 100644
> > --- a/doc/APIchanges
> > +++ b/doc/APIchanges
> > @@ -13,6 +13,10 @@ libavutil: 2015-08-28
> >
> >  API changes, most recent first:
> >
> > +2016-xx-xx - xxx - lavu 55.30.0 - frame.h
> > +  Add AVFrame.crop_left/crop_top fields for attaching cropping information 
> > to
> > +  video frames.
> > +
> >  2016-xx-xx - xxx - lavc 57.29.0 - avcodec.h
> >Add AV_PKT_DATA_SPHERICAL packet side data to export AVSphericalMapping
> >information from containers.
> > diff --git a/libavutil/frame.c b/libavutil/frame.c
> > index 1c14f5f..935c281 100644
> > --- a/libavutil/frame.c
> > +++ b/libavutil/frame.c
> > @@ -390,6 +390,8 @@ int av_frame_copy_props(AVFrame *dst, const AVFrame 
> > *src)
> >  dst->key_frame  = src->key_frame;
> >  dst->pict_type  = src->pict_type;
> >  dst->sample_aspect_ratio= src->sample_aspect_ratio;
> > +dst->crop_left  = src->crop_left;
> > +dst->crop_top   = src->crop_top;
> >  dst->pts= src->pts;
> >  dst->repeat_pict= src->repeat_pict;
> >  dst->interlaced_frame   = src->interlaced_frame;
> > diff --git a/libavutil/frame.h b/libavutil/frame.h
> > index 4052199..744d8d2 100644
> > --- a/libavutil/frame.h
> > +++ b/libavutil/frame.h
> > @@ -25,6 +25,7 @@
> >  #ifndef AVUTIL_FRAME_H
> >  #define AVUTIL_FRAME_H
> >
> > +#include 
> >  #include 
> >
> >  #include "avutil.h"
> > @@ -369,6 +370,19 @@ typedef struct AVFrame {
> >   * AVHWFramesContext describing the frame.
> >   */
> >  AVBufferRef *hw_frames_ctx;
> > +
> > +/**
> > + * Video frames only.
> > + * The number of pixels to discard from the left border of the frame to
> > + * obtain the part of the frame intended for presentation.
> > + */
> > +size_t crop_left;
> > +/**
> > + * Video frames only.
> > + * The number of pixels to discard from the top border of the frame to
> > + * obtain the part of the frame intended for presentation.
> > + */
> > +size_t crop_top;
> >  } AVFrame;
> 
> I have a couple of points about this, in random order:
> 
> 1. I had thought agreement was more towards a side data type rather
> than full types, is there any advantage with this approach?

CertainPeople(tm) claim that this is such an essential information about
the frame that it should live directly in it. I do not have a strong
opinion on the matter, so whatever is least objectionable to most people
is fine with me.

> 2. I would agree about having a full rectangle not two directions
> only. Possibly I would keep naming consistent with coded_width and
> coded_height as fields for uncropped size, and width and height for
> cropped size. Optionally left and top could be marked as offset.

Others seems to prefer that width/height are the pure original coded
values, with a full cropping rectangle.

> 3. What about container cropping? eg mov

The caller's job.

> 4. Does this support unaligned cropping? If not what happens to the
> options about it?

Read the following patches to find out.

> 5. What about Theora?

What about it?

> 6. Regarding 2/4, can you add a "third" way for apply_cropping so that
> it exports uncropped values but automatically adds the crop filter
> (kinda like we do for autorotate) and returns the filtered image at
> the cropped dimensions?

avcodec is unable to add any filters. If you wanted to call lavfi from
lavc, j-b would personally strangle you.

-- 
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 02/41] lavfi: Drop deprecated way of passing options for a few filters

2016-12-19 Thread Anton Khirnov 
Quoting Vittorio Giovara (2016-12-06 06:27:23)
> Deprecated in 02/2013.
> ---
>  libavfilter/af_channelmap.c |  7 -
>  libavfilter/af_join.c   |  8 -
>  libavfilter/avfilter.c  | 76 
> -
>  libavfilter/buffersrc.c |  8 -
>  libavfilter/version.h   |  3 --
>  libavfilter/vf_aspect.c | 46 ---
>  6 files changed, 148 deletions(-)
> 
> diff --git a/libavfilter/af_channelmap.c b/libavfilter/af_channelmap.c
> index 5725498..e214bdb 100644
> --- a/libavfilter/af_channelmap.c
> +++ b/libavfilter/af_channelmap.c

Looks ok.

-- 
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 08/41] lavf: Drop deprecated AVFract type and related field

2016-12-19 Thread Anton Khirnov 
Quoting Vittorio Giovara (2016-12-06 06:27:29)
> Deprecated in 05/2014.
> ---
>  libavformat/avformat.h | 21 -
>  libavformat/version.h  |  3 ---
>  2 files changed, 24 deletions(-)
> 

Ok

-- 
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 01/41] Bump major versions of all libraries

2016-12-19 Thread Anton Khirnov 
Quoting Diego Biurrun (2016-12-06 23:15:48)
> On Tue, Dec 06, 2016 at 04:23:09PM -0500, Vittorio Giovara wrote:
> > On Tue, Dec 6, 2016 at 2:43 AM, Diego Biurrun  wrote:
> > > On Tue, Dec 06, 2016 at 12:27:22AM -0500, Vittorio Giovara wrote:
> > >> --- a/libavdevice/version.h
> > >> +++ b/libavdevice/version.h
> > >> @@ -27,8 +27,8 @@
> > >>
> > >> -#define LIBAVDEVICE_VERSION_MAJOR 56
> > >> -#define LIBAVDEVICE_VERSION_MINOR  1
> > >> +#define LIBAVDEVICE_VERSION_MAJOR 57
> > >> +#define LIBAVDEVICE_VERSION_MINOR  0
> > >>  #define LIBAVDEVICE_VERSION_MICRO  0
> > >>
> > >> --- a/libavresample/version.h
> > >> +++ b/libavresample/version.h
> > >> @@ -27,7 +27,7 @@
> > >>
> > >> -#define LIBAVRESAMPLE_VERSION_MAJOR  3
> > >> +#define LIBAVRESAMPLE_VERSION_MAJOR  4
> > >>  #define LIBAVRESAMPLE_VERSION_MINOR  0
> > >>  #define LIBAVRESAMPLE_VERSION_MICRO  0
> > >>
> > >> --- a/libswscale/version.h
> > >> +++ b/libswscale/version.h
> > >> @@ -26,7 +26,7 @@
> > >>
> > >> -#define LIBSWSCALE_VERSION_MAJOR 4
> > >> +#define LIBSWSCALE_VERSION_MAJOR 5
> > >>  #define LIBSWSCALE_VERSION_MINOR 0
> > >>  #define LIBSWSCALE_VERSION_MICRO 0
> > >
> > > These bumps seem gratuitous, there are no deprecated APIs in these 
> > > libraries.
> > 
> > I'm aware there are not ABI-changes in those libs, but historically
> > we've always bumped every library to avoid any possible version
> > conflict. See for example 6d3ea1957f681b3bf9c752e6d21a501cc8d4180d or
> > 3bc2e89c76e88ae6f1fd5287e0b11abcfc3c601c. While most of the root
> > causes for those incompatibilities have been long resolved, it's still
> > a good practice and relatively harmless to do.
> 
> There was this idea of a single version number for all libraries.
> Maybe it's time to revisit it?

I do not think it is a good idea. IMO the libraries should be growing more
separate, not less.

-- 
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] ratecontrol: Drop xvid-rc-related struct members unused after a6901b9c6

2016-12-19 Thread Vittorio Giovara 
On Mon, Dec 19, 2016 at 12:21 PM, Diego Biurrun  wrote:
> ---
>
> Thanks to Vittorio for noticing.
>
>  libavcodec/ratecontrol.h | 4 
>  1 file changed, 4 deletions(-)
>
> diff --git a/libavcodec/ratecontrol.h b/libavcodec/ratecontrol.h
> index 2976806..7c289c6 100644
> --- a/libavcodec/ratecontrol.h
> +++ b/libavcodec/ratecontrol.h
> @@ -79,10 +79,6 @@ typedef struct RateControlContext{
>  uint64_t qscale_sum[5];
>  int frame_count[5];
>  int last_non_b_pict_type;
> -
> -void *non_lavc_opaque;///< context for non lavc rc code (for 
> example xvid)
> -float dry_run_qscale; ///< for xvid rc
> -int last_picture_number;  ///< for xvid rc
>  AVExpr * rc_eq_eval;
>  }RateControlContext;
>
> --

ok with me of course
-- 
Vittorio
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

[libav-devel] [PATCH] ratecontrol: Drop xvid-rc-related struct members unused after a6901b9c6

2016-12-19 Thread Diego Biurrun 
---

Thanks to Vittorio for noticing.

 libavcodec/ratecontrol.h | 4 
 1 file changed, 4 deletions(-)

diff --git a/libavcodec/ratecontrol.h b/libavcodec/ratecontrol.h
index 2976806..7c289c6 100644
--- a/libavcodec/ratecontrol.h
+++ b/libavcodec/ratecontrol.h
@@ -79,10 +79,6 @@ typedef struct RateControlContext{
 uint64_t qscale_sum[5];
 int frame_count[5];
 int last_non_b_pict_type;
-
-void *non_lavc_opaque;///< context for non lavc rc code (for 
example xvid)
-float dry_run_qscale; ///< for xvid rc
-int last_picture_number;  ///< for xvid rc
 AVExpr * rc_eq_eval;
 }RateControlContext;
 
-- 
2.1.4

___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

[libav-devel] Skipping checkasm on MSVC DLL setups?

2016-12-19 Thread Martin Storsjö 

Hi,

It seems like checkasm has started failing to build in MSVC DLL setups 
recently, see e.g. this instance: 
https://fate.libav.org/i686-msvc-10-dll-wine


The reason is that once you build with --enable-shared with MSVC, you 
can't link those object files via static libraries any longer. (See 
d66c52c2b369401ba4face1c171ccb19130b7a31, that added support for MSVC 
built DLLs, for the full explanation.) And checkasm links to the libs 
statically in order to link to non-exported fucntions.


In practice, this hasn't been an issue so far, but since 
972c71e9cb63e24f57ee481e413199c7d88a8813, checkasm seems to pull in enough 
object files from libavcodec to start exhibiting the problem I explained 
in the commit when MSVC DLL support as added above. So it has only worked 
by coincidence so far.


We could of course try to figure out what part of the dsp object files 
that checkasm links suddenly pulls in bsf code in this link, but that'd 
also be just hacking around the problem.


Since checkasm in MSVC DLL builds isn't that important, since it's covered 
pretty well in other test setups anyway, I would suggest to just disable 
checkasm in this case. We easily have got CONFIG_SHARED available in 
makefile, but I guess we'd need to add something else to identify MSVC. Or 
just a "disable checkasm" or similar, somewhere in configure?


// Martin
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 1/4] frame: add left/top cropping fields to AVFrame

2016-12-19 Thread Vittorio Giovara 
On Sun, Dec 18, 2016 at 9:27 PM, Anton Khirnov  wrote:
> ---
>  doc/APIchanges  |  4 
>  libavutil/frame.c   |  2 ++
>  libavutil/frame.h   | 14 ++
>  libavutil/version.h |  2 +-
>  4 files changed, 21 insertions(+), 1 deletion(-)
>
> diff --git a/doc/APIchanges b/doc/APIchanges
> index 7633c99..ca95308 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -13,6 +13,10 @@ libavutil: 2015-08-28
>
>  API changes, most recent first:
>
> +2016-xx-xx - xxx - lavu 55.30.0 - frame.h
> +  Add AVFrame.crop_left/crop_top fields for attaching cropping information to
> +  video frames.
> +
>  2016-xx-xx - xxx - lavc 57.29.0 - avcodec.h
>Add AV_PKT_DATA_SPHERICAL packet side data to export AVSphericalMapping
>information from containers.
> diff --git a/libavutil/frame.c b/libavutil/frame.c
> index 1c14f5f..935c281 100644
> --- a/libavutil/frame.c
> +++ b/libavutil/frame.c
> @@ -390,6 +390,8 @@ int av_frame_copy_props(AVFrame *dst, const AVFrame *src)
>  dst->key_frame  = src->key_frame;
>  dst->pict_type  = src->pict_type;
>  dst->sample_aspect_ratio= src->sample_aspect_ratio;
> +dst->crop_left  = src->crop_left;
> +dst->crop_top   = src->crop_top;
>  dst->pts= src->pts;
>  dst->repeat_pict= src->repeat_pict;
>  dst->interlaced_frame   = src->interlaced_frame;
> diff --git a/libavutil/frame.h b/libavutil/frame.h
> index 4052199..744d8d2 100644
> --- a/libavutil/frame.h
> +++ b/libavutil/frame.h
> @@ -25,6 +25,7 @@
>  #ifndef AVUTIL_FRAME_H
>  #define AVUTIL_FRAME_H
>
> +#include 
>  #include 
>
>  #include "avutil.h"
> @@ -369,6 +370,19 @@ typedef struct AVFrame {
>   * AVHWFramesContext describing the frame.
>   */
>  AVBufferRef *hw_frames_ctx;
> +
> +/**
> + * Video frames only.
> + * The number of pixels to discard from the left border of the frame to
> + * obtain the part of the frame intended for presentation.
> + */
> +size_t crop_left;
> +/**
> + * Video frames only.
> + * The number of pixels to discard from the top border of the frame to
> + * obtain the part of the frame intended for presentation.
> + */
> +size_t crop_top;
>  } AVFrame;

I have a couple of points about this, in random order:

1. I had thought agreement was more towards a side data type rather
than full types, is there any advantage with this approach?
2. I would agree about having a full rectangle not two directions
only. Possibly I would keep naming consistent with coded_width and
coded_height as fields for uncropped size, and width and height for
cropped size. Optionally left and top could be marked as offset.
3. What about container cropping? eg mov
4. Does this support unaligned cropping? If not what happens to the
options about it?
5. What about Theora?
6. Regarding 2/4, can you add a "third" way for apply_cropping so that
it exports uncropped values but automatically adds the crop filter
(kinda like we do for autorotate) and returns the filtered image at
the cropped dimensions?

Cheers
-- 
Vittorio
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

[libav-devel] [PATCH] aarch64: vp9itxfm: Use the offset parameter to movrel

2016-12-19 Thread Martin Storsjö 
This fixes build failures for iOS, broken since cad42fadcd2c.
---
 libavcodec/aarch64/vp9itxfm_neon.S | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/aarch64/vp9itxfm_neon.S 
b/libavcodec/aarch64/vp9itxfm_neon.S
index 053d46f..7ce6df0 100644
--- a/libavcodec/aarch64/vp9itxfm_neon.S
+++ b/libavcodec/aarch64/vp9itxfm_neon.S
@@ -1108,7 +1108,7 @@ function ff_vp9_idct_idct_32x32_add_neon, export=1
 
 movrel  x10, idct_coeffs
 add x11, x10, #32
-movrel  x12, min_eob_idct_idct_32 + 2
+movrel  x12, min_eob_idct_idct_32, 2
 
 mov x15, x30
 
-- 
2.10.1 (Apple Git-78)

___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel