[FFmpeg-devel] ffmpeg: Error resizing AVI file

[Albert]

Greetings. On Ubuntu 17.04 I have encountered an error while running ffmpeg 
3.2.2 (installed from universe repository):
Прикреплённые файлы:
https://drive.google.com/uc?id=0B3Qk7GruY7umVjRuXzU5cnF3bTQ=download
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] swresample/resample: do not allow negative dst_size return value

[Muhammad Faiz]

This should fix Ticket6012

Signed-off-by: Muhammad Faiz 
---
 libswresample/resample.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/libswresample/resample.c b/libswresample/resample.c
index 71dffb9..ce6a82f 100644
--- a/libswresample/resample.c
+++ b/libswresample/resample.c
@@ -478,8 +478,9 @@ static int swri_resample(ResampleContext *c,
 int64_t incr= (1LL<<32) * c->dst_incr / c->src_incr;
 int new_size = (src_size * (int64_t)c->src_incr - frac + c->dst_incr - 
1) / c->dst_incr;
 
-dst_size= FFMIN(dst_size, new_size);
-c->dsp.resample_one(dst, src, dst_size, index2, incr);
+dst_size = FFMAX(FFMIN(dst_size, new_size), 0);
+if (dst_size > 0)
+c->dsp.resample_one(dst, src, dst_size, index2, incr);
 
 index += dst_size * c->dst_incr_div;
 index += (frac + dst_size * (int64_t)c->dst_incr_mod) / c->src_incr;
@@ -494,7 +495,7 @@ static int swri_resample(ResampleContext *c,
 int64_t delta_frac = (end_index - c->index) * c->src_incr - c->frac;
 int delta_n = (delta_frac + c->dst_incr - 1) / c->dst_incr;
 
-dst_size = FFMIN(dst_size, delta_n);
+dst_size = FFMAX(FFMIN(dst_size, delta_n), 0);
 if (dst_size > 0) {
 /* resample_linear and resample_common should have same behavior
  * when frac and dst_incr_mod are zero */
-- 
2.5.0

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

Re: [FFmpeg-devel] [PATCH 2/3] avformat: fix overflows during bit rate calculation

[Paul B Mahol]

On 12/13/16, Andreas Cadhalpun  wrote:
> The bit_rate field has type int64_t since commit
> 7404f3bdb90e6a5dcb59bc0a091e2c5c038e557d.
>
> Signed-off-by: Andreas Cadhalpun 
> ---
>  libavformat/adxdec.c | 2 +-
>  libavformat/aiffdec.c| 4 ++--
>  libavformat/apc.c| 2 +-
>  libavformat/bfi.c| 2 +-
>  libavformat/electronicarts.c | 2 +-
>  libavformat/iff.c| 2 +-
>  libavformat/soxdec.c | 2 +-
>  libavformat/voc_packet.c | 2 +-
>  libavformat/vqf.c| 2 +-
>  libavformat/wsddec.c | 2 +-
>  10 files changed, 11 insertions(+), 11 deletions(-)
>

probably ok

Maybe my C sucks, but isn't this already covered when 8LL is used for
some cases?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/3] omadec: fix overflows during bit rate calculation

[Paul B Mahol]

On 12/13/16, Andreas Cadhalpun  wrote:
> Signed-off-by: Andreas Cadhalpun 
> ---
>  libavformat/omadec.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/omadec.c b/libavformat/omadec.c
> index 6e476db..e7751d0 100644
> --- a/libavformat/omadec.c
> +++ b/libavformat/omadec.c
> @@ -365,7 +365,7 @@ static int oma_read_header(AVFormatContext *s)
>  st->codecpar->channels= 2;
>  st->codecpar->channel_layout = AV_CH_LAYOUT_STEREO;
>  st->codecpar->sample_rate = samplerate;
> -st->codecpar->bit_rate= st->codecpar->sample_rate * framesize *
> 8 / 1024;
> +st->codecpar->bit_rate= st->codecpar->sample_rate * framesize /
> 128;
>
>  /* fake the ATRAC3 extradata
>   * (wav format, makes stream copy to wav work) */
> @@ -398,7 +398,7 @@ static int oma_read_header(AVFormatContext *s)
>  return AVERROR_INVALIDDATA;
>  }
>  st->codecpar->sample_rate = samplerate;
> -st->codecpar->bit_rate= samplerate * framesize * 8 / 2048;
> +st->codecpar->bit_rate= samplerate * framesize / 256;
>  avpriv_set_pts_info(st, 64, 1, samplerate);
>  break;
>  case OMA_CODECID_MP3:

Shouldn't using 8LL or similar be more future-proof?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/avfilter: fix filtering frames with unknown channel layouts for filters needing writable frames

[Paul B Mahol]

On 12/12/16, Marton Balint  wrote:
> Signed-off-by: Marton Balint 
> ---
>  libavfilter/avfilter.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

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

Re: [FFmpeg-devel] [PATCH 6/7] avcodec/mips: version 1 of wmv2dsp optimizations for loongson mmi

[Michael Niedermayer]

On Mon, Oct 10, 2016 at 04:10:59PM +0800, 周晓勇 wrote:
> From 9b19ea3364d96a6eb0f3441f549c8d20ede36592 Mon Sep 17 00:00:00 2001
> From: Zhou Xiaoyong 
> Date: Mon, 10 Oct 2016 15:04:35 +0800
> Subject: [PATCH 6/7] avcodec/mips: version 1 of wmv2dsp optimizations for
>  loongson mmi
> 

applied

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

What does censorship reveal? It reveals fear. -- Julian Assange


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

Re: [FFmpeg-devel] [PATCH 5/7] avcodec/mips: version 1 of vp8dsp optimizations for loongson mmi

[Michael Niedermayer]

On Mon, Oct 10, 2016 at 04:10:22PM +0800, 周晓勇 wrote:
> From 4fc873738c8db1cf711310bc5767f7574302eb96 Mon Sep 17 00:00:00 2001
> From: Zhou Xiaoyong 
> Date: Mon, 10 Oct 2016 14:50:08 +0800
> Subject: [PATCH 5/7] avcodec/mips: version 1 of vp8dsp optimizations for
>  loongson mmi
> 
> 
> ---
>  libavcodec/mips/Makefile   |1 +
>  libavcodec/mips/constants.c|1 +
>  libavcodec/mips/constants.h|1 +
>  libavcodec/mips/vp8dsp_init_mips.c |   89 ++
>  libavcodec/mips/vp8dsp_mips.h  |  117 ++
>  libavcodec/mips/vp8dsp_mmi.c   | 3052 
> 
>  6 files changed, 3261 insertions(+)
>  create mode 100644 libavcodec/mips/vp8dsp_mmi.c

applied

thx

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

Many things microsoft did are stupid, but not doing something just because
microsoft did it is even more stupid. If everything ms did were stupid they
would be bankrupt already.


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

Re: [FFmpeg-devel] [PATCH 4/7] avcodec/mips: loongson set xvid as default idct algorithm

[Michael Niedermayer]

On Mon, Oct 10, 2016 at 04:09:43PM +0800, 周晓勇 wrote:
> From e4d648fd34601cbe23a54af5d9489537896c6478 Mon Sep 17 00:00:00 2001
> From: Zhou Xiaoyong 
> Date: Mon, 10 Oct 2016 14:42:58 +0800
> Subject: [PATCH 4/7] avcodec/mips: loongson set xvid as default idct algorithm
> 
> 
> ---
>  libavcodec/mips/idctdsp_init_mips.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> 
> diff --git a/libavcodec/mips/idctdsp_init_mips.c 
> b/libavcodec/mips/idctdsp_init_mips.c
> index 8c26bca..7beb1f6 100644
> --- a/libavcodec/mips/idctdsp_init_mips.c
> +++ b/libavcodec/mips/idctdsp_init_mips.c
> @@ -20,6 +20,7 @@
>   */
>  
>  #include "idctdsp_mips.h"
> +#include "xvididct_mips.h"
>  
>  #if HAVE_MSA
>  static av_cold void idctdsp_init_msa(IDCTDSPContext *c, AVCodecContext 
> *avctx,
> @@ -49,7 +50,9 @@ static av_cold void idctdsp_init_mmi(IDCTDSPContext *c, 
> AVCodecContext *avctx,
>  (avctx->bits_per_raw_sample != 10) &&
>  (avctx->bits_per_raw_sample != 12) &&
>  (avctx->idct_algo == FF_IDCT_AUTO)) {
> -c->idct = ff_simple_idct_mmi;
> +c->idct_put = ff_xvid_idct_put_mmi;
> +c->idct_add = ff_xvid_idct_add_mmi;
> +c->idct = ff_xvid_idct_mmi;
>  c->perm_type = FF_IDCT_PERM_NONE;
>  }

This would affect encoders and some generated files would decode with
artifacts

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

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data


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

Re: [FFmpeg-devel] [PATCH 3/3] tiff: fix overflows when calling av_readuce

[Michael Niedermayer]

On Tue, Dec 13, 2016 at 12:50:19AM +0100, Andreas Cadhalpun wrote:
> The arguments of av_reduce are signed, so the cast to uint64_t is misleading.
> 
> Signed-off-by: Andreas Cadhalpun 
> ---
>  libavcodec/tiff.c | 11 +--
>  1 file changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
> index 4721e94..12ef419 100644
> --- a/libavcodec/tiff.c
> +++ b/libavcodec/tiff.c
> @@ -772,9 +772,16 @@ static void set_sar(TiffContext *s, unsigned tag, 
> unsigned num, unsigned den)
>  int offset = tag == TIFF_YRES ? 2 : 0;
>  s->res[offset++] = num;
>  s->res[offset]   = den;
> -if (s->res[0] && s->res[1] && s->res[2] && s->res[3])
> +if (s->res[0] && s->res[1] && s->res[2] && s->res[3]) {
> +uint64_t num = s->res[2] * (uint64_t)s->res[1];
> +uint64_t den = s->res[0] * (uint64_t)s->res[3];
> +if (num > INT64_MAX || den > INT64_MAX) {
> +num = num >> 1;
> +den = den >> 1;
> +}

this can make one of them 0, in fact i think even if they arent 0
the sample_aspect_ratio can be  after reduce
should they be checked after all that instead of before ?


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

Modern terrorism, a quick summary: Need oil, start war with country that
has oil, kill hundread thousand in war. Let country fall into chaos,
be surprised about raise of fundamantalists. Drop more bombs, kill more
people, be surprised about them taking revenge and drop even more bombs
and strip your own citizens of their rights and freedoms. to be continued


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

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Set skip_samples according to first edit list, when -ignore_editlist is set.

[Michael Niedermayer]

On Fri, Nov 11, 2016 at 10:02:28PM -0800, Sasi Inguva wrote:
> Signed-off-by: Sasi Inguva 
> ---
>  libavformat/isom.h |  2 ++
>  libavformat/mov.c  | 22 +-
>  2 files changed, 23 insertions(+), 1 deletion(-)

The commit message should be a bit more verbose,it says whats done
but not why

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

Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin


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

Re: [FFmpeg-devel] [PATCH] configure: add -fPIE instead of -pie to C flags for ThreadSanitizer

[Michael Niedermayer]

On Fri, Dec 02, 2016 at 02:04:53PM -0800, Wan-Teh Chang wrote:
> -pie was added to C flags for ThreadSanitizer in commit
> 19f251a2882a8d0779b432e63bf282e4d9c443bb. Under clang 3.8.0, the -pie
> flag causes a compiler warning and a linker error when running configure
> --toolchain=clang-tsan. Here is an excerpt from config.log:
> 
> clang ... -fsanitize=thread -pie -std=c11 -fomit-frame-pointer -pthread -c -o 
> /tmp/ffconf.hL61stP9.o /tmp/ffconf.YO6ZaSFG.c
> clang: warning: argument unused during compilation: '-pie'
> clang -fsanitize=thread -pie -Wl,--as-needed -Wl,-z,noexecstack -o 
> /tmp/ffconf.W5c2e41l /tmp/ffconf.hL61stP9.o -lbz2 -pthread
> /usr/bin/ld: /tmp/ffconf.hL61stP9.o: relocation R_X86_64_PC32 against 
> undefined symbol `atan2f@@GLIBC_2.2.5' can not be used when making a shared 
> object; recompile with -fPIC
> /usr/bin/ld: final link failed: Bad value
> clang: error: linker command failed with exit code 1 (use -v to see 
> invocation)
> 
> To be conservative, I changed -pie to -fPIE. But the documentation seems
> to imply just -fsanitize=thread is enough:
> 
> http://clang.llvm.org/docs/ThreadSanitizer.html
> https://github.com/google/sanitizers/wiki/ThreadSanitizerCppManual
> 
> Signed-off-by: Wan-Teh Chang 
> ---
>  configure | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

applied

thx

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

Modern terrorism, a quick summary: Need oil, start war with country that
has oil, kill hundread thousand in war. Let country fall into chaos,
be surprised about raise of fundamantalists. Drop more bombs, kill more
people, be surprised about them taking revenge and drop even more bombs
and strip your own citizens of their rights and freedoms. to be continued


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] tiff: fix overflows when calling av_readuce

[Andreas Cadhalpun]

The arguments of av_reduce are signed, so the cast to uint64_t is misleading.

Signed-off-by: Andreas Cadhalpun 
---
 libavcodec/tiff.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
index 4721e94..12ef419 100644
--- a/libavcodec/tiff.c
+++ b/libavcodec/tiff.c
@@ -772,9 +772,16 @@ static void set_sar(TiffContext *s, unsigned tag, unsigned 
num, unsigned den)
 int offset = tag == TIFF_YRES ? 2 : 0;
 s->res[offset++] = num;
 s->res[offset]   = den;
-if (s->res[0] && s->res[1] && s->res[2] && s->res[3])
+if (s->res[0] && s->res[1] && s->res[2] && s->res[3]) {
+uint64_t num = s->res[2] * (uint64_t)s->res[1];
+uint64_t den = s->res[0] * (uint64_t)s->res[3];
+if (num > INT64_MAX || den > INT64_MAX) {
+num = num >> 1;
+den = den >> 1;
+}
 av_reduce(>avctx->sample_aspect_ratio.num, 
>avctx->sample_aspect_ratio.den,
-  s->res[2] * (uint64_t)s->res[1], s->res[0] * 
(uint64_t)s->res[3], INT32_MAX);
+  num, den, INT32_MAX);
+}
 }
 
 static int tiff_decode_tag(TiffContext *s, AVFrame *frame)
-- 
2.10.2

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

[FFmpeg-devel] [PATCH 2/3] avformat: fix overflows during bit rate calculation

[Andreas Cadhalpun]

The bit_rate field has type int64_t since commit
7404f3bdb90e6a5dcb59bc0a091e2c5c038e557d.

Signed-off-by: Andreas Cadhalpun 
---
 libavformat/adxdec.c | 2 +-
 libavformat/aiffdec.c| 4 ++--
 libavformat/apc.c| 2 +-
 libavformat/bfi.c| 2 +-
 libavformat/electronicarts.c | 2 +-
 libavformat/iff.c| 2 +-
 libavformat/soxdec.c | 2 +-
 libavformat/voc_packet.c | 2 +-
 libavformat/vqf.c| 2 +-
 libavformat/wsddec.c | 2 +-
 10 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/libavformat/adxdec.c b/libavformat/adxdec.c
index 0315ecb..a271e2a 100644
--- a/libavformat/adxdec.c
+++ b/libavformat/adxdec.c
@@ -116,7 +116,7 @@ static int adx_read_header(AVFormatContext *s)
 
 par->codec_type  = AVMEDIA_TYPE_AUDIO;
 par->codec_id= s->iformat->raw_codec_id;
-par->bit_rate= par->sample_rate * par->channels * BLOCK_SIZE * 8LL / 
BLOCK_SAMPLES;
+par->bit_rate= (int64_t)par->sample_rate * par->channels * BLOCK_SIZE 
* 8LL / BLOCK_SAMPLES;
 
 avpriv_set_pts_info(st, 64, BLOCK_SAMPLES, par->sample_rate);
 
diff --git a/libavformat/aiffdec.c b/libavformat/aiffdec.c
index 59e969d..9e7a39c 100644
--- a/libavformat/aiffdec.c
+++ b/libavformat/aiffdec.c
@@ -181,7 +181,7 @@ static int get_aiff_header(AVFormatContext *s, int size,
 par->block_align = (av_get_bits_per_sample(par->codec_id) * 
par->channels) >> 3;
 
 if (aiff->block_duration) {
-par->bit_rate = par->sample_rate * (par->block_align << 3) /
+par->bit_rate = (int64_t)par->sample_rate * (par->block_align << 3) /
 aiff->block_duration;
 }
 
@@ -318,7 +318,7 @@ static int aiff_read_header(AVFormatContext *s)
 st->codecpar->block_align = 35;
 }
 aiff->block_duration = 160;
-st->codecpar->bit_rate = st->codecpar->sample_rate * 
(st->codecpar->block_align << 3) /
+st->codecpar->bit_rate = (int64_t)st->codecpar->sample_rate * 
(st->codecpar->block_align << 3) /
  aiff->block_duration;
 }
 break;
diff --git a/libavformat/apc.c b/libavformat/apc.c
index a4dcf66..b180a50 100644
--- a/libavformat/apc.c
+++ b/libavformat/apc.c
@@ -65,7 +65,7 @@ static int apc_read_header(AVFormatContext *s)
 }
 
 st->codecpar->bits_per_coded_sample = 4;
-st->codecpar->bit_rate = st->codecpar->bits_per_coded_sample * 
st->codecpar->channels
+st->codecpar->bit_rate = (int64_t)st->codecpar->bits_per_coded_sample * 
st->codecpar->channels
   * st->codecpar->sample_rate;
 st->codecpar->block_align = 1;
 
diff --git a/libavformat/bfi.c b/libavformat/bfi.c
index ef4c17d..6c98e33 100644
--- a/libavformat/bfi.c
+++ b/libavformat/bfi.c
@@ -108,7 +108,7 @@ static int bfi_read_header(AVFormatContext * s)
 astream->codecpar->channel_layout  = AV_CH_LAYOUT_MONO;
 astream->codecpar->bits_per_coded_sample = 8;
 astream->codecpar->bit_rate=
-astream->codecpar->sample_rate * 
astream->codecpar->bits_per_coded_sample;
+(int64_t)astream->codecpar->sample_rate * 
astream->codecpar->bits_per_coded_sample;
 avio_seek(pb, chunk_header - 3, SEEK_SET);
 avpriv_set_pts_info(astream, 64, 1, astream->codecpar->sample_rate);
 return 0;
diff --git a/libavformat/electronicarts.c b/libavformat/electronicarts.c
index 80ce4c6..30eb723 100644
--- a/libavformat/electronicarts.c
+++ b/libavformat/electronicarts.c
@@ -557,7 +557,7 @@ static int ea_read_header(AVFormatContext *s)
 st->codecpar->channels  = ea->num_channels;
 st->codecpar->sample_rate   = ea->sample_rate;
 st->codecpar->bits_per_coded_sample = ea->bytes * 8;
-st->codecpar->bit_rate  = st->codecpar->channels *
+st->codecpar->bit_rate  = (int64_t)st->codecpar->channels *
   st->codecpar->sample_rate *
   
st->codecpar->bits_per_coded_sample / 4;
 st->codecpar->block_align   = st->codecpar->channels *
diff --git a/libavformat/iff.c b/libavformat/iff.c
index bf44170..29fb7bf 100644
--- a/libavformat/iff.c
+++ b/libavformat/iff.c
@@ -748,7 +748,7 @@ static int iff_read_header(AVFormatContext *s)
 }
 
 st->codecpar->bits_per_coded_sample = 
av_get_bits_per_sample(st->codecpar->codec_id);
-st->codecpar->bit_rate = st->codecpar->channels * 
st->codecpar->sample_rate * st->codecpar->bits_per_coded_sample;
+st->codecpar->bit_rate = (int64_t)st->codecpar->channels * 
st->codecpar->sample_rate * st->codecpar->bits_per_coded_sample;
 st->codecpar->block_align = st->codecpar->channels * 
st->codecpar->bits_per_coded_sample;
 if (st->codecpar->codec_tag == ID_DSD && st->codecpar->block_align <= 
0)
  

[FFmpeg-devel] [PATCH 1/3] omadec: fix overflows during bit rate calculation

[Andreas Cadhalpun]

Signed-off-by: Andreas Cadhalpun 
---
 libavformat/omadec.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavformat/omadec.c b/libavformat/omadec.c
index 6e476db..e7751d0 100644
--- a/libavformat/omadec.c
+++ b/libavformat/omadec.c
@@ -365,7 +365,7 @@ static int oma_read_header(AVFormatContext *s)
 st->codecpar->channels= 2;
 st->codecpar->channel_layout = AV_CH_LAYOUT_STEREO;
 st->codecpar->sample_rate = samplerate;
-st->codecpar->bit_rate= st->codecpar->sample_rate * framesize * 8 
/ 1024;
+st->codecpar->bit_rate= st->codecpar->sample_rate * framesize / 
128;
 
 /* fake the ATRAC3 extradata
  * (wav format, makes stream copy to wav work) */
@@ -398,7 +398,7 @@ static int oma_read_header(AVFormatContext *s)
 return AVERROR_INVALIDDATA;
 }
 st->codecpar->sample_rate = samplerate;
-st->codecpar->bit_rate= samplerate * framesize * 8 / 2048;
+st->codecpar->bit_rate= samplerate * framesize / 256;
 avpriv_set_pts_info(st, 64, 1, samplerate);
 break;
 case OMA_CODECID_MP3:
-- 
2.10.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avutil: fix data race in av_get_cpu_flags()

[Michael Niedermayer]

On Tue, Dec 06, 2016 at 06:16:13PM -0800, Wan-Teh Chang wrote:
> Make the one-time initialization in av_get_cpu_flags() thread-safe. The
> static variable |cpu_flags| in libavutil/cpu.c is read and written using
> normal load and store operations. These are considered as data races.
> The fix is to use atomic load and store operations.
> 
> The fix can be verified by running the libavutil/tests/cpu_init.c test
> program under ThreadSanitizer:
> ./configure --toolchain=clang-tsan
> make libavutil/tests/cpu_init
> libavutil/tests/cpu_init
> 
> There should be no warnings from ThreadSanitizer.
> 
> Co-author: Dmitry Vyukov of Google, who suggested the data race fix.
> 
> Signed-off-by: Wan-Teh Chang 
> ---
>  libavutil/cpu.c | 12 +++-
>  libavutil/cpu.h |  2 --
>  2 files changed, 7 insertions(+), 7 deletions(-)

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 2/2] avformat/utils: Print verbose error message if stream count exceeds max_streams

[Andreas Cadhalpun]

On 10.12.2016 20:15, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/utils.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index 9e979a7c79..897352924d 100644
> --- a/libavformat/utils.c
> +++ b/libavformat/utils.c
> @@ -4217,8 +4217,11 @@ AVStream *avformat_new_stream(AVFormatContext *s, 
> const AVCodec *c)
>  int i;
>  AVStream **streams;
>  
> -if (s->nb_streams >= FFMIN(s->max_streams, INT_MAX/sizeof(*streams)))
> +if (s->nb_streams >= FFMIN(s->max_streams, INT_MAX/sizeof(*streams))) {
> +if (s->max_streams < INT_MAX/sizeof(*streams))
> +av_log(s, AV_LOG_ERROR, "Number of streams exceeds max_streams 
> parameter (%d), see the documentation if you wish to increase it\n", 
> s->max_streams);
>  return NULL;
> +}
>  streams = av_realloc_array(s->streams, s->nb_streams + 1, 
> sizeof(*streams));
>  if (!streams)
>  return NULL;
> 

This is probably OK.

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

Re: [FFmpeg-devel] [PATCH 1/2] avformat/options_table: Set the default maximum number of streams to 1000

[Andreas Cadhalpun]

On 10.12.2016 20:15, Michael Niedermayer wrote:
> Fixes CVE-2016-9561

I think the commit message should mention that the security relevance of
this is disputed, as running out of memory can happen with valid files.

> Suggested-by: Andreas Cadhalpun 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/options_table.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavformat/options_table.h b/libavformat/options_table.h
> index d5448e503f..a537dda95e 100644
> --- a/libavformat/options_table.h
> +++ b/libavformat/options_table.h
> @@ -105,7 +105,7 @@ static const AVOption avformat_options[] = {
>  {"format_whitelist", "List of demuxers that are allowed to be used", 
> OFFSET(format_whitelist), AV_OPT_TYPE_STRING, { .str = NULL },  CHAR_MIN, 
> CHAR_MAX, D },
>  {"protocol_whitelist", "List of protocols that are allowed to be used", 
> OFFSET(protocol_whitelist), AV_OPT_TYPE_STRING, { .str = NULL },  CHAR_MIN, 
> CHAR_MAX, D },
>  {"protocol_blacklist", "List of protocols that are not allowed to be used", 
> OFFSET(protocol_blacklist), AV_OPT_TYPE_STRING, { .str = NULL },  CHAR_MIN, 
> CHAR_MAX, D },
> -{"max_streams", "maximum number of streams", OFFSET(max_streams), 
> AV_OPT_TYPE_INT, { .i64 = INT_MAX }, 0, INT_MAX, D },
> +{"max_streams", "maximum number of streams", OFFSET(max_streams), 
> AV_OPT_TYPE_INT, { .i64 = 1000 }, 0, INT_MAX, D },
>  {NULL},
>  };

The change itself looks good to me.

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

Re: [FFmpeg-devel] [PATCH] lavf: add ffprobe demuxer

[Andreas Cadhalpun]

On 10.12.2016 17:55, Stefano Sabatini wrote:
> From ebc34da37648a07f25da94a1662c278c13ca7383 Mon Sep 17 00:00:00 2001
> From: Nicolas George 
> Date: Sat, 11 Jan 2014 19:42:41 +0100
> Subject: [PATCH] lavf: add ffprobe demuxer
> 
> With several modifications and documentation by Stefano Sabatini
> .
> 
> Signed-off-by: Nicolas George 
> ---
>  doc/demuxers.texi|  19 ++
>  doc/ffprobe-format.texi  | 121 +
>  doc/formats.texi |   1 +
>  libavformat/Makefile |   1 +
>  libavformat/allformats.c |   1 +
>  libavformat/ffprobedec.c | 452 
> +++
>  6 files changed, 595 insertions(+)
>  create mode 100644 doc/ffprobe-format.texi
>  create mode 100644 libavformat/ffprobedec.c
> 
[...]
> diff --git a/libavformat/ffprobedec.c b/libavformat/ffprobedec.c
> new file mode 100644
> index 000..f5d5ed7
> --- /dev/null
> +++ b/libavformat/ffprobedec.c
[...]
> +if (av_strstart(buf, "codec_name=", )) {
> +const AVCodecDescriptor *desc = 
> avcodec_descriptor_get_by_name(val);
> +if (desc) {
> +st->codecpar->codec_id   = desc->id;
> +st->codecpar->codec_type = desc->type;
> +}
> +if (!desc) {
> +av_log(avf, AV_LOG_WARNING, "Cannot recognize codec name 
> '%s'", val);

This log message is missing a newline at the end.

Other than that this only needs adding the format to doc/general.texi,
a minor version bump and a changelog entry.

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

Re: [FFmpeg-devel] [PATCH] opt: reject denominator zero as out of range

[Andreas Cadhalpun]

On 12.12.2016 03:39, Michael Niedermayer wrote:
> On Mon, Dec 12, 2016 at 01:31:47AM +0100, Andreas Cadhalpun wrote:
>> Signed-off-by: Andreas Cadhalpun 
>> ---
>>  libavutil/opt.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavutil/opt.c b/libavutil/opt.c
>> index f855ccb..6ae2af6 100644
>> --- a/libavutil/opt.c
>> +++ b/libavutil/opt.c
>> @@ -97,7 +97,7 @@ static int read_number(const AVOption *o, const void *dst, 
>> double *num, int *den
>>  static int write_number(void *obj, const AVOption *o, void *dst, double 
>> num, int den, int64_t intnum)
>>  {
>>  if (o->type != AV_OPT_TYPE_FLAGS &&
>> -(o->max * den < num * intnum || o->min * den > num * intnum)) {
>> +(!den || o->max * den < num * intnum || o->min * den > num * 
>> intnum)) {
> 
> probably ok

Pushed.

> (i assume we dont want/need to have 1/0 and max=infinity )

I also think so.

Best regards,
Andreas

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

Re: [FFmpeg-devel] [PATCH] libvpxenc: Don't spam level errors for VP8 encodes

[James Zern]

On Mon, Dec 12, 2016 at 12:12 PM, Alex Converse  wrote:
> Fixes "Failed to set VP9E_GET_LEVEL codec control: Codec does not
> implement requested capability" log messages on VP8 encodes.
> ---
>  libavcodec/libvpxenc.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>

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

Re: [FFmpeg-devel] [PATCH 1/2] avutil/replaygain: add av_replaygain_alloc()

[James Almer]

On 12/12/2016 7:24 PM, Michael Niedermayer wrote:
> On Mon, Dec 12, 2016 at 12:23:00AM -0300, James Almer wrote:
>> Signed-off-by: James Almer 
>> ---
>> TODO: APIChanges entry and version bump.
>>
>>  libavutil/replaygain.c | 38 ++
>>  libavutil/replaygain.h | 10 ++
>>  2 files changed, 48 insertions(+)
>>  create mode 100644 libavutil/replaygain.c
> 
> missing Makefile update

Whoops, fixed locally.

Thanks for noticing.

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

Re: [FFmpeg-devel] [PATCH 1/2] avutil/replaygain: add av_replaygain_alloc()

[Michael Niedermayer]

On Mon, Dec 12, 2016 at 12:23:00AM -0300, James Almer wrote:
> Signed-off-by: James Almer 
> ---
> TODO: APIChanges entry and version bump.
> 
>  libavutil/replaygain.c | 38 ++
>  libavutil/replaygain.h | 10 ++
>  2 files changed, 48 insertions(+)
>  create mode 100644 libavutil/replaygain.c

missing Makefile update

[...]
-- 
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

[FFmpeg-devel] [PATCH] avfilter/avfilter: fix filtering frames with unknown channel layouts for filters needing writable frames

[Marton Balint]

Signed-off-by: Marton Balint 
---
 libavfilter/avfilter.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavfilter/avfilter.c b/libavfilter/avfilter.c
index 662f933..6f30e3b 100644
--- a/libavfilter/avfilter.c
+++ b/libavfilter/avfilter.c
@@ -1096,7 +1096,7 @@ static int ff_filter_frame_framed(AVFilterLink *link, 
AVFrame *frame)
 case AVMEDIA_TYPE_AUDIO:
 av_samples_copy(out->extended_data, frame->extended_data,
 0, 0, frame->nb_samples,
-
av_get_channel_layout_nb_channels(frame->channel_layout),
+av_frame_get_channels(frame),
 frame->format);
 break;
 default:
-- 
2.10.2

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

[FFmpeg-devel] ARM fate

[Michael Niedermayer]

Hi all

The panda arm board iam using as fate client for fate.ffmpeg.org seems
not really able to handle the load.
Iam not sure why, but increasing number of fate tests, branches it
tests and compiler/option cases probably are the primary reason.
I already dropped half the branches it tests but it still needs
apparently on the order of a week for a single pass.

It would make alot of sense if more people could help here and run
some arm fate clients so that stuff gets tested more regularly and
with less latency

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.


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] Revert "avcodec: Add max_pixels options"

[Michael Niedermayer]

On Mon, Dec 12, 2016 at 09:16:54PM +0100, wm4 wrote:
> On Mon, 12 Dec 2016 21:00:19 +0100
> Michael Niedermayer  wrote:
> 
> > On Mon, Dec 12, 2016 at 12:04:05PM +0100, Nicolas George wrote:
> > > Le primidi 21 frimaire, an CCXXV, Michael Niedermayer a écrit :  
[...]
> > completely independant of this, the option is needed to fuzz FFmpeg
> > efficiently as andreas explained
> > 
> > and also completely independant of this, the option is needed to
> > allow finding some fixable OOM bugs that i would like to fix
> 
> You can do that with a wrapper that makes malloc randomly fail.

no, that will find a different class of issues

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

Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin


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] Revert "avcodec: Add max_pixels options"

[wm4]

On Mon, 12 Dec 2016 21:00:19 +0100
Michael Niedermayer  wrote:

> On Mon, Dec 12, 2016 at 12:04:05PM +0100, Nicolas George wrote:
> > Le primidi 21 frimaire, an CCXXV, Michael Niedermayer a écrit :  
> > > You misunderstand
> > > 
> > > I want to find code that allocates too much memory where it should
> > > not.
> > > to give an example
> > > there was long ago some code like
> > > 
> > > len = read()
> > > for (i > > x= alloc()
> > > x.whatever =read()
> > > ...
> > > 
> > > Straight OOM here with a tiny input file.
> > > add a simple if(eof) in there and no OOM anymore
> > > this is just one example, code can look very diferent.
> > > 
> > > I want to find these cases and i want to fix them
> > > But what i get from the fuzzer is files with resolutions like
> > > 65123x3210 which go OOM because of valid but silly resolution.
> > > If i can limit the resolution then i can find the other issues
> > > which i can fix.
> > > If i cannot limit the resolution then i cannot fix the other issues
> > > as they are in a sea of OOMs from large resolution files
> > > 
> > > Nothing you can do at the OS level will get you this effect  
> > 
> > Thanks for explaining.
> > 
> > If I read this correctly, this option does not fix any security issue at
> > all, it only help you find other parts of the code that may contain
> > security issues. Am I right?  
> 
> its more complex
> there are really independant things this achievs
> 
> OOM is a security issue under some(1) circumstances, one can hit OOM due
> to too many pixels (or streams), this specific issue is fixed by the
> options

But the transcoding dies with the max_streams limit enforced too. On
the other hand, if your server doesn't run the ffmpeg transcoder process
in a sandbox, and that process dying due to OOM kills your server, and
in response makes your entire site unavailable AND causes some actual
security issue... uh, I don't know what to say. Just don't run a server
in this case.

> 
> completely independant of this, the option is needed to fuzz FFmpeg
> efficiently as andreas explained
> 
> and also completely independant of this, the option is needed to
> allow finding some fixable OOM bugs that i would like to fix

You can do that with a wrapper that makes malloc randomly fail.

> 
> (1) For example a server process that dies due to it. Even if restarted
> this can put load on the machine to be a effective was to DOS it
> 
> Also its certainly true that this does not fix every OOM issue but
> no bugfix that fixes a out of array read fixes every out of array read
> either

An array out of bounds read is a real issue that programmers try to
avoid. OOM on the other hand is a "normal" failure just as much as an
invalid file that can't be read.

> 
> 
> >   
> > > it is exceptionally unprofessional to publish testcases for CVEs
> > > before they have been fixed.
> > > Also more generally its the researchers choice/job to publish their
> > > work. If you belive it should be put in a ticket you should ask him
> > > not a 3rd party like me to do that.  
> > 
> > This is Free software, secrecy is not a good policy. "I have this patch
> > that fix a bug, but I can not show you the bug." Well, if the patch is
> > straightforward, we can accept it, but if the patch is not
> > straightforward, we need, collectively, to see the bug.
> > 
> > I can understand that if the bug is a critical 0-day exploit, some
> > leeway must be accepted. But "there is a file that triggers a crash" is
> > not enough by far.  
> 
> If it is neccessary to publish exploits then i belive all security
> support will end in FFmpeg and move elsewhere
> I cannot really speak for others but i belive that companies doing
> fuzzing and submit testcases will not submit them if that implies
> them being made public. Actually they can probably not even legally
> do that if they wanted it would massivly endanger their customers.
> 
> About this specific bug, as mentioned it has a CVE, it is on the public
> oss security list
> heres a link:
> http://www.openwall.com/lists/oss-security/2016/12/08/1

Causing this a vulnerability was already derided as nonsense.

Assuming it's a real OOM kill, and not a buggy OOM error handling path.
I can't really see this from the report.

> That seems more than adequate to understand this one reported case
> I can privatly share the sample with FFmpeg developers who work on
> writing an alterantive fix
> 
> [...]
> 
> 

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

[FFmpeg-devel] [PATCH] libvpxenc: Don't spam level errors for VP8 encodes

[Alex Converse]

Fixes "Failed to set VP9E_GET_LEVEL codec control: Codec does not
implement requested capability" log messages on VP8 encodes.
---
 libavcodec/libvpxenc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
index 1325199..de0d0b6 100644
--- a/libavcodec/libvpxenc.c
+++ b/libavcodec/libvpxenc.c
@@ -293,7 +293,8 @@ static av_cold int vpx_free(AVCodecContext *avctx)
 VPxContext *ctx = avctx->priv_data;
 
 #if VPX_ENCODER_ABI_VERSION >= 12
-if (ctx->level >= 0 && !(avctx->flags & AV_CODEC_FLAG_PASS1)) {
+if (avctx->codec_id == AV_CODEC_ID_VP9 && ctx->level >= 0 &&
+!(avctx->flags & AV_CODEC_FLAG_PASS1)) {
 int level_out = 0;
 if (!codecctl_intp(avctx, VP9E_GET_LEVEL, _out))
 av_log(avctx, AV_LOG_INFO, "Encoded level %.1f\n", level_out * 
0.1);
-- 
2.8.0.rc3.226.g39d4020

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

Re: [FFmpeg-devel] [PATCH] avcodec: Require avoptions for the user to set max_pixels.

[Michael Niedermayer]

On Mon, Dec 12, 2016 at 08:28:40PM +0100, wm4 wrote:
> On Mon, 12 Dec 2016 19:55:59 +0100
> Michael Niedermayer  wrote:
> 
> > On Mon, Dec 12, 2016 at 05:59:32PM +0100, wm4 wrote:
> > > On Mon, 12 Dec 2016 17:34:15 +0100
> > > Michael Niedermayer  wrote:
> > >   
> > > > On Mon, Dec 12, 2016 at 09:48:01AM +0100, wm4 wrote:  
> > > > > On Mon, 12 Dec 2016 03:34:27 +0100
> > > > > Michael Niedermayer  wrote:
> > > > > 
> > > > > > On Sun, Dec 11, 2016 at 10:51:08PM -0300, James Almer wrote:
> > > > > > > On 12/11/2016 10:29 PM, Michael Niedermayer wrote:  
> > > > > > > > On Sat, Dec 10, 2016 at 09:52:08PM -0300, James Almer wrote:
> > > > > > > >   
> > > > > > > >> On 12/10/2016 9:23 PM, Michael Niedermayer wrote:  
> > > > > > > >>> On Sat, Dec 10, 2016 at 08:31:57PM -0300, James Almer wrote:  
> > > > > > > >>> 
> > > > > > >  On 12/10/2016 7:01 PM, Michael Niedermayer wrote:  
> > > > > > > > [...]
> > > > > > > >   
> > > > > > > >>> And also theres more work for us to maintain seperate 
> > > > > > > >>> implementations
> > > > > > > >>> for the options, all code accessing them has to deal with 
> > > > > > > >>> them being
> > > > > > > >>> in different places, making all related backports harder.
> > > > > > > >>>
> > > > > > > >>> To me that looks like a disadvantage from every side
> > > > > > > >>>
> > > > > > > >>> I think the real solution is to start liking AVOptions, they 
> > > > > > > >>> make
> > > > > > > >>> our work easier.  
> > > > > > > >>
> > > > > > > >> AVOptions are fine. Private-but-not-really and 
> > > > > > > >> no-direct-access fields
> > > > > > > >> in public structs are what's kinda ugly an unpopular.  
> > > > > > > > 
> > > > > > > > a slightly off topic question but
> > > > > > > > if people care about these existing "no direct access" fields
> > > > > > > > why do they not change them ?
> > > > > > > > its a bit reading and thinking and droping the "no direct 
> > > > > > > > access"
> > > > > > > > comments, this is not much work
> > > > > > > > It requires a tiny bit of care so that future added fields dont 
> > > > > > > > do
> > > > > > > > bad things and we should document that past releases still in 
> > > > > > > > some
> > > > > > > > cases need the indirect access  ...
> > > > > > > > 
> > > > > > > > just seems a bit odd to me in relation to the opposition to add 
> > > > > > > > such
> > > > > > > > a field were its needed for a bugfix but total apparent lack of
> > > > > > > > interrest in removing such "no direct access" restrctions  
> > > > > > > > where there
> > > > > > > > is no reason at all to keep them  
> > > > > > > 
> > > > > > > They are all supposed to stop being no direct access with the 
> > > > > > > next bump.
> > > > > > > Afaik most are remnants of the libav ABI compatibility days, same 
> > > > > > > with
> > > > > > > the get/setter functions, but they can't just be removed right 
> > > > > > > now because
> > > > > > > there are several versions using the current ABI (3.0 and newer i 
> > > > > > > think).  
> > > > > > 
> > > > > > theres no need to wait for the next bump with removing many of the
> > > > > > "no direct access" rules because the fields always where in the same
> > > > > > position in the current major version
> > > > > > 
> > > > > > Removing them before the bump would allow people to stop using
> > > > > > the accessors earlier
> > > > > > 
> > > > > > someone needs to read through the struct and think about it though
> > > > > > so nothing is missed but from just the diff between master and
> > > > > > the releases there seem to be many that did not move
> > > > > 
> > > > > Can I send a patch that makes them "real" public fields, and which
> > > > > deprecates the accessors? In all libs?
> > > > 
> > > > If someone first checks that they are in the same offset in their
> > > > structs in all FFmpeg releases with the same soname.
> > > > And someone checks that we have no "insert new ... field above/below
> > > > this line" things above them
> > > > 
> > > > Yes, definitly  
> > > 
> > > The offsets wouldn't have to be the same, since they were allowed to be
> > > accessed by accessor only.  
> > 
> > thats true but someone writing code to access it would likely use
> > the latest documentation and if that doesnt mention that earlier
> > versions needed a different access then likely not realize and as
> > that app would build and work fine against a release he wouldnt notice
> > until that app built against a older release is then linked to a
> > newer
> 
> We've never cared about such cases before.

I never knowingly ignored such case before
quite possibly i did so without conciously realizing. 

[...]
-- 
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, 

Re: [FFmpeg-devel] [PATCH 1/3] Revert "avcodec: Add max_pixels options"

[Michael Niedermayer]

On Mon, Dec 12, 2016 at 12:04:05PM +0100, Nicolas George wrote:
> Le primidi 21 frimaire, an CCXXV, Michael Niedermayer a écrit :
> > You misunderstand
> > 
> > I want to find code that allocates too much memory where it should
> > not.
> > to give an example
> > there was long ago some code like
> > 
> > len = read()
> > for (i > x= alloc()
> > x.whatever =read()
> > ...
> > 
> > Straight OOM here with a tiny input file.
> > add a simple if(eof) in there and no OOM anymore
> > this is just one example, code can look very diferent.
> > 
> > I want to find these cases and i want to fix them
> > But what i get from the fuzzer is files with resolutions like
> > 65123x3210 which go OOM because of valid but silly resolution.
> > If i can limit the resolution then i can find the other issues
> > which i can fix.
> > If i cannot limit the resolution then i cannot fix the other issues
> > as they are in a sea of OOMs from large resolution files
> > 
> > Nothing you can do at the OS level will get you this effect
> 
> Thanks for explaining.
> 
> If I read this correctly, this option does not fix any security issue at
> all, it only help you find other parts of the code that may contain
> security issues. Am I right?

its more complex
there are really independant things this achievs

OOM is a security issue under some(1) circumstances, one can hit OOM due
to too many pixels (or streams), this specific issue is fixed by the
options

completely independant of this, the option is needed to fuzz FFmpeg
efficiently as andreas explained

and also completely independant of this, the option is needed to
allow finding some fixable OOM bugs that i would like to fix


(1) For example a server process that dies due to it. Even if restarted
this can put load on the machine to be a effective was to DOS it

Also its certainly true that this does not fix every OOM issue but
no bugfix that fixes a out of array read fixes every out of array read
either


> 
> > it is exceptionally unprofessional to publish testcases for CVEs
> > before they have been fixed.
> > Also more generally its the researchers choice/job to publish their
> > work. If you belive it should be put in a ticket you should ask him
> > not a 3rd party like me to do that.
> 
> This is Free software, secrecy is not a good policy. "I have this patch
> that fix a bug, but I can not show you the bug." Well, if the patch is
> straightforward, we can accept it, but if the patch is not
> straightforward, we need, collectively, to see the bug.
> 
> I can understand that if the bug is a critical 0-day exploit, some
> leeway must be accepted. But "there is a file that triggers a crash" is
> not enough by far.

If it is neccessary to publish exploits then i belive all security
support will end in FFmpeg and move elsewhere
I cannot really speak for others but i belive that companies doing
fuzzing and submit testcases will not submit them if that implies
them being made public. Actually they can probably not even legally
do that if they wanted it would massivly endanger their customers.

About this specific bug, as mentioned it has a CVE, it is on the public
oss security list
heres a link:
http://www.openwall.com/lists/oss-security/2016/12/08/1

That seems more than adequate to understand this one reported case
I can privatly share the sample with FFmpeg developers who work on
writing an alterantive fix

[...]


-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data


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

Re: [FFmpeg-devel] [PATCH] configure: add -fPIE instead of -pie to C flags for ThreadSanitizer

[Carl Eugen Hoyos]

2016-12-12 20:55 GMT+01:00 Wan-Teh Chang :
> gcc 6.2.0 works with and without my patch.

Thank you.

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

Re: [FFmpeg-devel] [PATCH 1/3] Revert "avcodec: Add max_pixels options"

[Carl Eugen Hoyos]

2016-12-11 19:27 GMT+01:00 Nicolas George :
> To give an example, I think Anton, with his "evil plans", is
> good at seeing the big picture

To me, this seems like exactly the kind of offense that are
constantly asking to avoid.

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

Re: [FFmpeg-devel] [PATCH] configure: add -fPIE instead of -pie to C flags for ThreadSanitizer

[Wan-Teh Chang]

On Mon, Dec 12, 2016 at 6:42 AM, Carl Eugen Hoyos  wrote:
> 2016-12-02 23:04 GMT+01:00 Wan-Teh Chang :
>> -pie was added to C flags for ThreadSanitizer in commit
>> 19f251a2882a8d0779b432e63bf282e4d9c443bb. Under clang 3.8.0, the -pie
>> flag causes a compiler warning and a linker error when running configure
>> --toolchain=clang-tsan.
>
> Does the patch have any effect when using gcc?

Hi Carl,

Yes, the patch modifies the code shared by --toolchain=clang-tsan and
--toolchain=gcc-tsan.

I am using Ubuntu 14.04 LTS, which comes with gcc 4.8.4. gcc 4.8.4
does NOT work with and without my patch. I got an error in config.log
like this:

==
check_cc
BEGIN /tmp/ffconf.jceENASz.c
1   int main(void){ return 0; }
END /tmp/ffconf.jceENASz.c
gcc -fsanitize=thread -fPIE -fPIC -c -o /tmp/ffconf.LuPWPOJB.o
/tmp/ffconf.jceENASz.c
gcc -fsanitize=thread -pie -fPIC -o /tmp/ffconf.03RtebJv /tmp/ffconf.LuPWPOJB.o
/tmp/ffconf.LuPWPOJB.o: In function `_GLOBAL__sub_I_00099_0_ffconf.jceENASz.c':
ffconf.jceENASz.c:(.text+0x10): undefined reference to `__tsan_init'
collect2: error: ld returned 1 exit status
C compiler test failed.
==

This looks like the gcc 4.9.2 bug described in
https://bugs.launchpad.net/ubuntu/+source/gcc-5/+bug/1413474.
Unfortunately, I can't fix the undefined reference to __tsan_init even
if I add -ltsan to the linker flags.

I then built gcc 6.2.0 from sources and tested it. gcc 6.2.0 works
with and without my patch. So I consider my patch safe for gcc. If
there is any other gcc version I should test my patch with, please let
me know.

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

Re: [FFmpeg-devel] [PATCH] avcodec: Require avoptions for the user to set max_pixels.

[wm4]

On Mon, 12 Dec 2016 19:55:59 +0100
Michael Niedermayer  wrote:

> On Mon, Dec 12, 2016 at 05:59:32PM +0100, wm4 wrote:
> > On Mon, 12 Dec 2016 17:34:15 +0100
> > Michael Niedermayer  wrote:
> >   
> > > On Mon, Dec 12, 2016 at 09:48:01AM +0100, wm4 wrote:  
> > > > On Mon, 12 Dec 2016 03:34:27 +0100
> > > > Michael Niedermayer  wrote:
> > > > 
> > > > > On Sun, Dec 11, 2016 at 10:51:08PM -0300, James Almer wrote:
> > > > > > On 12/11/2016 10:29 PM, Michael Niedermayer wrote:  
> > > > > > > On Sat, Dec 10, 2016 at 09:52:08PM -0300, James Almer wrote:  
> > > > > > >> On 12/10/2016 9:23 PM, Michael Niedermayer wrote:  
> > > > > > >>> On Sat, Dec 10, 2016 at 08:31:57PM -0300, James Almer wrote:
> > > > > > >>>   
> > > > > >  On 12/10/2016 7:01 PM, Michael Niedermayer wrote:  
> > > > > > > [...]
> > > > > > >   
> > > > > > >>> And also theres more work for us to maintain seperate 
> > > > > > >>> implementations
> > > > > > >>> for the options, all code accessing them has to deal with them 
> > > > > > >>> being
> > > > > > >>> in different places, making all related backports harder.
> > > > > > >>>
> > > > > > >>> To me that looks like a disadvantage from every side
> > > > > > >>>
> > > > > > >>> I think the real solution is to start liking AVOptions, they 
> > > > > > >>> make
> > > > > > >>> our work easier.  
> > > > > > >>
> > > > > > >> AVOptions are fine. Private-but-not-really and no-direct-access 
> > > > > > >> fields
> > > > > > >> in public structs are what's kinda ugly an unpopular.  
> > > > > > > 
> > > > > > > a slightly off topic question but
> > > > > > > if people care about these existing "no direct access" fields
> > > > > > > why do they not change them ?
> > > > > > > its a bit reading and thinking and droping the "no direct access"
> > > > > > > comments, this is not much work
> > > > > > > It requires a tiny bit of care so that future added fields dont do
> > > > > > > bad things and we should document that past releases still in some
> > > > > > > cases need the indirect access  ...
> > > > > > > 
> > > > > > > just seems a bit odd to me in relation to the opposition to add 
> > > > > > > such
> > > > > > > a field were its needed for a bugfix but total apparent lack of
> > > > > > > interrest in removing such "no direct access" restrctions  where 
> > > > > > > there
> > > > > > > is no reason at all to keep them  
> > > > > > 
> > > > > > They are all supposed to stop being no direct access with the next 
> > > > > > bump.
> > > > > > Afaik most are remnants of the libav ABI compatibility days, same 
> > > > > > with
> > > > > > the get/setter functions, but they can't just be removed right now 
> > > > > > because
> > > > > > there are several versions using the current ABI (3.0 and newer i 
> > > > > > think).  
> > > > > 
> > > > > theres no need to wait for the next bump with removing many of the
> > > > > "no direct access" rules because the fields always where in the same
> > > > > position in the current major version
> > > > > 
> > > > > Removing them before the bump would allow people to stop using
> > > > > the accessors earlier
> > > > > 
> > > > > someone needs to read through the struct and think about it though
> > > > > so nothing is missed but from just the diff between master and
> > > > > the releases there seem to be many that did not move
> > > > 
> > > > Can I send a patch that makes them "real" public fields, and which
> > > > deprecates the accessors? In all libs?
> > > 
> > > If someone first checks that they are in the same offset in their
> > > structs in all FFmpeg releases with the same soname.
> > > And someone checks that we have no "insert new ... field above/below
> > > this line" things above them
> > > 
> > > Yes, definitly  
> > 
> > The offsets wouldn't have to be the same, since they were allowed to be
> > accessed by accessor only.  
> 
> thats true but someone writing code to access it would likely use
> the latest documentation and if that doesnt mention that earlier
> versions needed a different access then likely not realize and as
> that app would build and work fine against a release he wouldnt notice
> until that app built against a older release is then linked to a
> newer

We've never cared about such cases before.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec: Require avoptions for the user to set max_pixels.

[Michael Niedermayer]

On Mon, Dec 12, 2016 at 05:59:32PM +0100, wm4 wrote:
> On Mon, 12 Dec 2016 17:34:15 +0100
> Michael Niedermayer  wrote:
> 
> > On Mon, Dec 12, 2016 at 09:48:01AM +0100, wm4 wrote:
> > > On Mon, 12 Dec 2016 03:34:27 +0100
> > > Michael Niedermayer  wrote:
> > >   
> > > > On Sun, Dec 11, 2016 at 10:51:08PM -0300, James Almer wrote:  
> > > > > On 12/11/2016 10:29 PM, Michael Niedermayer wrote:
> > > > > > On Sat, Dec 10, 2016 at 09:52:08PM -0300, James Almer wrote:
> > > > > >> On 12/10/2016 9:23 PM, Michael Niedermayer wrote:
> > > > > >>> On Sat, Dec 10, 2016 at 08:31:57PM -0300, James Almer wrote:
> > > > >  On 12/10/2016 7:01 PM, Michael Niedermayer wrote:
> > > > > > [...]
> > > > > > 
> > > > > >>> And also theres more work for us to maintain seperate 
> > > > > >>> implementations
> > > > > >>> for the options, all code accessing them has to deal with them 
> > > > > >>> being
> > > > > >>> in different places, making all related backports harder.
> > > > > >>>
> > > > > >>> To me that looks like a disadvantage from every side
> > > > > >>>
> > > > > >>> I think the real solution is to start liking AVOptions, they make
> > > > > >>> our work easier.
> > > > > >>
> > > > > >> AVOptions are fine. Private-but-not-really and no-direct-access 
> > > > > >> fields
> > > > > >> in public structs are what's kinda ugly an unpopular.
> > > > > > 
> > > > > > a slightly off topic question but
> > > > > > if people care about these existing "no direct access" fields
> > > > > > why do they not change them ?
> > > > > > its a bit reading and thinking and droping the "no direct access"
> > > > > > comments, this is not much work
> > > > > > It requires a tiny bit of care so that future added fields dont do
> > > > > > bad things and we should document that past releases still in some
> > > > > > cases need the indirect access  ...
> > > > > > 
> > > > > > just seems a bit odd to me in relation to the opposition to add such
> > > > > > a field were its needed for a bugfix but total apparent lack of
> > > > > > interrest in removing such "no direct access" restrctions  where 
> > > > > > there
> > > > > > is no reason at all to keep them
> > > > > 
> > > > > They are all supposed to stop being no direct access with the next 
> > > > > bump.
> > > > > Afaik most are remnants of the libav ABI compatibility days, same with
> > > > > the get/setter functions, but they can't just be removed right now 
> > > > > because
> > > > > there are several versions using the current ABI (3.0 and newer i 
> > > > > think).
> > > > 
> > > > theres no need to wait for the next bump with removing many of the
> > > > "no direct access" rules because the fields always where in the same
> > > > position in the current major version
> > > > 
> > > > Removing them before the bump would allow people to stop using
> > > > the accessors earlier
> > > > 
> > > > someone needs to read through the struct and think about it though
> > > > so nothing is missed but from just the diff between master and
> > > > the releases there seem to be many that did not move  
> > > 
> > > Can I send a patch that makes them "real" public fields, and which
> > > deprecates the accessors? In all libs?  
> > 
> > If someone first checks that they are in the same offset in their
> > structs in all FFmpeg releases with the same soname.
> > And someone checks that we have no "insert new ... field above/below
> > this line" things above them
> > 
> > Yes, definitly
> 
> The offsets wouldn't have to be the same, since they were allowed to be
> accessed by accessor only.

thats true but someone writing code to access it would likely use
the latest documentation and if that doesnt mention that earlier
versions needed a different access then likely not realize and as
that app would build and work fine against a release he wouldnt notice
until that app built against a older release is then linked to a
newer

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

I have never wished to cater to the crowd; for what I know they do not
approve, and what they approve I do not know. -- 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: Require avoptions for the user to set max_pixels.

[wm4]

On Mon, 12 Dec 2016 17:34:15 +0100
Michael Niedermayer  wrote:

> On Mon, Dec 12, 2016 at 09:48:01AM +0100, wm4 wrote:
> > On Mon, 12 Dec 2016 03:34:27 +0100
> > Michael Niedermayer  wrote:
> >   
> > > On Sun, Dec 11, 2016 at 10:51:08PM -0300, James Almer wrote:  
> > > > On 12/11/2016 10:29 PM, Michael Niedermayer wrote:
> > > > > On Sat, Dec 10, 2016 at 09:52:08PM -0300, James Almer wrote:
> > > > >> On 12/10/2016 9:23 PM, Michael Niedermayer wrote:
> > > > >>> On Sat, Dec 10, 2016 at 08:31:57PM -0300, James Almer wrote:
> > > >  On 12/10/2016 7:01 PM, Michael Niedermayer wrote:
> > > > > [...]
> > > > > 
> > > > >>> And also theres more work for us to maintain seperate 
> > > > >>> implementations
> > > > >>> for the options, all code accessing them has to deal with them being
> > > > >>> in different places, making all related backports harder.
> > > > >>>
> > > > >>> To me that looks like a disadvantage from every side
> > > > >>>
> > > > >>> I think the real solution is to start liking AVOptions, they make
> > > > >>> our work easier.
> > > > >>
> > > > >> AVOptions are fine. Private-but-not-really and no-direct-access 
> > > > >> fields
> > > > >> in public structs are what's kinda ugly an unpopular.
> > > > > 
> > > > > a slightly off topic question but
> > > > > if people care about these existing "no direct access" fields
> > > > > why do they not change them ?
> > > > > its a bit reading and thinking and droping the "no direct access"
> > > > > comments, this is not much work
> > > > > It requires a tiny bit of care so that future added fields dont do
> > > > > bad things and we should document that past releases still in some
> > > > > cases need the indirect access  ...
> > > > > 
> > > > > just seems a bit odd to me in relation to the opposition to add such
> > > > > a field were its needed for a bugfix but total apparent lack of
> > > > > interrest in removing such "no direct access" restrctions  where there
> > > > > is no reason at all to keep them
> > > > 
> > > > They are all supposed to stop being no direct access with the next bump.
> > > > Afaik most are remnants of the libav ABI compatibility days, same with
> > > > the get/setter functions, but they can't just be removed right now 
> > > > because
> > > > there are several versions using the current ABI (3.0 and newer i 
> > > > think).
> > > 
> > > theres no need to wait for the next bump with removing many of the
> > > "no direct access" rules because the fields always where in the same
> > > position in the current major version
> > > 
> > > Removing them before the bump would allow people to stop using
> > > the accessors earlier
> > > 
> > > someone needs to read through the struct and think about it though
> > > so nothing is missed but from just the diff between master and
> > > the releases there seem to be many that did not move  
> > 
> > Can I send a patch that makes them "real" public fields, and which
> > deprecates the accessors? In all libs?  
> 
> If someone first checks that they are in the same offset in their
> structs in all FFmpeg releases with the same soname.
> And someone checks that we have no "insert new ... field above/below
> this line" things above them
> 
> Yes, definitly

The offsets wouldn't have to be the same, since they were allowed to be
accessed by accessor only.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/6] avutil/mastering_display_metadata: add av_mastering_display_metadata_alloc2()

[wm4]

On Mon, 12 Dec 2016 17:31:51 +0100
Michael Niedermayer  wrote:

> On Mon, Dec 12, 2016 at 10:06:31AM +0100, wm4 wrote:
> > On Sun, 11 Dec 2016 22:20:39 +0100
> > Michael Niedermayer  wrote:
> >   
> > > On Sun, Dec 11, 2016 at 02:00:04PM +0100, wm4 wrote:  
> > > > On Sun, 11 Dec 2016 00:33:03 -0300
> > > [...]  
> > > > Here are some brainstormed alternative ideas to adding those ...2()
> > > > functions:
> > > > - add functions to add side data by type to AVFrames etc.
> > > > - provide a generic function that allocates side data by passing the
> > > >   side data ID to it (would need separate ones for packet and stream
> > > >   side data)
> > >   
> > > > - unify the side data enums into one (i.e. merge packet and frame side
> > > >   data),
> > > 
> > > I was wondering previously already why there are multiple enums
> > > I think a single enum list would be simpler independant of other
> > > things  
> > 
> > Unfortunately Libav doesn't seem to have much interest, since it would
> > break the API (or at least ABI). Also they don't have many side data
> > types that require allocators.  
> 
> While it makes sense for us to listen and consider what Libav does,
> and we may very well choose to do the same. We could choose to
> do something different, if people prefer that ...

Well, they have a point: it would require changing ABI at least (and
maybe semi-weird hacks to keep the API compatible for a while).

We could still do av_allocate_frame_side_data(int id, ...) etc.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec: Require avoptions for the user to set max_pixels.

[Michael Niedermayer]

On Mon, Dec 12, 2016 at 09:48:01AM +0100, wm4 wrote:
> On Mon, 12 Dec 2016 03:34:27 +0100
> Michael Niedermayer  wrote:
> 
> > On Sun, Dec 11, 2016 at 10:51:08PM -0300, James Almer wrote:
> > > On 12/11/2016 10:29 PM, Michael Niedermayer wrote:  
> > > > On Sat, Dec 10, 2016 at 09:52:08PM -0300, James Almer wrote:  
> > > >> On 12/10/2016 9:23 PM, Michael Niedermayer wrote:  
> > > >>> On Sat, Dec 10, 2016 at 08:31:57PM -0300, James Almer wrote:  
> > >  On 12/10/2016 7:01 PM, Michael Niedermayer wrote:  
> > > > [...]
> > > >   
> > > >>> And also theres more work for us to maintain seperate implementations
> > > >>> for the options, all code accessing them has to deal with them being
> > > >>> in different places, making all related backports harder.
> > > >>>
> > > >>> To me that looks like a disadvantage from every side
> > > >>>
> > > >>> I think the real solution is to start liking AVOptions, they make
> > > >>> our work easier.  
> > > >>
> > > >> AVOptions are fine. Private-but-not-really and no-direct-access fields
> > > >> in public structs are what's kinda ugly an unpopular.  
> > > > 
> > > > a slightly off topic question but
> > > > if people care about these existing "no direct access" fields
> > > > why do they not change them ?
> > > > its a bit reading and thinking and droping the "no direct access"
> > > > comments, this is not much work
> > > > It requires a tiny bit of care so that future added fields dont do
> > > > bad things and we should document that past releases still in some
> > > > cases need the indirect access  ...
> > > > 
> > > > just seems a bit odd to me in relation to the opposition to add such
> > > > a field were its needed for a bugfix but total apparent lack of
> > > > interrest in removing such "no direct access" restrctions  where there
> > > > is no reason at all to keep them  
> > > 
> > > They are all supposed to stop being no direct access with the next bump.
> > > Afaik most are remnants of the libav ABI compatibility days, same with
> > > the get/setter functions, but they can't just be removed right now because
> > > there are several versions using the current ABI (3.0 and newer i think). 
> > >  
> > 
> > theres no need to wait for the next bump with removing many of the
> > "no direct access" rules because the fields always where in the same
> > position in the current major version
> > 
> > Removing them before the bump would allow people to stop using
> > the accessors earlier
> > 
> > someone needs to read through the struct and think about it though
> > so nothing is missed but from just the diff between master and
> > the releases there seem to be many that did not move
> 
> Can I send a patch that makes them "real" public fields, and which
> deprecates the accessors? In all libs?

If someone first checks that they are in the same offset in their
structs in all FFmpeg releases with the same soname.
And someone checks that we have no "insert new ... field above/below
this line" things above them

Yes, definitly


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

Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- Plato


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/6] avutil/mastering_display_metadata: add av_mastering_display_metadata_alloc2()

[Michael Niedermayer]

On Mon, Dec 12, 2016 at 10:06:31AM +0100, wm4 wrote:
> On Sun, 11 Dec 2016 22:20:39 +0100
> Michael Niedermayer  wrote:
> 
> > On Sun, Dec 11, 2016 at 02:00:04PM +0100, wm4 wrote:
> > > On Sun, 11 Dec 2016 00:33:03 -0300  
> > [...]
> > > Here are some brainstormed alternative ideas to adding those ...2()
> > > functions:
> > > - add functions to add side data by type to AVFrames etc.
> > > - provide a generic function that allocates side data by passing the
> > >   side data ID to it (would need separate ones for packet and stream
> > >   side data)  
> > 
> > > - unify the side data enums into one (i.e. merge packet and frame side
> > >   data),  
> > 
> > I was wondering previously already why there are multiple enums
> > I think a single enum list would be simpler independant of other
> > things
> 
> Unfortunately Libav doesn't seem to have much interest, since it would
> break the API (or at least ABI). Also they don't have many side data
> types that require allocators.

While it makes sense for us to listen and consider what Libav does,
and we may very well choose to do the same. We could choose to
do something different, if people prefer that ...

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

Avoid a single point of failure, be that a person or equipment.


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

Re: [FFmpeg-devel] [PATCH 2/2] avformat/hls: Add subtitle support

[Anssi Hannula]

Hi,

07.12.2016, 00:04, Franklin Phillips kirjoitti:
> Assuming the reason why my patch wasn't being merged was because it
> didn't use the X-TIMESTAMP-MAP, I have included the changes for that.
> 
> Those changes were basically a merge of work done by
> anssi.hann...@iki.fi which is why I've cc'd them.

I'm sorry about the lack of response.

I should be able to take a closer look by Friday this week, but with a
quick look your read_packet_subtitle() seems to contain quite a lot of
duplicated code with other parts of hls.c (unless I'm missing
something), so some refactoring should be done.


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

Re: [FFmpeg-devel] [PATCH] configure: add -fPIE instead of -pie to C flags for ThreadSanitizer

[Carl Eugen Hoyos]

2016-12-02 23:04 GMT+01:00 Wan-Teh Chang :
> -pie was added to C flags for ThreadSanitizer in commit
> 19f251a2882a8d0779b432e63bf282e4d9c443bb. Under clang 3.8.0, the -pie
> flag causes a compiler warning and a linker error when running configure
> --toolchain=clang-tsan.

Does the patch have any effect when using gcc?

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

Re: [FFmpeg-devel] lavf/isom: Support EVRC in pvAuthor files.

[Michael Niedermayer]

On Mon, Dec 12, 2016 at 11:49:41AM +0100, Carl Eugen Hoyos wrote:
> 2016-12-12 3:44 GMT+01:00 Michael Niedermayer :
> > On Mon, Dec 12, 2016 at 01:54:12AM +0100, Carl Eugen Hoyos wrote:
> >> Hi!
> >>
> >> Attached patch fixes ticket #6014.
> >>
> >> Please comment, Carl Eugen
> >
> >>  isom.c |1 +
> >>  1 file changed, 1 insertion(+)
> >> d9c95ca1ee86b780a596b39f0170cb176945a5a3  
> >> 0001-lavf-isom-Support-EVRC-in-pvAuthor-files.patch
> >> From 8878744426cdaf31227786a07743d06cc6ef8995 Mon Sep 17 00:00:00 2001
> >> From: Carl Eugen Hoyos 
> >> Date: Mon, 12 Dec 2016 01:52:12 +0100
> >> Subject: [PATCH] lavf/isom: Support EVRC in pvAuthor files.
> >>
> >> Fixes ticket #6014.
> >> ---
> >>  libavformat/isom.c |1 +
> >>  1 file changed, 1 insertion(+)
> >
> > should be ok
> > fate test is welcome if we have a small sample
> 
> Is that possible for flt codecs?

a reference PCM file can be used, fate supports "fuzzy" comparing
its not 100% sure that this is possible with this codec but its worth
a try

[...]
-- 
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

Re: [FFmpeg-devel] [PATCH]lavf/mov: Accept multiple fourcc for AVID 1:1

[Carl Eugen Hoyos]

2016-12-02 1:03 GMT+01:00 compn :
> On Fri, 2 Dec 2016 00:40:02 +0100
> Carl Eugen Hoyos  wrote:
>
>> 2016-12-01 19:58 GMT+01:00 compn :
>>
>> >  if (codec_tag &&
>> >   (codec_tag != format &&
>> > +  (codec_tag != AV_RL32("AV1x") || format !=
>> > AV_RL32("AVup")) && // prores is allowed to have differing data
>> > format and codec tag codec_tag != AV_RL32("apcn") && codec_tag !=
>> > AV_RL32("apch") && // so is dv (sigh)
>> >
>> > what about adding a comment like the prores/dv comments?
>>
>> How should the comment look like?
>
> // Avid codecs create different format and codec tags

Pushed with a similar comment.

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

Re: [FFmpeg-devel] [PATCH 1/3] Revert "avcodec: Add max_pixels options"

[Nicolas George]

Le primidi 21 frimaire, an CCXXV, Michael Niedermayer a écrit :
> You misunderstand
> 
> I want to find code that allocates too much memory where it should
> not.
> to give an example
> there was long ago some code like
> 
> len = read()
> for (i x= alloc()
> x.whatever =read()
> ...
> 
> Straight OOM here with a tiny input file.
> add a simple if(eof) in there and no OOM anymore
> this is just one example, code can look very diferent.
> 
> I want to find these cases and i want to fix them
> But what i get from the fuzzer is files with resolutions like
> 65123x3210 which go OOM because of valid but silly resolution.
> If i can limit the resolution then i can find the other issues
> which i can fix.
> If i cannot limit the resolution then i cannot fix the other issues
> as they are in a sea of OOMs from large resolution files
> 
> Nothing you can do at the OS level will get you this effect

Thanks for explaining.

If I read this correctly, this option does not fix any security issue at
all, it only help you find other parts of the code that may contain
security issues. Am I right?

> it is exceptionally unprofessional to publish testcases for CVEs
> before they have been fixed.
> Also more generally its the researchers choice/job to publish their
> work. If you belive it should be put in a ticket you should ask him
> not a 3rd party like me to do that.

This is Free software, secrecy is not a good policy. "I have this patch
that fix a bug, but I can not show you the bug." Well, if the patch is
straightforward, we can accept it, but if the patch is not
straightforward, we need, collectively, to see the bug.

I can understand that if the bug is a critical 0-day exploit, some
leeway must be accepted. But "there is a file that triggers a crash" is
not enough by far.

> who is "us", who is affected by this ?
> I thought i would be maintaining this alone. Is there someone who
> will help and work on this ?

Maintaining "this": it does not work that way, a change in the code puts
burden on anybody that work on the code, not just the person who wants
the feature.

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

Re: [FFmpeg-devel] lavf/isom: Support EVRC in pvAuthor files.

[Carl Eugen Hoyos]

2016-12-12 3:44 GMT+01:00 Michael Niedermayer :
> On Mon, Dec 12, 2016 at 01:54:12AM +0100, Carl Eugen Hoyos wrote:
>> Hi!
>>
>> Attached patch fixes ticket #6014.
>>
>> Please comment, Carl Eugen
>
>>  isom.c |1 +
>>  1 file changed, 1 insertion(+)
>> d9c95ca1ee86b780a596b39f0170cb176945a5a3  
>> 0001-lavf-isom-Support-EVRC-in-pvAuthor-files.patch
>> From 8878744426cdaf31227786a07743d06cc6ef8995 Mon Sep 17 00:00:00 2001
>> From: Carl Eugen Hoyos 
>> Date: Mon, 12 Dec 2016 01:52:12 +0100
>> Subject: [PATCH] lavf/isom: Support EVRC in pvAuthor files.
>>
>> Fixes ticket #6014.
>> ---
>>  libavformat/isom.c |1 +
>>  1 file changed, 1 insertion(+)
>
> should be ok
> fate test is welcome if we have a small sample

Is that possible for flt codecs?

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

Re: [FFmpeg-devel] lavf/isom: Support EVRC in pvAuthor files.

[Carl Eugen Hoyos]

2016-12-12 11:15 GMT+01:00 Paul B Mahol :
> On 12/12/16, Carl Eugen Hoyos  wrote:
>> 2016-12-12 9:24 GMT+01:00 Paul B Mahol :
>>> On 12/12/16, Carl Eugen Hoyos  wrote:
 Hi!

 Attached patch fixes ticket #6014.

 Please comment, Carl Eugen

>>>
>>> Please try keep it in order, otherwise ok
>>
>> Where exactly do you want me to put the new line?
>>
>
> Right before vorbis is, few lines above.

Moved right before vorbis and pushed.

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

Re: [FFmpeg-devel] [PATCH 1/3] Revert "avcodec: Add max_pixels options"

[Nicolas George]

Le primidi 21 frimaire, an CCXXV, compn a écrit :
> would you rather the people doing the fuzzing use this feature as a
> separate patch so it does not contaminate master?

I would rather have the people doing the fussing stop for a few minutes
to think what they need exactly and implement it properly.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] lavf/isom: Support EVRC in pvAuthor files.

[Paul B Mahol]

On 12/12/16, Carl Eugen Hoyos  wrote:
> 2016-12-12 9:24 GMT+01:00 Paul B Mahol :
>> On 12/12/16, Carl Eugen Hoyos  wrote:
>>> Hi!
>>>
>>> Attached patch fixes ticket #6014.
>>>
>>> Please comment, Carl Eugen
>>>
>>
>> Please try keep it in order, otherwise ok
>
> Where exactly do you want me to put the new line?
>

Right before vorbis is, few lines above.

> Carl Eugen
> ___
> 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] lavf/isom: Support EVRC in pvAuthor files.

[Carl Eugen Hoyos]

2016-12-12 9:24 GMT+01:00 Paul B Mahol :
> On 12/12/16, Carl Eugen Hoyos  wrote:
>> Hi!
>>
>> Attached patch fixes ticket #6014.
>>
>> Please comment, Carl Eugen
>>
>
> Please try keep it in order, otherwise ok

Where exactly do you want me to put the new line?

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

Re: [FFmpeg-devel] [PATCH 1/6] avutil/mastering_display_metadata: add av_mastering_display_metadata_alloc2()

[wm4]

On Sun, 11 Dec 2016 22:20:39 +0100
Michael Niedermayer  wrote:

> On Sun, Dec 11, 2016 at 02:00:04PM +0100, wm4 wrote:
> > On Sun, 11 Dec 2016 00:33:03 -0300  
> [...]
> > Here are some brainstormed alternative ideas to adding those ...2()
> > functions:
> > - add functions to add side data by type to AVFrames etc.
> > - provide a generic function that allocates side data by passing the
> >   side data ID to it (would need separate ones for packet and stream
> >   side data)  
> 
> > - unify the side data enums into one (i.e. merge packet and frame side
> >   data),  
> 
> I was wondering previously already why there are multiple enums
> I think a single enum list would be simpler independant of other
> things

Unfortunately Libav doesn't seem to have much interest, since it would
break the API (or at least ABI). Also they don't have many side data
types that require allocators.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/3] Revert "avcodec: Add max_pixels options"

[wm4]

On Sun, 11 Dec 2016 22:38:44 -0500
compn  wrote:

> On Sun, 11 Dec 2016 17:39:58 +0100
> Nicolas George  wrote:
> 
> > This reverts commit 2f07830e69bd14eaba348eb739b9503e7eb7cd4b.  
> 
> would you rather the people doing the fuzzing use this feature as a
> separate patch so it does not contaminate master?

That would also be a very simple solution for the fuzzers.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec: Require avoptions for the user to set max_pixels.

[wm4]

On Mon, 12 Dec 2016 03:34:27 +0100
Michael Niedermayer  wrote:

> On Sun, Dec 11, 2016 at 10:51:08PM -0300, James Almer wrote:
> > On 12/11/2016 10:29 PM, Michael Niedermayer wrote:  
> > > On Sat, Dec 10, 2016 at 09:52:08PM -0300, James Almer wrote:  
> > >> On 12/10/2016 9:23 PM, Michael Niedermayer wrote:  
> > >>> On Sat, Dec 10, 2016 at 08:31:57PM -0300, James Almer wrote:  
> >  On 12/10/2016 7:01 PM, Michael Niedermayer wrote:  
> > > [...]
> > >   
> > >>> And also theres more work for us to maintain seperate implementations
> > >>> for the options, all code accessing them has to deal with them being
> > >>> in different places, making all related backports harder.
> > >>>
> > >>> To me that looks like a disadvantage from every side
> > >>>
> > >>> I think the real solution is to start liking AVOptions, they make
> > >>> our work easier.  
> > >>
> > >> AVOptions are fine. Private-but-not-really and no-direct-access fields
> > >> in public structs are what's kinda ugly an unpopular.  
> > > 
> > > a slightly off topic question but
> > > if people care about these existing "no direct access" fields
> > > why do they not change them ?
> > > its a bit reading and thinking and droping the "no direct access"
> > > comments, this is not much work
> > > It requires a tiny bit of care so that future added fields dont do
> > > bad things and we should document that past releases still in some
> > > cases need the indirect access  ...
> > > 
> > > just seems a bit odd to me in relation to the opposition to add such
> > > a field were its needed for a bugfix but total apparent lack of
> > > interrest in removing such "no direct access" restrctions  where there
> > > is no reason at all to keep them  
> > 
> > They are all supposed to stop being no direct access with the next bump.
> > Afaik most are remnants of the libav ABI compatibility days, same with
> > the get/setter functions, but they can't just be removed right now because
> > there are several versions using the current ABI (3.0 and newer i think).  
> 
> theres no need to wait for the next bump with removing many of the
> "no direct access" rules because the fields always where in the same
> position in the current major version
> 
> Removing them before the bump would allow people to stop using
> the accessors earlier
> 
> someone needs to read through the struct and think about it though
> so nothing is missed but from just the diff between master and
> the releases there seem to be many that did not move

Can I send a patch that makes them "real" public fields, and which
deprecates the accessors? In all libs?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] lavf/isom: Support EVRC in pvAuthor files.

[Paul B Mahol]

On 12/12/16, Carl Eugen Hoyos  wrote:
> Hi!
>
> Attached patch fixes ticket #6014.
>
> Please comment, Carl Eugen
>

Please try keep it in order, otherwise ok
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Getting Started.

[Paul B Mahol]

On 12/12/16, Agneet Chatterjee  wrote:
> I'm having prior knowledge in C and C++. What I have no knowledge is the
> code base of ffmpeg. If you could provide me the basics of where to start
> and get me accustomed to the various projects that the organisation deals
> with. I could start contributing at my earliest.
>
> Thank you.
>

If you haven't yet, take look at
http://ffmpeg.org/developer.html#Developers-Guide

Once you find your area of interest in FFmpeg: one of libs or in utility itself,
ask more.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Getting Started.

[Agneet Chatterjee]

I'm having prior knowledge in C and C++. What I have no knowledge is the
code base of ffmpeg. If you could provide me the basics of where to start
and get me accustomed to the various projects that the organisation deals
with. I could start contributing at my earliest.

Thank you.

On 12 Dec 2016 00:19, "Paul B Mahol"  wrote:

> On 12/11/16, Agneet Chatterjee  wrote:
> > Hello everyone. I'm a second year CS undergrad willing to contribute to
> > this organisation. Could somebody help me get started?
>
> Anything you are interested to work on?
> There are numerous possibilities.
>
> >
> > Thank you.
> > Agneet Chatterjee.
> > ___
> > 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
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel