Re: [FFmpeg-devel] [PATCH] avcodec/xpmdec: Fix multiple pointer/memory issues

2017-05-12 Thread wm4
On Fri, 12 May 2017 20:55:13 +0200
Michael Niedermayer  wrote:

> On Fri, May 12, 2017 at 03:29:52PM +0200, Paul B Mahol wrote:
> > On 5/12/17, Michael Niedermayer  wrote:  
> > > On Thu, May 11, 2017 at 11:17:33AM +0200, Michael Niedermayer wrote:  
> > >> On Thu, May 11, 2017 at 09:01:57AM +0200, Paul B Mahol wrote:  
> > >> > On 5/11/17, Michael Niedermayer  wrote:  
> > >> > > Most of these were found through code review in response to
> > >> > > fixing 1466/clusterfuzz-testcase-minimized-5961584419536896
> > >> > > There is thus no testcase for most of this.
> > >> > > The initial issue was Found-by: continuous fuzzing process
> > >> > > https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
> > >> > >
> > >> > > Signed-off-by: Michael Niedermayer 
> > >> > > ---
> > >> > >  libavcodec/xpmdec.c | 37 ++---
> > >> > >  1 file changed, 30 insertions(+), 7 deletions(-)
> > >> > >
> > >> > > diff --git a/libavcodec/xpmdec.c b/libavcodec/xpmdec.c
> > >> > > index 9112d4cb5e..03172e4aad 100644
> > >> > > --- a/libavcodec/xpmdec.c
> > >> > > +++ b/libavcodec/xpmdec.c
> > >> > > @@ -29,6 +29,8 @@
> > >> > >  typedef struct XPMContext {
> > >> > >  uint32_t  *pixels;
> > >> > >  intpixels_size;
> > >> > > +uint8_t   *buf;
> > >> > > +intbuf_size;
> > >> > >  } XPMDecContext;
> > >> > >
> > >> > >  typedef struct ColorEntry {
> > >> > > @@ -233,6 +235,8 @@ static uint32_t color_string_to_rgba(const char
> > >> > > *p, int
> > >> > > len)
> > >> > >  const ColorEntry *entry;
> > >> > >  char color_name[100];
> > >> > >
> > >> > > +len = FFMIN(FFMAX(len, 0), sizeof(color_name) - 1);
> > >> > > +
> > >> > >  if (*p == '#') {
> > >> > >  p++;
> > >> > >  len--;
> > >> > > @@ -299,18 +303,25 @@ static int xpm_decode_frame(AVCodecContext
> > >> > > *avctx,
> > >> > > void *data,
> > >> > >  {
> > >> > >  XPMDecContext *x = avctx->priv_data;
> > >> > >  AVFrame *p=data;
> > >> > > -const uint8_t *end, *ptr = avpkt->data;
> > >> > > +const uint8_t *end, *ptr;
> > >> > >  int ncolors, cpp, ret, i, j;
> > >> > >  int64_t size;
> > >> > >  uint32_t *dst;
> > >> > >
> > >> > >  avctx->pix_fmt = AV_PIX_FMT_BGRA;
> > >> > >
> > >> > > -end = avpkt->data + avpkt->size;
> > >> > > -while (memcmp(ptr, "/* XPM */", 9) && ptr < end - 9)
> > >> > > +av_fast_padded_malloc(&x->buf, &x->buf_size, avpkt->size);
> > >> > > +if (!x->buf)
> > >> > > +return AVERROR(ENOMEM);
> > >> > > +memcpy(x->buf, avpkt->data, avpkt->size);
> > >> > > +x->buf[avpkt->size] = 0;
> > >> > > +
> > >> > > +ptr = x->buf;
> > >> > > +end = x->buf + avpkt->size;
> > >> > > +while (end - ptr > 9 && memcmp(ptr, "/* XPM */", 9))
> > >> > >  ptr++;
> > >> > >
> > >> > > -if (ptr >= end) {
> > >> > > +if (end - ptr <= 9) {
> > >> > >  av_log(avctx, AV_LOG_ERROR, "missing signature\n");
> > >> > >  return AVERROR_INVALIDDATA;
> > >> > >  }
> > >> > > @@ -335,7 +346,7 @@ static int xpm_decode_frame(AVCodecContext 
> > >> > > *avctx,
> > >> > > void
> > >> > > *data,
> > >> > >
> > >> > >  size = 1;
> > >> > >  for (i = 0; i < cpp; i++)
> > >> > > -size *= 94;
> > >> > > +size *= 95;
> > >> > >
> > >> > >  if (ncolors <= 0 || ncolors > size) {
> > >> > >  av_log(avctx, AV_LOG_ERROR, "invalid number of colors:
> > >> > > %d\n",
> > >> > > ncolors);
> > >> > > @@ -349,12 +360,15 @@ static int xpm_decode_frame(AVCodecContext
> > >> > > *avctx,
> > >> > > void *data,
> > >> > >  return AVERROR(ENOMEM);
> > >> > >
> > >> > >  ptr += mod_strcspn(ptr, ",") + 1;
> > >> > > +if (end - ptr < 1)
> > >> > > +return AVERROR_INVALIDDATA;
> > >> > > +
> > >> > >  for (i = 0; i < ncolors; i++) {
> > >> > >  const uint8_t *index;
> > >> > >  int len;
> > >> > >
> > >> > >  ptr += mod_strcspn(ptr, "\"") + 1;
> > >> > > -if (ptr + cpp > end)
> > >> > > +if (end - ptr < cpp)
> > >> > >  return AVERROR_INVALIDDATA;
> > >> > >  index = ptr;
> > >> > >  ptr += cpp;
> > >> > > @@ -373,14 +387,20 @@ static int xpm_decode_frame(AVCodecContext
> > >> > > *avctx,
> > >> > > void *data,
> > >> > >
> > >> > >  x->pixels[ret] = color_string_to_rgba(ptr, len);
> > >> > >  ptr += mod_strcspn(ptr, ",") + 1;
> > >> > > +if (end - ptr < 1)
> > >> > > +return AVERROR_INVALIDDATA;
> > >> > >  }
> > >> > >
> > >> > >  for (i = 0; i < avctx->height; i++) {
> > >> > >  dst = (uint32_t *)(p->data[0] + i * p->linesize[0]);
> > >> > > +if (end - ptr < 1)
> > >> > > +return AVERROR_INVALIDDATA;
> > >> > >  ptr += mod_strcspn(ptr, "\"") + 1;
> > >> > > +if (end - ptr < 1)
> > >> > > +return AVERROR_INVALIDDATA;
> > >> > >
> > >> > >  for (j = 0; j < avctx->width; j++

Re: [FFmpeg-devel] [PATCH 2/2] ffmpeg: Made execution of reap_filters() more deterministic with respect to when headers are written

2017-05-12 Thread wm4
On Fri, 12 May 2017 13:28:14 -0700
Aaron Levinson  wrote:

> Purpose: Made execution of reap_filters() more deterministic with
> respect to when headers are written in relationship with the
> initialization of output streams and the processing of input audio
> and/or video frames.  This change fixes a bug in ffmpeg encountered
> when decoding interlaced video.  In some cases, ffmpeg would treat it
> as progressive.
> 
> Detailed description of problem: Run the following command: "ffmpeg -i
> test8_1080i.h264 -c:v mpeg2video test8_1080i_mp2.ts".  In this case,
> test8_1080i.h264 is an H.264-encoded file with 1080i59.94
> (interlaced).  Prior to the patch, the following output is generated:
> 
> Input #0, h264, from 'test8_1080i.h264':
>   Duration: N/A, bitrate: N/A
> Stream #0:0: Video: h264 (High), yuv420p(top first), 1920x1080 [SAR 1:1 
> DAR 16:9], 29.97 fps, 29.97 tbr, 1200k tbn, 59.94 tbc
> Stream mapping:
>   Stream #0:0 -> #0:0 (h264 (native) -> mpeg2video (native))
> Press [q] to stop, [?] for help
> Output #0, mpegts, to 'test8_1080i_mp2_2.ts':
>   Metadata:
> encoder : Lavf57.72.100
> Stream #0:0: Video: mpeg2video (Main), yuv420p, 1920x1080 [SAR 1:1 DAR 
> 16:9], q=2-31, 200 kb/s, 29.97 fps, 90k tbn, 29.97 tbc
> Metadata:
>   encoder : Lavc57.92.100 mpeg2video
> 
> which demonstrates the bug.  The output stream should instead look like:
> 
> Stream #0:0: Video: mpeg2video (Main), yuv420p(top coded first 
> (swapped)), 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 200 kb/s, 29.97 fps, 90k 
> tbn, 29.97 tbc
> 
> The bug is caused by the fact that reap_filters() calls
> init_output_stream(), which is then immediately followed by a call to
> check_init_output_file(), and this is all done prior to the first call
> to do_video_out().  An initial call to do_video_out() is necessary to
> populate the interlaced video information to the output stream's
> codecpar (mux_par->field_order in do_video_out()).  However,
> check_init_output_file() calls avformat_write_header() prior to the
> initial call to do_video_out(), so field_order is populated too late,
> and the header is written with the default field_order value,
> progressive.
> 
> Signed-off-by: Aaron Levinson 
> ---
>  ffmpeg.c | 43 ---
>  1 file changed, 40 insertions(+), 3 deletions(-)
> 
> diff --git a/ffmpeg.c b/ffmpeg.c
> index 3cd45ba665..7b044b068c 100644
> --- a/ffmpeg.c
> +++ b/ffmpeg.c
> @@ -1434,6 +1434,7 @@ static int reap_filters(int flush)
>  AVFilterContext *filter;
>  AVCodecContext *enc = ost->enc_ctx;
>  int ret = 0;
> +int do_check_init_output_file = 0;
>  
>  if (!ost->filter || !ost->filter->graph->graph)
>  continue;
> @@ -1448,9 +1449,7 @@ static int reap_filters(int flush)
>  exit_program(1);
>  }
>  
> -ret = check_init_output_file(of, ost->file_index);
> -if (ret < 0)
> -exit_program(1);
> +do_check_init_output_file = 1;
>  }
>  
>  if (!ost->filtered_frame && !(ost->filtered_frame = 
> av_frame_alloc())) {
> @@ -1526,6 +1525,44 @@ static int reap_filters(int flush)
>  }
>  
>  av_frame_unref(filtered_frame);
> +
> +/*
> + * It is important to call check_init_output_file() here, after
> + * do_video_out() was called, instead of in init_output_stream(),
> + * as was done previously.
> + * If called from init_output_stream(), it is possible that not
> + * everything will have been fully initialized by the time that
> + * check_init_output_file() is called, and if
> + * check_init_output_file() determines that all output streams
> + * have been initialized, it will write the header.  An example
> + * of initialization that depends on do_video_out() being called
> + * at least once is the specification of interlaced video, which
> + * happens in do_video_out().  This is particularly relevant when
> + * decoding--without processing a video frame, the interlaced
> + * video setting is not propagated before the header is written,
> + * and that causes problems.
> + * TODO:  should probably handle interlaced video differently
> + * and not depend on it being setup in do_video_out().  Another
> + * solution would be to set it up once by examining the input
> + * header.
> + */
> +if (do_check_init_output_file) {
> +ret = check_init_output_file(of, ost->file_index);
> +if (ret < 0)
> +exit_program(1);
> +do_check_init_output_file = 0;
> +}
> +}
> +
> +/*
> + * Can't wait too long to call check_init_output_file().
> + * Otherwise, bad th

Re: [FFmpeg-devel] [PATCH] avfilter: don't anonymously typedef structs

2017-05-12 Thread wm4
On Fri, 12 May 2017 20:01:54 +0200
Paul B Mahol  wrote:

> Signed-off-by: Paul B Mahol 
> ---

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


Re: [FFmpeg-devel] [PATCH] avcodec/xpmdec: Fix multiple pointer/memory issues

2017-05-12 Thread wm4
On Fri, 12 May 2017 18:21:07 +0200
Nicolas George  wrote:

> Le tridi 23 floréal, an CCXXV, Paul B Mahol a écrit :
> > I told you that its unacceptable.  
> 
> And I told you, before you pushed, that your cowboy-style parser was
> unacceptable. You chose to disregard it.

AFAIK all of our subtitle parsers make the same assumption.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] Fixed bug encountered when decoding interlaced video

2017-05-12 Thread Aaron Levinson

On 5/12/2017 5:51 PM, Michael Niedermayer wrote:

On Fri, May 12, 2017 at 01:19:43PM -0700, Aaron Levinson wrote:

On 5/9/2017 11:56 AM, Michael Niedermayer wrote:

On Thu, May 04, 2017 at 11:46:30PM -0700, Aaron Levinson wrote:


I've provided a new version of the patch.  When I created the first version of the patch on March 
26th, this was the first patch that I submitted to ffmpeg, and some aspects were rough.  I had 
indicated that the patch passed regression tests, but all I did was run "make fate", 
instead of "make fate SAMPLES=fate-suite/", and once I understood that I should use 
fate-suite, I discovered that some of the FATE tests failed with this patch.  I fixed the issues 
with the patch, adjusted some comments, and adjusted the patch description text.  I've confirmed 
that this patch passes all fate-suite tests for 64-bit MSVC on Windows and 64-bit gcc on Linux.

Thanks,
Aaron Levinson




>From 85aa383f5753795652bae015f4fe91b016f7387e Mon Sep 17 00:00:00 2001

From: Aaron Levinson 
Date: Thu, 4 May 2017 22:54:31 -0700
Subject: [PATCH] ffmpeg:  Fixed bug with decoding interlaced video

Purpose: Fixed bug in ffmpeg encountered when decoding interlaced
video.  In some cases, ffmpeg would treat it as progressive.  As a
result of the change, the issues with interlaced video are fixed.

Detailed description of problem: Run the following command: "ffmpeg -i
test8_1080i.h264 -c:v mpeg2video test8_1080i_mp2.ts".  In this case,
test8_1080i.h264 is an H.264-encoded file with 1080i59.94
(interlaced).  Prior to the patch, the following output is generated:

Input #0, h264, from 'test8_1080i.h264':
 Duration: N/A, bitrate: N/A
   Stream #0:0: Video: h264 (High), yuv420p(top first), 1920x1080 [SAR 1:1 DAR 
16:9], 29.97 fps, 29.97 tbr, 1200k tbn, 59.94 tbc
Stream mapping:
 Stream #0:0 -> #0:0 (h264 (native) -> mpeg2video (native))
Press [q] to stop, [?] for help
Output #0, mpegts, to 'test8_1080i_mp2_2.ts':
 Metadata:
   encoder : Lavf57.72.100
   Stream #0:0: Video: mpeg2video (Main), yuv420p, 1920x1080 [SAR 1:1 DAR 
16:9], q=2-31, 200 kb/s, 29.97 fps, 90k tbn, 29.97 tbc
   Metadata:
 encoder : Lavc57.92.100 mpeg2video

which demonstrates the bug.  The output should instead look like:

   Stream #0:0: Video: mpeg2video (Main), yuv420p(top coded first (swapped)), 
1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 200 kb/s, 29.97 fps, 90k tbn, 29.97 tbc

The bug is caused by the fact that reap_filters() calls
init_output_stream(), which in turn calls check_init_output_file(),
and this is all done prior to the first call to do_video_out().  An
initial call to do_video_out() is necessary to populate the interlaced
video information to the output stream's codecpar
(mux_par->field_order in do_video_out()).  However,
check_init_output_file() calls avformat_write_header() prior to the
initial call to do_video_out(), so field_order is populated too late,
and the header is written with the default field_order value,
progressive.

Comments:

-- ffmpeg.c:
a) Enhanced init_output_stream() to take an additional input
  indicating whether or not check_init_output_file() should be
  called.  There are other places that call init_output_stream(), and
  it was important to make sure that these continued to work
  properly.
b) Adjusted reap_filters() such that, in the case that
  init_output_stream() is called, it indicates that it should not
  call check_init_output_file() in init_output_stream().  Instead, it
  makes the call to check_init_output_file() directly, but after it
  does the filtered frame setup and processing.

Signed-off-by: Aaron Levinson 
---
ffmpeg.c | 61 +
1 file changed, 53 insertions(+), 8 deletions(-)

diff --git a/ffmpeg.c b/ffmpeg.c
index e798d92277..45dbfafc04 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c



@@ -1400,7 +1400,7 @@ static void do_video_stats(OutputStream *ost, int 
frame_size)
}
}

-static int init_output_stream(OutputStream *ost, char *error, int error_len);
+static int init_output_stream(OutputStream *ost, char *error, int error_len, 
int do_check_output_file);

static void finish_output_stream(OutputStream *ost)
{



@@ -1415,6 +1415,8 @@ static void finish_output_stream(OutputStream *ost)
}
}

+static int check_init_output_file(OutputFile *of, int file_index);


should be close to the file top, together with similar prototypes


Will do.


[...]

@@ -1521,6 +1526,44 @@ static int reap_filters(int flush)
}

av_frame_unref(filtered_frame);
+
+/*
+ * It is important to call check_init_output_file() here, after
+ * do_video_out() was called, instead of in init_output_stream(),
+ * as was done previously.
+ * If called from init_output_stream(), it is possible that not
+ * everything will have been fully initialized by the time that
+ * check

Re: [FFmpeg-devel] [PATCH] Fixed bug encountered when decoding interlaced video

2017-05-12 Thread Michael Niedermayer
On Fri, May 12, 2017 at 01:19:43PM -0700, Aaron Levinson wrote:
> On 5/9/2017 11:56 AM, Michael Niedermayer wrote:
> >On Thu, May 04, 2017 at 11:46:30PM -0700, Aaron Levinson wrote:
> >>
> >>I've provided a new version of the patch.  When I created the first version 
> >>of the patch on March 26th, this was the first patch that I submitted to 
> >>ffmpeg, and some aspects were rough.  I had indicated that the patch passed 
> >>regression tests, but all I did was run "make fate", instead of "make fate 
> >>SAMPLES=fate-suite/", and once I understood that I should use fate-suite, I 
> >>discovered that some of the FATE tests failed with this patch.  I fixed the 
> >>issues with the patch, adjusted some comments, and adjusted the patch 
> >>description text.  I've confirmed that this patch passes all fate-suite 
> >>tests for 64-bit MSVC on Windows and 64-bit gcc on Linux.
> >>
> >>Thanks,
> >>Aaron Levinson
> >>
> >>
> >>
> >>From 85aa383f5753795652bae015f4fe91b016f7387e Mon Sep 17 00:00:00 2001
> >>From: Aaron Levinson 
> >>Date: Thu, 4 May 2017 22:54:31 -0700
> >>Subject: [PATCH] ffmpeg:  Fixed bug with decoding interlaced video
> >>
> >>Purpose: Fixed bug in ffmpeg encountered when decoding interlaced
> >>video.  In some cases, ffmpeg would treat it as progressive.  As a
> >>result of the change, the issues with interlaced video are fixed.
> >>
> >>Detailed description of problem: Run the following command: "ffmpeg -i
> >>test8_1080i.h264 -c:v mpeg2video test8_1080i_mp2.ts".  In this case,
> >>test8_1080i.h264 is an H.264-encoded file with 1080i59.94
> >>(interlaced).  Prior to the patch, the following output is generated:
> >>
> >>Input #0, h264, from 'test8_1080i.h264':
> >>  Duration: N/A, bitrate: N/A
> >>Stream #0:0: Video: h264 (High), yuv420p(top first), 1920x1080 [SAR 1:1 
> >> DAR 16:9], 29.97 fps, 29.97 tbr, 1200k tbn, 59.94 tbc
> >>Stream mapping:
> >>  Stream #0:0 -> #0:0 (h264 (native) -> mpeg2video (native))
> >>Press [q] to stop, [?] for help
> >>Output #0, mpegts, to 'test8_1080i_mp2_2.ts':
> >>  Metadata:
> >>encoder : Lavf57.72.100
> >>Stream #0:0: Video: mpeg2video (Main), yuv420p, 1920x1080 [SAR 1:1 DAR 
> >> 16:9], q=2-31, 200 kb/s, 29.97 fps, 90k tbn, 29.97 tbc
> >>Metadata:
> >>  encoder : Lavc57.92.100 mpeg2video
> >>
> >>which demonstrates the bug.  The output should instead look like:
> >>
> >>Stream #0:0: Video: mpeg2video (Main), yuv420p(top coded first 
> >> (swapped)), 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 200 kb/s, 29.97 fps, 90k 
> >> tbn, 29.97 tbc
> >>
> >>The bug is caused by the fact that reap_filters() calls
> >>init_output_stream(), which in turn calls check_init_output_file(),
> >>and this is all done prior to the first call to do_video_out().  An
> >>initial call to do_video_out() is necessary to populate the interlaced
> >>video information to the output stream's codecpar
> >>(mux_par->field_order in do_video_out()).  However,
> >>check_init_output_file() calls avformat_write_header() prior to the
> >>initial call to do_video_out(), so field_order is populated too late,
> >>and the header is written with the default field_order value,
> >>progressive.
> >>
> >>Comments:
> >>
> >>-- ffmpeg.c:
> >>a) Enhanced init_output_stream() to take an additional input
> >>   indicating whether or not check_init_output_file() should be
> >>   called.  There are other places that call init_output_stream(), and
> >>   it was important to make sure that these continued to work
> >>   properly.
> >>b) Adjusted reap_filters() such that, in the case that
> >>   init_output_stream() is called, it indicates that it should not
> >>   call check_init_output_file() in init_output_stream().  Instead, it
> >>   makes the call to check_init_output_file() directly, but after it
> >>   does the filtered frame setup and processing.
> >>
> >>Signed-off-by: Aaron Levinson 
> >>---
> >> ffmpeg.c | 61 +
> >> 1 file changed, 53 insertions(+), 8 deletions(-)
> >>
> >>diff --git a/ffmpeg.c b/ffmpeg.c
> >>index e798d92277..45dbfafc04 100644
> >>--- a/ffmpeg.c
> >>+++ b/ffmpeg.c
> >
> >>@@ -1400,7 +1400,7 @@ static void do_video_stats(OutputStream *ost, int 
> >>frame_size)
> >> }
> >> }
> >>
> >>-static int init_output_stream(OutputStream *ost, char *error, int 
> >>error_len);
> >>+static int init_output_stream(OutputStream *ost, char *error, int 
> >>error_len, int do_check_output_file);
> >>
> >> static void finish_output_stream(OutputStream *ost)
> >> {
> >
> >>@@ -1415,6 +1415,8 @@ static void finish_output_stream(OutputStream *ost)
> >> }
> >> }
> >>
> >>+static int check_init_output_file(OutputFile *of, int file_index);
> >
> >should be close to the file top, together with similar prototypes
> 
> Will do.
> 
> >[...]
> >>@@ -1521,6 +1526,44 @@ static int reap_filters(int flush)
> >> }
> >>
> >> a

Re: [FFmpeg-devel] [PATCH] avcodec/avpacket: allow only one element per type in packet side data

2017-05-12 Thread James Almer
On 5/12/2017 6:27 PM, Michael Niedermayer wrote:
> On Fri, May 12, 2017 at 01:58:27PM -0300, James Almer wrote:
>> It was never meant to do otherwise, as av_packet_get_side_data() returns the 
>> first
>> entry it finds of a given type.
>>
>> Based on code from libavformat's av_stream_add_side_data().
>>
>> Signed-off-by: James Almer 
>> ---
>>  libavcodec/avpacket.c | 13 -
>>  1 file changed, 12 insertions(+), 1 deletion(-)
> 
> probably ok
> 
> thx

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


Re: [FFmpeg-devel] libavcodec/exr : cosmetics : rename variable

2017-05-12 Thread Michael Niedermayer
On Sat, Mar 25, 2017 at 01:08:39PM +0100, Martin Vignali wrote:
> Hello,
> 
> In attach a patch who rename tile variable to better follow ffmpeg coding
> style
> 
> 
> Martin
> 
> 
> -- 
> Martin Vignali
> Jokyo Images
> 18 rue du Transvaal
> 69008 Lyon
> 06 99 89 33 30
> m.vign...@jokyo-images.com
> http://www.jokyo-images.com/

>  exr.c |   20 ++--
>  1 file changed, 10 insertions(+), 10 deletions(-)
> cc713a76b22d6dda0468c206f603ae154cdf620d  
> 0003-libavcodec-exr-cosmetics-variable-name.patch
> From 7a74258e98395256fd0556bb7e2c81b8ae0cfc4e Mon Sep 17 00:00:00 2001
> From: Martin Vignali 
> Date: Sat, 25 Mar 2017 13:05:45 +0100
> Subject: [PATCH 3/3] libavcodec/exr : cosmetics variable name
> 
> rename tile variable to better follow ffmpeg coding style

applied

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Into a blind darkness they enter who follow after the Ignorance,
they as if into a greater darkness enter who devote themselves
to the Knowledge alone. -- Isha Upanishad


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] avcodec/avpacket: allow only one element per type in packet side data

2017-05-12 Thread Michael Niedermayer
On Fri, May 12, 2017 at 01:58:27PM -0300, James Almer wrote:
> It was never meant to do otherwise, as av_packet_get_side_data() returns the 
> first
> entry it finds of a given type.
> 
> Based on code from libavformat's av_stream_add_side_data().
> 
> Signed-off-by: James Almer 
> ---
>  libavcodec/avpacket.c | 13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)

probably ok

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] avcodec/xpmdec: Fix multiple pointer/memory issues

2017-05-12 Thread Michael Niedermayer
On Fri, May 12, 2017 at 09:13:51PM +0200, Paul B Mahol wrote:
> On 5/12/17, Paul B Mahol  wrote:
> > On 5/12/17, Michael Niedermayer  wrote:
> >> On Fri, May 12, 2017 at 03:29:52PM +0200, Paul B Mahol wrote:
> >>> On 5/12/17, Michael Niedermayer  wrote:
> >>> > On Thu, May 11, 2017 at 11:17:33AM +0200, Michael Niedermayer wrote:
> >>> >> On Thu, May 11, 2017 at 09:01:57AM +0200, Paul B Mahol wrote:
> >>> >> > On 5/11/17, Michael Niedermayer  wrote:
> >>> >> > > Most of these were found through code review in response to
> >>> >> > > fixing 1466/clusterfuzz-testcase-minimized-5961584419536896
> >>> >> > > There is thus no testcase for most of this.
> >>> >> > > The initial issue was Found-by: continuous fuzzing process
> >>> >> > > https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
> >>> >> > >
> >>> >> > > Signed-off-by: Michael Niedermayer 
> >>> >> > > ---
> >>> >> > >  libavcodec/xpmdec.c | 37 ++---
> >>> >> > >  1 file changed, 30 insertions(+), 7 deletions(-)
> >>> >> > >
> >>> >> > > diff --git a/libavcodec/xpmdec.c b/libavcodec/xpmdec.c
> >>> >> > > index 9112d4cb5e..03172e4aad 100644
> >>> >> > > --- a/libavcodec/xpmdec.c
> >>> >> > > +++ b/libavcodec/xpmdec.c
> >>> >> > > @@ -29,6 +29,8 @@
> >>> >> > >  typedef struct XPMContext {
> >>> >> > >  uint32_t  *pixels;
> >>> >> > >  intpixels_size;
> >>> >> > > +uint8_t   *buf;
> >>> >> > > +intbuf_size;
> >>> >> > >  } XPMDecContext;
> >>> >> > >
> >>> >> > >  typedef struct ColorEntry {
> >>> >> > > @@ -233,6 +235,8 @@ static uint32_t color_string_to_rgba(const
> >>> >> > > char
> >>> >> > > *p, int
> >>> >> > > len)
> >>> >> > >  const ColorEntry *entry;
> >>> >> > >  char color_name[100];
> >>> >> > >
> >>> >> > > +len = FFMIN(FFMAX(len, 0), sizeof(color_name) - 1);
> >>> >> > > +
> >>> >> > >  if (*p == '#') {
> >>> >> > >  p++;
> >>> >> > >  len--;
> >>> >> > > @@ -299,18 +303,25 @@ static int xpm_decode_frame(AVCodecContext
> >>> >> > > *avctx,
> >>> >> > > void *data,
> >>> >> > >  {
> >>> >> > >  XPMDecContext *x = avctx->priv_data;
> >>> >> > >  AVFrame *p=data;
> >>> >> > > -const uint8_t *end, *ptr = avpkt->data;
> >>> >> > > +const uint8_t *end, *ptr;
> >>> >> > >  int ncolors, cpp, ret, i, j;
> >>> >> > >  int64_t size;
> >>> >> > >  uint32_t *dst;
> >>> >> > >
> >>> >> > >  avctx->pix_fmt = AV_PIX_FMT_BGRA;
> >>> >> > >
> >>> >> > > -end = avpkt->data + avpkt->size;
> >>> >> > > -while (memcmp(ptr, "/* XPM */", 9) && ptr < end - 9)
> >>> >> > > +av_fast_padded_malloc(&x->buf, &x->buf_size, avpkt->size);
> >>> >> > > +if (!x->buf)
> >>> >> > > +return AVERROR(ENOMEM);
> >>> >> > > +memcpy(x->buf, avpkt->data, avpkt->size);
> >>> >> > > +x->buf[avpkt->size] = 0;
> >>> >> > > +
> >>> >> > > +ptr = x->buf;
> >>> >> > > +end = x->buf + avpkt->size;
> >>> >> > > +while (end - ptr > 9 && memcmp(ptr, "/* XPM */", 9))
> >>> >> > >  ptr++;
> >>> >> > >
> >>> >> > > -if (ptr >= end) {
> >>> >> > > +if (end - ptr <= 9) {
> >>> >> > >  av_log(avctx, AV_LOG_ERROR, "missing signature\n");
> >>> >> > >  return AVERROR_INVALIDDATA;
> >>> >> > >  }
> >>> >> > > @@ -335,7 +346,7 @@ static int xpm_decode_frame(AVCodecContext
> >>> >> > > *avctx,
> >>> >> > > void
> >>> >> > > *data,
> >>> >> > >
> >>> >> > >  size = 1;
> >>> >> > >  for (i = 0; i < cpp; i++)
> >>> >> > > -size *= 94;
> >>> >> > > +size *= 95;
> >>> >> > >
> >>> >> > >  if (ncolors <= 0 || ncolors > size) {
> >>> >> > >  av_log(avctx, AV_LOG_ERROR, "invalid number of colors:
> >>> >> > > %d\n",
> >>> >> > > ncolors);
> >>> >> > > @@ -349,12 +360,15 @@ static int xpm_decode_frame(AVCodecContext
> >>> >> > > *avctx,
> >>> >> > > void *data,
> >>> >> > >  return AVERROR(ENOMEM);
> >>> >> > >
> >>> >> > >  ptr += mod_strcspn(ptr, ",") + 1;
> >>> >> > > +if (end - ptr < 1)
> >>> >> > > +return AVERROR_INVALIDDATA;
> >>> >> > > +
> >>> >> > >  for (i = 0; i < ncolors; i++) {
> >>> >> > >  const uint8_t *index;
> >>> >> > >  int len;
> >>> >> > >
> >>> >> > >  ptr += mod_strcspn(ptr, "\"") + 1;
> >>> >> > > -if (ptr + cpp > end)
> >>> >> > > +if (end - ptr < cpp)
> >>> >> > >  return AVERROR_INVALIDDATA;
> >>> >> > >  index = ptr;
> >>> >> > >  ptr += cpp;
> >>> >> > > @@ -373,14 +387,20 @@ static int xpm_decode_frame(AVCodecContext
> >>> >> > > *avctx,
> >>> >> > > void *data,
> >>> >> > >
> >>> >> > >  x->pixels[ret] = color_string_to_rgba(ptr, len);
> >>> >> > >  ptr += mod_strcspn(ptr, ",") + 1;
> >>> >> > > +if (end - ptr < 1)
> >>> >> > > +return AVERROR_INVALIDDATA;
> >>> >> > >  }
> >>> >> > >
> >>> >> > >  for (i = 0; i < avctx->height; i++) {
> >>> >> > >  dst = (uint32_t *)(p->data[0] + i * p-

Re: [FFmpeg-devel] [PATCH] avcodec/xpmdec: Fix multiple pointer/memory issues

2017-05-12 Thread Michael Niedermayer
On Fri, May 12, 2017 at 08:58:52PM +0200, Paul B Mahol wrote:
> On 5/12/17, Michael Niedermayer  wrote:
> > On Fri, May 12, 2017 at 03:29:52PM +0200, Paul B Mahol wrote:
> >> On 5/12/17, Michael Niedermayer  wrote:
> >> > On Thu, May 11, 2017 at 11:17:33AM +0200, Michael Niedermayer wrote:
> >> >> On Thu, May 11, 2017 at 09:01:57AM +0200, Paul B Mahol wrote:
> >> >> > On 5/11/17, Michael Niedermayer  wrote:
> >> >> > > Most of these were found through code review in response to
> >> >> > > fixing 1466/clusterfuzz-testcase-minimized-5961584419536896
> >> >> > > There is thus no testcase for most of this.
> >> >> > > The initial issue was Found-by: continuous fuzzing process
> >> >> > > https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
> >> >> > >
> >> >> > > Signed-off-by: Michael Niedermayer 
> >> >> > > ---
> >> >> > >  libavcodec/xpmdec.c | 37 ++---
> >> >> > >  1 file changed, 30 insertions(+), 7 deletions(-)
> >> >> > >
> >> >> > > diff --git a/libavcodec/xpmdec.c b/libavcodec/xpmdec.c
> >> >> > > index 9112d4cb5e..03172e4aad 100644
> >> >> > > --- a/libavcodec/xpmdec.c
> >> >> > > +++ b/libavcodec/xpmdec.c
> >> >> > > @@ -29,6 +29,8 @@
> >> >> > >  typedef struct XPMContext {
> >> >> > >  uint32_t  *pixels;
> >> >> > >  intpixels_size;
> >> >> > > +uint8_t   *buf;
> >> >> > > +intbuf_size;
> >> >> > >  } XPMDecContext;
> >> >> > >
> >> >> > >  typedef struct ColorEntry {
> >> >> > > @@ -233,6 +235,8 @@ static uint32_t color_string_to_rgba(const
> >> >> > > char
> >> >> > > *p, int
> >> >> > > len)
> >> >> > >  const ColorEntry *entry;
> >> >> > >  char color_name[100];
> >> >> > >
> >> >> > > +len = FFMIN(FFMAX(len, 0), sizeof(color_name) - 1);
> >> >> > > +
> >> >> > >  if (*p == '#') {
> >> >> > >  p++;
> >> >> > >  len--;
> >> >> > > @@ -299,18 +303,25 @@ static int xpm_decode_frame(AVCodecContext
> >> >> > > *avctx,
> >> >> > > void *data,
> >> >> > >  {
> >> >> > >  XPMDecContext *x = avctx->priv_data;
> >> >> > >  AVFrame *p=data;
> >> >> > > -const uint8_t *end, *ptr = avpkt->data;
> >> >> > > +const uint8_t *end, *ptr;
> >> >> > >  int ncolors, cpp, ret, i, j;
> >> >> > >  int64_t size;
> >> >> > >  uint32_t *dst;
> >> >> > >
> >> >> > >  avctx->pix_fmt = AV_PIX_FMT_BGRA;
> >> >> > >
> >> >> > > -end = avpkt->data + avpkt->size;
> >> >> > > -while (memcmp(ptr, "/* XPM */", 9) && ptr < end - 9)
> >> >> > > +av_fast_padded_malloc(&x->buf, &x->buf_size, avpkt->size);
> >> >> > > +if (!x->buf)
> >> >> > > +return AVERROR(ENOMEM);
> >> >> > > +memcpy(x->buf, avpkt->data, avpkt->size);
> >> >> > > +x->buf[avpkt->size] = 0;
> >> >> > > +
> >> >> > > +ptr = x->buf;
> >> >> > > +end = x->buf + avpkt->size;
> >> >> > > +while (end - ptr > 9 && memcmp(ptr, "/* XPM */", 9))
> >> >> > >  ptr++;
> >> >> > >
> >> >> > > -if (ptr >= end) {
> >> >> > > +if (end - ptr <= 9) {
> >> >> > >  av_log(avctx, AV_LOG_ERROR, "missing signature\n");
> >> >> > >  return AVERROR_INVALIDDATA;
> >> >> > >  }
> >> >> > > @@ -335,7 +346,7 @@ static int xpm_decode_frame(AVCodecContext
> >> >> > > *avctx,
> >> >> > > void
> >> >> > > *data,
> >> >> > >
> >> >> > >  size = 1;
> >> >> > >  for (i = 0; i < cpp; i++)
> >> >> > > -size *= 94;
> >> >> > > +size *= 95;
> >> >> > >
> >> >> > >  if (ncolors <= 0 || ncolors > size) {
> >> >> > >  av_log(avctx, AV_LOG_ERROR, "invalid number of colors:
> >> >> > > %d\n",
> >> >> > > ncolors);
> >> >> > > @@ -349,12 +360,15 @@ static int xpm_decode_frame(AVCodecContext
> >> >> > > *avctx,
> >> >> > > void *data,
> >> >> > >  return AVERROR(ENOMEM);
> >> >> > >
> >> >> > >  ptr += mod_strcspn(ptr, ",") + 1;
> >> >> > > +if (end - ptr < 1)
> >> >> > > +return AVERROR_INVALIDDATA;
> >> >> > > +
> >> >> > >  for (i = 0; i < ncolors; i++) {
> >> >> > >  const uint8_t *index;
> >> >> > >  int len;
> >> >> > >
> >> >> > >  ptr += mod_strcspn(ptr, "\"") + 1;
> >> >> > > -if (ptr + cpp > end)
> >> >> > > +if (end - ptr < cpp)
> >> >> > >  return AVERROR_INVALIDDATA;
> >> >> > >  index = ptr;
> >> >> > >  ptr += cpp;
> >> >> > > @@ -373,14 +387,20 @@ static int xpm_decode_frame(AVCodecContext
> >> >> > > *avctx,
> >> >> > > void *data,
> >> >> > >
> >> >> > >  x->pixels[ret] = color_string_to_rgba(ptr, len);
> >> >> > >  ptr += mod_strcspn(ptr, ",") + 1;
> >> >> > > +if (end - ptr < 1)
> >> >> > > +return AVERROR_INVALIDDATA;
> >> >> > >  }
> >> >> > >
> >> >> > >  for (i = 0; i < avctx->height; i++) {
> >> >> > >  dst = (uint32_t *)(p->data[0] + i * p->linesize[0]);
> >> >> > > +if (end - ptr < 1)
> >> >> > > +return AVERROR_INVALIDDATA;
> >> >> > >  ptr += mod_strcspn(ptr, "\

Re: [FFmpeg-devel] [PATCH] lavf/mov: make invalid mdhd time_scale default to 1 instead of erroring out

2017-05-12 Thread Michael Niedermayer
On Thu, May 11, 2017 at 04:33:50PM +0200, Matthieu Bouron wrote:
> Some samples have their metadata track time_scale incorrectly set to 0
> and the check introduced by a398f054fdb9b0f0b5a91c231fba6ce014143f71
> prevents playback of those samples. Setting the time_scale to 1 fixes
> playback.
> ---
>  libavformat/mov.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

should be ok
please add a fate test

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Freedom in capitalist society always remains about the same as it was in
ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH 2/2] ffmpeg: Made execution of reap_filters() more deterministic with respect to when headers are written

2017-05-12 Thread Aaron Levinson
Purpose: Made execution of reap_filters() more deterministic with
respect to when headers are written in relationship with the
initialization of output streams and the processing of input audio
and/or video frames.  This change fixes a bug in ffmpeg encountered
when decoding interlaced video.  In some cases, ffmpeg would treat it
as progressive.

Detailed description of problem: Run the following command: "ffmpeg -i
test8_1080i.h264 -c:v mpeg2video test8_1080i_mp2.ts".  In this case,
test8_1080i.h264 is an H.264-encoded file with 1080i59.94
(interlaced).  Prior to the patch, the following output is generated:

Input #0, h264, from 'test8_1080i.h264':
  Duration: N/A, bitrate: N/A
Stream #0:0: Video: h264 (High), yuv420p(top first), 1920x1080 [SAR 1:1 DAR 
16:9], 29.97 fps, 29.97 tbr, 1200k tbn, 59.94 tbc
Stream mapping:
  Stream #0:0 -> #0:0 (h264 (native) -> mpeg2video (native))
Press [q] to stop, [?] for help
Output #0, mpegts, to 'test8_1080i_mp2_2.ts':
  Metadata:
encoder : Lavf57.72.100
Stream #0:0: Video: mpeg2video (Main), yuv420p, 1920x1080 [SAR 1:1 DAR 
16:9], q=2-31, 200 kb/s, 29.97 fps, 90k tbn, 29.97 tbc
Metadata:
  encoder : Lavc57.92.100 mpeg2video

which demonstrates the bug.  The output stream should instead look like:

Stream #0:0: Video: mpeg2video (Main), yuv420p(top coded first (swapped)), 
1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 200 kb/s, 29.97 fps, 90k tbn, 29.97 tbc

The bug is caused by the fact that reap_filters() calls
init_output_stream(), which is then immediately followed by a call to
check_init_output_file(), and this is all done prior to the first call
to do_video_out().  An initial call to do_video_out() is necessary to
populate the interlaced video information to the output stream's
codecpar (mux_par->field_order in do_video_out()).  However,
check_init_output_file() calls avformat_write_header() prior to the
initial call to do_video_out(), so field_order is populated too late,
and the header is written with the default field_order value,
progressive.

Signed-off-by: Aaron Levinson 
---
 ffmpeg.c | 43 ---
 1 file changed, 40 insertions(+), 3 deletions(-)

diff --git a/ffmpeg.c b/ffmpeg.c
index 3cd45ba665..7b044b068c 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -1434,6 +1434,7 @@ static int reap_filters(int flush)
 AVFilterContext *filter;
 AVCodecContext *enc = ost->enc_ctx;
 int ret = 0;
+int do_check_init_output_file = 0;
 
 if (!ost->filter || !ost->filter->graph->graph)
 continue;
@@ -1448,9 +1449,7 @@ static int reap_filters(int flush)
 exit_program(1);
 }
 
-ret = check_init_output_file(of, ost->file_index);
-if (ret < 0)
-exit_program(1);
+do_check_init_output_file = 1;
 }
 
 if (!ost->filtered_frame && !(ost->filtered_frame = av_frame_alloc())) 
{
@@ -1526,6 +1525,44 @@ static int reap_filters(int flush)
 }
 
 av_frame_unref(filtered_frame);
+
+/*
+ * It is important to call check_init_output_file() here, after
+ * do_video_out() was called, instead of in init_output_stream(),
+ * as was done previously.
+ * If called from init_output_stream(), it is possible that not
+ * everything will have been fully initialized by the time that
+ * check_init_output_file() is called, and if
+ * check_init_output_file() determines that all output streams
+ * have been initialized, it will write the header.  An example
+ * of initialization that depends on do_video_out() being called
+ * at least once is the specification of interlaced video, which
+ * happens in do_video_out().  This is particularly relevant when
+ * decoding--without processing a video frame, the interlaced
+ * video setting is not propagated before the header is written,
+ * and that causes problems.
+ * TODO:  should probably handle interlaced video differently
+ * and not depend on it being setup in do_video_out().  Another
+ * solution would be to set it up once by examining the input
+ * header.
+ */
+if (do_check_init_output_file) {
+ret = check_init_output_file(of, ost->file_index);
+if (ret < 0)
+exit_program(1);
+do_check_init_output_file = 0;
+}
+}
+
+/*
+ * Can't wait too long to call check_init_output_file().
+ * Otherwise, bad things start to occur.
+ * If didn't do it earlier, do it by the time it gets here.
+ */
+if (do_check_init_output_file) {
+ret = check_init_output_file(of, ost->file_index);
+if (ret < 0)
+exit_program(1);
 

[FFmpeg-devel] [PATCH 1/2] ffmpeg: Separated check_init_output_file() from init_output_stream()

2017-05-12 Thread Aaron Levinson
Purpose: Separated the call to check_init_output_file() from
init_output_stream(), and now check_init_output_file() is called by
the parent after calling init_output_stream().  Additionally, moved
some static function declarations to the beginning of the file.

Signed-off-by: Aaron Levinson 
---
 ffmpeg.c | 27 +++
 1 file changed, 19 insertions(+), 8 deletions(-)

diff --git a/ffmpeg.c b/ffmpeg.c
index e798d92277..3cd45ba665 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -141,6 +141,9 @@ AVIOContext *progress_avio = NULL;
 
 static uint8_t *subtitle_out;
 
+static int init_output_stream(OutputStream *ost, char *error, int error_len);
+static int check_init_output_file(OutputFile *of, int file_index);
+
 InputStream **input_streams = NULL;
 intnb_input_streams = 0;
 InputFile   **input_files   = NULL;
@@ -1400,8 +1403,6 @@ static void do_video_stats(OutputStream *ost, int 
frame_size)
 }
 }
 
-static int init_output_stream(OutputStream *ost, char *error, int error_len);
-
 static void finish_output_stream(OutputStream *ost)
 {
 OutputFile *of = output_files[ost->file_index];
@@ -1446,6 +1447,10 @@ static int reap_filters(int flush)
ost->file_index, ost->index, error);
 exit_program(1);
 }
+
+ret = check_init_output_file(of, ost->file_index);
+if (ret < 0)
+exit_program(1);
 }
 
 if (!ost->filtered_frame && !(ost->filtered_frame = av_frame_alloc())) 
{
@@ -1894,6 +1899,10 @@ static void flush_encoders(void)
ost->file_index, ost->index, error);
 exit_program(1);
 }
+
+ret = check_init_output_file(of, ost->file_index);
+if (ret < 0)
+exit_program(1);
 }
 
 if (enc->codec_type == AVMEDIA_TYPE_AUDIO && enc->frame_size <= 1)
@@ -3564,10 +3573,6 @@ static int init_output_stream(OutputStream *ost, char 
*error, int error_len)
 
 ost->initialized = 1;
 
-ret = check_init_output_file(output_files[ost->file_index], 
ost->file_index);
-if (ret < 0)
-return ret;
-
 return ret;
 }
 
@@ -3629,11 +3634,17 @@ static int transcode_init(void)
 
 /* open each encoder */
 for (i = 0; i < nb_output_streams; i++) {
+ost = output_streams[i];
 // skip streams fed from filtergraphs until we have a frame for them
-if (output_streams[i]->filter)
+if (ost->filter)
 continue;
 
-ret = init_output_stream(output_streams[i], error, sizeof(error));
+ret = init_output_stream(ost, error, sizeof(error));
+if (ret < 0)
+goto dump_format;
+
+ret = check_init_output_file(output_files[ost->file_index],
+ ost->file_index);
 if (ret < 0)
 goto dump_format;
 }
-- 
2.12.2.windows.2

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


Re: [FFmpeg-devel] [PATCH 1/2] ffmpeg: Separated check_init_output_file() from, init_output_stream()

2017-05-12 Thread Aaron Levinson

Please disregard--I messed up the subject.  I'll send a new one.

Aaron Levinson

On 5/12/2017 1:22 PM, Aaron Levinson wrote:

Purpose: Separated the call to check_init_output_file() from
init_output_stream(), and now check_init_output_file() is called by
the parent after calling init_output_stream().  Additionally, moved
some static function declarations to the beginning of the file.

Signed-off-by: Aaron Levinson 
---
 ffmpeg.c | 27 +++
 1 file changed, 19 insertions(+), 8 deletions(-)

diff --git a/ffmpeg.c b/ffmpeg.c
index e798d92277..3cd45ba665 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -141,6 +141,9 @@ AVIOContext *progress_avio = NULL;

 static uint8_t *subtitle_out;

+static int init_output_stream(OutputStream *ost, char *error, int error_len);
+static int check_init_output_file(OutputFile *of, int file_index);
+
 InputStream **input_streams = NULL;
 intnb_input_streams = 0;
 InputFile   **input_files   = NULL;
@@ -1400,8 +1403,6 @@ static void do_video_stats(OutputStream *ost, int 
frame_size)
 }
 }

-static int init_output_stream(OutputStream *ost, char *error, int error_len);
-
 static void finish_output_stream(OutputStream *ost)
 {
 OutputFile *of = output_files[ost->file_index];
@@ -1446,6 +1447,10 @@ static int reap_filters(int flush)
ost->file_index, ost->index, error);
 exit_program(1);
 }
+
+ret = check_init_output_file(of, ost->file_index);
+if (ret < 0)
+exit_program(1);
 }

 if (!ost->filtered_frame && !(ost->filtered_frame = av_frame_alloc())) 
{
@@ -1894,6 +1899,10 @@ static void flush_encoders(void)
ost->file_index, ost->index, error);
 exit_program(1);
 }
+
+ret = check_init_output_file(of, ost->file_index);
+if (ret < 0)
+exit_program(1);
 }

 if (enc->codec_type == AVMEDIA_TYPE_AUDIO && enc->frame_size <= 1)
@@ -3564,10 +3573,6 @@ static int init_output_stream(OutputStream *ost, char 
*error, int error_len)

 ost->initialized = 1;

-ret = check_init_output_file(output_files[ost->file_index], 
ost->file_index);
-if (ret < 0)
-return ret;
-
 return ret;
 }

@@ -3629,11 +3634,17 @@ static int transcode_init(void)

 /* open each encoder */
 for (i = 0; i < nb_output_streams; i++) {
+ost = output_streams[i];
 // skip streams fed from filtergraphs until we have a frame for them
-if (output_streams[i]->filter)
+if (ost->filter)
 continue;

-ret = init_output_stream(output_streams[i], error, sizeof(error));
+ret = init_output_stream(ost, error, sizeof(error));
+if (ret < 0)
+goto dump_format;
+
+ret = check_init_output_file(output_files[ost->file_index],
+ ost->file_index);
 if (ret < 0)
 goto dump_format;
 }


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


[FFmpeg-devel] [PATCH 1/2] ffmpeg: Separated check_init_output_file() from, init_output_stream()

2017-05-12 Thread Aaron Levinson
Purpose: Separated the call to check_init_output_file() from
init_output_stream(), and now check_init_output_file() is called by
the parent after calling init_output_stream().  Additionally, moved
some static function declarations to the beginning of the file.

Signed-off-by: Aaron Levinson 
---
 ffmpeg.c | 27 +++
 1 file changed, 19 insertions(+), 8 deletions(-)

diff --git a/ffmpeg.c b/ffmpeg.c
index e798d92277..3cd45ba665 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -141,6 +141,9 @@ AVIOContext *progress_avio = NULL;
 
 static uint8_t *subtitle_out;
 
+static int init_output_stream(OutputStream *ost, char *error, int error_len);
+static int check_init_output_file(OutputFile *of, int file_index);
+
 InputStream **input_streams = NULL;
 intnb_input_streams = 0;
 InputFile   **input_files   = NULL;
@@ -1400,8 +1403,6 @@ static void do_video_stats(OutputStream *ost, int 
frame_size)
 }
 }
 
-static int init_output_stream(OutputStream *ost, char *error, int error_len);
-
 static void finish_output_stream(OutputStream *ost)
 {
 OutputFile *of = output_files[ost->file_index];
@@ -1446,6 +1447,10 @@ static int reap_filters(int flush)
ost->file_index, ost->index, error);
 exit_program(1);
 }
+
+ret = check_init_output_file(of, ost->file_index);
+if (ret < 0)
+exit_program(1);
 }
 
 if (!ost->filtered_frame && !(ost->filtered_frame = av_frame_alloc())) 
{
@@ -1894,6 +1899,10 @@ static void flush_encoders(void)
ost->file_index, ost->index, error);
 exit_program(1);
 }
