date:20170407

[FFmpeg-devel] [PATCH] avfilter/avf_showcqt: add attack option

2017-04-07 Thread Muhammad Faiz

Signed-off-by: Muhammad Faiz 
---
 doc/filters.texi  |  5 +
 libavfilter/avf_showcqt.c | 39 ---
 libavfilter/avf_showcqt.h |  3 +++
 libavfilter/version.h |  2 +-
 4 files changed, 41 insertions(+), 8 deletions(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index 32720db..e002f25 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -17192,6 +17192,11 @@ event in time domain is represented more accurately 
(such as fast bass drum),
 otherwise event in frequency domain is represented more accurately
 (such as bass guitar). Acceptable range is @code{[0.002, 1]}. Default value is 
@code{0.17}.
 
+@item attack
+Set attack time in seconds. The default is @code{0} (disabled). Otherwise, it
+limits future samples by applying asymmetric windowing in time domain, useful
+when low latency is required. Accepted range is @code{[0, 1]}.
+
 @item basefreq
 Specify the transform base frequency. Default value is 
@code{20.01523126408007475},
 which is frequency 50 cents below E0. Acceptable range is @code{[10, 10]}.
diff --git a/libavfilter/avf_showcqt.c b/libavfilter/avf_showcqt.c
index ede56f4..7bc3a26 100644
--- a/libavfilter/avf_showcqt.c
+++ b/libavfilter/avf_showcqt.c
@@ -78,6 +78,7 @@ static const AVOption showcqt_options[] = {
 { "bar_t",  "set bar transparency", OFFSET(bar_t),  AV_OPT_TYPE_FLOAT, 
{ .dbl = 1.0 },0.0, 1.0,  FLAGS },
 { "timeclamp", "set timeclamp", OFFSET(timeclamp), AV_OPT_TYPE_DOUBLE, 
{ .dbl = 0.17 }, 0.002, 1.0,  FLAGS },
 { "tc","set timeclamp", OFFSET(timeclamp), AV_OPT_TYPE_DOUBLE, 
{ .dbl = 0.17 }, 0.002, 1.0,  FLAGS },
+{ "attack",  "set attack time", OFFSET(attack),AV_OPT_TYPE_DOUBLE, 
{ .dbl = 0 },  0.0, 1.0,  FLAGS },
 { "basefreq", "set base frequency", OFFSET(basefreq),  AV_OPT_TYPE_DOUBLE, 
{ .dbl = BASEFREQ },  10.0, 10.0, FLAGS },
 { "endfreq",   "set end frequency", OFFSET(endfreq),   AV_OPT_TYPE_DOUBLE, 
{ .dbl = ENDFREQ },   10.0, 10.0, FLAGS },
 { "coeffclamp",   "set coeffclamp", OFFSET(coeffclamp), AV_OPT_TYPE_FLOAT, 
{ .dbl = 1.0 },0.1, 10.0, FLAGS },
@@ -152,6 +153,7 @@ static void common_uninit(ShowCQTContext *s)
 av_freep(>fft_data);
 av_freep(>fft_result);
 av_freep(>cqt_result);
+av_freep(>attack_data);
 av_freep(>c_buf);
 av_freep(>h_buf);
 av_freep(>rcp_h_buf);
@@ -1138,6 +1140,14 @@ static int plot_cqt(AVFilterContext *ctx, AVFrame 
**frameout)
 last_time = av_gettime();
 
 memcpy(s->fft_result, s->fft_data, s->fft_len * sizeof(*s->fft_data));
+if (s->attack_data) {
+int k;
+for (k = 0; k < s->remaining_fill_max; k++) {
+s->fft_result[s->fft_len/2+k].re *= s->attack_data[k];
+s->fft_result[s->fft_len/2+k].im *= s->attack_data[k];
+}
+}
+
 av_fft_permute(s->fft_ctx, s->fft_result);
 av_fft_calc(s->fft_ctx, s->fft_result);
 s->fft_result[s->fft_len] = s->fft_result[0];
@@ -1377,6 +1387,21 @@ static int config_output(AVFilterLink *outlink)
 if (!s->fft_ctx || !s->fft_data || !s->fft_result || !s->cqt_result)
 return AVERROR(ENOMEM);
 
+s->remaining_fill_max = s->fft_len / 2;
+if (s->attack > 0.0) {
+int k;
+
+s->remaining_fill_max = FFMIN(s->remaining_fill_max, 
ceil(inlink->sample_rate * s->attack));
+s->attack_data = av_malloc_array(s->remaining_fill_max, 
sizeof(*s->attack_data));
+if (!s->attack_data)
+return AVERROR(ENOMEM);
+
+for (k = 0; k < s->remaining_fill_max; k++) {
+double y = M_PI * k / (inlink->sample_rate * s->attack);
+s->attack_data[k] = 0.355768 + 0.487396 * cos(y) + 0.144232 * 
cos(2*y) + 0.012604 * cos(3*y);
+}
+}
+
 s->cqt_align = 1;
 s->cqt_calc = cqt_calc;
 s->permute_coeffs = NULL;
@@ -1435,7 +1460,7 @@ static int config_output(AVFilterLink *outlink)
 s->sono_count = 0;
 s->next_pts = 0;
 s->sono_idx = 0;
-s->remaining_fill = s->fft_len / 2;
+s->remaining_fill = s->remaining_fill_max;
 s->remaining_frac = 0;
 s->step_frac = av_div_q(av_make_q(inlink->sample_rate, s->count) , 
s->rate);
 s->step = (int)(s->step_frac.num / s->step_frac.den);
@@ -1463,15 +1488,15 @@ static int filter_frame(AVFilterLink *inlink, AVFrame 
*insamples)
 AVFrame *out = NULL;
 
 if (!insamples) {
-while (s->remaining_fill < s->fft_len / 2) {
-memset(>fft_data[s->fft_len - s->remaining_fill], 0, 
sizeof(*s->fft_data) * s->remaining_fill);
+while (s->remaining_fill < s->remaining_fill_max) {
+memset(>fft_data[s->fft_len/2 + s->remaining_fill_max - 
s->remaining_fill], 0, sizeof(*s->fft_data) * s->remaining_fill);
 ret = plot_cqt(ctx, );
 if (ret < 0)
 return ret;
 
 step = s->step + (s->step_frac.num

[FFmpeg-devel] [PATCH 1/2] avcodec/mjpegenc_huffman: Assert length in ff_mjpegenc_huffman_compute_bits()

2017-04-07 Thread Michael Niedermayer

This should help coverity see that the issues this leads to cannot occur

Signed-off-by: Michael Niedermayer 
---
 libavcodec/mjpegenc_huffman.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavcodec/mjpegenc_huffman.c b/libavcodec/mjpegenc_huffman.c
index ebf1311466..0e63f8066b 100644
--- a/libavcodec/mjpegenc_huffman.c
+++ b/libavcodec/mjpegenc_huffman.c
@@ -87,6 +87,8 @@ void ff_mjpegenc_huffman_compute_bits(PTable *prob_table, 
HuffTable *distincts,
 
 int min;
 
+av_assert0(max_length > 0);
+
 to->nitems = 0;
 from->nitems = 0;
 to->item_idx[0] = 0;
-- 
2.11.0

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

[FFmpeg-devel] [PATCH 2/2] avcodec/pixlet: Reorder rlen check

2017-04-07 Thread Michael Niedermayer

This changes nothing but is nicer looking as this checks rlen

Maybe this helps coverity remove CID1397743

Signed-off-by: Michael Niedermayer 
---
 libavcodec/pixlet.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/pixlet.c b/libavcodec/pixlet.c
index 4aa59f8f33..c4f7597866 100644
--- a/libavcodec/pixlet.c
+++ b/libavcodec/pixlet.c
@@ -173,7 +173,7 @@ static int read_low_coeffs(AVCodecContext *avctx, int16_t 
*dst, int size, int wi
 }
 }
 
-if (i + rlen > size)
+if (rlen > size - i)
 return AVERROR_INVALIDDATA;
 i += rlen;
 
-- 
2.11.0

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

Re: [FFmpeg-devel] [PATCH] Observe Set-Cookie headers in HLS streams

2017-04-07 Thread Micah Galizia



On 2017-04-07 02:48 AM, wm4 wrote:

On Thu,  6 Apr 2017 22:48:59 -0400
Micah Galizia   wrote:


Signed-off-by: Micah Galizia 

---
  libavformat/hls.c | 10 --
  1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/libavformat/hls.c b/libavformat/hls.c
index bac53a4..ab81863 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -630,8 +630,14 @@ static int open_url(AVFormatContext *s, AVIOContext **pb, 
const char *url,
  ret = s->io_open(s, pb, url, AVIO_FLAG_READ, );
  if (ret >= 0) {
  // update cookies on http response with setcookies.
-void *u = (s->flags & AVFMT_FLAG_CUSTOM_IO) ? NULL : s->pb;
-update_options(>cookies, "cookies", u);
+char *new_cookies = NULL;
+
+av_opt_get(*pb, "cookies", AV_OPT_SEARCH_CHILDREN, 
(uint8_t**)_cookies);
+if (new_cookies) {
+av_free(c->cookies);
+c->cookies = new_cookies;
+}
+
  av_dict_set(, "cookies", c->cookies, 0);
  }
  

So far, all code is doing the same thing by calling update_options()
on pb, or NULL if it's a custom IO context.

What you seem to change is always using the pb (even if it's a custom
context), duplicating the update_options() code (subtly changing some
corner case behavior), and, this is probably the important one, you use
*pb instead of s->pb.


True. But, the cookies option of *pb comes back NULL _unless_ they are 
updated, so we should check first before replacing. I could also update 
update_options, but that is probably overkill.  I haven't really chased 
down the reason why the cookies sometimes come back (if they get 
changed) and sometimes don't.



I suspect the latter is the only change that matters, and you probably
want:

void *u = (s->flags & AVFMT_FLAG_CUSTOM_IO) ? NULL : *pb;


Yes, but then IIRC the flag was always set and we would actually try to 
pull cookies from NULL, which you allude to below.  Also, without the 
ternary assignment, u is just *pb, so why create another variable?



Now I have no idea why it checks "s->flags & AVFMT_FLAG_CUSTOM_IO", or
what it means, but it feels very wrong. A common case is probably that
the main playlist is accessed through a custom AVIOContext, but further
nested playlists or actual .ts data probably use libavformat's code.

I'm thinking that all uses of AVFMT_FLAG_CUSTOM_IO anywhere are
probably bugs.


I'm happy to take it out the check for AVFMT_FLAG_CUSTOM_IO -- there are 
only two and on the streams I tested it had no effect. However, I was 
hoping someone could explain why its there. If someone wants to write 
back and explain I'd appreciate it, otherwise, I'll send a patch to get 
rid of it.


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

Re: [FFmpeg-devel] Fix leaked dictionary in mp3dec

2017-04-07 Thread Thomas Guilbert

In Chromium code, we set s->metadata ahead of time, with a custom entry to
avoid id3v1 tag parsing.

Some recent changes in mp3dec.c meant that we had to update this code, and
in the process, we discovered this reference leak on our end.

I am submitting this patch as a general code hardening patch. I also
understand if our use case is unusual and that one may assume that
s->metadata is always NULL.

On Thu, Apr 6, 2017 at 11:32 PM, wm4  wrote:

> On Thu, 6 Apr 2017 14:07:53 -0700
> Thomas Guilbert  wrote:
>
> > The patch didn't show up as properly formatted on
> > https://patchwork.ffmpeg.org/patch/3228/.
> >
> > Re-submitting using no line wrap in the base64 attachment, and copying
> the
> > contents of the patch for ease of review:
> >
> > From fced5ab0e09f529397adddcb560d1a08f2df4840 Mon Sep 17 00:00:00 2001
> > From: Thomas Guilbert 
> > Date: Thu, 30 Mar 2017 18:23:29 -0700
> > Subject: [PATCH] Fix dictionnary leak in mp3dec
> >
> > ---
> >  libavformat/mp3dec.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c
> > index 0924a57843..fd8184cc0b 100644
> > --- a/libavformat/mp3dec.c
> > +++ b/libavformat/mp3dec.c
> > @@ -349,6 +349,7 @@ static int mp3_read_header(AVFormatContext *s)
> >  int ret;
> >  int i;
> >
> > +av_dict_free(>metadata);
> >  s->metadata = s->internal->id3v2_meta;
> >  s->internal->id3v2_meta = NULL;
> >
>
> So in which situations is s->metadata not NULL?
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v12] avformat/dashdec: add dash demuxer base version

2017-04-07 Thread Andy Furniss


Steven Liu wrote:

ffmpeg need a dash demuxer for demux the dash formats
base on
https://github.com/samsamsam-iptvplayer/exteplayer3/blob/master/tmp/ffmpeg/patches/3.2.2/01_add_dash_demux.patch


Just a user, this will be a good feature.

This patch doesn't seem to work with say -

http://dash.edgesuite.net/akamai/bbb_30fps/bbb_30fps.mpd

Of course that base url is ./ - but I can change that or I can
grab the content and make a local setup to match.

Either way this doesn't seem to replace $Number$ properly/in time so I
get an error.

ffmpeg -loglevel debug  -i bbb_30fps-mod.mpd -f null -
ffmpeg version N-85325-g9c7ee37 Copyright (c) 2000-2017 the FFmpeg 
developers

  built with gcc 5.3.0 (GCC)
  configuration: --prefix=/usr --disable-doc --enable-gpl --enable-omx 
--enable-opencl --enable-libvpx --enable-libx265 --enable-libmp3lame 
--enable-libx264 --enable-gnutls --enable-libxml2

  libavutil  55. 60.100 / 55. 60.100
  libavcodec 57. 92.100 / 57. 92.100
  libavformat57. 72.100 / 57. 72.100
  libavdevice57.  7.100 / 57.  7.100
  libavfilter 6. 84.100 /  6. 84.100
  libswscale  4.  7.100 /  4.  7.100
  libswresample   2.  8.100 /  2.  8.100
  libpostproc54.  6.100 / 54.  6.100
Splitting the commandline.
Reading option '-loglevel' ... matched as option 'loglevel' (set logging 
level) with argument 'debug'.
Reading option '-i' ... matched as input url with argument 
'bbb_30fps-mod.mpd'.
Reading option '-f' ... matched as option 'f' (force format) with 
argument 'null'.

Reading option '-' ... matched as output url.
Finished splitting the commandline.
Parsing a group of options: global .
Applying option loglevel (set logging level) with argument debug.
Successfully parsed a group of options.
Parsing a group of options: input url bbb_30fps-mod.mpd.
Successfully parsed a group of options.
Opening an input file: bbb_30fps-mod.mpd.
[file @ 0x2ce4b80] Setting default whitelist 'file,crypto'
[dash @ 0x2ce4320] Format dash probed with size=2048 and score=100
[dash @ 0x2ce4320] rep_idx[0]
[dash @ 0x2ce4320] rep_count[0]
[dash @ 0x2ce4320] Invalid segment filename template 
http://dash.edgesuite.net/akamai/bbb_30fps/bbb_30fps_1024x576_2500k/bbb_30fps_1024x576_2500k_$Number$.m4v

Last message repeated 5 times
[dash @ 0x2ce4320] Error when loading first fragment, playlist 0
[AVIOContext @ 0x2cecec0] Statistics: 3101 bytes read, 0 seeks
bbb_30fps-mod.mpd: Invalid data found when processing input

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

[FFmpeg-devel] [PATCH 1/2] avcodec/dcadsp: Fix runtime error: signed integer overflow

2017-04-07 Thread Michael Niedermayer

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/dcadsp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/dcadsp.c b/libavcodec/dcadsp.c
index 4f1e933cfb..fade1a6c02 100644
--- a/libavcodec/dcadsp.c
+++ b/libavcodec/dcadsp.c
@@ -320,7 +320,7 @@ static void dmix_sub_c(int32_t *dst, const int32_t *src, 
int coeff, ptrdiff_t le
 int i;
 
 for (i = 0; i < len; i++)
-dst[i] -= mul15(src[i], coeff);
+dst[i] -= (unsigned)mul15(src[i], coeff);
 }
 
 static void dmix_add_c(int32_t *dst, const int32_t *src, int coeff, ptrdiff_t 
len)
-- 
2.11.0

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

[FFmpeg-devel] [PATCH 2/2] doc/examples/decode_video: Fix format string vulnerability

2017-04-07 Thread Michael Niedermayer

Fixes: CID1404843

Signed-off-by: Michael Niedermayer 
---
 doc/examples/decode_video.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/examples/decode_video.c b/doc/examples/decode_video.c
index 613bc5cc88..4377fd49e0 100644
--- a/doc/examples/decode_video.c
+++ b/doc/examples/decode_video.c
@@ -74,7 +74,7 @@ static void decode(AVCodecContext *dec_ctx, AVFrame *frame, 
AVPacket *pkt,
 
 /* the picture is allocated by the decoder. no need to
free it */
-snprintf(buf, sizeof(buf), filename, dec_ctx->frame_number);
+snprintf(buf, sizeof(buf), "%s-%d", filename, dec_ctx->frame_number);
 pgm_save(frame->data[0], frame->linesize[0],
  frame->width, frame->height, buf);
 }
-- 
2.11.0

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

Re: [FFmpeg-devel] [PATCH] vf_pad: center image on padded area if negative x/y

2017-04-07 Thread Rostislav Pehlivanov

On 3 April 2017 at 19:34, Ricardo Constantino  wrote:

> or if x/y go beyond padded area.
>
> This is mostly useful when paired with the aspect option.
> Defaults aren't changed.
>
> Idea for this was taken from mpv's soon-to-be-removed expand vf.
> ---
>  doc/filters.texi |  3 +++
>  libavfilter/vf_pad.c | 12 +++-
>  2 files changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/doc/filters.texi b/doc/filters.texi
> index bc37e667e0..32720dba41 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -10430,6 +10430,9 @@ expression, and vice versa.
>
>  The default value of @var{x} and @var{y} is 0.
>
> +If @var{x} or @var{y} evaluate to a negative number, they'll be changed
> +so the input image is centered on the padded area.
> +
>  @item color
>  Specify the color of the padded area. For the syntax of this option,
>  check the "Color" section in the ffmpeg-utils manual.
> diff --git a/libavfilter/vf_pad.c b/libavfilter/vf_pad.c
> index 5b81379691..757170e742 100644
> --- a/libavfilter/vf_pad.c
> +++ b/libavfilter/vf_pad.c
> @@ -173,8 +173,13 @@ static int config_input(AVFilterLink *inlink)
>  goto eval_fail;
>  s->x = var_values[VAR_X] = res;
>
> +if (s->x < 0 || s->x + inlink->w > s->w)
> +s->x = var_values[VAR_X] = (s->w - inlink->w) / 2;
> +if (s->y < 0 || s->y + inlink->h > s->h)
> +s->y = var_values[VAR_Y] = (s->h - inlink->h) / 2;
> +
>  /* sanity check params */
> -if (s->w < 0 || s->h < 0 || s->x < 0 || s->y < 0) {
> +if (s->w < 0 || s->h < 0) {
>  av_log(ctx, AV_LOG_ERROR, "Negative values are not
> acceptable.\n");
>  return AVERROR(EINVAL);
>  }
> @@ -192,10 +197,7 @@ static int config_input(AVFilterLink *inlink)
> inlink->w, inlink->h, s->w, s->h, s->x, s->y,
> s->rgba_color[0], s->rgba_color[1], s->rgba_color[2],
> s->rgba_color[3]);
>
> -if (s->x <  0 || s->y <  0  ||
> -s->w <= 0 || s->h <= 0  ||
> -(unsigned)s->x + (unsigned)inlink->w > s->w ||
> -(unsigned)s->y + (unsigned)inlink->h > s->h) {
> +if (s->w <= 0 || s->h <= 0) {
>  av_log(ctx, AV_LOG_ERROR,
> "Input area %d:%d:%d:%d not within the padded area
> 0:0:%d:%d or zero-sized\n",
> s->x, s->y, s->x + inlink->w, s->y + inlink->h, s->w,
> s->h);
> --
> 2.12.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>


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

Re: [FFmpeg-devel] [PATCH 3/5] avcodec/hevc_parse: ignore all non parameter set NAL units in extradata

2017-04-07 Thread James Almer

On 4/3/2017 7:04 AM, Michael Niedermayer wrote:
> On Sun, Apr 02, 2017 at 10:45:43PM -0300, James Almer wrote:
>> While they shouldn't be present, they are harmless if they are.
>>
>> Signed-off-by: James Almer 
>> ---
>>  libavcodec/hevc_parse.c | 21 ++---
>>  1 file changed, 2 insertions(+), 19 deletions(-)
> 
> should be ok but maybe wait before applying so others can comment too

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

Re: [FFmpeg-devel] [PATCH v2] lavf: use the new bitstream filter for extracting extradata

2017-04-07 Thread James Almer

On 4/5/2017 6:22 PM, James Almer wrote:
> On 4/1/2017 9:03 PM, James Almer wrote:
>> This merges commits 8e2ea691351c5079cdab245ff7bfa5c0f3e3bfe4 and
>> 096a8effa3f8f3455292c958c3ed07e798def7bd by Anton Khirnov, with the
>> following change:
>>
>> - extract_extradata_check() is added to know if the codec is supported
>> by the bsf before trying to initialize it. This behaviour is similar to
>> the old AVCodecParser.split checks.
>>
>> The FATE reference changes are due to the filtered out NAL units that
>> the old AVCodecParser.split implementation left alone.
>> Decoding is unchanged as the functions that parse extradata simply
>> ignored said unnecessary NAL units.
>>
>> Signed-off-by: James Almer 
>> ---
>>  libavformat/internal.h   |   9 ++
>>  libavformat/utils.c  | 146 
>> ---
>>  tests/ref/fate/copy-trac2211-avi |   4 +-
>>  tests/ref/fate/h264_mp4toannexb_ticket2991   |   2 +-
>>  tests/ref/fate/h264_mp4toannexb_ticket5927   |   2 +-
>>  tests/ref/fate/h264_mp4toannexb_ticket5927_2 |   2 +-
>>  tests/ref/fate/segment-mp4-to-ts |   2 +-
>>  7 files changed, 148 insertions(+), 19 deletions(-)
> 
> I'll be pushing this soon.

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

Re: [FFmpeg-devel] [PATCH] ffmpeg: use av_stream_new_side_data()

2017-04-07 Thread James Almer

On 12/26/2016 6:36 PM, James Almer wrote:
> Signed-off-by: James Almer 
> ---
>  ffmpeg.c | 17 -
>  1 file changed, 4 insertions(+), 13 deletions(-)
> 
> diff --git a/ffmpeg.c b/ffmpeg.c
> index ec9da3e..a1c02ca 100644
> --- a/ffmpeg.c
> +++ b/ffmpeg.c
> @@ -2916,26 +2916,17 @@ static int init_output_stream_streamcopy(OutputStream 
> *ost)
>  ost->st->disposition = ist->st->disposition;
>  
>  if (ist->st->nb_side_data) {
> -ost->st->side_data = av_realloc_array(NULL, ist->st->nb_side_data,
> -  sizeof(*ist->st->side_data));
> -if (!ost->st->side_data)
> -return AVERROR(ENOMEM);
> -
> -ost->st->nb_side_data = 0;
>  for (i = 0; i < ist->st->nb_side_data; i++) {
>  const AVPacketSideData *sd_src = >st->side_data[i];
> -AVPacketSideData *sd_dst = 
> >st->side_data[ost->st->nb_side_data];
> +uint8_t *dst_data;
>  
>  if (ost->rotate_overridden && sd_src->type == 
> AV_PKT_DATA_DISPLAYMATRIX)
>  continue;
>  
> -sd_dst->data = av_malloc(sd_src->size);
> -if (!sd_dst->data)
> +dst_data = av_stream_new_side_data(ost->st, sd_src->type, 
> sd_src->size);
> +if (!dst_data)
>  return AVERROR(ENOMEM);
> -memcpy(sd_dst->data, sd_src->data, sd_src->size);
> -sd_dst->size = sd_src->size;
> -sd_dst->type = sd_src->type;
> -ost->st->nb_side_data++;
> +memcpy(dst_data, sd_src->data, sd_src->size);
>  }
>  }

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

Re: [FFmpeg-devel] Patch: filter af_amix inputs

2017-04-07 Thread John Warburton

On Fri, Apr 7, 2017 at 10:25 AM, Michael Niedermayer
 wrote:
>
> this patch is corrupted by linebreaks

I'm sorry about that. It's attached to this email, from a file made by
git format-patch.
J
--
John Warburton
Tonmeister, Director,
Associate Lecturer, University of Surrey Department of Music and Media


0001-libavfilter-af_amix.c-Increase-sources-from-32-to-10.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libopus: Add channel mapping 2 support in libopusdec

2017-04-07 Thread Felicia Lim

Hi,

Just wanted to follow up and check if there any changes I should add to
this patch?

Thanks for taking a look.

Felicia

On Mon, Mar 27, 2017 at 5:35 PM Felicia Lim  wrote:

> Hi all,
>
> Here is another patch to decode Opus ambisonics files using channel
> mapping 2 [1], this time in libopusdec.c.
>
> Please let me know if there are any concerns.
>
> Thanks,
> Felicia
>
> [1] 
> *https://trac.tools.ietf.org/html/draft-ietf-codec-ambisonics-02#section-3.1
> *
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avutil/internal: Do not enable CHECKED with DEBUG

2017-04-07 Thread Ronald S. Bultje

Hi,

On Fri, Apr 7, 2017 at 7:49 AM, Michael Niedermayer 
wrote:

> This avoids potential undefined behavior in debug mode while still allowing
> developers which want to check for potential additional overflows to do so
> by manually enabling this.
>
> Signed-off-by: Michael Niedermayer 
> ---
>  libavutil/internal.h | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/libavutil/internal.h b/libavutil/internal.h
> index 7780a9a791..70ae37f859 100644
> --- a/libavutil/internal.h
> +++ b/libavutil/internal.h
> @@ -30,9 +30,8 @@
>  #define NDEBUG
>  #endif
>
> -#if defined(DEBUG) && !defined(CHECKED)
> -#define CHECKED
> -#endif
> +// This can be enabld to allow detection of additional integer overflows
> with ubsan
> +//#define CHECKED


s/enabld/enabled/.

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

Re: [FFmpeg-devel] [PATCH] avcodec/mjpegdec: Fixes runtime error: signed integer overflow: -24543 * 2031616 cannot be represented in type 'int'

2017-04-07 Thread Michael Niedermayer

On Fri, Apr 07, 2017 at 07:46:01AM -0400, Ronald S. Bultje wrote:
> Hi,
> 
> On Fri, Apr 7, 2017 at 6:47 AM, Michael Niedermayer 
> wrote:
> 
> > On Fri, Apr 07, 2017 at 06:26:05AM -0400, Ronald S. Bultje wrote:
> > > On Fri, Apr 7, 2017 at 6:22 AM, Michael Niedermayer
> > 
> > > > Id like to apply the patch unless you or someone else objects.
> > >
> > > I really don't like this approach. I'd like you to try to find something
> > > more sensible that protects developer machines from bugs also.
> >
> > i suggested to decouple SUINT from the #ifdef DEBUG, which fixes
> > exactly that possibility (and noone seemed to care)
> 
> 
> You asked - in this email - to apply this patch as-is. The patch does not
> decouple #ifdef DEBUG from SUINT.

I suggested it previously to decouple them.
This patch is in no way related to the coupling, with or without the
coupling the patch wouldnt change

> 
> Now the question is whether SUINT has any raison d'etre in our main
> codebase. If it's under #if 0 or otherwise "dead code", any Diego'ification
> would immediately get rid of it. So answer me this question: if the code is
> under #if 0, why shouldn't it just exist locally on your hard disk only?

as has been said many times SUINT is essential to test for one class
of bugs with ubsan.
If its in a private branch, only i would test with it, only i would
maintain it until i lost interrest and it bit rots, if that happens
we lose the ability to test for this class of bugs

do people want this ?

>
> (Yes, I have actual (old) debug branches for the vp9 decoder locally.)

i have all kinds of branches too, but this isnt specific to a single
codec or a single developer

Do you maintain some branch that contains type changes
accorss the codebase that you know you will need repeatly in the
future ?

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

If you drop bombs on a foreign country and kill a hundred thousand
innocent people, expect your government to call the consequence
"unprovoked inhuman terrorist attacks" and use it to justify dropping
more bombs and killing more people. The technology changed, the idea is old.

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

Re: [FFmpeg-devel] [PATCH] pthread_frame: make accesses to debug field be protected by owner lock.

2017-04-07 Thread wm4

On Fri, 7 Apr 2017 08:30:00 -0400
"Ronald S. Bultje"  wrote:

> Hi,
> 
> On Fri, Apr 7, 2017 at 2:37 AM, wm4  wrote:
> 
> > On Thu,  6 Apr 2017 13:48:41 -0400
> > "Ronald S. Bultje"  wrote:
> >  
> > > The av_log() is done outside the lock, but this way the accesses to the
> > > field (reads and writes) are always protected by a mutex. The av_log()
> > > is not run inside the lock context because it may involve user callbacks
> > > and doing that in performance-sensitive code is probably not a good idea.
> > >
> > > This should fix occasional tsan warnings when running fate-h264, like:
> > >
> > > WARNING: ThreadSanitizer: data race (pid=10916)
> > >   Write of size 4 at 0x7d64000174fc by main thread (mutexes: write  
> > M2313):  
> > > #0 update_context_from_user src/libavcodec/pthread_frame.c:335  
> > (ffmpeg+0x00df7b06)  
> > > [..]
> > >   Previous read of size 4 at 0x7d64000174fc by thread T1 (mutexes: write  
> > M2311):  
> > > #0 ff_thread_await_progress src/libavcodec/pthread_frame.c:592  
> > (ffmpeg+0x00df8b3e)  
> > > ---
> > >  libavcodec/pthread_frame.c | 20 
> > >  1 file changed, 12 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c
> > > index c246c2f..8857bfc 100644
> > > --- a/libavcodec/pthread_frame.c
> > > +++ b/libavcodec/pthread_frame.c
> > > @@ -559,6 +559,7 @@ void ff_thread_report_progress(ThreadFrame *f, int  
> > n, int field)  
> > >  {
> > >  PerThreadContext *p;
> > >  atomic_int *progress = f->progress ? (atomic_int*)f->progress->data  
> > : NULL;  
> > > +int debug_mv;
> > >
> > >  if (!progress ||
> > >  atomic_load_explicit([field], memory_order_relaxed)
> > >= n)
> > > @@ -566,22 +567,24 @@ void ff_thread_report_progress(ThreadFrame *f,  
> > int n, int field)  
> > >
> > >  p = f->owner[field]->internal->thread_ctx;
> > >
> > > -if (f->owner[field]->debug_DEBUG_THREADS)
> > > -av_log(f->owner[field], AV_LOG_DEBUG,
> > > -   "%p finished %d field %d\n", progress, n, field);
> > > -
> > >  pthread_mutex_lock(>progress_mutex);
> > > +debug_mv = f->owner[field]->debug_DEBUG_THREADS;
> > >
> > >  atomic_store_explicit([field], n, memory_order_release);
> > >
> > >  pthread_cond_broadcast(>progress_cond);
> > >  pthread_mutex_unlock(>progress_mutex);
> > > +
> > > +if (debug_mv)
> > > +av_log(f->owner[field], AV_LOG_DEBUG,
> > > +   "%p finished %d field %d\n", progress, n, field);
> > >  }
> > >
> > >  void ff_thread_await_progress(ThreadFrame *f, int n, int field)
> > >  {
> > >  PerThreadContext *p;
> > >  atomic_int *progress = f->progress ? (atomic_int*)f->progress->data  
> > : NULL;  
> > > +int debug_mv;
> > >
> > >  if (!progress ||
> > >  atomic_load_explicit([field], memory_order_acquire)
> > >= n)
> > > @@ -589,14 +592,15 @@ void ff_thread_await_progress(ThreadFrame *f, int  
> > n, int field)  
> > >
> > >  p = f->owner[field]->internal->thread_ctx;
> > >
> > > -if (f->owner[field]->debug_DEBUG_THREADS)
> > > -av_log(f->owner[field], AV_LOG_DEBUG,
> > > -   "thread awaiting %d field %d from %p\n", n, field,  
> > progress);  
> > > -
> > >  pthread_mutex_lock(>progress_mutex);
> > > +debug_mv = f->owner[field]->debug_DEBUG_THREADS;
> > >  while (atomic_load_explicit([field],  
> > memory_order_relaxed) < n)  
> > >  pthread_cond_wait(>progress_cond, >progress_mutex);
> > >  pthread_mutex_unlock(>progress_mutex);
> > > +
> > > +if (debug_mv)
> > > +av_log(f->owner[field], AV_LOG_DEBUG,
> > > +   "thread awaited %d field %d from %p\n", n, field,  
> > progress);  
> > >  }
> > >
> > >  void ff_thread_finish_setup(AVCodecContext *avctx) {  
> >
> > I'm not sure what "debug_mv" stands for, and I think this is a bit
> > overkill. It's run only when FF_DEBUG_THREADS is set (who even sets
> > that,  
> 
> 
> I actually occasionally use it.
> 
> and why does access to it need to be synchronized?),
> 
> 
> Now that's a really good question.
> 
> Let me give my explanation (which is probably similar to Clement's) and
> then we can see if others agree with it.
> 
> So first of all: is there a race condition here? Really, no. Sort of. A
> race condition is (for me) non-static behaviour in output in response to
> otherwise identical input. So imagine the following code fragment:
> 
> avctx = alloc(threads=2); open(avctx);
> for (i=0;i<5;i++)
> decode(avctx, frame);
> close(avctx);
> 
> Is there a race condition (with my definition)? No. The code will always
> give the same return values. Now, let's look at this code fragment:
> 
> avctx = alloc(threads=2); open(avctx);
> for (i=0;i<5;i++) {
> decode(avctx, frame);
> if (i == 2) { avctx->debug |= THREADS; av_log_set_level(DEBUG); }
> }
> close(avctx);
> 
> Here,

Re: [FFmpeg-devel] [PATCH] avutil/internal: Do not enable CHECKED with DEBUG

2017-04-07 Thread wm4

On Fri,  7 Apr 2017 13:49:09 +0200
Michael Niedermayer  wrote:

> This avoids potential undefined behavior in debug mode while still allowing
> developers which want to check for potential additional overflows to do so
> by manually enabling this.
> 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavutil/internal.h | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/libavutil/internal.h b/libavutil/internal.h
> index 7780a9a791..70ae37f859 100644
> --- a/libavutil/internal.h
> +++ b/libavutil/internal.h
> @@ -30,9 +30,8 @@
>  #define NDEBUG
>  #endif
>  
> -#if defined(DEBUG) && !defined(CHECKED)
> -#define CHECKED
> -#endif
> +// This can be enabld to allow detection of additional integer overflows 
> with ubsan
> +//#define CHECKED
>  
>  #include 
>  #include 

I think the SUINT stuff should be removed completely, but for now I
think this patch improves the situation, so LGTM.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] pthread_frame: make accesses to debug field be protected by owner lock.

2017-04-07 Thread Ronald S. Bultje

Hi,

On Fri, Apr 7, 2017 at 2:37 AM, wm4  wrote:

> On Thu,  6 Apr 2017 13:48:41 -0400
> "Ronald S. Bultje"  wrote:
>
> > The av_log() is done outside the lock, but this way the accesses to the
> > field (reads and writes) are always protected by a mutex. The av_log()
> > is not run inside the lock context because it may involve user callbacks
> > and doing that in performance-sensitive code is probably not a good idea.
> >
> > This should fix occasional tsan warnings when running fate-h264, like:
> >
> > WARNING: ThreadSanitizer: data race (pid=10916)
> >   Write of size 4 at 0x7d64000174fc by main thread (mutexes: write
> M2313):
> > #0 update_context_from_user src/libavcodec/pthread_frame.c:335
> (ffmpeg+0x00df7b06)
> > [..]
> >   Previous read of size 4 at 0x7d64000174fc by thread T1 (mutexes: write
> M2311):
> > #0 ff_thread_await_progress src/libavcodec/pthread_frame.c:592
> (ffmpeg+0x00df8b3e)
> > ---
> >  libavcodec/pthread_frame.c | 20 
> >  1 file changed, 12 insertions(+), 8 deletions(-)
> >
> > diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c
> > index c246c2f..8857bfc 100644
> > --- a/libavcodec/pthread_frame.c
> > +++ b/libavcodec/pthread_frame.c
> > @@ -559,6 +559,7 @@ void ff_thread_report_progress(ThreadFrame *f, int
> n, int field)
> >  {
> >  PerThreadContext *p;
> >  atomic_int *progress = f->progress ? (atomic_int*)f->progress->data
> : NULL;
> > +int debug_mv;
> >
> >  if (!progress ||
> >  atomic_load_explicit([field], memory_order_relaxed)
> >= n)
> > @@ -566,22 +567,24 @@ void ff_thread_report_progress(ThreadFrame *f,
> int n, int field)
> >
> >  p = f->owner[field]->internal->thread_ctx;
> >
> > -if (f->owner[field]->debug_DEBUG_THREADS)
> > -av_log(f->owner[field], AV_LOG_DEBUG,
> > -   "%p finished %d field %d\n", progress, n, field);
> > -
> >  pthread_mutex_lock(>progress_mutex);
> > +debug_mv = f->owner[field]->debug_DEBUG_THREADS;
> >
> >  atomic_store_explicit([field], n, memory_order_release);
> >
> >  pthread_cond_broadcast(>progress_cond);
> >  pthread_mutex_unlock(>progress_mutex);
> > +
> > +if (debug_mv)
> > +av_log(f->owner[field], AV_LOG_DEBUG,
> > +   "%p finished %d field %d\n", progress, n, field);
> >  }
> >
> >  void ff_thread_await_progress(ThreadFrame *f, int n, int field)
> >  {
> >  PerThreadContext *p;
> >  atomic_int *progress = f->progress ? (atomic_int*)f->progress->data
> : NULL;
> > +int debug_mv;
> >
> >  if (!progress ||
> >  atomic_load_explicit([field], memory_order_acquire)
> >= n)
> > @@ -589,14 +592,15 @@ void ff_thread_await_progress(ThreadFrame *f, int
> n, int field)
> >
> >  p = f->owner[field]->internal->thread_ctx;
> >
> > -if (f->owner[field]->debug_DEBUG_THREADS)
> > -av_log(f->owner[field], AV_LOG_DEBUG,
> > -   "thread awaiting %d field %d from %p\n", n, field,
> progress);
> > -
> >  pthread_mutex_lock(>progress_mutex);
> > +debug_mv = f->owner[field]->debug_DEBUG_THREADS;
> >  while (atomic_load_explicit([field],
> memory_order_relaxed) < n)
> >  pthread_cond_wait(>progress_cond, >progress_mutex);
> >  pthread_mutex_unlock(>progress_mutex);
> > +
> > +if (debug_mv)
> > +av_log(f->owner[field], AV_LOG_DEBUG,
> > +   "thread awaited %d field %d from %p\n", n, field,
> progress);
> >  }
> >
> >  void ff_thread_finish_setup(AVCodecContext *avctx) {
>
> I'm not sure what "debug_mv" stands for, and I think this is a bit
> overkill. It's run only when FF_DEBUG_THREADS is set (who even sets
> that,


I actually occasionally use it.

and why does access to it need to be synchronized?),


Now that's a really good question.

Let me give my explanation (which is probably similar to Clement's) and
then we can see if others agree with it.

So first of all: is there a race condition here? Really, no. Sort of. A
race condition is (for me) non-static behaviour in output in response to
otherwise identical input. So imagine the following code fragment:

avctx = alloc(threads=2); open(avctx);
for (i=0;i<5;i++)
decode(avctx, frame);
close(avctx);

Is there a race condition (with my definition)? No. The code will always
give the same return values. Now, let's look at this code fragment:

avctx = alloc(threads=2); open(avctx);
for (i=0;i<5;i++) {
decode(avctx, frame);
if (i == 2) { avctx->debug |= THREADS; av_log_set_level(DEBUG); }
}
close(avctx);

Here, a week ago, you got a race condition because user threads would be
synchronized with the next worker thread unlocked, thus allowing
debug to be updated mid-frame in an active thread. This was fixed
in 1269cd5.

Is this a big deal? No, honestly. But it's sort-of a race. If you wanted to
debug threading, at least it know always produces the same output.

This patch does not solve a race of that kind. It

Re: [FFmpeg-devel] [PATCH] vf_framestep: add blend parameter for motion blur effect

2017-04-07 Thread Matthias Troffaes

On Thu, Apr 6, 2017 at 5:00 PM, Michael Niedermayer
 wrote:
> On Thu, Apr 06, 2017 at 02:09:46PM +0100, Matthias Troffaes wrote:
>> Many thanks for your feedback, Michael and Nicolas.
>>
>> On Wed, Apr 5, 2017 at 7:02 PM, Michael Niedermayer
>>  wrote:
>> > fails on qemu mips
>>
>> Thank you for flagging this failure. I'm currently trying to reproduce
>> the problem. May I ask what toolchain you typically use to compile to
>> mips? (I'm trying debian malta on qemu-system-mips, but it seems that
>> the configure script can't correctly set up config.h in that
>> environment.)
>
> its a really old cross compiler from the no longer existing emdebian
>
> i also have a native loongson system but that is less convenient to
> test with

Ok. In the mean time I fixed the configure problem - just had to
specify "--cpu 24kc" explicitly. Now compiling slowly but steadily.

Kind regards,
Matthias
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avutil/internal: Do not enable CHECKED with DEBUG

2017-04-07 Thread Michael Niedermayer

This avoids potential undefined behavior in debug mode while still allowing
developers which want to check for potential additional overflows to do so
by manually enabling this.

Signed-off-by: Michael Niedermayer 
---
 libavutil/internal.h | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/libavutil/internal.h b/libavutil/internal.h
index 7780a9a791..70ae37f859 100644
--- a/libavutil/internal.h
+++ b/libavutil/internal.h
@@ -30,9 +30,8 @@
 #define NDEBUG
 #endif
 
-#if defined(DEBUG) && !defined(CHECKED)
-#define CHECKED
-#endif
+// This can be enabld to allow detection of additional integer overflows with 
ubsan
+//#define CHECKED
 
 #include 
 #include 
-- 
2.11.0

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

Re: [FFmpeg-devel] [PATCH] avcodec/mjpegdec: Fixes runtime error: signed integer overflow: -24543 * 2031616 cannot be represented in type 'int'

2017-04-07 Thread Ronald S. Bultje

Hi,

On Fri, Apr 7, 2017 at 6:47 AM, Michael Niedermayer 
wrote:

> On Fri, Apr 07, 2017 at 06:26:05AM -0400, Ronald S. Bultje wrote:
> > On Fri, Apr 7, 2017 at 6:22 AM, Michael Niedermayer
> 
> > > Id like to apply the patch unless you or someone else objects.
> >
> > I really don't like this approach. I'd like you to try to find something
> > more sensible that protects developer machines from bugs also.
>
> i suggested to decouple SUINT from the #ifdef DEBUG, which fixes
> exactly that possibility (and noone seemed to care)

You asked - in this email - to apply this patch as-is. The patch does not
decouple #ifdef DEBUG from SUINT.

Now the question is whether SUINT has any raison d'etre in our main
codebase. If it's under #if 0 or otherwise "dead code", any Diego'ification
would immediately get rid of it. So answer me this question: if the code is
under #if 0, why shouldn't it just exist locally on your hard disk only?

(Yes, I have actual (old) debug branches for the vp9 decoder locally.)

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

Re: [FFmpeg-devel] [PATCH] avcodec/mjpegdec: Fixes runtime error: signed integer overflow: -24543 * 2031616 cannot be represented in type 'int'

2017-04-07 Thread wm4

On Fri, 7 Apr 2017 13:07:23 +0200
Michael Niedermayer  wrote:

> On Fri, Apr 07, 2017 at 12:35:37PM +0200, wm4 wrote:
> > On Fri, 7 Apr 2017 12:22:07 +0200
> > Michael Niedermayer  wrote:
> >   
> > > On Fri, Apr 07, 2017 at 08:30:50AM +0200, wm4 wrote:  
> > > > On Fri, 7 Apr 2017 02:17:37 +0200
> > > > Michael Niedermayer  wrote:
> > > > 
> > > > > On Wed, Mar 29, 2017 at 11:47:31AM +0200, wm4 wrote:
> > > > > > On Mon, 27 Mar 2017 00:41:05 +0200
> > > > > > Michael Niedermayer  wrote:
> > > > > >   
> > > > > > > On Sun, Mar 26, 2017 at 05:30:05PM -0400, Ronald S. Bultje wrote: 
> > > > > > >  
> > > > > > > > Hi,
> > > > > > > > 
> > > > > > > > On Sun, Mar 26, 2017 at 3:31 PM, Michael Niedermayer 
> > > > > > > >  > > > > > > > > wrote:
> > > > > > > > 
> > > > > > > > > On Sun, Mar 26, 2017 at 07:41:58PM +0200, wm4 wrote:
> > > > > > > > > > On Sun, 26 Mar 2017 19:16:26 +0200
> > > > > > > > > > Michael Niedermayer  wrote:
> > > > > > > > > >
> > > > > > > > > > > On Sun, Mar 26, 2017 at 06:51:11PM +0200, wm4 wrote:  
> > > > > > > > > > >   
> > > > > > > > > > > > On Sun, 26 Mar 2017 18:11:01 +0200
> > > > > > > > > > > > Michael Niedermayer  wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > Fixes: 943/clusterfuzz-testcase-5114865297391616
> > > > > > > > > > > > >
> > > > > > > > > > > > > Found-by: continuous fuzzing process
> > > > > > > > > https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg 
> > > > > > > > >
> > > > > > > > > > > > > Signed-off-by: Michael Niedermayer 
> > > > > > > > > > > > > 
> > > > > > > > > > > > > ---
> > > > > > > > > > > > >  libavcodec/mjpegdec.c | 3 ++-
> > > > > > > > > > > > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > > > > > > > > > > >
> > > > > > > > > > > > > diff --git a/libavcodec/mjpegdec.c 
> > > > > > > > > > > > > b/libavcodec/mjpegdec.c
> > > > > > > > > > > > > index f26e8a3f9a..e08b045fe7 100644
> > > > > > > > > > > > > --- a/libavcodec/mjpegdec.c
> > > > > > > > > > > > > +++ b/libavcodec/mjpegdec.c
> > > > > > > > > > > > > @@ -757,7 +757,8 @@ static int 
> > > > > > > > > > > > > decode_block_progressive(MJpegDecodeContext
> > > > > > > > > *s, int16_t *block,
> > > > > > > > > > > > >  uint16_t 
> > > > > > > > > > > > > *quant_matrix,
> > > > > > > > > > > > >  int ss, int se, 
> > > > > > > > > > > > > int Al, int
> > > > > > > > > *EOBRUN)
> > > > > > > > > > > > >  {
> > > > > > > > > > > > > -int code, i, j, level, val, run;
> > > > > > > > > > > > > +int code, i, j, val, run;
> > > > > > > > > > > > > +SUINT level;
> > > > > > > > > > > > >
> > > > > > > > > > > > >  if (*EOBRUN) {
> > > > > > > > > > > > >  (*EOBRUN)--;
> > > > > > > > > > > >
> > > > > > > > > > > > Please make the type either signed or unsigned. Making 
> > > > > > > > > > > > it both
> > > > > > > > > > > > (depending on the debug level) just to make the fuzzer 
> > > > > > > > > > > > happy (or
> > > > > > > > > > > > something more complicated than that?) isn't a good 
> > > > > > > > > > > > idea. You
> > > > > > > > > probably
> > > > > > > > > > > > want to make it always unsigned?
> > > > > > > > > > >
> > > > > > > > > > > No, i want to make it SUINT
> > > > > > > > > > >
> > > > > > > > > > > If it is always unsigned then its not possible to detect 
> > > > > > > > > > > overflows
> > > > > > > > > > > without explicitly checking for overflows.
> > > > > > > > > > > If it is SUINT then ubsan can be used to detect 
> > > > > > > > > > > overflows, this is
> > > > > > > > > > > usefull to test files showing artifacts but no decode 
> > > > > > > > > > > errors.
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > The point of these tools (static analyzers, sanitizers, 
> > > > > > > > > > fuzzers) is to
> > > > > > > > > > improve the correctness of the code.
> > > > > > > > >
> > > > > > > > > > SUINT is still defined to "int" if
> > > > > > > > > > CHECKED is not defined
> > > > > > > > >
> > > > > > > > > no
> > > > > > > > >
> > > > > > > > > internal.h:
> > > > > > > > > #ifdef CHECKED
> > > > > > > > > #define SUINT   int
> > > > > > > > > #define SUINT32 int32_t
> > > > > > > > > #else
> > > > > > > > > #define SUINT   unsigned
> > > > > > > > > #define SUINT32 uint32_t
> > > > > > > > > #endif
> > > > > > > > >
> > > > > > > > > I belive the rest of your mail assumes this condition is 
> > > > > > > > > backward to
> > > > > > > > > how it is
> > > > > > > > >
> > > > > > > > > SUINT is not there to make any tools happy its there to allow 
> > > > > > > > >

Re: [FFmpeg-devel] [PATCH] avcodec/mjpegdec: Fixes runtime error: signed integer overflow: -24543 * 2031616 cannot be represented in type 'int'

2017-04-07 Thread Michael Niedermayer

On Fri, Apr 07, 2017 at 12:35:37PM +0200, wm4 wrote:
> On Fri, 7 Apr 2017 12:22:07 +0200
> Michael Niedermayer  wrote:
> 
> > On Fri, Apr 07, 2017 at 08:30:50AM +0200, wm4 wrote:
> > > On Fri, 7 Apr 2017 02:17:37 +0200
> > > Michael Niedermayer  wrote:
> > >   
> > > > On Wed, Mar 29, 2017 at 11:47:31AM +0200, wm4 wrote:  
> > > > > On Mon, 27 Mar 2017 00:41:05 +0200
> > > > > Michael Niedermayer  wrote:
> > > > > 
> > > > > > On Sun, Mar 26, 2017 at 05:30:05PM -0400, Ronald S. Bultje wrote:   
> > > > > >  
> > > > > > > Hi,
> > > > > > > 
> > > > > > > On Sun, Mar 26, 2017 at 3:31 PM, Michael Niedermayer 
> > > > > > >  > > > > > > > wrote:  
> > > > > > >   
> > > > > > > > On Sun, Mar 26, 2017 at 07:41:58PM +0200, wm4 wrote:  
> > > > > > > > > On Sun, 26 Mar 2017 19:16:26 +0200
> > > > > > > > > Michael Niedermayer  wrote:
> > > > > > > > >  
> > > > > > > > > > On Sun, Mar 26, 2017 at 06:51:11PM +0200, wm4 wrote:  
> > > > > > > > > > > On Sun, 26 Mar 2017 18:11:01 +0200
> > > > > > > > > > > Michael Niedermayer  wrote:
> > > > > > > > > > >  
> > > > > > > > > > > > Fixes: 943/clusterfuzz-testcase-5114865297391616
> > > > > > > > > > > >
> > > > > > > > > > > > Found-by: continuous fuzzing process  
> > > > > > > > https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg   
> > > > > > > >
> > > > > > > > > > > > Signed-off-by: Michael Niedermayer 
> > > > > > > > > > > > 
> > > > > > > > > > > > ---
> > > > > > > > > > > >  libavcodec/mjpegdec.c | 3 ++-
> > > > > > > > > > > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > > > > > > > > > >
> > > > > > > > > > > > diff --git a/libavcodec/mjpegdec.c 
> > > > > > > > > > > > b/libavcodec/mjpegdec.c
> > > > > > > > > > > > index f26e8a3f9a..e08b045fe7 100644
> > > > > > > > > > > > --- a/libavcodec/mjpegdec.c
> > > > > > > > > > > > +++ b/libavcodec/mjpegdec.c
> > > > > > > > > > > > @@ -757,7 +757,8 @@ static int 
> > > > > > > > > > > > decode_block_progressive(MJpegDecodeContext  
> > > > > > > > *s, int16_t *block,  
> > > > > > > > > > > >  uint16_t 
> > > > > > > > > > > > *quant_matrix,
> > > > > > > > > > > >  int ss, int se, 
> > > > > > > > > > > > int Al, int  
> > > > > > > > *EOBRUN)  
> > > > > > > > > > > >  {
> > > > > > > > > > > > -int code, i, j, level, val, run;
> > > > > > > > > > > > +int code, i, j, val, run;
> > > > > > > > > > > > +SUINT level;
> > > > > > > > > > > >
> > > > > > > > > > > >  if (*EOBRUN) {
> > > > > > > > > > > >  (*EOBRUN)--;  
> > > > > > > > > > >
> > > > > > > > > > > Please make the type either signed or unsigned. Making it 
> > > > > > > > > > > both
> > > > > > > > > > > (depending on the debug level) just to make the fuzzer 
> > > > > > > > > > > happy (or
> > > > > > > > > > > something more complicated than that?) isn't a good idea. 
> > > > > > > > > > > You  
> > > > > > > > probably  
> > > > > > > > > > > want to make it always unsigned?  
> > > > > > > > > >
> > > > > > > > > > No, i want to make it SUINT
> > > > > > > > > >
> > > > > > > > > > If it is always unsigned then its not possible to detect 
> > > > > > > > > > overflows
> > > > > > > > > > without explicitly checking for overflows.
> > > > > > > > > > If it is SUINT then ubsan can be used to detect overflows, 
> > > > > > > > > > this is
> > > > > > > > > > usefull to test files showing artifacts but no decode 
> > > > > > > > > > errors.
> > > > > > > > > >  
> > > > > > > > >
> > > > > > > > > The point of these tools (static analyzers, sanitizers, 
> > > > > > > > > fuzzers) is to
> > > > > > > > > improve the correctness of the code.  
> > > > > > > >  
> > > > > > > > > SUINT is still defined to "int" if
> > > > > > > > > CHECKED is not defined  
> > > > > > > >
> > > > > > > > no
> > > > > > > >
> > > > > > > > internal.h:
> > > > > > > > #ifdef CHECKED
> > > > > > > > #define SUINT   int
> > > > > > > > #define SUINT32 int32_t
> > > > > > > > #else
> > > > > > > > #define SUINT   unsigned
> > > > > > > > #define SUINT32 uint32_t
> > > > > > > > #endif
> > > > > > > >
> > > > > > > > I belive the rest of your mail assumes this condition is 
> > > > > > > > backward to
> > > > > > > > how it is
> > > > > > > >
> > > > > > > > SUINT is not there to make any tools happy its there to allow 
> > > > > > > > finding
> > > > > > > > overflows in debug more while having valid c code in normal 
> > > > > > > > builds  
> > > > > > > 
> > > > > > >   
> > > > > > 
> > > > > > > Why don't we want to detect overflows in debug mode?  
> > > > > > 
> > > > > > like wm4 you read "#if A" as "#if not A", all your mail and 
> > > > > > questions
> > > > > > seem based

Re: [FFmpeg-devel] [PATCH] avcodec/mjpegdec: Fixes runtime error: signed integer overflow: -24543 * 2031616 cannot be represented in type 'int'

2017-04-07 Thread Michael Niedermayer

On Fri, Apr 07, 2017 at 06:26:05AM -0400, Ronald S. Bultje wrote:
> Hi,
> 
> On Fri, Apr 7, 2017 at 6:22 AM, Michael Niedermayer 
> wrote:
> 
> > if you say these are not bugs by definition even though its
> > quite obvious they are bugs then whatever you use as definition must
> > be flawed. Or you misunderstood what i wrote.
> >
> 
> That's hypocritical.

in what way ?


> 
> Id like to apply the patch unless you or someone else objects.
> 
> 
> I really don't like this approach. I'd like you to try to find something
> more sensible that protects developer machines from bugs also.

i suggested to decouple SUINT from the #ifdef DEBUG, which fixes
exactly that possibility (and noone seemed to care)



[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

He who knows, does not speak. He who speaks, does not know. -- Lao Tsu


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

Re: [FFmpeg-devel] [PATCH] avfilter: implement vf_remap_frac

2017-04-07 Thread Paul B Mahol

On 4/7/17, Daniel Oberhoff  wrote:
>>>
>>> Signed-off-by: Daniel Oberhoff 
>>> ---
>>> libavfilter/Makefile|   1 +
>>> libavfilter/allfilters.c|   1 +
>>> libavfilter/vf_remap_frac.c | 491
>>> 
>>> 3 files changed, 493 insertions(+)
>>> create mode 100644 libavfilter/vf_remap_frac.c
>>>
>>
>> I do not like '_' in filter name.
>
> what do you propose?

No point to have separate filter that operates like remap.
Just add option to remap filter to interpret values differently.

One could also make use of RGBA64, and use alfa values for interpolation.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter: implement vf_remap_frac

2017-04-07 Thread Nicolas George

L'octidi 18 germinal, an CCXXV, Daniel Oberhoff a écrit :
> what do you propose?

I personally have no objection underscores in filter names.
Spaceswereinventedforareason. And we already have a few filters with
underscores in them.

On the other hand, the patch looks like a big copy-paste of the original
vf_remap with a few changes and some extra features (slice threading,
high bit depth), and that is a big no. I think the features should be
implemented in the original filter. The normal and 16 versions of the
functions also looks nearly identical and should be factored.

Also, it is missing documentation.

Regards,

-- 
  Nicolas George


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/mjpegdec: Fixes runtime error: signed integer overflow: -24543 * 2031616 cannot be represented in type 'int'

2017-04-07 Thread wm4

On Fri, 7 Apr 2017 12:22:07 +0200
Michael Niedermayer  wrote:

> On Fri, Apr 07, 2017 at 08:30:50AM +0200, wm4 wrote:
> > On Fri, 7 Apr 2017 02:17:37 +0200
> > Michael Niedermayer  wrote:
> >   
> > > On Wed, Mar 29, 2017 at 11:47:31AM +0200, wm4 wrote:  
> > > > On Mon, 27 Mar 2017 00:41:05 +0200
> > > > Michael Niedermayer  wrote:
> > > > 
> > > > > On Sun, Mar 26, 2017 at 05:30:05PM -0400, Ronald S. Bultje wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > On Sun, Mar 26, 2017 at 3:31 PM, Michael Niedermayer 
> > > > > >  > > > > > > wrote:  
> > > > > >   
> > > > > > > On Sun, Mar 26, 2017 at 07:41:58PM +0200, wm4 wrote:  
> > > > > > > > On Sun, 26 Mar 2017 19:16:26 +0200
> > > > > > > > Michael Niedermayer  wrote:
> > > > > > > >  
> > > > > > > > > On Sun, Mar 26, 2017 at 06:51:11PM +0200, wm4 wrote:  
> > > > > > > > > > On Sun, 26 Mar 2017 18:11:01 +0200
> > > > > > > > > > Michael Niedermayer  wrote:
> > > > > > > > > >  
> > > > > > > > > > > Fixes: 943/clusterfuzz-testcase-5114865297391616
> > > > > > > > > > >
> > > > > > > > > > > Found-by: continuous fuzzing process  
> > > > > > > https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg 
> > > > > > >  
> > > > > > > > > > > Signed-off-by: Michael Niedermayer 
> > > > > > > > > > > 
> > > > > > > > > > > ---
> > > > > > > > > > >  libavcodec/mjpegdec.c | 3 ++-
> > > > > > > > > > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > > > > > > > > >
> > > > > > > > > > > diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
> > > > > > > > > > > index f26e8a3f9a..e08b045fe7 100644
> > > > > > > > > > > --- a/libavcodec/mjpegdec.c
> > > > > > > > > > > +++ b/libavcodec/mjpegdec.c
> > > > > > > > > > > @@ -757,7 +757,8 @@ static int 
> > > > > > > > > > > decode_block_progressive(MJpegDecodeContext  
> > > > > > > *s, int16_t *block,  
> > > > > > > > > > >  uint16_t 
> > > > > > > > > > > *quant_matrix,
> > > > > > > > > > >  int ss, int se, int 
> > > > > > > > > > > Al, int  
> > > > > > > *EOBRUN)  
> > > > > > > > > > >  {
> > > > > > > > > > > -int code, i, j, level, val, run;
> > > > > > > > > > > +int code, i, j, val, run;
> > > > > > > > > > > +SUINT level;
> > > > > > > > > > >
> > > > > > > > > > >  if (*EOBRUN) {
> > > > > > > > > > >  (*EOBRUN)--;  
> > > > > > > > > >
> > > > > > > > > > Please make the type either signed or unsigned. Making it 
> > > > > > > > > > both
> > > > > > > > > > (depending on the debug level) just to make the fuzzer 
> > > > > > > > > > happy (or
> > > > > > > > > > something more complicated than that?) isn't a good idea. 
> > > > > > > > > > You  
> > > > > > > probably  
> > > > > > > > > > want to make it always unsigned?  
> > > > > > > > >
> > > > > > > > > No, i want to make it SUINT
> > > > > > > > >
> > > > > > > > > If it is always unsigned then its not possible to detect 
> > > > > > > > > overflows
> > > > > > > > > without explicitly checking for overflows.
> > > > > > > > > If it is SUINT then ubsan can be used to detect overflows, 
> > > > > > > > > this is
> > > > > > > > > usefull to test files showing artifacts but no decode errors.
> > > > > > > > >  
> > > > > > > >
> > > > > > > > The point of these tools (static analyzers, sanitizers, 
> > > > > > > > fuzzers) is to
> > > > > > > > improve the correctness of the code.  
> > > > > > >  
> > > > > > > > SUINT is still defined to "int" if
> > > > > > > > CHECKED is not defined  
> > > > > > >
> > > > > > > no
> > > > > > >
> > > > > > > internal.h:
> > > > > > > #ifdef CHECKED
> > > > > > > #define SUINT   int
> > > > > > > #define SUINT32 int32_t
> > > > > > > #else
> > > > > > > #define SUINT   unsigned
> > > > > > > #define SUINT32 uint32_t
> > > > > > > #endif
> > > > > > >
> > > > > > > I belive the rest of your mail assumes this condition is backward 
> > > > > > > to
> > > > > > > how it is
> > > > > > >
> > > > > > > SUINT is not there to make any tools happy its there to allow 
> > > > > > > finding
> > > > > > > overflows in debug more while having valid c code in normal 
> > > > > > > builds  
> > > > > > 
> > > > > >   
> > > > > 
> > > > > > Why don't we want to detect overflows in debug mode?  
> > > > > 
> > > > > like wm4 you read "#if A" as "#if not A", all your mail and questions
> > > > > seem based on reading the condition for SUINT flipped around
> > > > > 
> > > > > in DEBUG mode CHECKED is enabled, SUINT is int and overflows are
> > > > > undefined behaviour which can be detected easily with ubsan.
> > > > > 
> > > > > This allows us to debug samples producing artifacts but no decode
> > > > > errors due to overflows.
> > > > > 
> >

Re: [FFmpeg-devel] [PATCH] avcodec/mjpegdec: Fixes runtime error: signed integer overflow: -24543 * 2031616 cannot be represented in type 'int'

2017-04-07 Thread Ronald S. Bultje

Hi,

On Fri, Apr 7, 2017 at 6:22 AM, Michael Niedermayer 
wrote:

> if you say these are not bugs by definition even though its
> quite obvious they are bugs then whatever you use as definition must
> be flawed. Or you misunderstood what i wrote.
>

That's hypocritical.

Id like to apply the patch unless you or someone else objects.

I really don't like this approach. I'd like you to try to find something
more sensible that protects developer machines from bugs also.

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

Re: [FFmpeg-devel] [PATCH] avfilter: implement vf_remap_frac

2017-04-07 Thread Daniel Oberhoff

>> 
>> Signed-off-by: Daniel Oberhoff 
>> ---
>> libavfilter/Makefile|   1 +
>> libavfilter/allfilters.c|   1 +
>> libavfilter/vf_remap_frac.c | 491
>> 
>> 3 files changed, 493 insertions(+)
>> create mode 100644 libavfilter/vf_remap_frac.c
>> 
> 
> I do not like '_' in filter name.

what do you propose?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/h264: Check weight values to be within the specs limits.

2017-04-07 Thread Michael Niedermayer

On Thu, Apr 06, 2017 at 10:32:15PM -0400, Ronald S. Bultje wrote:
> Hi,
> 
> On Thu, Apr 6, 2017 at 8:10 PM, Michael Niedermayer 
> wrote:
> 
> > On Wed, Mar 22, 2017 at 07:09:23PM +0100, Michael Niedermayer wrote:
> > > On Wed, Mar 22, 2017 at 09:06:09AM -0400, Ronald S. Bultje wrote:
> > > > Hi,
> > > >
> > > > On Tue, Mar 21, 2017 at 9:59 PM, Michael Niedermayer
> >  > > > > wrote:
> > > >
> > > > > @@ -59,6 +59,9 @@ int ff_h264_pred_weight_table(GetBitContext *gb,
> > const
> > > > > SPS *sps,
> > > > >  if (luma_weight_flag) {
> > > > >  pwt->luma_weight[i][list][0] = get_se_golomb(gb);
> > > > >  pwt->luma_weight[i][list][1] = get_se_golomb(gb);
> > > > > +if (   (int8_t)pwt->luma_weight[i][list][0] !=
> > > > > pwt->luma_weight[i][list][0]
> > > > > +|| (int8_t)pwt->luma_weight[i][list][1] !=
> > > > > pwt->luma_weight[i][list][1])
> > > > > +goto error;
> > > > >
> > > >
> > > > Can we please put || on the line before? h264* and a very limited
> > subset of
> > > > other files in our codebase have always been an exception to the large
> > > > majority of the codebase and it's about time we fix that [1].
> > >
> > > i find putting the operators in the first column more readable
> > > but if its preferred in the last, iam happy to change it.
> > >
> > >
> > > >
> > > > It's interesting (I mean that in a positive way) how you use casting to
> > > > check for the range. It's a little obscure, but it's OK.
> > >
> > > yes, it caused me to pause to but it was the simplest way i saw to do
> > > the check
> > >
> > >
> > > >
> > > > +error:
> > > > > +avpriv_request_sample(logctx, "Out of range weight\n");
> > > > > +return AVERROR_INVALIDDATA;
> > > >
> > > >
> > > > Same comment as previously in other, but related, threads: unless
> > there is
> > > > real, demonstrable evidence that this happens in real-world files,
> > this is
> > > > fuzz/corruption only and shouldn't be accompanied by an explicit log
> > > > message. Just return AVERROR_INVALIDDATA directly and remove the
> > goto/error
> > > > message.
> > >
> > > If there is "real, demonstrable evidence that this happens in real-world
> > > files" then we would likely have a sample and not ask for one with
> > > avpriv_request_sample()
> > >
> > > I think its very plausible that a encoder would use a weight that is
> > > outside the range. Printing something does make sense.
> >
> > i will apply this with the label chaned to out_range_weight:
> > unless there are objections
> 
> 
> OK.

applied

thanks

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

The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus


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/mjpegdec: Fixes runtime error: signed integer overflow: -24543 * 2031616 cannot be represented in type 'int'

2017-04-07 Thread Michael Niedermayer

On Fri, Apr 07, 2017 at 08:30:50AM +0200, wm4 wrote:
> On Fri, 7 Apr 2017 02:17:37 +0200
> Michael Niedermayer  wrote:
> 
> > On Wed, Mar 29, 2017 at 11:47:31AM +0200, wm4 wrote:
> > > On Mon, 27 Mar 2017 00:41:05 +0200
> > > Michael Niedermayer  wrote:
> > >   
> > > > On Sun, Mar 26, 2017 at 05:30:05PM -0400, Ronald S. Bultje wrote:  
> > > > > Hi,
> > > > > 
> > > > > On Sun, Mar 26, 2017 at 3:31 PM, Michael Niedermayer 
> > > > >  > > > > > wrote:
> > > > > 
> > > > > > On Sun, Mar 26, 2017 at 07:41:58PM +0200, wm4 wrote:
> > > > > > > On Sun, 26 Mar 2017 19:16:26 +0200
> > > > > > > Michael Niedermayer  wrote:
> > > > > > >
> > > > > > > > On Sun, Mar 26, 2017 at 06:51:11PM +0200, wm4 wrote:
> > > > > > > > > On Sun, 26 Mar 2017 18:11:01 +0200
> > > > > > > > > Michael Niedermayer  wrote:
> > > > > > > > >
> > > > > > > > > > Fixes: 943/clusterfuzz-testcase-5114865297391616
> > > > > > > > > >
> > > > > > > > > > Found-by: continuous fuzzing process
> > > > > > https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
> > > > > > > > > > Signed-off-by: Michael Niedermayer 
> > > > > > > > > > ---
> > > > > > > > > >  libavcodec/mjpegdec.c | 3 ++-
> > > > > > > > > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > > > > > > > >
> > > > > > > > > > diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
> > > > > > > > > > index f26e8a3f9a..e08b045fe7 100644
> > > > > > > > > > --- a/libavcodec/mjpegdec.c
> > > > > > > > > > +++ b/libavcodec/mjpegdec.c
> > > > > > > > > > @@ -757,7 +757,8 @@ static int 
> > > > > > > > > > decode_block_progressive(MJpegDecodeContext
> > > > > > *s, int16_t *block,
> > > > > > > > > >  uint16_t *quant_matrix,
> > > > > > > > > >  int ss, int se, int 
> > > > > > > > > > Al, int
> > > > > > *EOBRUN)
> > > > > > > > > >  {
> > > > > > > > > > -int code, i, j, level, val, run;
> > > > > > > > > > +int code, i, j, val, run;
> > > > > > > > > > +SUINT level;
> > > > > > > > > >
> > > > > > > > > >  if (*EOBRUN) {
> > > > > > > > > >  (*EOBRUN)--;
> > > > > > > > >
> > > > > > > > > Please make the type either signed or unsigned. Making it both
> > > > > > > > > (depending on the debug level) just to make the fuzzer happy 
> > > > > > > > > (or
> > > > > > > > > something more complicated than that?) isn't a good idea. You 
> > > > > > > > >
> > > > > > probably
> > > > > > > > > want to make it always unsigned?
> > > > > > > >
> > > > > > > > No, i want to make it SUINT
> > > > > > > >
> > > > > > > > If it is always unsigned then its not possible to detect 
> > > > > > > > overflows
> > > > > > > > without explicitly checking for overflows.
> > > > > > > > If it is SUINT then ubsan can be used to detect overflows, this 
> > > > > > > > is
> > > > > > > > usefull to test files showing artifacts but no decode errors.
> > > > > > > >
> > > > > > >
> > > > > > > The point of these tools (static analyzers, sanitizers, fuzzers) 
> > > > > > > is to
> > > > > > > improve the correctness of the code.
> > > > > >
> > > > > > > SUINT is still defined to "int" if
> > > > > > > CHECKED is not defined
> > > > > >
> > > > > > no
> > > > > >
> > > > > > internal.h:
> > > > > > #ifdef CHECKED
> > > > > > #define SUINT   int
> > > > > > #define SUINT32 int32_t
> > > > > > #else
> > > > > > #define SUINT   unsigned
> > > > > > #define SUINT32 uint32_t
> > > > > > #endif
> > > > > >
> > > > > > I belive the rest of your mail assumes this condition is backward to
> > > > > > how it is
> > > > > >
> > > > > > SUINT is not there to make any tools happy its there to allow 
> > > > > > finding
> > > > > > overflows in debug more while having valid c code in normal builds  
> > > > > >   
> > > > > 
> > > > > 
> > > >   
> > > > > Why don't we want to detect overflows in debug mode?
> > > > 
> > > > like wm4 you read "#if A" as "#if not A", all your mail and questions
> > > > seem based on reading the condition for SUINT flipped around
> > > > 
> > > > in DEBUG mode CHECKED is enabled, SUINT is int and overflows are
> > > > undefined behaviour which can be detected easily with ubsan.
> > > > 
> > > > This allows us to debug samples producing artifacts but no decode
> > > > errors due to overflows.
> > > > 
> > > > 
> > > > in normal mode CHECKED is disabled, SUINT is unsigned and overflows
> > > > are defined behavior. There must be no undefined behavior in releases
> > > > 
> > > > maybe you belive everyone is using debug mode and the fuzzers run in
> > > > debug mode. Maybe this is why everyone belives the condition is
> > > > backward  
> > > 
> > > How would we know this? Maybe I've been assuming too much in order to
> > > try to make sense out of it.
> >

Re: [FFmpeg-devel] Patch: filter af_amix inputs

2017-04-07 Thread Michael Niedermayer

On Thu, Apr 06, 2017 at 09:49:21AM +0100, John Warburton wrote:
> Dear All,
> 
> While needing automatically to mix several hundred audio files, I
> noticed that the libavfilter module af_amix.c (audio filter 'amix') is
> hard-coded to limit inputs to 32. Of course, I believe this to be
> sensible as no doubt you do, too.
> 
> However, because the code appears to be written robustly, it was
> trivial to increase the limit to 1024 and, on a fast machine with SATA
> drives, I have used FFmpeg to mix simultaneously over 400 16-bit
> stereo wav files (48kHz sample rate) at approximately 2 x realtime. It
> starts very slowly, but speed soon builds up.
> 
> Naturally, memory use increased. But the job was done. It's generating
> files for a sound installation in an art exhibition in Brighton, UK,
> where many hundreds of migrant birds' songs must be heard together
> ("SWAY" at the ONCA Gallery).
> 
> Below is the very trivial patch in case the result of this experiment
> is of interest.
> 
> Thank you for all the work you do to make FFmpeg so incredibly useful.
> J
> 
> --- libavfilter/af_amix.c.orig 2017-04-05 22:26:26.326379600 +0100
> +++ libavfilter/af_amix.c 2017-04-05 18:00:59.291196000 +0100
> @@ -177,7 +177,7 @@
>  #define F AV_OPT_FLAG_FILTERING_PARAM
>  static const AVOption amix_options[] = {
>  { "inputs", "Number of inputs.",
> -OFFSET(nb_inputs), AV_OPT_TYPE_INT, { .i64 = 2 }, 1, 32, A|F },
> +OFFSET(nb_inputs), AV_OPT_TYPE_INT, { .i64 = 2 }, 1, 1024, A|F },
>  { "duration", "How to determine the end-of-stream.",
>  OFFSET(duration_mode), AV_OPT_TYPE_INT, { .i64 =
> DURATION_LONGEST }, 0,  2, A|F, "duration" },
>  { "longest",  "Duration of longest input.",  0,
> AV_OPT_TYPE_CONST, { .i64 = DURATION_LONGEST  }, INT_MIN, INT_MAX,
> A|F, "duration" },
> 

this patch is corrupted by linebreaks

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

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact


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

Re: [FFmpeg-devel] [PATCHv2] avfilter/vf_framerate: always request input if no output is provided in request_frame

2017-04-07 Thread Nicolas George

L'octidi 18 germinal, an CCXXV, Marton Balint a écrit :
> Fixes ticket #6285.
> 
> Signed-off-by: Marton Balint 
> ---
>  libavfilter/vf_framerate.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)

Still LGTM, of course.

But since the questions of elegance have been raised, here are my two
zorkmids:

Another solution that I personally find more elegant (but it is only a
matter of taste) would be to have process_work_frame() return to the
caller whether a frame was sent:

static int process_work_frame(AVFilterContext *ctx, int stop, int 
*frame_sent)
...
*frame_sent = 1;
return ff_filter_frame(ctx->outputs[0], s->work);

And then check this variable and call ff_request_frame() from
request_frame() rather than calling it directly from
process_work_frame():

ret = process_work_frame(ctx, 0, _sent);
return frame_sent ? ret : ff_request_frame(...)

But it is only a matter of personal preference, and I mention it only in
case you share it; the patch as is looks fine to me.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH] Observe Set-Cookie headers in HLS streams

2017-04-07 Thread wm4

On Thu,  6 Apr 2017 22:48:59 -0400
Micah Galizia  wrote:

> Signed-off-by: Micah Galizia 
> ---
>  libavformat/hls.c | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/libavformat/hls.c b/libavformat/hls.c
> index bac53a4..ab81863 100644
> --- a/libavformat/hls.c
> +++ b/libavformat/hls.c
> @@ -630,8 +630,14 @@ static int open_url(AVFormatContext *s, AVIOContext 
> **pb, const char *url,
>  ret = s->io_open(s, pb, url, AVIO_FLAG_READ, );
>  if (ret >= 0) {
>  // update cookies on http response with setcookies.
> -void *u = (s->flags & AVFMT_FLAG_CUSTOM_IO) ? NULL : s->pb;
> -update_options(>cookies, "cookies", u);
> +char *new_cookies = NULL;
> +
> +av_opt_get(*pb, "cookies", AV_OPT_SEARCH_CHILDREN, 
> (uint8_t**)_cookies);
> +if (new_cookies) {
> +av_free(c->cookies);
> +c->cookies = new_cookies;
> +}
> +
>  av_dict_set(, "cookies", c->cookies, 0);
>  }
>  

So far, all code is doing the same thing by calling update_options()
on pb, or NULL if it's a custom IO context.

What you seem to change is always using the pb (even if it's a custom
context), duplicating the update_options() code (subtly changing some
corner case behavior), and, this is probably the important one, you use
*pb instead of s->pb.

I suspect the latter is the only change that matters, and you probably
want:

void *u = (s->flags & AVFMT_FLAG_CUSTOM_IO) ? NULL : *pb;

Now I have no idea why it checks "s->flags & AVFMT_FLAG_CUSTOM_IO", or
what it means, but it feels very wrong. A common case is probably that
the main playlist is accessed through a custom AVIOContext, but further
nested playlists or actual .ts data probably use libavformat's code.

I'm thinking that all uses of AVFMT_FLAG_CUSTOM_IO anywhere are
probably bugs.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] pthread_frame: make accesses to debug field be protected by owner lock.

2017-04-07 Thread wm4

On Thu,  6 Apr 2017 13:48:41 -0400
"Ronald S. Bultje"  wrote:

> The av_log() is done outside the lock, but this way the accesses to the
> field (reads and writes) are always protected by a mutex. The av_log()
> is not run inside the lock context because it may involve user callbacks
> and doing that in performance-sensitive code is probably not a good idea.
> 
> This should fix occasional tsan warnings when running fate-h264, like:
> 
> WARNING: ThreadSanitizer: data race (pid=10916)
>   Write of size 4 at 0x7d64000174fc by main thread (mutexes: write M2313):
> #0 update_context_from_user src/libavcodec/pthread_frame.c:335 
> (ffmpeg+0x00df7b06)
> [..]
>   Previous read of size 4 at 0x7d64000174fc by thread T1 (mutexes: write 
> M2311):
> #0 ff_thread_await_progress src/libavcodec/pthread_frame.c:592 
> (ffmpeg+0x00df8b3e)
> ---
>  libavcodec/pthread_frame.c | 20 
>  1 file changed, 12 insertions(+), 8 deletions(-)
> 
> diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c
> index c246c2f..8857bfc 100644
> --- a/libavcodec/pthread_frame.c
> +++ b/libavcodec/pthread_frame.c
> @@ -559,6 +559,7 @@ void ff_thread_report_progress(ThreadFrame *f, int n, int 
> field)
>  {
>  PerThreadContext *p;
>  atomic_int *progress = f->progress ? (atomic_int*)f->progress->data : 
> NULL;
> +int debug_mv;
>  
>  if (!progress ||
>  atomic_load_explicit([field], memory_order_relaxed) >= n)
> @@ -566,22 +567,24 @@ void ff_thread_report_progress(ThreadFrame *f, int n, 
> int field)
>  
>  p = f->owner[field]->internal->thread_ctx;
>  
> -if (f->owner[field]->debug_DEBUG_THREADS)
> -av_log(f->owner[field], AV_LOG_DEBUG,
> -   "%p finished %d field %d\n", progress, n, field);
> -
>  pthread_mutex_lock(>progress_mutex);
> +debug_mv = f->owner[field]->debug_DEBUG_THREADS;
>  
>  atomic_store_explicit([field], n, memory_order_release);
>  
>  pthread_cond_broadcast(>progress_cond);
>  pthread_mutex_unlock(>progress_mutex);
> +
> +if (debug_mv)
> +av_log(f->owner[field], AV_LOG_DEBUG,
> +   "%p finished %d field %d\n", progress, n, field);
>  }
>  
>  void ff_thread_await_progress(ThreadFrame *f, int n, int field)
>  {
>  PerThreadContext *p;
>  atomic_int *progress = f->progress ? (atomic_int*)f->progress->data : 
> NULL;
> +int debug_mv;
>  
>  if (!progress ||
>  atomic_load_explicit([field], memory_order_acquire) >= n)
> @@ -589,14 +592,15 @@ void ff_thread_await_progress(ThreadFrame *f, int n, 
> int field)
>  
>  p = f->owner[field]->internal->thread_ctx;
>  
> -if (f->owner[field]->debug_DEBUG_THREADS)
> -av_log(f->owner[field], AV_LOG_DEBUG,
> -   "thread awaiting %d field %d from %p\n", n, field, progress);
> -
>  pthread_mutex_lock(>progress_mutex);
> +debug_mv = f->owner[field]->debug_DEBUG_THREADS;
>  while (atomic_load_explicit([field], memory_order_relaxed) < n)
>  pthread_cond_wait(>progress_cond, >progress_mutex);
>  pthread_mutex_unlock(>progress_mutex);
> +
> +if (debug_mv)
> +av_log(f->owner[field], AV_LOG_DEBUG,
> +   "thread awaited %d field %d from %p\n", n, field, progress);
>  }
>  
>  void ff_thread_finish_setup(AVCodecContext *avctx) {

I'm not sure what "debug_mv" stands for, and I think this is a bit
overkill. It's run only when FF_DEBUG_THREADS is set (who even sets
that, and why does access to it need to be synchronized?), so I see no
big offense in calling av_log() inside of it.

But other than that LGTM.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] pthread_frame: don't return stale error codes after flush

2017-04-07 Thread wm4

On Thu, 06 Apr 2017 23:09:41 +0300
Uoti Urpala  wrote:

> On Thu, 2017-04-06 at 18:18 +0200, wm4 wrote:
> > > >  p->got_frame = 0;
> > > >  av_frame_unref(p->frame);
> > > > +p->result = 0;  
> 
> Shouldn't p->result be similarly reset together with p->got_frame also
> in ff_thread_decode_frame()? A similar problem seems possible:
> - a normal decode call returns an error due to p->result being negative
> - drain packet is sent before cycling through all threads
> - the loop in ff_thread_decode_frame hits "if (p->result < 0)"
> Thus incorrectly returning the same error again from the drain packet.

Please send a patch.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Fix leaked dictionary in mp3dec

2017-04-07 Thread wm4

On Thu, 6 Apr 2017 14:07:53 -0700
Thomas Guilbert  wrote:

> The patch didn't show up as properly formatted on
> https://patchwork.ffmpeg.org/patch/3228/.
> 
> Re-submitting using no line wrap in the base64 attachment, and copying the
> contents of the patch for ease of review:
> 
> From fced5ab0e09f529397adddcb560d1a08f2df4840 Mon Sep 17 00:00:00 2001
> From: Thomas Guilbert 
> Date: Thu, 30 Mar 2017 18:23:29 -0700
> Subject: [PATCH] Fix dictionnary leak in mp3dec
> 
> ---
>  libavformat/mp3dec.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c
> index 0924a57843..fd8184cc0b 100644
> --- a/libavformat/mp3dec.c
> +++ b/libavformat/mp3dec.c
> @@ -349,6 +349,7 @@ static int mp3_read_header(AVFormatContext *s)
>  int ret;
>  int i;
> 
> +av_dict_free(>metadata);
>  s->metadata = s->internal->id3v2_meta;
>  s->internal->id3v2_meta = NULL;
> 

So in which situations is s->metadata not NULL?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/mjpegdec: Fixes runtime error: signed integer overflow: -24543 * 2031616 cannot be represented in type 'int'

2017-04-07 Thread wm4

On Fri, 7 Apr 2017 02:17:37 +0200
Michael Niedermayer  wrote:

> On Wed, Mar 29, 2017 at 11:47:31AM +0200, wm4 wrote:
> > On Mon, 27 Mar 2017 00:41:05 +0200
> > Michael Niedermayer  wrote:
> >   
> > > On Sun, Mar 26, 2017 at 05:30:05PM -0400, Ronald S. Bultje wrote:  
> > > > Hi,
> > > > 
> > > > On Sun, Mar 26, 2017 at 3:31 PM, Michael Niedermayer 
> > > >  > > > > wrote:
> > > > 
> > > > > On Sun, Mar 26, 2017 at 07:41:58PM +0200, wm4 wrote:
> > > > > > On Sun, 26 Mar 2017 19:16:26 +0200
> > > > > > Michael Niedermayer  wrote:
> > > > > >
> > > > > > > On Sun, Mar 26, 2017 at 06:51:11PM +0200, wm4 wrote:
> > > > > > > > On Sun, 26 Mar 2017 18:11:01 +0200
> > > > > > > > Michael Niedermayer  wrote:
> > > > > > > >
> > > > > > > > > Fixes: 943/clusterfuzz-testcase-5114865297391616
> > > > > > > > >
> > > > > > > > > Found-by: continuous fuzzing process
> > > > > https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
> > > > > > > > > Signed-off-by: Michael Niedermayer 
> > > > > > > > > ---
> > > > > > > > >  libavcodec/mjpegdec.c | 3 ++-
> > > > > > > > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > > > > > > >
> > > > > > > > > diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
> > > > > > > > > index f26e8a3f9a..e08b045fe7 100644
> > > > > > > > > --- a/libavcodec/mjpegdec.c
> > > > > > > > > +++ b/libavcodec/mjpegdec.c
> > > > > > > > > @@ -757,7 +757,8 @@ static int 
> > > > > > > > > decode_block_progressive(MJpegDecodeContext
> > > > > *s, int16_t *block,
> > > > > > > > >  uint16_t *quant_matrix,
> > > > > > > > >  int ss, int se, int Al, 
> > > > > > > > > int
> > > > > *EOBRUN)
> > > > > > > > >  {
> > > > > > > > > -int code, i, j, level, val, run;
> > > > > > > > > +int code, i, j, val, run;
> > > > > > > > > +SUINT level;
> > > > > > > > >
> > > > > > > > >  if (*EOBRUN) {
> > > > > > > > >  (*EOBRUN)--;
> > > > > > > >
> > > > > > > > Please make the type either signed or unsigned. Making it both
> > > > > > > > (depending on the debug level) just to make the fuzzer happy (or
> > > > > > > > something more complicated than that?) isn't a good idea. You   
> > > > > > > >  
> > > > > probably
> > > > > > > > want to make it always unsigned?
> > > > > > >
> > > > > > > No, i want to make it SUINT
> > > > > > >
> > > > > > > If it is always unsigned then its not possible to detect overflows
> > > > > > > without explicitly checking for overflows.
> > > > > > > If it is SUINT then ubsan can be used to detect overflows, this is
> > > > > > > usefull to test files showing artifacts but no decode errors.
> > > > > > >
> > > > > >
> > > > > > The point of these tools (static analyzers, sanitizers, fuzzers) is 
> > > > > > to
> > > > > > improve the correctness of the code.
> > > > >
> > > > > > SUINT is still defined to "int" if
> > > > > > CHECKED is not defined
> > > > >
> > > > > no
> > > > >
> > > > > internal.h:
> > > > > #ifdef CHECKED
> > > > > #define SUINT   int
> > > > > #define SUINT32 int32_t
> > > > > #else
> > > > > #define SUINT   unsigned
> > > > > #define SUINT32 uint32_t
> > > > > #endif
> > > > >
> > > > > I belive the rest of your mail assumes this condition is backward to
> > > > > how it is
> > > > >
> > > > > SUINT is not there to make any tools happy its there to allow finding
> > > > > overflows in debug more while having valid c code in normal builds
> > > > 
> > > > 
> > >   
> > > > Why don't we want to detect overflows in debug mode?
> > > 
> > > like wm4 you read "#if A" as "#if not A", all your mail and questions
> > > seem based on reading the condition for SUINT flipped around
> > > 
> > > in DEBUG mode CHECKED is enabled, SUINT is int and overflows are
> > > undefined behaviour which can be detected easily with ubsan.
> > > 
> > > This allows us to debug samples producing artifacts but no decode
> > > errors due to overflows.
> > > 
> > > 
> > > in normal mode CHECKED is disabled, SUINT is unsigned and overflows
> > > are defined behavior. There must be no undefined behavior in releases
> > > 
> > > maybe you belive everyone is using debug mode and the fuzzers run in
> > > debug mode. Maybe this is why everyone belives the condition is
> > > backward  
> > 
> > How would we know this? Maybe I've been assuming too much in order to
> > try to make sense out of it.
> >   
> > > I might be wrong but unless you manually pass -DDEBUG you dont use
> > > debug mode, adding -DDEBUG is how our debug mode fate client tests that
> > > mode  
> >   
> 
> > But why do you want to detect overflows in debug mode, if in release  
> 
> To debug.
> Like i want compiler warnings to "debug"
> or coverity warnings to find and correct

39 matches

Mail list logo