+
+ret = check_init_output_file(of, ost->file_index);
+if (ret < 0)
+exit_program(1);
 }
 
 if (enc->codec_type == AVMEDIA_TYPE_AUDIO && enc->frame_size <= 1)
@@ -3564,10 +3573,6 @@ static int init_output_stream(OutputStream *ost, char 
*error, int error_len)
 
 ost->initialized = 1;
 
-ret = check_init_output_file(output_files[ost->file_index], 
ost->file_index);
-if (ret < 0)
-return ret;
-
 return ret;
 }
 
@@ -3629,11 +3634,17 @@ static int transcode_init(void)
 
 /* open each encoder */
 for (i = 0; i < nb_output_streams; i++) {
+ost = output_streams[i];
 // skip streams fed from filtergraphs until we have a frame for them
-if (output_streams[i]->filter)
+if (ost->filter)
 continue;
 
-ret = init_output_stream(output_streams[i], error, sizeof(error));
+ret = init_output_stream(ost, error, sizeof(error));
+if (ret < 0)
+goto dump_format;
+
+ret = check_init_output_file(output_files[ost->file_index],
+ ost->file_index);
 if (ret < 0)
 goto dump_format;
 }
-- 
2.12.2.windows.2

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


Re: [FFmpeg-devel] [PATCH] Fixed bug encountered when decoding interlaced video

2017-05-12 Thread Aaron Levinson

On 5/9/2017 11:56 AM, Michael Niedermayer wrote:

On Thu, May 04, 2017 at 11:46:30PM -0700, Aaron Levinson wrote:


I've provided a new version of the patch.  When I created the first version of the patch on March 
26th, this was the first patch that I submitted to ffmpeg, and some aspects were rough.  I had 
indicated that the patch passed regression tests, but all I did was run "make fate", 
instead of "make fate SAMPLES=fate-suite/", and once I understood that I should use 
fate-suite, I discovered that some of the FATE tests failed with this patch.  I fixed the issues 
with the patch, adjusted some comments, and adjusted the patch description text.  I've confirmed 
that this patch passes all fate-suite tests for 64-bit MSVC on Windows and 64-bit gcc on Linux.

Thanks,
Aaron Levinson



From 85aa383f5753795652bae015f4fe91b016f7387e Mon Sep 17 00:00:00 2001
From: Aaron Levinson 
Date: Thu, 4 May 2017 22:54:31 -0700
Subject: [PATCH] ffmpeg:  Fixed bug with decoding interlaced video

Purpose: Fixed bug in ffmpeg encountered when decoding interlaced
video.  In some cases, ffmpeg would treat it as progressive.  As a
result of the change, the issues with interlaced video are fixed.

Detailed description of problem: Run the following command: "ffmpeg -i
test8_1080i.h264 -c:v mpeg2video test8_1080i_mp2.ts".  In this case,
test8_1080i.h264 is an H.264-encoded file with 1080i59.94
(interlaced).  Prior to the patch, the following output is generated:

Input #0, h264, from 'test8_1080i.h264':
  Duration: N/A, bitrate: N/A
Stream #0:0: Video: h264 (High), yuv420p(top first), 1920x1080 [SAR 1:1 DAR 
16:9], 29.97 fps, 29.97 tbr, 1200k tbn, 59.94 tbc
Stream mapping:
  Stream #0:0 -> #0:0 (h264 (native) -> mpeg2video (native))
Press [q] to stop, [?] for help
Output #0, mpegts, to 'test8_1080i_mp2_2.ts':
  Metadata:
encoder : Lavf57.72.100
Stream #0:0: Video: mpeg2video (Main), yuv420p, 1920x1080 [SAR 1:1 DAR 
16:9], q=2-31, 200 kb/s, 29.97 fps, 90k tbn, 29.97 tbc
Metadata:
  encoder : Lavc57.92.100 mpeg2video

which demonstrates the bug.  The output should instead look like:

Stream #0:0: Video: mpeg2video (Main), yuv420p(top coded first (swapped)), 
1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 200 kb/s, 29.97 fps, 90k tbn, 29.97 tbc

The bug is caused by the fact that reap_filters() calls
init_output_stream(), which in turn calls check_init_output_file(),
and this is all done prior to the first call to do_video_out().  An
initial call to do_video_out() is necessary to populate the interlaced
video information to the output stream's codecpar
(mux_par->field_order in do_video_out()).  However,
check_init_output_file() calls avformat_write_header() prior to the
initial call to do_video_out(), so field_order is populated too late,
and the header is written with the default field_order value,
progressive.

Comments:

-- ffmpeg.c:
a) Enhanced init_output_stream() to take an additional input
   indicating whether or not check_init_output_file() should be
   called.  There are other places that call init_output_stream(), and
   it was important to make sure that these continued to work
   properly.
b) Adjusted reap_filters() such that, in the case that
   init_output_stream() is called, it indicates that it should not
   call check_init_output_file() in init_output_stream().  Instead, it
   makes the call to check_init_output_file() directly, but after it
   does the filtered frame setup and processing.

Signed-off-by: Aaron Levinson 
---
 ffmpeg.c | 61 +
 1 file changed, 53 insertions(+), 8 deletions(-)

diff --git a/ffmpeg.c b/ffmpeg.c
index e798d92277..45dbfafc04 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c



@@ -1400,7 +1400,7 @@ static void do_video_stats(OutputStream *ost, int 
frame_size)
 }
 }

-static int init_output_stream(OutputStream *ost, char *error, int error_len);
+static int init_output_stream(OutputStream *ost, char *error, int error_len, 
int do_check_output_file);

 static void finish_output_stream(OutputStream *ost)
 {



@@ -1415,6 +1415,8 @@ static void finish_output_stream(OutputStream *ost)
 }
 }

+static int check_init_output_file(OutputFile *of, int file_index);


should be close to the file top, together with similar prototypes


Will do.


[...]

@@ -1521,6 +1526,44 @@ static int reap_filters(int flush)
 }

 av_frame_unref(filtered_frame);
+
+/*
+ * It is important to call check_init_output_file() here, after
+ * do_video_out() was called, instead of in init_output_stream(),
+ * as was done previously.
+ * If called from init_output_stream(), it is possible that not
+ * everything will have been fully initialized by the time that
+ * check_init_output_file() is called, and if
+ * check_init_output_file() determines t

Re: [FFmpeg-devel] [PATCH V2] lavc/vaapi_encode_h264: Enable MB rate control

2017-05-12 Thread Michael Niedermayer
On Fri, May 12, 2017 at 02:27:45PM +0800, Jun Zhao wrote:
> V2: - Refine the name/value type to mb_rate_control/bool.
> - Only supported GEN9+ (SKL/APL/KBL/...)
> - i965 driver default use frame-level rate control algorithm (generate 
> the QP for each frame), 
>   when enable mb_rate_control, it's will enable the MB-level RC algorithm 
> (generate the QP for each MB). 
> - enables MB-level bitrate control that generally improves subjective 
> visual quality, 
>   but have negative impact on performance and objective visual quality 
> metric. 

>  vaapi_encode_h264.c |8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> c835733e8022f49f94585253793fb6712509d1cb  
> 0001-lavc-vaapi_encode_h264-Enable-MB-rate-control.patch
> From 9223a87e48c846f1ab7c65ba857d902de70349a8 Mon Sep 17 00:00:00 2001
> From: Jun Zhao 
> Date: Tue, 9 May 2017 08:19:16 +0800
> Subject: [PATCH V2] lavc/vaapi_encode_h264: Enable MB rate control.
> 
> Enables macroblock-level bitrate control that generally improves
> subjective visual quality. It may have a negative impact on
> performance and objective visual quality metrics. Default is off
> and can't compatible with Constant QP.
> 
> Signed-off-by: Jun Zhao 
> ---
>  libavcodec/vaapi_encode_h264.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)

Fails to build
libavcodec/vaapi_encode_h264.c: In function ‘vaapi_encode_h264_configure’:
libavcodec/vaapi_encode_h264.c:1137:40: error: ‘struct ’ has no 
member named ‘mb_rate_control’
 ctx->rc_params.rc.rc_flags.bits.mb_rate_control = opt->mb_rate_control;
^
make: *** [libavcodec/vaapi_encode_h264.o] Error 1

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The educated differ from the uneducated as much as the living from the
dead. -- Aristotle 


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] avcodec/xpmdec: Fix multiple pointer/memory issues

2017-05-12 Thread Paul B Mahol
On 5/12/17, Nicolas George  wrote:
> Le tridi 23 floreal, an CCXXV, Paul B Mahol a ecrit :
>> Because I assumed packets are padded with zeroes.
>
> Because you chose to write quick-and-dirty instead of robust.

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


Re: [FFmpeg-devel] [PATCH] avcodec/xpmdec: Fix multiple pointer/memory issues

2017-05-12 Thread Nicolas George
Le tridi 23 floréal, an CCXXV, Paul B Mahol a écrit :
> Because I assumed packets are padded with zeroes.

Because you chose to write quick-and-dirty instead of robust.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH 3/3] avfilter/scale_cuda: add CUDA scale filter

2017-05-12 Thread Timo Rothenpieler
From: Yogender Gupta 

---
 libavfilter/Makefile |   1 +
 libavfilter/allfilters.c |   1 +
 libavfilter/vf_scale_cuda.c  | 555 +++
 libavfilter/vf_scale_cuda.cu | 212 +
 4 files changed, 769 insertions(+)
 create mode 100644 libavfilter/vf_scale_cuda.c
 create mode 100644 libavfilter/vf_scale_cuda.cu

diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index f7dfe8ad54..f177fdb42b 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -267,6 +267,7 @@ OBJS-$(CONFIG_REVERSE_FILTER)+= f_reverse.o
 OBJS-$(CONFIG_ROTATE_FILTER) += vf_rotate.o
 OBJS-$(CONFIG_SAB_FILTER)+= vf_sab.o
 OBJS-$(CONFIG_SCALE_FILTER)  += vf_scale.o scale.o
+OBJS-$(CONFIG_SCALE_CUDA_FILTER) += vf_scale_cuda.o 
vf_scale_cuda.ptx.o
 OBJS-$(CONFIG_SCALE_NPP_FILTER)  += vf_scale_npp.o scale.o
 OBJS-$(CONFIG_SCALE_QSV_FILTER)  += vf_scale_qsv.o
 OBJS-$(CONFIG_SCALE_VAAPI_FILTER)+= vf_scale_vaapi.o scale.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index cd35ae4c9c..a8939b9094 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -278,6 +278,7 @@ static void register_all(void)
 REGISTER_FILTER(ROTATE, rotate, vf);
 REGISTER_FILTER(SAB,sab,vf);
 REGISTER_FILTER(SCALE,  scale,  vf);
+REGISTER_FILTER(SCALE_CUDA, scale_cuda, vf);
 REGISTER_FILTER(SCALE_NPP,  scale_npp,  vf);
 REGISTER_FILTER(SCALE_QSV,  scale_qsv,  vf);
 REGISTER_FILTER(SCALE_VAAPI,scale_vaapi,vf);
diff --git a/libavfilter/vf_scale_cuda.c b/libavfilter/vf_scale_cuda.c
new file mode 100644
index 00..1f643197ac
--- /dev/null
+++ b/libavfilter/vf_scale_cuda.c
@@ -0,0 +1,555 @@
+/*
+* Copyright (c) 2017, NVIDIA CORPORATION. All rights reserved.
+*
+* Permission is hereby granted, free of charge, to any person obtaining a
+* copy of this software and associated documentation files (the "Software"),
+* to deal in the Software without restriction, including without limitation
+* the rights to use, copy, modify, merge, publish, distribute, sublicense,
+* and/or sell copies of the Software, and to permit persons to whom the
+* Software is furnished to do so, subject to the following conditions:
+*
+* The above copyright notice and this permission notice shall be included in
+* all copies or substantial portions of the Software.
+*
+* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+* THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+* FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+* DEALINGS IN THE SOFTWARE.
+*/
+
+#include 
+#include 
+#include 
+
+#include "libavutil/avstring.h"
+#include "libavutil/common.h"
+#include "libavutil/hwcontext.h"
+#include "libavutil/hwcontext_cuda_internal.h"
+#include "libavutil/internal.h"
+#include "libavutil/opt.h"
+#include "libavutil/pixdesc.h"
+
+#include "avfilter.h"
+#include "formats.h"
+#include "internal.h"
+#include "scale.h"
+#include "video.h"
+
+static const enum AVPixelFormat supported_formats[] = {
+AV_PIX_FMT_YUV420P,
+AV_PIX_FMT_NV12,
+AV_PIX_FMT_YUV444P,
+AV_PIX_FMT_P010,
+AV_PIX_FMT_P016
+};
+
+#define DIV_UP(a, b) ( ((a) + (b) - 1) / (b) )
+#define ALIGN_UP(a, b) ((a + b -1) & ~(b-1))
+#define NUM_BUFFERS 2
+#define BLOCKX 32
+#define BLOCKY 16
+
+typedef struct CUDAScaleContext {
+const AVClass *class;
+enum AVPixelFormat in_fmt;
+enum AVPixelFormat out_fmt;
+
+struct {
+int width;
+int height;
+} planes_in[3], planes_out[3];
+
+AVBufferRef *frames_ctx;
+AVFrame *frame;
+
+AVFrame *tmp_frame;
+int passthrough;
+
+/**
+ * Output sw format. AV_PIX_FMT_NONE for no conversion.
+ */
+enum AVPixelFormat format;
+
+char *w_expr;   ///< width  expression string
+char *h_expr;   ///< height expression string
+
+CUcontext   cu_ctx;
+CUevent cu_event;
+CUmodulecu_module;
+CUfunction  cu_func_uchar;
+CUfunction  cu_func_uchar2;
+CUfunction  cu_func_uchar4;
+CUfunction  cu_func_ushort;
+CUfunction  cu_func_ushort2;
+CUfunction  cu_func_ushort4;
+CUtexrefcu_tex_uchar;
+CUtexrefcu_tex_uchar2;
+CUtexrefcu_tex_uchar4;
+CUtexrefcu_tex_ushort;
+CUtexrefcu_tex_ushort2;
+CUtexrefcu_tex_ushort4;
+
+CUdeviceptr srcBuffer;
+CUdeviceptr dstBuffer;
+int tex_alignment;
+} CUDAScaleContext;
+
+static int cudascale_init(AVFilterContext *ctx)
+{
+CUDAScaleContext *s = ctx->pr

[FFmpeg-devel] [PATCH 2/3] build: add support for building .cu files via nvcc

2017-05-12 Thread Timo Rothenpieler
Original work by Yogender Gupta 
---
 .gitignore   |  2 ++
 Makefile |  2 ++
 compat/cuda/ptx2c.sh | 35 +++
 configure| 24 +++-
 ffbuild/common.mak   | 15 ---
 5 files changed, 74 insertions(+), 4 deletions(-)
 create mode 100644 compat/cuda/ptx2c.sh

diff --git a/.gitignore b/.gitignore
index 96172fea74..dabb51762d 100644
--- a/.gitignore
+++ b/.gitignore
@@ -19,6 +19,8 @@
 *.swp
 *.ver
 *.version
+*.ptx
+*.ptx.c
 *_g
 \#*
 .\#*
diff --git a/Makefile b/Makefile
index d414cf841e..4d1c3d768f 100644
--- a/Makefile
+++ b/Makefile
@@ -11,6 +11,8 @@ vpath %.asm  $(SRC_PATH)
 vpath %.rc   $(SRC_PATH)
 vpath %.v$(SRC_PATH)
 vpath %.texi $(SRC_PATH)
+vpath %.cu   $(SRC_PATH)
+vpath %.ptx  $(SRC_PATH)
 vpath %/fate_config.sh.template $(SRC_PATH)
 
 AVPROGS-$(CONFIG_FFMPEG)   += ffmpeg
diff --git a/compat/cuda/ptx2c.sh b/compat/cuda/ptx2c.sh
new file mode 100644
index 00..51f0f57ba7
--- /dev/null
+++ b/compat/cuda/ptx2c.sh
@@ -0,0 +1,35 @@
+# Copyright (c) 2017, NVIDIA CORPORATION. All rights reserved.
+#
+# Permission is hereby granted, free of charge, to any person obtaining a
+# copy of this software and associated documentation files (the "Software"),
+# to deal in the Software without restriction, including without limitation
+# the rights to use, copy, modify, merge, publish, distribute, sublicense,
+# and/or sell copies of the Software, and to permit persons to whom the
+# Software is furnished to do so, subject to the following conditions:
+#
+# The above copyright notice and this permission notice shall be included in
+# all copies or substantial portions of the Software.
+#
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+# DEALINGS IN THE SOFTWARE.
+
+set -e
+
+OUT="$1"
+IN="$2"
+NAME="$(basename "$IN")"
+NAME="${NAME/.ptx/}"
+
+echo -n "const char ${NAME}_ptx[] = \\" > "$OUT"
+while read LINE
+do
+echo -ne "\n\t\"$LINE\\\n\"" >> "$OUT"
+done < "$IN"
+echo ";" >> "$OUT"
+
+exit 0
\ No newline at end of file
diff --git a/configure b/configure
index 8d67838aab..db9d7a1a74 100755
--- a/configure
+++ b/configure
@@ -338,6 +338,7 @@ Toolchain options:
   --cxx=CXXuse C compiler CXX [$cxx_default]
   --objcc=OCC  use ObjC compiler OCC [$cc_default]
   --dep-cc=DEPCC   use dependency generator DEPCC [$cc_default]
+  --nvcc=NVCC  use Nvidia CUDA compiler NVCC [$nvcc_default]
   --ld=LD  use linker LD [$ld_default]
   --pkg-config=PKGCONFIG   use pkg-config tool PKGCONFIG [$pkg_config_default]
   --pkg-config-flags=FLAGS pass additional flags to pkgconf []
@@ -359,6 +360,7 @@ Toolchain options:
   --extra-libs=ELIBS   add ELIBS [$ELIBS]
   --extra-version=STRING   version string suffix []
   --optflags=OPTFLAGS  override optimization-related compiler flags
+  --nvccflags=NVCCFLAGSoverride nvcc flags [$nvccflags_default]
   --build-suffix=SUFFIXlibrary name suffix []
   --enable-pic build position-independent code
   --enable-thumb   compile for Thumb instruction set
@@ -2221,6 +2223,7 @@ CMDLINE_SET="
 malloc_prefix
 nm
 optflags
+nvccflags
 pkg_config
 pkg_config_flags
 progs_suffix
@@ -2719,6 +2722,7 @@ vaapi_encode_deps="vaapi"
 
 hwupload_cuda_filter_deps="cuda"
 scale_npp_filter_deps="cuda_sdk libnpp"
+scale_cuda_filter_deps="cuda_sdk"
 
 nvenc_deps="cuda"
 nvenc_deps_any="dlopen LoadLibrary"
@@ -3261,6 +3265,8 @@ strip_default="strip"
 version_script='--version-script'
 yasmexe_default="yasm"
 windres_default="windres"
+nvcc_default="nvcc"
+nvccflags_default="-gencode arch=compute_30,code=sm_30 -O2"
 
 # OS
 target_os_default=$(tolower $(uname -s))
@@ -3334,6 +3340,8 @@ HOSTCC_C='-c'
 HOSTCC_E='-E -o $@'
 HOSTCC_O='-o $@'
 HOSTLD_O='-o $@'
+NVCC_C='-c'
+NVCC_O='-o $@'
 
 host_extralibs='-lm'
 host_cflags_filter=echo
@@ -3721,7 +3729,7 @@ windres_default="${cross_prefix}${windres_default}"
 sysinclude_default="${sysroot}/usr/include"
 
 set_default arch cc cxx doxygen pkg_config ranlib strip sysinclude \
-target_exec target_os yasmexe
+target_exec target_os yasmexe nvcc
 enabled cross_compile || host_cc_default=$cc
 set_default host_cc
 
@@ -6241,6 +6249,16 @@ if [ -z "$optflags" ]; then
 fi
 fi
 
+if [ -z "$nvccflags" ]; then
+nvccflags=$nvccflags_default
+fi
+
+if enabled x86_64 || enabled ppc64 || enabled aarch64; then
+nvccflags="$nvccflags -m64"
+else
+nvccflags="$nvccflags -m32"
+fi
+
 check_optflags(){
 check_cflags "$@"
 enabled lto && chec

[FFmpeg-devel] [PATCH 1/3 fixed] configure: add cuda-sdk for things requiring full CUDA sdk

2017-05-12 Thread Timo Rothenpieler
---
 configure | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/configure b/configure
index 5ae5227868..8d67838aab 100755
--- a/configure
+++ b/configure
@@ -297,6 +297,7 @@ External library support:
   The following libraries provide various hardware acceleration features:
   --disable-audiotoolbox   disable Apple AudioToolbox code [autodetect]
   --disable-cuda   disable dynamically linked Nvidia CUDA code 
[autodetect]
+  --enable-cuda-sdkenable CUDA features that require the CUDA SDK [no]
   --disable-cuvid  disable Nvidia CUVID support [autodetect]
   --disable-d3d11vadisable Microsoft Direct3D 11 video acceleration 
code [autodetect]
   --disable-dxva2  disable Microsoft DirectX 9 video acceleration code 
[autodetect]
@@ -1598,6 +1599,7 @@ HWACCEL_AUTODETECT_LIBRARY_LIST="
 "
 
 HWACCEL_LIBRARY_NONFREE_LIST="
+cuda_sdk
 libnpp
 "
 
@@ -2716,7 +2718,7 @@ qsvenc_select="qsv"
 vaapi_encode_deps="vaapi"
 
 hwupload_cuda_filter_deps="cuda"
-scale_npp_filter_deps="cuda libnpp"
+scale_npp_filter_deps="cuda_sdk libnpp"
 
 nvenc_deps="cuda"
 nvenc_deps_any="dlopen LoadLibrary"
@@ -5755,7 +5757,7 @@ done
 enabled avfoundation_indev && { check_header_objcc AVFoundation/AVFoundation.h 
|| disable avfoundation_indev; }
 enabled avfoundation_indev && { check_lib avfoundation_indev 
CoreGraphics/CoreGraphics.h CGGetActiveDisplayList -framework CoreGraphics ||
 check_lib avfoundation_indev 
ApplicationServices/ApplicationServices.h CGGetActiveDisplayList -framework 
ApplicationServices; }
-enabled cuda  && check_header cuda.h # this is not a dependency
+enabled cuda_sdk  && require cuda_sdk cuda.h cuCtxCreate -lcuda
 enabled cuvid && { enabled cuda ||
die "ERROR: CUVID requires CUDA"; }
 enabled chromaprint   && require chromaprint chromaprint.h 
chromaprint_get_version -lchromaprint
-- 
2.12.2

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


Re: [FFmpeg-devel] [PATCH 1/3] configure: add cuda-sdk for things requiring full CUDA sdk

2017-05-12 Thread Timo Rothenpieler

I can also try re-sending the series, but I don't know anything I could
potentially do different.


Probably because it's missing
https://github.com/BtbN/FFmpeg/commit/5048e1159a6f5f5d9cf4cbd78535bc73da6b32bc
which modifies configure as well, and generates a conflict that git am
can't work around when you skip it.


Oh, that's not supposed to be in there.
Will fix and re-send.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 1/3] configure: add cuda-sdk for things requiring full CUDA sdk

2017-05-12 Thread James Almer
On 5/12/2017 4:28 PM, Timo Rothenpieler wrote:
> Am 12.05.2017 um 20:48 schrieb Michael Niedermayer:
>> On Thu, May 11, 2017 at 10:59:19PM +0200, Timo Rothenpieler wrote:
>>> ---
>>>   configure | 6 --
>>>   1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> This doesnt apply so i cant test this or dependant patches
>>
>> Applying: configure: add cuda-sdk for things requiring full CUDA sdk
>> error: sha1 information is lacking or useless (configure).
>> error: could not build fake ancestor
>> Patch failed at 0001 configure: add cuda-sdk for things requiring full
>> CUDA sdk
>> The copy of the patch that failed is found in: .git/rebase-apply/patch
>> When you have resolved this problem, run "git am --continue".
>> If you prefer to skip this patch, run "git am --skip" instead.
>> To restore the original branch and stop patching, run "git am --abort".
> 
> That's weird, this series was made with format-patch + send-email,
> without any manual modifications in between.
> 
> Can also find it on github:
> https://github.com/BtbN/FFmpeg/commit/d4e1bc56c40dc4749b8f5cee6f9037d53ffc245d.patch
> 
> 
> I can also try re-sending the series, but I don't know anything I could
> potentially do different.

Probably because it's missing
https://github.com/BtbN/FFmpeg/commit/5048e1159a6f5f5d9cf4cbd78535bc73da6b32bc
which modifies configure as well, and generates a conflict that git am
can't work around when you skip it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 1/3] configure: add cuda-sdk for things requiring full CUDA sdk

2017-05-12 Thread Timo Rothenpieler

Am 12.05.2017 um 20:48 schrieb Michael Niedermayer:

On Thu, May 11, 2017 at 10:59:19PM +0200, Timo Rothenpieler wrote:

---
  configure | 6 --
  1 file changed, 4 insertions(+), 2 deletions(-)


This doesnt apply so i cant test this or dependant patches

Applying: configure: add cuda-sdk for things requiring full CUDA sdk
error: sha1 information is lacking or useless (configure).
error: could not build fake ancestor
Patch failed at 0001 configure: add cuda-sdk for things requiring full CUDA sdk
The copy of the patch that failed is found in: .git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".


That's weird, this series was made with format-patch + send-email, 
without any manual modifications in between.


Can also find it on github:
https://github.com/BtbN/FFmpeg/commit/d4e1bc56c40dc4749b8f5cee6f9037d53ffc245d.patch

I can also try re-sending the series, but I don't know anything I could 
potentially do different.

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


Re: [FFmpeg-devel] [PATCH] configure: jni no longer requires -ldl

2017-05-12 Thread Aaron Levinson

On 5/12/2017 11:34 AM, Aman Gupta wrote:

From: Aman Gupta 

this dependency was removed in 33d69a90085d30af8a292d9364b835a26565d6b9
---
 configure | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/configure b/configure
index 5ae5227868..ba33241a45 100755
--- a/configure
+++ b/configure
@@ -5766,8 +5766,7 @@ enabled decklink  && { { check_header DeckLinkAPI.h || 
die "ERROR: DeckL
 enabled frei0r&& { check_header frei0r.h || die "ERROR: frei0r.h header 
not found"; }
 enabled gmp   && require gmp gmp.h mpz_export -lgmp
 enabled gnutls&& require_pkg_config gnutls gnutls/gnutls.h 
gnutls_global_init
-enabled jni   && { [ $target_os = "android" ] && check_header jni.h && 
enabled pthreads &&
-   check_lib jni "dlfcn.h" dlopen -ldl || die "ERROR: 
jni not found"; }
+enabled jni   && { [ $target_os = "android" ] && check_header jni.h && 
enabled pthreads || die "ERROR: jni not found"; }
 enabled ladspa&& { check_header ladspa.h || die "ERROR: ladspa.h header 
not found"; }
 enabled libiec61883   && require libiec61883 libiec61883/iec61883.h 
iec61883_cmp_connect -lraw1394 -lavc1394 -lrom1394 -liec61883
 enabled libass&& require_pkg_config libass ass/ass.h 
ass_library_init



LGTM--I see that the use of dl was eliminated in 33d69a9 (at 
https://github.com/FFmpeg/FFmpeg/commit/33d69a90085d30af8a292d9364b835a26565d6b9 
).


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


Re: [FFmpeg-devel] [PATCH] avcodec/xpmdec: Fix multiple pointer/memory issues

2017-05-12 Thread Paul B Mahol
On 5/12/17, Paul B Mahol  wrote:
> On 5/12/17, Michael Niedermayer  wrote:
>> On Fri, May 12, 2017 at 03:29:52PM +0200, Paul B Mahol wrote:
>>> On 5/12/17, Michael Niedermayer  wrote:
>>> > On Thu, May 11, 2017 at 11:17:33AM +0200, Michael Niedermayer wrote:
>>> >> On Thu, May 11, 2017 at 09:01:57AM +0200, Paul B Mahol wrote:
>>> >> > On 5/11/17, Michael Niedermayer  wrote:
>>> >> > > Most of these were found through code review in response to
>>> >> > > fixing 1466/clusterfuzz-testcase-minimized-5961584419536896
>>> >> > > There is thus no testcase for most of this.
>>> >> > > The initial issue was Found-by: continuous fuzzing process
>>> >> > > https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
>>> >> > >
>>> >> > > Signed-off-by: Michael Niedermayer 
>>> >> > > ---
>>> >> > >  libavcodec/xpmdec.c | 37 ++---
>>> >> > >  1 file changed, 30 insertions(+), 7 deletions(-)
>>> >> > >
>>> >> > > diff --git a/libavcodec/xpmdec.c b/libavcodec/xpmdec.c
>>> >> > > index 9112d4cb5e..03172e4aad 100644
>>> >> > > --- a/libavcodec/xpmdec.c
>>> >> > > +++ b/libavcodec/xpmdec.c
>>> >> > > @@ -29,6 +29,8 @@
>>> >> > >  typedef struct XPMContext {
>>> >> > >  uint32_t  *pixels;
>>> >> > >  intpixels_size;
>>> >> > > +uint8_t   *buf;
>>> >> > > +intbuf_size;
>>> >> > >  } XPMDecContext;
>>> >> > >
>>> >> > >  typedef struct ColorEntry {
>>> >> > > @@ -233,6 +235,8 @@ static uint32_t color_string_to_rgba(const
>>> >> > > char
>>> >> > > *p, int
>>> >> > > len)
>>> >> > >  const ColorEntry *entry;
>>> >> > >  char color_name[100];
>>> >> > >
>>> >> > > +len = FFMIN(FFMAX(len, 0), sizeof(color_name) - 1);
>>> >> > > +
>>> >> > >  if (*p == '#') {
>>> >> > >  p++;
>>> >> > >  len--;
>>> >> > > @@ -299,18 +303,25 @@ static int xpm_decode_frame(AVCodecContext
>>> >> > > *avctx,
>>> >> > > void *data,
>>> >> > >  {
>>> >> > >  XPMDecContext *x = avctx->priv_data;
>>> >> > >  AVFrame *p=data;
>>> >> > > -const uint8_t *end, *ptr = avpkt->data;
>>> >> > > +const uint8_t *end, *ptr;
>>> >> > >  int ncolors, cpp, ret, i, j;
>>> >> > >  int64_t size;
>>> >> > >  uint32_t *dst;
>>> >> > >
>>> >> > >  avctx->pix_fmt = AV_PIX_FMT_BGRA;
>>> >> > >
>>> >> > > -end = avpkt->data + avpkt->size;
>>> >> > > -while (memcmp(ptr, "/* XPM */", 9) && ptr < end - 9)
>>> >> > > +av_fast_padded_malloc(&x->buf, &x->buf_size, avpkt->size);
>>> >> > > +if (!x->buf)
>>> >> > > +return AVERROR(ENOMEM);
>>> >> > > +memcpy(x->buf, avpkt->data, avpkt->size);
>>> >> > > +x->buf[avpkt->size] = 0;
>>> >> > > +
>>> >> > > +ptr = x->buf;
>>> >> > > +end = x->buf + avpkt->size;
>>> >> > > +while (end - ptr > 9 && memcmp(ptr, "/* XPM */", 9))
>>> >> > >  ptr++;
>>> >> > >
>>> >> > > -if (ptr >= end) {
>>> >> > > +if (end - ptr <= 9) {
>>> >> > >  av_log(avctx, AV_LOG_ERROR, "missing signature\n");
>>> >> > >  return AVERROR_INVALIDDATA;
>>> >> > >  }
>>> >> > > @@ -335,7 +346,7 @@ static int xpm_decode_frame(AVCodecContext
>>> >> > > *avctx,
>>> >> > > void
>>> >> > > *data,
>>> >> > >
>>> >> > >  size = 1;
>>> >> > >  for (i = 0; i < cpp; i++)
>>> >> > > -size *= 94;
>>> >> > > +size *= 95;
>>> >> > >
>>> >> > >  if (ncolors <= 0 || ncolors > size) {
>>> >> > >  av_log(avctx, AV_LOG_ERROR, "invalid number of colors:
>>> >> > > %d\n",
>>> >> > > ncolors);
>>> >> > > @@ -349,12 +360,15 @@ static int xpm_decode_frame(AVCodecContext
>>> >> > > *avctx,
>>> >> > > void *data,
>>> >> > >  return AVERROR(ENOMEM);
>>> >> > >
>>> >> > >  ptr += mod_strcspn(ptr, ",") + 1;
>>> >> > > +if (end - ptr < 1)
>>> >> > > +return AVERROR_INVALIDDATA;
>>> >> > > +
>>> >> > >  for (i = 0; i < ncolors; i++) {
>>> >> > >  const uint8_t *index;
>>> >> > >  int len;
>>> >> > >
>>> >> > >  ptr += mod_strcspn(ptr, "\"") + 1;
>>> >> > > -if (ptr + cpp > end)
>>> >> > > +if (end - ptr < cpp)
>>> >> > >  return AVERROR_INVALIDDATA;
>>> >> > >  index = ptr;
>>> >> > >  ptr += cpp;
>>> >> > > @@ -373,14 +387,20 @@ static int xpm_decode_frame(AVCodecContext
>>> >> > > *avctx,
>>> >> > > void *data,
>>> >> > >
>>> >> > >  x->pixels[ret] = color_string_to_rgba(ptr, len);
>>> >> > >  ptr += mod_strcspn(ptr, ",") + 1;
>>> >> > > +if (end - ptr < 1)
>>> >> > > +return AVERROR_INVALIDDATA;
>>> >> > >  }
>>> >> > >
>>> >> > >  for (i = 0; i < avctx->height; i++) {
>>> >> > >  dst = (uint32_t *)(p->data[0] + i * p->linesize[0]);
>>> >> > > +if (end - ptr < 1)
>>> >> > > +return AVERROR_INVALIDDATA;
>>> >> > >  ptr += mod_strcspn(ptr, "\"") + 1;
>>> >> > > +if (end - ptr < 1)
>>> >> > > +return AVERROR_INVALIDDATA;
>>> >> > >
>>> >> > >  for (j = 0; j < avc

Re: [FFmpeg-devel] Patch libavformat/aviobuf.c fixes data loss on named pipe reads

2017-05-12 Thread Rob Meyers
Attaching the output of "git diff -p".

On Fri, May 12, 2017 at 11:50 AM Michael Niedermayer 
wrote:

> On Fri, May 12, 2017 at 06:31:19PM +, Rob Meyers wrote:
> > Submitting a patch to fix a bug in ffmpeg found when reading data from a
> > named pipe. In our test, a pipe sending twelve bytes in two 6 byte
> messages
> > results in the first 10 bytes being lost. We found the problem was
> > introduced with this commit (2ca48e466675a8a3630061cd2c15325eab8eda97) on
> > June 30, 2013. In this code, the "dst" pointer is always set to
> s->buffer,
> > and earlier message bytes are overwritten by later ones when assembling a
> > packet from multiple small reads.
> >
> Patch is corrupted by linebreaks
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Let us carefully observe those good qualities wherein our enemies excel us
> and endeavor to excel them, by avoiding what is faulty, and imitating what
> is excellent in them. -- Plutarch
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
index 0a7c39eacd..4e04cb79e0 100644
--- a/libavformat/aviobuf.c
+++ b/libavformat/aviobuf.c
@@ -519,9 +519,7 @@ void avio_write_marker(AVIOContext *s, int64_t time, enum AVIODataMarkerType typ
 
 static void fill_buffer(AVIOContext *s)
 {
-int max_buffer_size = s->max_packet_size ?
-  s->max_packet_size : IO_BUFFER_SIZE;
-uint8_t *dst= s->buf_end - s->buffer + max_buffer_size < s->buffer_size ?
+uint8_t *dst= !s->max_packet_size && s->buf_end - s->buffer < s->buffer_size ?
   s->buf_end : s->buffer;
 int len = s->buffer_size - (dst - s->buffer);
 
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] avcodec/xpmdec: Fix multiple pointer/memory issues

2017-05-12 Thread Paul B Mahol
On 5/12/17, Michael Niedermayer  wrote:
> On Fri, May 12, 2017 at 03:29:52PM +0200, Paul B Mahol wrote:
>> On 5/12/17, Michael Niedermayer  wrote:
>> > On Thu, May 11, 2017 at 11:17:33AM +0200, Michael Niedermayer wrote:
>> >> On Thu, May 11, 2017 at 09:01:57AM +0200, Paul B Mahol wrote:
>> >> > On 5/11/17, Michael Niedermayer  wrote:
>> >> > > Most of these were found through code review in response to
>> >> > > fixing 1466/clusterfuzz-testcase-minimized-5961584419536896
>> >> > > There is thus no testcase for most of this.
>> >> > > The initial issue was Found-by: continuous fuzzing process
>> >> > > https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
>> >> > >
>> >> > > Signed-off-by: Michael Niedermayer 
>> >> > > ---
>> >> > >  libavcodec/xpmdec.c | 37 ++---
>> >> > >  1 file changed, 30 insertions(+), 7 deletions(-)
>> >> > >
>> >> > > diff --git a/libavcodec/xpmdec.c b/libavcodec/xpmdec.c
>> >> > > index 9112d4cb5e..03172e4aad 100644
>> >> > > --- a/libavcodec/xpmdec.c
>> >> > > +++ b/libavcodec/xpmdec.c
>> >> > > @@ -29,6 +29,8 @@
>> >> > >  typedef struct XPMContext {
>> >> > >  uint32_t  *pixels;
>> >> > >  intpixels_size;
>> >> > > +uint8_t   *buf;
>> >> > > +intbuf_size;
>> >> > >  } XPMDecContext;
>> >> > >
>> >> > >  typedef struct ColorEntry {
>> >> > > @@ -233,6 +235,8 @@ static uint32_t color_string_to_rgba(const
>> >> > > char
>> >> > > *p, int
>> >> > > len)
>> >> > >  const ColorEntry *entry;
>> >> > >  char color_name[100];
>> >> > >
>> >> > > +len = FFMIN(FFMAX(len, 0), sizeof(color_name) - 1);
>> >> > > +
>> >> > >  if (*p == '#') {
>> >> > >  p++;
>> >> > >  len--;
>> >> > > @@ -299,18 +303,25 @@ static int xpm_decode_frame(AVCodecContext
>> >> > > *avctx,
>> >> > > void *data,
>> >> > >  {
>> >> > >  XPMDecContext *x = avctx->priv_data;
>> >> > >  AVFrame *p=data;
>> >> > > -const uint8_t *end, *ptr = avpkt->data;
>> >> > > +const uint8_t *end, *ptr;
>> >> > >  int ncolors, cpp, ret, i, j;
>> >> > >  int64_t size;
>> >> > >  uint32_t *dst;
>> >> > >
>> >> > >  avctx->pix_fmt = AV_PIX_FMT_BGRA;
>> >> > >
>> >> > > -end = avpkt->data + avpkt->size;
>> >> > > -while (memcmp(ptr, "/* XPM */", 9) && ptr < end - 9)
>> >> > > +av_fast_padded_malloc(&x->buf, &x->buf_size, avpkt->size);
>> >> > > +if (!x->buf)
>> >> > > +return AVERROR(ENOMEM);
>> >> > > +memcpy(x->buf, avpkt->data, avpkt->size);
>> >> > > +x->buf[avpkt->size] = 0;
>> >> > > +
>> >> > > +ptr = x->buf;
>> >> > > +end = x->buf + avpkt->size;
>> >> > > +while (end - ptr > 9 && memcmp(ptr, "/* XPM */", 9))
>> >> > >  ptr++;
>> >> > >
>> >> > > -if (ptr >= end) {
>> >> > > +if (end - ptr <= 9) {
>> >> > >  av_log(avctx, AV_LOG_ERROR, "missing signature\n");
>> >> > >  return AVERROR_INVALIDDATA;
>> >> > >  }
>> >> > > @@ -335,7 +346,7 @@ static int xpm_decode_frame(AVCodecContext
>> >> > > *avctx,
>> >> > > void
>> >> > > *data,
>> >> > >
>> >> > >  size = 1;
>> >> > >  for (i = 0; i < cpp; i++)
>> >> > > -size *= 94;
>> >> > > +size *= 95;
>> >> > >
>> >> > >  if (ncolors <= 0 || ncolors > size) {
>> >> > >  av_log(avctx, AV_LOG_ERROR, "invalid number of colors:
>> >> > > %d\n",
>> >> > > ncolors);
>> >> > > @@ -349,12 +360,15 @@ static int xpm_decode_frame(AVCodecContext
>> >> > > *avctx,
>> >> > > void *data,
>> >> > >  return AVERROR(ENOMEM);
>> >> > >
>> >> > >  ptr += mod_strcspn(ptr, ",") + 1;
>> >> > > +if (end - ptr < 1)
>> >> > > +return AVERROR_INVALIDDATA;
>> >> > > +
>> >> > >  for (i = 0; i < ncolors; i++) {
>> >> > >  const uint8_t *index;
>> >> > >  int len;
>> >> > >
>> >> > >  ptr += mod_strcspn(ptr, "\"") + 1;
>> >> > > -if (ptr + cpp > end)
>> >> > > +if (end - ptr < cpp)
>> >> > >  return AVERROR_INVALIDDATA;
>> >> > >  index = ptr;
>> >> > >  ptr += cpp;
>> >> > > @@ -373,14 +387,20 @@ static int xpm_decode_frame(AVCodecContext
>> >> > > *avctx,
>> >> > > void *data,
>> >> > >
>> >> > >  x->pixels[ret] = color_string_to_rgba(ptr, len);
>> >> > >  ptr += mod_strcspn(ptr, ",") + 1;
>> >> > > +if (end - ptr < 1)
>> >> > > +return AVERROR_INVALIDDATA;
>> >> > >  }
>> >> > >
>> >> > >  for (i = 0; i < avctx->height; i++) {
>> >> > >  dst = (uint32_t *)(p->data[0] + i * p->linesize[0]);
>> >> > > +if (end - ptr < 1)
>> >> > > +return AVERROR_INVALIDDATA;
>> >> > >  ptr += mod_strcspn(ptr, "\"") + 1;
>> >> > > +if (end - ptr < 1)
>> >> > > +return AVERROR_INVALIDDATA;
>> >> > >
>> >> > >  for (j = 0; j < avctx->width; j++) {
>> >> > > -if (ptr + cpp > end)
>> >> > > +if (end - ptr < cpp)
>> >> > >  return AVERROR_INVALIDDATA;

Re: [FFmpeg-devel] [PATCH] avcodec/xpmdec: Fix multiple pointer/memory issues

2017-05-12 Thread Michael Niedermayer
On Fri, May 12, 2017 at 03:29:52PM +0200, Paul B Mahol wrote:
> On 5/12/17, Michael Niedermayer  wrote:
> > On Thu, May 11, 2017 at 11:17:33AM +0200, Michael Niedermayer wrote:
> >> On Thu, May 11, 2017 at 09:01:57AM +0200, Paul B Mahol wrote:
> >> > On 5/11/17, Michael Niedermayer  wrote:
> >> > > Most of these were found through code review in response to
> >> > > fixing 1466/clusterfuzz-testcase-minimized-5961584419536896
> >> > > There is thus no testcase for most of this.
> >> > > The initial issue was Found-by: continuous fuzzing process
> >> > > https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
> >> > >
> >> > > Signed-off-by: Michael Niedermayer 
> >> > > ---
> >> > >  libavcodec/xpmdec.c | 37 ++---
> >> > >  1 file changed, 30 insertions(+), 7 deletions(-)
> >> > >
> >> > > diff --git a/libavcodec/xpmdec.c b/libavcodec/xpmdec.c
> >> > > index 9112d4cb5e..03172e4aad 100644
> >> > > --- a/libavcodec/xpmdec.c
> >> > > +++ b/libavcodec/xpmdec.c
> >> > > @@ -29,6 +29,8 @@
> >> > >  typedef struct XPMContext {
> >> > >  uint32_t  *pixels;
> >> > >  intpixels_size;
> >> > > +uint8_t   *buf;
> >> > > +intbuf_size;
> >> > >  } XPMDecContext;
> >> > >
> >> > >  typedef struct ColorEntry {
> >> > > @@ -233,6 +235,8 @@ static uint32_t color_string_to_rgba(const char
> >> > > *p, int
> >> > > len)
> >> > >  const ColorEntry *entry;
> >> > >  char color_name[100];
> >> > >
> >> > > +len = FFMIN(FFMAX(len, 0), sizeof(color_name) - 1);
> >> > > +
> >> > >  if (*p == '#') {
> >> > >  p++;
> >> > >  len--;
> >> > > @@ -299,18 +303,25 @@ static int xpm_decode_frame(AVCodecContext
> >> > > *avctx,
> >> > > void *data,
> >> > >  {
> >> > >  XPMDecContext *x = avctx->priv_data;
> >> > >  AVFrame *p=data;
> >> > > -const uint8_t *end, *ptr = avpkt->data;
> >> > > +const uint8_t *end, *ptr;
> >> > >  int ncolors, cpp, ret, i, j;
> >> > >  int64_t size;
> >> > >  uint32_t *dst;
> >> > >
> >> > >  avctx->pix_fmt = AV_PIX_FMT_BGRA;
> >> > >
> >> > > -end = avpkt->data + avpkt->size;
> >> > > -while (memcmp(ptr, "/* XPM */", 9) && ptr < end - 9)
> >> > > +av_fast_padded_malloc(&x->buf, &x->buf_size, avpkt->size);
> >> > > +if (!x->buf)
> >> > > +return AVERROR(ENOMEM);
> >> > > +memcpy(x->buf, avpkt->data, avpkt->size);
> >> > > +x->buf[avpkt->size] = 0;
> >> > > +
> >> > > +ptr = x->buf;
> >> > > +end = x->buf + avpkt->size;
> >> > > +while (end - ptr > 9 && memcmp(ptr, "/* XPM */", 9))
> >> > >  ptr++;
> >> > >
> >> > > -if (ptr >= end) {
> >> > > +if (end - ptr <= 9) {
> >> > >  av_log(avctx, AV_LOG_ERROR, "missing signature\n");
> >> > >  return AVERROR_INVALIDDATA;
> >> > >  }
> >> > > @@ -335,7 +346,7 @@ static int xpm_decode_frame(AVCodecContext *avctx,
> >> > > void
> >> > > *data,
> >> > >
> >> > >  size = 1;
> >> > >  for (i = 0; i < cpp; i++)
> >> > > -size *= 94;
> >> > > +size *= 95;
> >> > >
> >> > >  if (ncolors <= 0 || ncolors > size) {
> >> > >  av_log(avctx, AV_LOG_ERROR, "invalid number of colors:
> >> > > %d\n",
> >> > > ncolors);
> >> > > @@ -349,12 +360,15 @@ static int xpm_decode_frame(AVCodecContext
> >> > > *avctx,
> >> > > void *data,
> >> > >  return AVERROR(ENOMEM);
> >> > >
> >> > >  ptr += mod_strcspn(ptr, ",") + 1;
> >> > > +if (end - ptr < 1)
> >> > > +return AVERROR_INVALIDDATA;
> >> > > +
> >> > >  for (i = 0; i < ncolors; i++) {
> >> > >  const uint8_t *index;
> >> > >  int len;
> >> > >
> >> > >  ptr += mod_strcspn(ptr, "\"") + 1;
> >> > > -if (ptr + cpp > end)
> >> > > +if (end - ptr < cpp)
> >> > >  return AVERROR_INVALIDDATA;
> >> > >  index = ptr;
> >> > >  ptr += cpp;
> >> > > @@ -373,14 +387,20 @@ static int xpm_decode_frame(AVCodecContext
> >> > > *avctx,
> >> > > void *data,
> >> > >
> >> > >  x->pixels[ret] = color_string_to_rgba(ptr, len);
> >> > >  ptr += mod_strcspn(ptr, ",") + 1;
> >> > > +if (end - ptr < 1)
> >> > > +return AVERROR_INVALIDDATA;
> >> > >  }
> >> > >
> >> > >  for (i = 0; i < avctx->height; i++) {
> >> > >  dst = (uint32_t *)(p->data[0] + i * p->linesize[0]);
> >> > > +if (end - ptr < 1)
> >> > > +return AVERROR_INVALIDDATA;
> >> > >  ptr += mod_strcspn(ptr, "\"") + 1;
> >> > > +if (end - ptr < 1)
> >> > > +return AVERROR_INVALIDDATA;
> >> > >
> >> > >  for (j = 0; j < avctx->width; j++) {
> >> > > -if (ptr + cpp > end)
> >> > > +if (end - ptr < cpp)
> >> > >  return AVERROR_INVALIDDATA;
> >> > >
> >> > >  if ((ret = ascii2index(ptr, cpp)) < 0)
> >> > > @@ -405,6 +425,9 @@ static av_cold int
> >> > > xpm_decode_close(AVCodecContext
> >> > > *avctx)
> >> > >  

Re: [FFmpeg-devel] Patch libavformat/aviobuf.c fixes data loss on named pipe reads

2017-05-12 Thread Michael Niedermayer
On Fri, May 12, 2017 at 06:31:19PM +, Rob Meyers wrote:
> Submitting a patch to fix a bug in ffmpeg found when reading data from a
> named pipe. In our test, a pipe sending twelve bytes in two 6 byte messages
> results in the first 10 bytes being lost. We found the problem was
> introduced with this commit (2ca48e466675a8a3630061cd2c15325eab8eda97) on
> June 30, 2013. In this code, the "dst" pointer is always set to s->buffer,
> and earlier message bytes are overwritten by later ones when assembling a
> packet from multiple small reads.
> 
> 
> diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
> index 0a7c39eacd..4e04cb79e0 100644
> --- a/libavformat/aviobuf.c
> +++ b/libavformat/aviobuf.c
> @@ -519,9 +519,7 @@ void avio_write_marker(AVIOContext *s, int64_t time,
> enum AVIODataMarkerType typ
> 
>  static void fill_buffer(AVIOContext *s)
>  {
> -int max_buffer_size = s->max_packet_size ?
> -  s->max_packet_size : IO_BUFFER_SIZE;
> -uint8_t *dst= s->buf_end - s->buffer + max_buffer_size <
> s->buffer_size ?
> +uint8_t *dst= !s->max_packet_size && s->buf_end - s->buffer <
> s->buffer_size ?

Patch is corrupted by linebreaks

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 1/3] configure: add cuda-sdk for things requiring full CUDA sdk

2017-05-12 Thread Michael Niedermayer
On Thu, May 11, 2017 at 10:59:19PM +0200, Timo Rothenpieler wrote:
> ---
>  configure | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)

This doesnt apply so i cant test this or dependant patches

Applying: configure: add cuda-sdk for things requiring full CUDA sdk
error: sha1 information is lacking or useless (configure).
error: could not build fake ancestor
Patch failed at 0001 configure: add cuda-sdk for things requiring full CUDA sdk
The copy of the patch that failed is found in: .git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".


[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH] configure: jni no longer requires -ldl

2017-05-12 Thread Aman Gupta
From: Aman Gupta 

this dependency was removed in 33d69a90085d30af8a292d9364b835a26565d6b9
---
 configure | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/configure b/configure
index 5ae5227868..ba33241a45 100755
--- a/configure
+++ b/configure
@@ -5766,8 +5766,7 @@ enabled decklink  && { { check_header 
DeckLinkAPI.h || die "ERROR: DeckL
 enabled frei0r&& { check_header frei0r.h || die "ERROR: frei0r.h 
header not found"; }
 enabled gmp   && require gmp gmp.h mpz_export -lgmp
 enabled gnutls&& require_pkg_config gnutls gnutls/gnutls.h 
gnutls_global_init
-enabled jni   && { [ $target_os = "android" ] && check_header 
jni.h && enabled pthreads &&
-   check_lib jni "dlfcn.h" dlopen -ldl || die 
"ERROR: jni not found"; }
+enabled jni   && { [ $target_os = "android" ] && check_header 
jni.h && enabled pthreads || die "ERROR: jni not found"; }
 enabled ladspa&& { check_header ladspa.h || die "ERROR: ladspa.h 
header not found"; }
 enabled libiec61883   && require libiec61883 libiec61883/iec61883.h 
iec61883_cmp_connect -lraw1394 -lavc1394 -lrom1394 -liec61883
 enabled libass&& require_pkg_config libass ass/ass.h 
ass_library_init
-- 
2.11.0 (Apple Git-81)

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


[FFmpeg-devel] Patch libavformat/aviobuf.c fixes data loss on named pipe reads

2017-05-12 Thread Rob Meyers
Submitting a patch to fix a bug in ffmpeg found when reading data from a
named pipe. In our test, a pipe sending twelve bytes in two 6 byte messages
results in the first 10 bytes being lost. We found the problem was
introduced with this commit (2ca48e466675a8a3630061cd2c15325eab8eda97) on
June 30, 2013. In this code, the "dst" pointer is always set to s->buffer,
and earlier message bytes are overwritten by later ones when assembling a
packet from multiple small reads.


diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
index 0a7c39eacd..4e04cb79e0 100644
--- a/libavformat/aviobuf.c
+++ b/libavformat/aviobuf.c
@@ -519,9 +519,7 @@ void avio_write_marker(AVIOContext *s, int64_t time,
enum AVIODataMarkerType typ

 static void fill_buffer(AVIOContext *s)
 {
-int max_buffer_size = s->max_packet_size ?
-  s->max_packet_size : IO_BUFFER_SIZE;
-uint8_t *dst= s->buf_end - s->buffer + max_buffer_size <
s->buffer_size ?
+uint8_t *dst= !s->max_packet_size && s->buf_end - s->buffer <
s->buffer_size ?
   s->buf_end : s->buffer;
 int len = s->buffer_size - (dst - s->buffer);
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 1/3] configure: add cuda-sdk for things requiring full CUDA sdk

2017-05-12 Thread Timo Rothenpieler

Am 12.05.2017 um 15:34 schrieb James Almer:

On 5/12/2017 5:21 AM, Timo Rothenpieler wrote:

Am 12.05.2017 um 07:32 schrieb Yogender Gupta:

+cuda_sdk
 libnpp


IMO, Libnpp is part of the CUDA SDK, and we can remove all the libnpp related 
changes and just replace it by cuda-sdk in the configure/make files.


True, but I'm not sure if an existing config parameter can be that
easily removed without breaking a bunch of existing build scripts.


You can keep the option marked as deprecated for a while, while removing
all the relevant internals and making it an alias for cuda_sdk.


Thinking about it, I'd rather keep libnpp separate, as --enable-cuda-sdk 
still results in an ffmpeg binary that only depends on stuff the 
nvidia-driver ships with, while for a build with libnpp it depends on 
some libs that only come with the CUDA SDK.

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


Re: [FFmpeg-devel] [PATCH 6/7] lavf/flacenc: avoid buffer overread with unexpected extradata sizes

2017-05-12 Thread James Almer
On 5/8/2017 1:36 AM, Rodger Combs wrote:
> ---
>  libavformat/flacenc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavformat/flacenc.c b/libavformat/flacenc.c
> index 9bb4947..b8800cc 100644
> --- a/libavformat/flacenc.c
> +++ b/libavformat/flacenc.c
> @@ -315,7 +315,7 @@ static int flac_write_trailer(struct AVFormatContext *s)
>  if (!c->write_header || !streaminfo)
>  return 0;
>  
> -if (pb->seekable & AVIO_SEEKABLE_NORMAL) {
> +if (pb->seekable & AVIO_SEEKABLE_NORMAL && (c->streaminfo || 
> s->streams[0]->codecpar->extradata_size == FLAC_STREAMINFO_SIZE)) {

Instead of this, ff_flac_write_header() in flacenc_header.c should make
sure that extradata_size is exactly FLAC_STREAMINFO_SIZE and not equal
or greater.

And for that matter, this function shouldn't bother trying to rewrite
the codecpar extradata. The point of this code here is to write the new
extradata sent as part of the last packet by the flac encoder and stored
in c->streaminfo if available, not pointlessly write the original one a
second time.

>  /* rewrite the STREAMINFO header block data */
>  file_size = avio_tell(pb);
>  avio_seek(pb, 8, SEEK_SET);
> 

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


[FFmpeg-devel] [PATCH] avfilter: don't anonymously typedef structs

2017-05-12 Thread Paul B Mahol
Signed-off-by: Paul B Mahol 
---
 libavfilter/aeval.c|  2 +-
 libavfilter/af_afade.c |  2 +-
 libavfilter/af_amerge.c|  2 +-
 libavfilter/af_apad.c  |  2 +-
 libavfilter/af_aresample.c |  2 +-
 libavfilter/af_asetnsamples.c  |  2 +-
 libavfilter/af_asetrate.c  |  2 +-
 libavfilter/af_astats.c|  2 +-
 libavfilter/af_atempo.c|  4 ++--
 libavfilter/af_earwax.c|  2 +-
 libavfilter/af_firequalizer.c  |  6 +++---
 libavfilter/af_hdcd.c  |  4 ++--
 libavfilter/af_volumedetect.c  |  2 +-
 libavfilter/asrc_anoisesrc.c   |  2 +-
 libavfilter/asrc_anullsrc.c|  2 +-
 libavfilter/asrc_flite.c   |  2 +-
 libavfilter/asrc_sine.c|  2 +-
 libavfilter/avf_concat.c   |  2 +-
 libavfilter/avf_showcqt.h  |  8 
 libavfilter/avf_showspectrum.c |  2 +-
 libavfilter/avf_showwaves.c|  2 +-
 libavfilter/bbox.h |  2 +-
 libavfilter/buffersink.h   |  4 ++--
 libavfilter/deshake.h  | 10 +-
 libavfilter/deshake_opencl.h   |  2 +-
 libavfilter/dualinput.h|  2 +-
 libavfilter/ebur128.h  |  2 +-
 libavfilter/f_bench.c  |  2 +-
 libavfilter/f_ebur128.c|  2 +-
 libavfilter/f_interleave.c |  2 +-
 libavfilter/f_perms.c  |  2 +-
 libavfilter/f_sendcmd.c|  6 +++---
 libavfilter/f_zmq.c|  4 ++--
 libavfilter/signature.h| 10 +-
 libavfilter/signature_lookup.c |  2 +-
 libavfilter/tinterlace.h   |  2 +-
 libavfilter/unsharp.h  |  2 +-
 libavfilter/vf_alphamerge.c|  2 +-
 libavfilter/vf_bbox.c  |  2 +-
 libavfilter/vf_blackdetect.c   |  2 +-
 libavfilter/vf_codecview.c |  2 +-
 libavfilter/vf_colorbalance.c  |  4 ++--
 libavfilter/vf_colorchannelmixer.c |  2 +-
 libavfilter/vf_colorlevels.c   |  4 ++--
 libavfilter/vf_colormatrix.c   |  2 +-
 libavfilter/vf_curves.c|  2 +-
 libavfilter/vf_decimate.c  |  2 +-
 libavfilter/vf_dejudder.c  |  2 +-
 libavfilter/vf_detelecine.c|  2 +-
 libavfilter/vf_edgedetect.c|  2 +-
 libavfilter/vf_eq.h|  2 +-
 libavfilter/vf_extractplanes.c |  2 +-
 libavfilter/vf_fftfilt.c   |  2 +-
 libavfilter/vf_field.c |  2 +-
 libavfilter/vf_fieldmatch.c|  2 +-
 libavfilter/vf_geq.c   |  2 +-
 libavfilter/vf_histeq.c|  2 +-
 libavfilter/vf_hqx.c   |  2 +-
 libavfilter/vf_hue.c   |  2 +-
 libavfilter/vf_idet.h  |  2 +-
 libavfilter/vf_il.c|  2 +-
 libavfilter/vf_kerndeint.c |  2 +-
 libavfilter/vf_mcdeint.c   |  2 +-
 libavfilter/vf_mpdecimate.c|  2 +-
 libavfilter/vf_nlmeans.c   |  2 +-
 libavfilter/vf_noise.h |  4 ++--
 libavfilter/vf_owdenoise.c |  2 +-
 libavfilter/vf_palettegen.c|  2 +-
 libavfilter/vf_pp.c|  2 +-
 libavfilter/vf_removelogo.c|  2 +-
 libavfilter/vf_sab.c   |  4 ++--
 libavfilter/vf_selectivecolor.c|  2 +-
 libavfilter/vf_separatefields.c|  2 +-
 libavfilter/vf_setfield.c  |  2 +-
 libavfilter/vf_showpalette.c   |  2 +-
 libavfilter/vf_signalstats.c   |  2 +-
 libavfilter/vf_smartblur.c |  4 ++--
 libavfilter/vf_spp.h   |  2 +-
 libavfilter/vf_subtitles.c |  2 +-
 libavfilter/vf_super2xsai.c|  2 +-
 libavfilter/vf_telecine.c  |  2 +-
 libavfilter/vf_thumbnail.c |  2 +-
 libavfilter/vf_tile.c  |  2 +-
 libavfilter/vf_uspp.c  |  2 +-
 libavfilter/vf_vidstabdetect.c |  2 +-
 libavfilter/vf_vidstabtransform.c  |  2 +-
 libavfilter/vf_vignette.c  |  2 +-
 libavfilter/vf_xbr.c   |  2 +-
 libavfilter/vidstabutils.c |  2 +-
 libavfilter/vsrc_cellauto.c|  2 +-
 libavfilter/vsrc_life.c|  2 +-
 libavfilter/vsrc_mandelbrot.c  |  2 +-
 92 files changed, 116 insertions(+), 116 deletions(-)

diff --git a/libavfilter/aeval.c b/libavfilter/aeval.c
index 42970f4..faf4835 100644
--- a/libavfilter/aeval.c
+++ b/libavfilter/aeval.c
@@ -53,7 +53,7 @@ enum var_name {
 VAR_VARS_NB
 };
 
-typedef struct {
+typedef struct EvalContext {
 const AVClass *class;
 char *sample_rate_str;
 int sample_rate;
diff --git a/libavfilter/af_afade.c b/libavfilter/af_afade.c
index 3a6266f..ba7a2ab 100644
--- a/libavfilter/af_afade.c
+++ b/libavfilter/af_afade.c
@@ -29,7 +29,7 @@
 #include "avfilter.h"
 #include "internal.h"
 
-typedef struct {
+typedef struct AudioFadeContext {
 const AVClass *class;
 int type;
 int curve, curve2;
diff --git a/libavfilter/af_amerge.c b/libavfilter/af_amerge.c
index 3cf36b3..cc974cd 100644
--- a/libavfilter/af_amerge.c
+++ b/libavfilter/af_amerge.c
@@ -37,7

Re: [FFmpeg-devel] [PATCH 5/7] lavf/flacenc: support writing attached pictures

2017-05-12 Thread James Almer
On 5/8/2017 1:36 AM, Rodger Combs wrote:
> ---
>  libavformat/flacenc.c | 271 
> +++---
>  1 file changed, 236 insertions(+), 35 deletions(-)
> 
> diff --git a/libavformat/flacenc.c b/libavformat/flacenc.c
> index b894f9e..9bb4947 100644
> --- a/libavformat/flacenc.c
> +++ b/libavformat/flacenc.c
> @@ -21,10 +21,13 @@
>  
>  #include "libavutil/channel_layout.h"
>  #include "libavutil/opt.h"
> +#include "libavutil/pixdesc.h"
>  #include "libavcodec/flac.h"
>  #include "avformat.h"
>  #include "avio_internal.h"
>  #include "flacenc.h"
> +#include "id3v2.h"
> +#include "internal.h"
>  #include "vorbiscomment.h"
>  #include "libavcodec/bytestream.h"
>  
> @@ -33,8 +36,16 @@ typedef struct FlacMuxerContext {
>  const AVClass *class;
>  int write_header;
>  
> +int audio_stream_idx;
> +AVPacket *pics;
> +int nb_pics, waiting_pics;
> +/* audio packets are queued here until we get all the attached pictures 
> */
> +AVPacketList *queue, *queue_end;
> +
>  /* updated streaminfo sent by the encoder at the end */
>  uint8_t *streaminfo;
> +
> +unsigned attached_types;
>  } FlacMuxerContext;
>  
>  static int flac_write_block_padding(AVIOContext *pb, unsigned int 
> n_padding_bytes,
> @@ -74,31 +85,149 @@ static int flac_write_block_comment(AVIOContext *pb, 
> AVDictionary **m,
>  return 0;
>  }
>  
> -static int flac_write_header(struct AVFormatContext *s)
> +static int flac_write_picture(struct AVFormatContext *s, AVPacket *pkt)
>  {
> -int ret;
> -int padding = s->metadata_header_padding;
> -AVCodecParameters *par = s->streams[0]->codecpar;
> -FlacMuxerContext *c   = s->priv_data;
> -
> -if (!c->write_header)
> +FlacMuxerContext *c = s->priv_data;
> +AVIOContext *pb = s->pb;
> +const AVPixFmtDescriptor *pixdesc;
> +const CodecMime *mime = ff_id3v2_mime_tags;
> +AVDictionaryEntry *e;
> +const char *mimetype = NULL, *desc = "";
> +const AVStream *st = s->streams[pkt->stream_index];
> +int i, mimelen, desclen, type = 0;
> +
> +if (!pkt->data)
>  return 0;
>  
> -if (s->nb_streams > 1) {
> -av_log(s, AV_LOG_ERROR, "only one stream is supported\n");
> +while (mime->id != AV_CODEC_ID_NONE) {
> +if (mime->id == st->codecpar->codec_id) {
> +mimetype = mime->str;
> +break;
> +}
> +mime++;
> +}
> +if (!mimetype) {
> +av_log(s, AV_LOG_ERROR, "No mimetype is known for stream %d, cannot "
> +   "write an attached picture.\n", st->index);
>  return AVERROR(EINVAL);
>  }
> -if (par->codec_id != AV_CODEC_ID_FLAC) {
> -av_log(s, AV_LOG_ERROR, "unsupported codec\n");
> +mimelen = strlen(mimetype);
> +
> +/* get the picture type */
> +e = av_dict_get(st->metadata, "comment", NULL, 0);
> +for (i = 0; e && i < FF_ARRAY_ELEMS(ff_id3v2_picture_types); i++) {
> +if (!av_strcasecmp(e->value, ff_id3v2_picture_types[i])) {
> +type = i;
> +break;
> +}
> +}
> +
> +if (c->attached_types & (1 << type)) {
> +av_log(s, AV_LOG_ERROR, "Duplicate attachment for type '%s'\n", 
> ff_id3v2_picture_types[type]);
>  return AVERROR(EINVAL);
>  }
>  
> +c->attached_types |= (1 << type);
> +
> +/* get the description */
> +if ((e = av_dict_get(st->metadata, "title", NULL, 0)))
> +desc = e->value;
> +desclen = strlen(desc);
> +
> +avio_w8(pb, 0x06);
> +avio_wb24(pb, 4 + 4 + mimelen + 4 + desclen + 4 + 4 + 4 + 4 + 4 + 
> pkt->size);
> +
> +avio_wb32(pb, type);
> +
> +avio_wb32(pb, mimelen);
> +avio_write(pb, mimetype, mimelen);
> +
> +avio_wb32(pb, desclen);
> +avio_write(pb, desc, desclen);
> +
> +avio_wb32(pb, st->codecpar->width);
> +avio_wb32(pb, st->codecpar->height);
> +if ((pixdesc = av_pix_fmt_desc_get(st->codecpar->format)))
> +avio_wb32(pb, av_get_bits_per_pixel(pixdesc));
> +else
> +avio_wb32(pb, 0);
> +avio_wb32(pb, 0);
> +
> +avio_wb32(pb, pkt->size);
> +avio_write(pb, pkt->data, pkt->size);
> +return 0;
> +}
> +
> +static int flac_finish_header(struct AVFormatContext *s)
> +{
> +FlacMuxerContext *c = s->priv_data;
> +int i, ret, padding = s->metadata_header_padding;
>  if (padding < 0)
>  padding = 8192;
>  /* The FLAC specification states that 24 bits are used to represent the
>   * size of a metadata block so we must clip this value to 2^24-1. */
>  padding = av_clip_uintp2(padding, 24);
>  
> +for (i = 0; i < c->nb_pics; i++) {
> +ret = flac_write_picture(s, &c->pics[i]);
> +if (ret)
> +return ret;
> +}
> +
> +ret = flac_write_block_comment(s->pb, &s->metadata, !padding,
> +   s->flags & AVFMT_FLAG_BITEXACT);
> +if (ret)
> +return ret;
> +
> +/* The command line flac encoder default

Re: [FFmpeg-devel] [PATCH 5/7] lavf/flacenc: support writing attached pictures

2017-05-12 Thread Rostislav Pehlivanov
On 8 May 2017 at 05:36, Rodger Combs  wrote:

> ---
>  libavformat/flacenc.c | 271 ++
> +---
>  1 file changed, 236 insertions(+), 35 deletions(-)
>
> diff --git a/libavformat/flacenc.c b/libavformat/flacenc.c
> index b894f9e..9bb4947 100644
> --- a/libavformat/flacenc.c
> +++ b/libavformat/flacenc.c
> @@ -21,10 +21,13 @@
>
>  #include "libavutil/channel_layout.h"
>  #include "libavutil/opt.h"
> +#include "libavutil/pixdesc.h"
>  #include "libavcodec/flac.h"
>  #include "avformat.h"
>  #include "avio_internal.h"
>  #include "flacenc.h"
> +#include "id3v2.h"
> +#include "internal.h"
>  #include "vorbiscomment.h"
>  #include "libavcodec/bytestream.h"
>
> @@ -33,8 +36,16 @@ typedef struct FlacMuxerContext {
>  const AVClass *class;
>  int write_header;
>
> +int audio_stream_idx;
> +AVPacket *pics;
> +int nb_pics, waiting_pics;
> +/* audio packets are queued here until we get all the attached
> pictures */
> +AVPacketList *queue, *queue_end;
> +
>  /* updated streaminfo sent by the encoder at the end */
>  uint8_t *streaminfo;
> +
> +unsigned attached_types;
>  } FlacMuxerContext;
>
>  static int flac_write_block_padding(AVIOContext *pb, unsigned int
> n_padding_bytes,
> @@ -74,31 +85,149 @@ static int flac_write_block_comment(AVIOContext *pb,
> AVDictionary **m,
>  return 0;
>  }
>
> -static int flac_write_header(struct AVFormatContext *s)
> +static int flac_write_picture(struct AVFormatContext *s, AVPacket *pkt)
>  {
> -int ret;
> -int padding = s->metadata_header_padding;
> -AVCodecParameters *par = s->streams[0]->codecpar;
> -FlacMuxerContext *c   = s->priv_data;
> -
> -if (!c->write_header)
> +FlacMuxerContext *c = s->priv_data;
> +AVIOContext *pb = s->pb;
> +const AVPixFmtDescriptor *pixdesc;
> +const CodecMime *mime = ff_id3v2_mime_tags;
> +AVDictionaryEntry *e;
> +const char *mimetype = NULL, *desc = "";
> +const AVStream *st = s->streams[pkt->stream_index];
> +int i, mimelen, desclen, type = 0;
> +
> +if (!pkt->data)
>  return 0;
>
> -if (s->nb_streams > 1) {
> -av_log(s, AV_LOG_ERROR, "only one stream is supported\n");
> +while (mime->id != AV_CODEC_ID_NONE) {
> +if (mime->id == st->codecpar->codec_id) {
> +mimetype = mime->str;
> +break;
> +}
> +mime++;
> +}
> +if (!mimetype) {
> +av_log(s, AV_LOG_ERROR, "No mimetype is known for stream %d,
> cannot "
> +   "write an attached picture.\n", st->index);
>  return AVERROR(EINVAL);
>  }
> -if (par->codec_id != AV_CODEC_ID_FLAC) {
> -av_log(s, AV_LOG_ERROR, "unsupported codec\n");
> +mimelen = strlen(mimetype);
> +
> +/* get the picture type */
> +e = av_dict_get(st->metadata, "comment", NULL, 0);
> +for (i = 0; e && i < FF_ARRAY_ELEMS(ff_id3v2_picture_types); i++) {
> +if (!av_strcasecmp(e->value, ff_id3v2_picture_types[i])) {
> +type = i;
> +break;
> +}
> +}
> +
> +if (c->attached_types & (1 << type)) {
> +av_log(s, AV_LOG_ERROR, "Duplicate attachment for type '%s'\n",
> ff_id3v2_picture_types[type]);
>  return AVERROR(EINVAL);
>  }
>
> +c->attached_types |= (1 << type);
> +
> +/* get the description */
> +if ((e = av_dict_get(st->metadata, "title", NULL, 0)))
> +desc = e->value;
> +desclen = strlen(desc);
> +
> +avio_w8(pb, 0x06);
> +avio_wb24(pb, 4 + 4 + mimelen + 4 + desclen + 4 + 4 + 4 + 4 + 4 +
> pkt->size);
> +
> +avio_wb32(pb, type);
> +
> +avio_wb32(pb, mimelen);
> +avio_write(pb, mimetype, mimelen);
> +
> +avio_wb32(pb, desclen);
> +avio_write(pb, desc, desclen);
> +
> +avio_wb32(pb, st->codecpar->width);
> +avio_wb32(pb, st->codecpar->height);
> +if ((pixdesc = av_pix_fmt_desc_get(st->codecpar->format)))
> +avio_wb32(pb, av_get_bits_per_pixel(pixdesc));
> +else
> +avio_wb32(pb, 0);
> +avio_wb32(pb, 0);
> +
> +avio_wb32(pb, pkt->size);
> +avio_write(pb, pkt->data, pkt->size);
> +return 0;
> +}
> +
> +static int flac_finish_header(struct AVFormatContext *s)
> +{
> +FlacMuxerContext *c = s->priv_data;
> +int i, ret, padding = s->metadata_header_padding;
>  if (padding < 0)
>  padding = 8192;
>  /* The FLAC specification states that 24 bits are used to represent
> the
>   * size of a metadata block so we must clip this value to 2^24-1. */
>  padding = av_clip_uintp2(padding, 24);
>
> +for (i = 0; i < c->nb_pics; i++) {
> +ret = flac_write_picture(s, &c->pics[i]);
> +if (ret)
> +return ret;
> +}
> +
> +ret = flac_write_block_comment(s->pb, &s->metadata, !padding,
> +   s->flags & AVFMT_FLAG_BITEXACT);
> +if (ret)
> +return ret;
> +
> +/* The command line flac encoder defaults to placing 

[FFmpeg-devel] [PATCH] avcodec/avpacket: allow only one element per type in packet side data

2017-05-12 Thread James Almer
It was never meant to do otherwise, as av_packet_get_side_data() returns the 
first
entry it finds of a given type.

Based on code from libavformat's av_stream_add_side_data().

Signed-off-by: James Almer 
---
 libavcodec/avpacket.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/libavcodec/avpacket.c b/libavcodec/avpacket.c
index 26d561a00a..a04cdaf530 100644
--- a/libavcodec/avpacket.c
+++ b/libavcodec/avpacket.c
@@ -296,7 +296,18 @@ int av_packet_add_side_data(AVPacket *pkt, enum 
AVPacketSideDataType type,
 uint8_t *data, size_t size)
 {
 AVPacketSideData *tmp;
-int elems = pkt->side_data_elems;
+int i, elems = pkt->side_data_elems;
+
+for (i = 0; i < elems; i++) {
+AVPacketSideData *sd = &pkt->side_data[i];
+
+if (sd->type == type) {
+av_free(sd->data);
+sd->data = data;
+sd->size = size;
+return 0;
+}
+}
 
 if ((unsigned)elems + 1 > AV_PKT_DATA_NB)
 return AVERROR(ERANGE);
-- 
2.12.1

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


Re: [FFmpeg-devel] [PATCH] avcodec/xpmdec: Fix multiple pointer/memory issues

2017-05-12 Thread Paul B Mahol
On 5/12/17, Nicolas George  wrote:
> Le tridi 23 floreal, an CCXXV, Paul B Mahol a ecrit :
>> I told you that its unacceptable.
>
> And I told you, before you pushed, that your cowboy-style parser was
> unacceptable. You chose to disregard it.

Because I assumed packets are padded with zeroes.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] avcodec/xpmdec: Fix multiple pointer/memory issues

2017-05-12 Thread Nicolas George
Le tridi 23 floréal, an CCXXV, Paul B Mahol a écrit :
> I told you that its unacceptable.

And I told you, before you pushed, that your cowboy-style parser was
unacceptable. You chose to disregard it.

Regards,

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


Re: [FFmpeg-devel] [PATCH] avcodec/avcodec: Limit the number of side data elements per packet

2017-05-12 Thread James Almer
On 5/12/2017 12:55 PM, wm4 wrote:
> On Fri, 12 May 2017 10:59:50 -0300
> James Almer  wrote:
> 
>> On 5/12/2017 9:20 AM, Michael Niedermayer wrote:
>>> On Fri, May 12, 2017 at 06:16:38AM +0200, wm4 wrote:  
 On Thu, 11 May 2017 23:27:37 +0200
 Michael Niedermayer  wrote:
  
> On Thu, May 11, 2017 at 06:54:16PM +0200, wm4 wrote:  
>> On Thu, 11 May 2017 13:01:36 +0200
>> Michael Niedermayer  wrote:
>> 
>>> Fixes: 1293/clusterfuzz-testcase-minimized-6054752074858496
>>>
>>> Found-by: continuous fuzzing process 
>>> https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
>>> Signed-off-by: Michael Niedermayer 
>>> ---
>>>  libavcodec/avcodec.h  | 8 
>>>  libavcodec/avpacket.c | 5 -
>>>  2 files changed, 12 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
>>> index df6d2bc748..173c083a86 100644
>>> --- a/libavcodec/avcodec.h
>>> +++ b/libavcodec/avcodec.h
>>> @@ -1593,6 +1593,14 @@ enum AVPacketSideDataType {
>>>   * AVContentLightMetadata struct.
>>>   */
>>>  AV_PKT_DATA_CONTENT_LIGHT_LEVEL,
>>> +
>>> +/**
>>> + * The number of side data elements (in fact a bit more than it).
>>> + * This is not part of the public API/ABI in the sense that it may
>>> + * change when new side data types are added.
>>> + * This must stay the last enum value.
>>> + */
>>> +AV_PKT_DATA_NB,
>>>  };
>>
>> OK I guess.
>> 
>>>  #define AV_PKT_DATA_QUALITY_FACTOR AV_PKT_DATA_QUALITY_STATS 
>>> //DEPRECATED
>>> diff --git a/libavcodec/avpacket.c b/libavcodec/avpacket.c
>>> index 369dd78208..200ba99f34 100644
>>> --- a/libavcodec/avpacket.c
>>> +++ b/libavcodec/avpacket.c
>>> @@ -298,7 +298,7 @@ int av_packet_add_side_data(AVPacket *pkt, enum 
>>> AVPacketSideDataType type,
>>>  AVPacketSideData *tmp;
>>>  int elems = pkt->side_data_elems;
>>>  
>>> -if ((unsigned)elems + 1 > INT_MAX / sizeof(*pkt->side_data))
>>> +if ((unsigned)elems + 1 > FFMIN(INT_MAX / sizeof(*pkt->side_data), 
>>> AV_PKT_DATA_NB))
>>
>> Does the FFMIN and the old expression on the right side still have any
>> function?
>
> In practice, no
> In principle, yes, AV_PKT_DATA_NB could be larger than
> INT_MAX / sizeof(*pkt->side_data  

 That seems extremely unlikely. Feel free to extend the comment on the
 new enum item to this extend.
  
>
> do you prefer if i remove it ?  

 Yes.  
>>>
>>> changed
>>>
>>> applied
>>>
>>> thx  
>>
>> For the record, by limiting the amount of side data elements to
>> AV_PKT_DATA_NB we're potentially breaking the current behavior where the
>> function allows more than one element of the same side data type in a
>> packet.
>> What should be done here is make this function behave the same as
>> av_stream_add_side_data() and allow only one element per type,
>> overwriting the existing one when a new one is provided.
>>
>> I don't know for that matter if the above would have been better than
>> adding this _NB enum, or at least sufficient, seeing how
>> av_stream_add_side_data() also does a "INT_MAX / sizeof(*side_data)"
>> check after making sure only one element per type is allowed, and can't
>> really use this _NB enum being in a different library.
> 
> How was that ever allowed and where is this used?

What was what allowed and used? If you're talking about AV_PKT_DATA_NB,
it's obviously not being used anywhere but libavcodec.

> 
> I doubt anything can properly deal with it, and duplicate side data
> elements should be disallowed.

That's my point. av_packet_add_side_data() currently allows multiple
side data elements of the same type in a packet, and this patch breaks
that behavior by limiting it to a max of AV_PKT_DATA_NB elements.
It should be changed to behave the same way as
av_stream_add_side_data(), allowing only one side data element per type
in a packet.

I'll send a patch for this.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] avcodec/avcodec: Limit the number of side data elements per packet

2017-05-12 Thread wm4
On Fri, 12 May 2017 10:59:50 -0300
James Almer  wrote:

> On 5/12/2017 9:20 AM, Michael Niedermayer wrote:
> > On Fri, May 12, 2017 at 06:16:38AM +0200, wm4 wrote:  
> >> On Thu, 11 May 2017 23:27:37 +0200
> >> Michael Niedermayer  wrote:
> >>  
> >>> On Thu, May 11, 2017 at 06:54:16PM +0200, wm4 wrote:  
>  On Thu, 11 May 2017 13:01:36 +0200
>  Michael Niedermayer  wrote:
>  
> > Fixes: 1293/clusterfuzz-testcase-minimized-6054752074858496
> >
> > Found-by: continuous fuzzing process 
> > https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/avcodec.h  | 8 
> >  libavcodec/avpacket.c | 5 -
> >  2 files changed, 12 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> > index df6d2bc748..173c083a86 100644
> > --- a/libavcodec/avcodec.h
> > +++ b/libavcodec/avcodec.h
> > @@ -1593,6 +1593,14 @@ enum AVPacketSideDataType {
> >   * AVContentLightMetadata struct.
> >   */
> >  AV_PKT_DATA_CONTENT_LIGHT_LEVEL,
> > +
> > +/**
> > + * The number of side data elements (in fact a bit more than it).
> > + * This is not part of the public API/ABI in the sense that it may
> > + * change when new side data types are added.
> > + * This must stay the last enum value.
> > + */
> > +AV_PKT_DATA_NB,
> >  };
> 
>  OK I guess.
>  
> >  #define AV_PKT_DATA_QUALITY_FACTOR AV_PKT_DATA_QUALITY_STATS 
> > //DEPRECATED
> > diff --git a/libavcodec/avpacket.c b/libavcodec/avpacket.c
> > index 369dd78208..200ba99f34 100644
> > --- a/libavcodec/avpacket.c
> > +++ b/libavcodec/avpacket.c
> > @@ -298,7 +298,7 @@ int av_packet_add_side_data(AVPacket *pkt, enum 
> > AVPacketSideDataType type,
> >  AVPacketSideData *tmp;
> >  int elems = pkt->side_data_elems;
> >  
> > -if ((unsigned)elems + 1 > INT_MAX / sizeof(*pkt->side_data))
> > +if ((unsigned)elems + 1 > FFMIN(INT_MAX / sizeof(*pkt->side_data), 
> > AV_PKT_DATA_NB))
> 
>  Does the FFMIN and the old expression on the right side still have any
>  function?
> >>>
> >>> In practice, no
> >>> In principle, yes, AV_PKT_DATA_NB could be larger than
> >>> INT_MAX / sizeof(*pkt->side_data  
> >>
> >> That seems extremely unlikely. Feel free to extend the comment on the
> >> new enum item to this extend.
> >>  
> >>>
> >>> do you prefer if i remove it ?  
> >>
> >> Yes.  
> > 
> > changed
> > 
> > applied
> > 
> > thx  
> 
> For the record, by limiting the amount of side data elements to
> AV_PKT_DATA_NB we're potentially breaking the current behavior where the
> function allows more than one element of the same side data type in a
> packet.
> What should be done here is make this function behave the same as
> av_stream_add_side_data() and allow only one element per type,
> overwriting the existing one when a new one is provided.
> 
> I don't know for that matter if the above would have been better than
> adding this _NB enum, or at least sufficient, seeing how
> av_stream_add_side_data() also does a "INT_MAX / sizeof(*side_data)"
> check after making sure only one element per type is allowed, and can't
> really use this _NB enum being in a different library.

How was that ever allowed and where is this used?

I doubt anything can properly deal with it, and duplicate side data
elements should be disallowed.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH/WIP] avcodec/x86: move simple_idct to external assembly

2017-05-12 Thread James Darnley
---

For initial review and comments.

I plan to drop the '2' from the filename before pushing.  I haven't done it yet
because I am still working on the file.  I didn't make any changes with speedup
in mind so I haven't done any benchmarking yet.

 libavcodec/x86/Makefile |   4 +-
 libavcodec/x86/simple_idct.c| 929 
 libavcodec/x86/simple_idct2.asm | 892 ++
 3 files changed, 894 insertions(+), 931 deletions(-)
 delete mode 100644 libavcodec/x86/simple_idct.c
 create mode 100644 libavcodec/x86/simple_idct2.asm

diff --git a/libavcodec/x86/Makefile b/libavcodec/x86/Makefile
index d4cb27fa13..af3b50f17a 100644
--- a/libavcodec/x86/Makefile
+++ b/libavcodec/x86/Makefile
@@ -79,7 +79,6 @@ OBJS-$(CONFIG_WEBP_DECODER)+= x86/vp8dsp_init.o
 # GCC inline assembly optimizations
 # subsystems
 MMX-OBJS-$(CONFIG_FDCTDSP) += x86/fdct.o
-MMX-OBJS-$(CONFIG_IDCTDSP) += x86/simple_idct.o
 MMX-OBJS-$(CONFIG_VC1DSP)  += x86/vc1dsp_mmx.o
 
 # decoders/encoders
@@ -128,7 +127,8 @@ YASM-OBJS-$(CONFIG_QPELDSP)+= x86/qpeldsp.o 
\
 YASM-OBJS-$(CONFIG_RV34DSP)+= x86/rv34dsp.o
 YASM-OBJS-$(CONFIG_VC1DSP) += x86/vc1dsp_loopfilter.o   \
   x86/vc1dsp_mc.o
-YASM-OBJS-$(CONFIG_IDCTDSP)+= x86/simple_idct10.o
+YASM-OBJS-$(CONFIG_IDCTDSP)+= x86/simple_idct10.o   \
+  x86/simple_idct2.o
 YASM-OBJS-$(CONFIG_VIDEODSP)   += x86/videodsp.o
 YASM-OBJS-$(CONFIG_VP3DSP) += x86/vp3dsp.o
 YASM-OBJS-$(CONFIG_VP8DSP) += x86/vp8dsp.o  \
diff --git a/libavcodec/x86/simple_idct.c b/libavcodec/x86/simple_idct.c
deleted file mode 100644
index 1155920ae8..00
--- a/libavcodec/x86/simple_idct.c
+++ /dev/null
@@ -1,929 +0,0 @@
-/*
- * Simple IDCT MMX
- *
- * Copyright (c) 2001, 2002 Michael Niedermayer 
- *
- * This file is part of FFmpeg.
- *
- * FFmpeg is free software; you can redistribute it and/or
- * modify it under the terms of the GNU Lesser General Public
- * License as published by the Free Software Foundation; either
- * version 2.1 of the License, or (at your option) any later version.
- *
- * FFmpeg is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
- * Lesser General Public License for more details.
- *
- * You should have received a copy of the GNU Lesser General Public
- * License along with FFmpeg; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
- */
-
-#include "libavutil/mem.h"
-#include "libavutil/x86/asm.h"
-
-#include "libavcodec/idctdsp.h"
-#include "libavcodec/x86/idctdsp.h"
-
-#include "idctdsp.h"
-#include "simple_idct.h"
-
-#if HAVE_INLINE_ASM
-
-/*
-23170.475006
-22725.260826
-21406.727617
-19265.545870
-16384.00
-12872.826198
-8866.956905
-4520.335430
-*/
-#define C0 23170 //cos(i*M_PI/16)*sqrt(2)*(1<<14) + 0.5
-#define C1 22725 //cos(i*M_PI/16)*sqrt(2)*(1<<14) + 0.5
-#define C2 21407 //cos(i*M_PI/16)*sqrt(2)*(1<<14) + 0.5
-#define C3 19266 //cos(i*M_PI/16)*sqrt(2)*(1<<14) + 0.5
-#define C4 16383 //cos(i*M_PI/16)*sqrt(2)*(1<<14) - 0.5
-#define C5 12873 //cos(i*M_PI/16)*sqrt(2)*(1<<14) + 0.5
-#define C6 8867  //cos(i*M_PI/16)*sqrt(2)*(1<<14) + 0.5
-#define C7 4520  //cos(i*M_PI/16)*sqrt(2)*(1<<14) + 0.5
-
-#define ROW_SHIFT 11
-#define COL_SHIFT 20 // 6
-
-DECLARE_ASM_CONST(8, uint64_t, wm1010)= 0xULL;
-DECLARE_ASM_CONST(8, uint64_t, d4)= 0x0004ULL;
-
-DECLARE_ALIGNED(8, static const int16_t, coeffs)[]= {
-1<<(ROW_SHIFT-1), 0, 1<<(ROW_SHIFT-1), 0,
-//1<<(COL_SHIFT-1), 0, 1<<(COL_SHIFT-1), 0,
-//0, 1<<(COL_SHIFT-1-16), 0, 1<<(COL_SHIFT-1-16),
-1<<(ROW_SHIFT-1), 1, 1<<(ROW_SHIFT-1), 0,
-// the 1 = ((1<<(COL_SHIFT-1))/C4)<
+;
+; This file is part of FFmpeg.
+;
+; FFmpeg is free software; you can redistribute it and/or
+; modify it under the terms of the GNU Lesser General Public
+; License as published by the Free Software Foundation; either
+; version 2.1 of the License, or (at your option) any later version.
+;
+; FFmpeg is distributed in the hope that it will be useful,
+; but WITHOUT ANY WARRANTY; without even the implied warranty of
+; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+; Lesser General Public License for more details.
+;
+; You should have received a copy of the GNU Lesser General Public
+; License along with FFmpeg; if not, write to the Free Software
+; Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+;/
+
+%include "libavutil/x86/x86util.asm"
+
+SECTION_RODATA
+
+cextern pb_80
+
+wm1010: dw 0, 0x, 0, 0x
+d4: dw 0, 4, 0, 0
+
+; 2

Re: [FFmpeg-devel] [PATCH] avcodec/avcodec: Limit the number of side data elements per packet

2017-05-12 Thread James Almer
On 5/12/2017 9:20 AM, Michael Niedermayer wrote:
> On Fri, May 12, 2017 at 06:16:38AM +0200, wm4 wrote:
>> On Thu, 11 May 2017 23:27:37 +0200
>> Michael Niedermayer  wrote:
>>
>>> On Thu, May 11, 2017 at 06:54:16PM +0200, wm4 wrote:
 On Thu, 11 May 2017 13:01:36 +0200
 Michael Niedermayer  wrote:
   
> Fixes: 1293/clusterfuzz-testcase-minimized-6054752074858496
>
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/avcodec.h  | 8 
>  libavcodec/avpacket.c | 5 -
>  2 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index df6d2bc748..173c083a86 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -1593,6 +1593,14 @@ enum AVPacketSideDataType {
>   * AVContentLightMetadata struct.
>   */
>  AV_PKT_DATA_CONTENT_LIGHT_LEVEL,
> +
> +/**
> + * The number of side data elements (in fact a bit more than it).
> + * This is not part of the public API/ABI in the sense that it may
> + * change when new side data types are added.
> + * This must stay the last enum value.
> + */
> +AV_PKT_DATA_NB,
>  };  

 OK I guess.
   
>  #define AV_PKT_DATA_QUALITY_FACTOR AV_PKT_DATA_QUALITY_STATS //DEPRECATED
> diff --git a/libavcodec/avpacket.c b/libavcodec/avpacket.c
> index 369dd78208..200ba99f34 100644
> --- a/libavcodec/avpacket.c
> +++ b/libavcodec/avpacket.c
> @@ -298,7 +298,7 @@ int av_packet_add_side_data(AVPacket *pkt, enum 
> AVPacketSideDataType type,
>  AVPacketSideData *tmp;
>  int elems = pkt->side_data_elems;
>  
> -if ((unsigned)elems + 1 > INT_MAX / sizeof(*pkt->side_data))
> +if ((unsigned)elems + 1 > FFMIN(INT_MAX / sizeof(*pkt->side_data), 
> AV_PKT_DATA_NB))  

 Does the FFMIN and the old expression on the right side still have any
 function?  
>>>
>>> In practice, no
>>> In principle, yes, AV_PKT_DATA_NB could be larger than
>>> INT_MAX / sizeof(*pkt->side_data
>>
>> That seems extremely unlikely. Feel free to extend the comment on the
>> new enum item to this extend.
>>
>>>
>>> do you prefer if i remove it ?
>>
>> Yes.
> 
> changed
> 
> applied
> 
> thx

For the record, by limiting the amount of side data elements to
AV_PKT_DATA_NB we're potentially breaking the current behavior where the
function allows more than one element of the same side data type in a
packet.
What should be done here is make this function behave the same as
av_stream_add_side_data() and allow only one element per type,
overwriting the existing one when a new one is provided.

I don't know for that matter if the above would have been better than
adding this _NB enum, or at least sufficient, seeing how
av_stream_add_side_data() also does a "INT_MAX / sizeof(*side_data)"
check after making sure only one element per type is allowed, and can't
really use this _NB enum being in a different library.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 1/3] configure: add cuda-sdk for things requiring full CUDA sdk

2017-05-12 Thread James Almer
On 5/12/2017 5:21 AM, Timo Rothenpieler wrote:
> Am 12.05.2017 um 07:32 schrieb Yogender Gupta:
 +cuda_sdk
 libnpp
>>
>> IMO, Libnpp is part of the CUDA SDK, and we can remove all the libnpp 
>> related changes and just replace it by cuda-sdk in the configure/make files.
> 
> True, but I'm not sure if an existing config parameter can be that
> easily removed without breaking a bunch of existing build scripts.

You can keep the option marked as deprecated for a while, while removing
all the relevant internals and making it an alias for cuda_sdk.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] avcodec/xpmdec: Fix multiple pointer/memory issues

2017-05-12 Thread Paul B Mahol
On 5/12/17, Michael Niedermayer  wrote:
> On Thu, May 11, 2017 at 11:17:33AM +0200, Michael Niedermayer wrote:
>> On Thu, May 11, 2017 at 09:01:57AM +0200, Paul B Mahol wrote:
>> > On 5/11/17, Michael Niedermayer  wrote:
>> > > Most of these were found through code review in response to
>> > > fixing 1466/clusterfuzz-testcase-minimized-5961584419536896
>> > > There is thus no testcase for most of this.
>> > > The initial issue was Found-by: continuous fuzzing process
>> > > https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
>> > >
>> > > Signed-off-by: Michael Niedermayer 
>> > > ---
>> > >  libavcodec/xpmdec.c | 37 ++---
>> > >  1 file changed, 30 insertions(+), 7 deletions(-)
>> > >
>> > > diff --git a/libavcodec/xpmdec.c b/libavcodec/xpmdec.c
>> > > index 9112d4cb5e..03172e4aad 100644
>> > > --- a/libavcodec/xpmdec.c
>> > > +++ b/libavcodec/xpmdec.c
>> > > @@ -29,6 +29,8 @@
>> > >  typedef struct XPMContext {
>> > >  uint32_t  *pixels;
>> > >  intpixels_size;
>> > > +uint8_t   *buf;
>> > > +intbuf_size;
>> > >  } XPMDecContext;
>> > >
>> > >  typedef struct ColorEntry {
>> > > @@ -233,6 +235,8 @@ static uint32_t color_string_to_rgba(const char
>> > > *p, int
>> > > len)
>> > >  const ColorEntry *entry;
>> > >  char color_name[100];
>> > >
>> > > +len = FFMIN(FFMAX(len, 0), sizeof(color_name) - 1);
>> > > +
>> > >  if (*p == '#') {
>> > >  p++;
>> > >  len--;
>> > > @@ -299,18 +303,25 @@ static int xpm_decode_frame(AVCodecContext
>> > > *avctx,
>> > > void *data,
>> > >  {
>> > >  XPMDecContext *x = avctx->priv_data;
>> > >  AVFrame *p=data;
>> > > -const uint8_t *end, *ptr = avpkt->data;
>> > > +const uint8_t *end, *ptr;
>> > >  int ncolors, cpp, ret, i, j;
>> > >  int64_t size;
>> > >  uint32_t *dst;
>> > >
>> > >  avctx->pix_fmt = AV_PIX_FMT_BGRA;
>> > >
>> > > -end = avpkt->data + avpkt->size;
>> > > -while (memcmp(ptr, "/* XPM */", 9) && ptr < end - 9)
>> > > +av_fast_padded_malloc(&x->buf, &x->buf_size, avpkt->size);
>> > > +if (!x->buf)
>> > > +return AVERROR(ENOMEM);
>> > > +memcpy(x->buf, avpkt->data, avpkt->size);
>> > > +x->buf[avpkt->size] = 0;
>> > > +
>> > > +ptr = x->buf;
>> > > +end = x->buf + avpkt->size;
>> > > +while (end - ptr > 9 && memcmp(ptr, "/* XPM */", 9))
>> > >  ptr++;
>> > >
>> > > -if (ptr >= end) {
>> > > +if (end - ptr <= 9) {
>> > >  av_log(avctx, AV_LOG_ERROR, "missing signature\n");
>> > >  return AVERROR_INVALIDDATA;
>> > >  }
>> > > @@ -335,7 +346,7 @@ static int xpm_decode_frame(AVCodecContext *avctx,
>> > > void
>> > > *data,
>> > >
>> > >  size = 1;
>> > >  for (i = 0; i < cpp; i++)
>> > > -size *= 94;
>> > > +size *= 95;
>> > >
>> > >  if (ncolors <= 0 || ncolors > size) {
>> > >  av_log(avctx, AV_LOG_ERROR, "invalid number of colors:
>> > > %d\n",
>> > > ncolors);
>> > > @@ -349,12 +360,15 @@ static int xpm_decode_frame(AVCodecContext
>> > > *avctx,
>> > > void *data,
>> > >  return AVERROR(ENOMEM);
>> > >
>> > >  ptr += mod_strcspn(ptr, ",") + 1;
>> > > +if (end - ptr < 1)
>> > > +return AVERROR_INVALIDDATA;
>> > > +
>> > >  for (i = 0; i < ncolors; i++) {
>> > >  const uint8_t *index;
>> > >  int len;
>> > >
>> > >  ptr += mod_strcspn(ptr, "\"") + 1;
>> > > -if (ptr + cpp > end)
>> > > +if (end - ptr < cpp)
>> > >  return AVERROR_INVALIDDATA;
>> > >  index = ptr;
>> > >  ptr += cpp;
>> > > @@ -373,14 +387,20 @@ static int xpm_decode_frame(AVCodecContext
>> > > *avctx,
>> > > void *data,
>> > >
>> > >  x->pixels[ret] = color_string_to_rgba(ptr, len);
>> > >  ptr += mod_strcspn(ptr, ",") + 1;
>> > > +if (end - ptr < 1)
>> > > +return AVERROR_INVALIDDATA;
>> > >  }
>> > >
>> > >  for (i = 0; i < avctx->height; i++) {
>> > >  dst = (uint32_t *)(p->data[0] + i * p->linesize[0]);
>> > > +if (end - ptr < 1)
>> > > +return AVERROR_INVALIDDATA;
>> > >  ptr += mod_strcspn(ptr, "\"") + 1;
>> > > +if (end - ptr < 1)
>> > > +return AVERROR_INVALIDDATA;
>> > >
>> > >  for (j = 0; j < avctx->width; j++) {
>> > > -if (ptr + cpp > end)
>> > > +if (end - ptr < cpp)
>> > >  return AVERROR_INVALIDDATA;
>> > >
>> > >  if ((ret = ascii2index(ptr, cpp)) < 0)
>> > > @@ -405,6 +425,9 @@ static av_cold int
>> > > xpm_decode_close(AVCodecContext
>> > > *avctx)
>> > >  XPMDecContext *x = avctx->priv_data;
>> > >  av_freep(&x->pixels);
>> > >
>> > > +av_freep(&x->buf);
>> > > +x->buf_size = 0;
>> > > +
>> > >  return 0;
>> > >  }
>> > >
>> > > --
>> > > 2.11.0
>> > >
>> > > ___
>> > > ffmpeg-devel mailing list
>> > > ffmpeg-d

Re: [FFmpeg-devel] [PATCH] avcodec/vp8dsp: vp7_luma_dc_wht_c: Fix multiple runtime error: signed integer overflow: -1366381240 + -1262413604 cannot be represented in type 'int'

2017-05-12 Thread Michael Niedermayer
On Wed, May 10, 2017 at 02:50:40PM +0200, Michael Niedermayer wrote:
> Fixes: 1440/clusterfuzz-testcase-minimized-5785716111966208
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/vp8dsp.c | 19 ++-
>  1 file changed, 10 insertions(+), 9 deletions(-)

applied

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] avcodec/xpmdec: Fix multiple pointer/memory issues

2017-05-12 Thread Michael Niedermayer
On Thu, May 11, 2017 at 11:17:33AM +0200, Michael Niedermayer wrote:
> On Thu, May 11, 2017 at 09:01:57AM +0200, Paul B Mahol wrote:
> > On 5/11/17, Michael Niedermayer  wrote:
> > > Most of these were found through code review in response to
> > > fixing 1466/clusterfuzz-testcase-minimized-5961584419536896
> > > There is thus no testcase for most of this.
> > > The initial issue was Found-by: continuous fuzzing process
> > > https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
> > >
> > > Signed-off-by: Michael Niedermayer 
> > > ---
> > >  libavcodec/xpmdec.c | 37 ++---
> > >  1 file changed, 30 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/libavcodec/xpmdec.c b/libavcodec/xpmdec.c
> > > index 9112d4cb5e..03172e4aad 100644
> > > --- a/libavcodec/xpmdec.c
> > > +++ b/libavcodec/xpmdec.c
> > > @@ -29,6 +29,8 @@
> > >  typedef struct XPMContext {
> > >  uint32_t  *pixels;
> > >  intpixels_size;
> > > +uint8_t   *buf;
> > > +intbuf_size;
> > >  } XPMDecContext;
> > >
> > >  typedef struct ColorEntry {
> > > @@ -233,6 +235,8 @@ static uint32_t color_string_to_rgba(const char *p, 
> > > int
> > > len)
> > >  const ColorEntry *entry;
> > >  char color_name[100];
> > >
> > > +len = FFMIN(FFMAX(len, 0), sizeof(color_name) - 1);
> > > +
> > >  if (*p == '#') {
> > >  p++;
> > >  len--;
> > > @@ -299,18 +303,25 @@ static int xpm_decode_frame(AVCodecContext *avctx,
> > > void *data,
> > >  {
> > >  XPMDecContext *x = avctx->priv_data;
> > >  AVFrame *p=data;
> > > -const uint8_t *end, *ptr = avpkt->data;
> > > +const uint8_t *end, *ptr;
> > >  int ncolors, cpp, ret, i, j;
> > >  int64_t size;
> > >  uint32_t *dst;
> > >
> > >  avctx->pix_fmt = AV_PIX_FMT_BGRA;
> > >
> > > -end = avpkt->data + avpkt->size;
> > > -while (memcmp(ptr, "/* XPM */", 9) && ptr < end - 9)
> > > +av_fast_padded_malloc(&x->buf, &x->buf_size, avpkt->size);
> > > +if (!x->buf)
> > > +return AVERROR(ENOMEM);
> > > +memcpy(x->buf, avpkt->data, avpkt->size);
> > > +x->buf[avpkt->size] = 0;
> > > +
> > > +ptr = x->buf;
> > > +end = x->buf + avpkt->size;
> > > +while (end - ptr > 9 && memcmp(ptr, "/* XPM */", 9))
> > >  ptr++;
> > >
> > > -if (ptr >= end) {
> > > +if (end - ptr <= 9) {
> > >  av_log(avctx, AV_LOG_ERROR, "missing signature\n");
> > >  return AVERROR_INVALIDDATA;
> > >  }
> > > @@ -335,7 +346,7 @@ static int xpm_decode_frame(AVCodecContext *avctx, 
> > > void
> > > *data,
> > >
> > >  size = 1;
> > >  for (i = 0; i < cpp; i++)
> > > -size *= 94;
> > > +size *= 95;
> > >
> > >  if (ncolors <= 0 || ncolors > size) {
> > >  av_log(avctx, AV_LOG_ERROR, "invalid number of colors: %d\n",
> > > ncolors);
> > > @@ -349,12 +360,15 @@ static int xpm_decode_frame(AVCodecContext *avctx,
> > > void *data,
> > >  return AVERROR(ENOMEM);
> > >
> > >  ptr += mod_strcspn(ptr, ",") + 1;
> > > +if (end - ptr < 1)
> > > +return AVERROR_INVALIDDATA;
> > > +
> > >  for (i = 0; i < ncolors; i++) {
> > >  const uint8_t *index;
> > >  int len;
> > >
> > >  ptr += mod_strcspn(ptr, "\"") + 1;
> > > -if (ptr + cpp > end)
> > > +if (end - ptr < cpp)
> > >  return AVERROR_INVALIDDATA;
> > >  index = ptr;
> > >  ptr += cpp;
> > > @@ -373,14 +387,20 @@ static int xpm_decode_frame(AVCodecContext *avctx,
> > > void *data,
> > >
> > >  x->pixels[ret] = color_string_to_rgba(ptr, len);
> > >  ptr += mod_strcspn(ptr, ",") + 1;
> > > +if (end - ptr < 1)
> > > +return AVERROR_INVALIDDATA;
> > >  }
> > >
> > >  for (i = 0; i < avctx->height; i++) {
> > >  dst = (uint32_t *)(p->data[0] + i * p->linesize[0]);
> > > +if (end - ptr < 1)
> > > +return AVERROR_INVALIDDATA;
> > >  ptr += mod_strcspn(ptr, "\"") + 1;
> > > +if (end - ptr < 1)
> > > +return AVERROR_INVALIDDATA;
> > >
> > >  for (j = 0; j < avctx->width; j++) {
> > > -if (ptr + cpp > end)
> > > +if (end - ptr < cpp)
> > >  return AVERROR_INVALIDDATA;
> > >
> > >  if ((ret = ascii2index(ptr, cpp)) < 0)
> > > @@ -405,6 +425,9 @@ static av_cold int xpm_decode_close(AVCodecContext
> > > *avctx)
> > >  XPMDecContext *x = avctx->priv_data;
> > >  av_freep(&x->pixels);
> > >
> > > +av_freep(&x->buf);
> > > +x->buf_size = 0;
> > > +
> > >  return 0;
> > >  }
> > >
> > > --
> > > 2.11.0
> > >
> > > ___
> > > ffmpeg-devel mailing list
> > > ffmpeg-devel@ffmpeg.org
> > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > >
> > 
> > This is suboptimal solution.
> 
> That comment isnt helpfull in improving the patch. It doesnt say
> what it is that you would l

Re: [FFmpeg-devel] [PATCH] avcodec/avcodec: Limit the number of side data elements per packet

2017-05-12 Thread Michael Niedermayer
On Fri, May 12, 2017 at 06:16:38AM +0200, wm4 wrote:
> On Thu, 11 May 2017 23:27:37 +0200
> Michael Niedermayer  wrote:
> 
> > On Thu, May 11, 2017 at 06:54:16PM +0200, wm4 wrote:
> > > On Thu, 11 May 2017 13:01:36 +0200
> > > Michael Niedermayer  wrote:
> > >   
> > > > Fixes: 1293/clusterfuzz-testcase-minimized-6054752074858496
> > > > 
> > > > Found-by: continuous fuzzing process 
> > > > https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
> > > > Signed-off-by: Michael Niedermayer 
> > > > ---
> > > >  libavcodec/avcodec.h  | 8 
> > > >  libavcodec/avpacket.c | 5 -
> > > >  2 files changed, 12 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> > > > index df6d2bc748..173c083a86 100644
> > > > --- a/libavcodec/avcodec.h
> > > > +++ b/libavcodec/avcodec.h
> > > > @@ -1593,6 +1593,14 @@ enum AVPacketSideDataType {
> > > >   * AVContentLightMetadata struct.
> > > >   */
> > > >  AV_PKT_DATA_CONTENT_LIGHT_LEVEL,
> > > > +
> > > > +/**
> > > > + * The number of side data elements (in fact a bit more than it).
> > > > + * This is not part of the public API/ABI in the sense that it may
> > > > + * change when new side data types are added.
> > > > + * This must stay the last enum value.
> > > > + */
> > > > +AV_PKT_DATA_NB,
> > > >  };  
> > > 
> > > OK I guess.
> > >   
> > > >  #define AV_PKT_DATA_QUALITY_FACTOR AV_PKT_DATA_QUALITY_STATS 
> > > > //DEPRECATED
> > > > diff --git a/libavcodec/avpacket.c b/libavcodec/avpacket.c
> > > > index 369dd78208..200ba99f34 100644
> > > > --- a/libavcodec/avpacket.c
> > > > +++ b/libavcodec/avpacket.c
> > > > @@ -298,7 +298,7 @@ int av_packet_add_side_data(AVPacket *pkt, enum 
> > > > AVPacketSideDataType type,
> > > >  AVPacketSideData *tmp;
> > > >  int elems = pkt->side_data_elems;
> > > >  
> > > > -if ((unsigned)elems + 1 > INT_MAX / sizeof(*pkt->side_data))
> > > > +if ((unsigned)elems + 1 > FFMIN(INT_MAX / sizeof(*pkt->side_data), 
> > > > AV_PKT_DATA_NB))  
> > > 
> > > Does the FFMIN and the old expression on the right side still have any
> > > function?  
> > 
> > In practice, no
> > In principle, yes, AV_PKT_DATA_NB could be larger than
> > INT_MAX / sizeof(*pkt->side_data
> 
> That seems extremely unlikely. Feel free to extend the comment on the
> new enum item to this extend.
> 
> > 
> > do you prefer if i remove it ?
> 
> Yes.

changed

applied

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Everything should be made as simple as possible, but not simpler.
-- Albert Einstein


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] avcodec/avcodec: Limit the number of side data elements per packet

2017-05-12 Thread Michael Niedermayer
On Thu, May 11, 2017 at 01:57:01PM +0200, Clément Bœsch wrote:
> On Thu, May 11, 2017 at 01:01:36PM +0200, Michael Niedermayer wrote:
> > Fixes: 1293/clusterfuzz-testcase-minimized-6054752074858496
> > 
> > Found-by: continuous fuzzing process 
> > https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/avcodec.h  | 8 
> >  libavcodec/avpacket.c | 5 -
> >  2 files changed, 12 insertions(+), 1 deletion(-)
> > 
> > diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> > index df6d2bc748..173c083a86 100644
> > --- a/libavcodec/avcodec.h
> > +++ b/libavcodec/avcodec.h
> > @@ -1593,6 +1593,14 @@ enum AVPacketSideDataType {
> >   * AVContentLightMetadata struct.
> >   */
> >  AV_PKT_DATA_CONTENT_LIGHT_LEVEL,
> > +
> > +/**
> > + * The number of side data elements (in fact a bit more than it).
> > + * This is not part of the public API/ABI in the sense that it may
> > + * change when new side data types are added.
> > + * This must stay the last enum value.
> > + */
> > +AV_PKT_DATA_NB,
> 
> if it's supposed to always be the last value, you can drop the trailing
> comma.

fixed

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Everything should be made as simple as possible, but not simpler.
-- Albert Einstein


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] Possible minor bug found in AVI decoder

2017-05-12 Thread Tobias Rapp

On 12.05.2017 11:33, Eric Beuque wrote:

Hi,

i'm not really sure but i think a found a bug in the avi decoder of
avformat.

In the following function of the avidec.c:

static int avi_read_header(AVFormatContext *s)
{
...
switch (tag) {
...
case MKTAG('s', 't', 'r', 'f'):
/* stream header */
if (!size)
break;
if (stream_index >= (unsigned)s->nb_streams || avi->dv_demux) {
avio_skip(pb, size);
} else {
...
switch (codec_type) {
...
default:
st->codec->codec_type = AVMEDIA_TYPE_DATA;
st->codec->codec_id   = AV_CODEC_ID_NONE;
st->codec->codec_tag  = 0;
avio_skip(pb, size);
break;
}
}
break;
...
}

If the codec_type is AVMEDIA_TYPE_DATA, but the format is empty (size=0)
(which i think is allowed), then the codec_id is not set to
AV_CODEC_ID_NONE.

This will generate a trace when calling the avformat_find_stream_info:
"Could not find codec parameters for stream 1 (Unknown: none): unknown codec
Consider increasing the value for the 'analyzeduration' and 'probesize'
options"

I'm not really sure about he AVI spec if the format is mandatory or not,
but i think there is a bug.


According to the document at 
https://msdn.microsoft.com/en-us/library/windows/desktop/dd318189(v=vs.85).aspx 
the "strf" chunk is mandatory but the data is only specified for 
audio/video streams so indeed it might be possible that a chunk size of 
0 occurs for generic data streams.


Regards,
Tobias

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


Re: [FFmpeg-devel] Possible minor bug found in AVI decoder

2017-05-12 Thread Eric Beuque
2017-05-12 11:46 GMT+02:00 Paul B Mahol :

> On 5/12/17, Eric Beuque  wrote:
> > Hi,
> >
> > i'm not really sure but i think a found a bug in the avi decoder of
> > avformat.
> >
> > In the following function of the avidec.c:
> >
> > static int avi_read_header(AVFormatContext *s)
> > {
> > ...
> > switch (tag) {
> > ...
> > case MKTAG('s', 't', 'r', 'f'):
> > /* stream header */
> > if (!size)
> > break;
> > if (stream_index >= (unsigned)s->nb_streams ||
> avi->dv_demux) {
> > avio_skip(pb, size);
> > } else {
> > ...
> > switch (codec_type) {
> > ...
> > default:
> > st->codec->codec_type = AVMEDIA_TYPE_DATA;
> > st->codec->codec_id   = AV_CODEC_ID_NONE;
> > st->codec->codec_tag  = 0;
> > avio_skip(pb, size);
> > break;
> > }
> > }
> > break;
> > ...
> > }
> >
> > If the codec_type is AVMEDIA_TYPE_DATA, but the format is empty (size=0)
> > (which i think is allowed), then the codec_id is not set to
> > AV_CODEC_ID_NONE.
> >
> > This will generate a trace when calling the avformat_find_stream_info:
> > "Could not find codec parameters for stream 1 (Unknown: none): unknown
> codec
> > Consider increasing the value for the 'analyzeduration' and 'probesize'
> > options"
> >
> > I'm not really sure about he AVI spec if the format is mandatory or not,
> > but i think there is a bug.
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
>
> AVI is not decoder
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Yes, i mean the demuxer, sorry (i mistake because the file is called
avidec.c).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] Possible minor bug found in AVI decoder

2017-05-12 Thread Paul B Mahol
On 5/12/17, Eric Beuque  wrote:
> Hi,
>
> i'm not really sure but i think a found a bug in the avi decoder of
> avformat.
>
> In the following function of the avidec.c:
>
> static int avi_read_header(AVFormatContext *s)
> {
> ...
> switch (tag) {
> ...
> case MKTAG('s', 't', 'r', 'f'):
> /* stream header */
> if (!size)
> break;
> if (stream_index >= (unsigned)s->nb_streams || avi->dv_demux) {
> avio_skip(pb, size);
> } else {
> ...
> switch (codec_type) {
> ...
> default:
> st->codec->codec_type = AVMEDIA_TYPE_DATA;
> st->codec->codec_id   = AV_CODEC_ID_NONE;
> st->codec->codec_tag  = 0;
> avio_skip(pb, size);
> break;
> }
> }
> break;
> ...
> }
>
> If the codec_type is AVMEDIA_TYPE_DATA, but the format is empty (size=0)
> (which i think is allowed), then the codec_id is not set to
> AV_CODEC_ID_NONE.
>
> This will generate a trace when calling the avformat_find_stream_info:
> "Could not find codec parameters for stream 1 (Unknown: none): unknown codec
> Consider increasing the value for the 'analyzeduration' and 'probesize'
> options"
>
> I'm not really sure about he AVI spec if the format is mandatory or not,
> but i think there is a bug.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

AVI is not decoder
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] Possible minor bug found in AVI decoder

2017-05-12 Thread Eric Beuque
Hi,

i'm not really sure but i think a found a bug in the avi decoder of
avformat.

In the following function of the avidec.c:

static int avi_read_header(AVFormatContext *s)
{
...
switch (tag) {
...
case MKTAG('s', 't', 'r', 'f'):
/* stream header */
if (!size)
break;
if (stream_index >= (unsigned)s->nb_streams || avi->dv_demux) {
avio_skip(pb, size);
} else {
...
switch (codec_type) {
...
default:
st->codec->codec_type = AVMEDIA_TYPE_DATA;
st->codec->codec_id   = AV_CODEC_ID_NONE;
st->codec->codec_tag  = 0;
avio_skip(pb, size);
break;
}
}
break;
...
}

If the codec_type is AVMEDIA_TYPE_DATA, but the format is empty (size=0)
(which i think is allowed), then the codec_id is not set to
AV_CODEC_ID_NONE.

This will generate a trace when calling the avformat_find_stream_info:
"Could not find codec parameters for stream 1 (Unknown: none): unknown codec
Consider increasing the value for the 'analyzeduration' and 'probesize'
options"

I'm not really sure about he AVI spec if the format is mandatory or not,
but i think there is a bug.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 1/3] configure: add cuda-sdk for things requiring full CUDA sdk

2017-05-12 Thread Timo Rothenpieler
Am 12.05.2017 um 07:32 schrieb Yogender Gupta:
>>> +cuda_sdk
>>> libnpp
> 
> IMO, Libnpp is part of the CUDA SDK, and we can remove all the libnpp related 
> changes and just replace it by cuda-sdk in the configure/make files.

True, but I'm not sure if an existing config parameter can be that
easily removed without breaking a bunch of existing build scripts.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel