[FFmpeg-devel] configure: clang -Oz for small size build to reduce size further

[Wang Bin]

0001-configure-clang-Oz-for-small-size-build-to-reduce-si.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavcodec/libopenjpegenc.c

[Michael Bradshaw]

On Thu, Mar 9, 2017 at 8:09 PM, Aaron Boxer  wrote:
>
> Thanks, Michael. Here are those changes.


Applied. Thanks for the patch!
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavcodec/libopenjpegenc.c

[Aaron Boxer]

On Thu, Mar 9, 2017 at 10:31 PM, Michael Bradshaw  wrote:

> On Wed, Mar 8, 2017 at 5:19 AM, Aaron Boxer  wrote:
>
> > Final version of simple patch to :
> >
> > limit encoder to single layer
> > add lossless option
> > set better defaults for a few encoding parameters.
>
>
> I think I'd prefer to remove the numlayers option altogether if the only
> possible value it can have is 1.
>
> Small nitpick: please amend the commit message so the first line of the
> message is a short summary of the overall commit, and move the numbered
> list to below the first line. That is, the command git log --pretty=short
> should look something like:
>
> commit 440b7cb6abb32e35464c7c86634d655ccb1d7e7c
> Author: Aaron Boxer 
>
> 
>
> The command git log can give the full commit message:
>
> commit 440b7cb6abb32e35464c7c86634d655ccb1d7e7c
> Author: Aaron Boxer 
>
> 
>
> 1. limit...
> 2. encoder...
> 3. remove...
> 4. add...
> 5. set...
>


Thanks, Michael. Here are those changes.

Cheers,
Aaron


0001-libavcodec-libopenjpegenc-enable-lossless-option-rem.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] swresample/options: enable linear_interp and exact_rational by default

[Muhammad Faiz]

On Fri, Mar 10, 2017 at 10:44 AM, Michael Niedermayer
 wrote:
> On Fri, Mar 10, 2017 at 09:19:38AM +0700, Muhammad Faiz wrote:
>> for higher quality resampling
>
> can you hear the difference ?

Yes, but it is sinesweep test audio, not real music audio.

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

Re: [FFmpeg-devel] [PATCH] swresample/options: enable linear_interp and exact_rational by default

[Muhammad Faiz]

On Fri, Mar 10, 2017 at 10:04 AM, Marton Balint  wrote:
>
> On Fri, 10 Mar 2017, Muhammad Faiz wrote:
>
>> for higher quality resampling
>
>
> How much slower is it?

Not slower when exact_rational doesn't fail, because it doesn't trigger
linear interpolation (even when linear_interp is enabled).
For example 44100 -> 48000 (147:160) so phase_count = 160 <= 1024

But if exact_rational fails, it will be slower because it triggers
linear interpolation.
For example 11025 -> 96000 (147:1280) so phase_count = 1280 > 1024
ans phase_count wil set to 1024 instead.
This will trigger slower linear interpolation.
I mention this in linear_interp doc entry.

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

Re: [FFmpeg-devel] [PATCH] swresample/options: enable linear_interp and exact_rational by default

[Michael Niedermayer]

On Fri, Mar 10, 2017 at 09:19:38AM +0700, Muhammad Faiz wrote:
> for higher quality resampling

can you hear the difference ?

[...]
-- 
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] libavcodec/libopenjpegenc.c

[Michael Bradshaw]

On Wed, Mar 8, 2017 at 5:19 AM, Aaron Boxer  wrote:

> Final version of simple patch to :
>
> limit encoder to single layer
> add lossless option
> set better defaults for a few encoding parameters.


I think I'd prefer to remove the numlayers option altogether if the only
possible value it can have is 1.

Small nitpick: please amend the commit message so the first line of the
message is a short summary of the overall commit, and move the numbered
list to below the first line. That is, the command git log --pretty=short
should look something like:

commit 440b7cb6abb32e35464c7c86634d655ccb1d7e7c
Author: Aaron Boxer 



The command git log can give the full commit message:

commit 440b7cb6abb32e35464c7c86634d655ccb1d7e7c
Author: Aaron Boxer 



1. limit...
2. encoder...
3. remove...
4. add...
5. set...
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] swresample/options: enable linear_interp and exact_rational by default

[Marton Balint]

On Fri, 10 Mar 2017, Muhammad Faiz wrote:


for higher quality resampling


How much slower is it?

Thanks,
Marton



Signed-off-by: Muhammad Faiz 
---
doc/resampler.texi   |   5 +-
libswresample/options.c  |   4 +-
tests/fate/libswresample.mak | 189 ---
tests/ref/acodec/s302m   |   6 +-
tests/ref/lavf/dv_fmt|   8 +-
tests/ref/lavf/gxf   |   8 +-
tests/ref/lavf/mxf   |  12 +--
7 files changed, 201 insertions(+), 31 deletions(-)

diff --git a/doc/resampler.texi b/doc/resampler.texi
index d72677c..5ed3f43 100644
--- a/doc/resampler.texi
+++ b/doc/resampler.texi
@@ -132,12 +132,13 @@ For swr only, set resampling phase shift, default value 
is 10, and must be in
the interval [0,30].

@item linear_interp
-Use linear interpolation if set to 1, default value is 0.
+Use linear interpolation when enabled (the default). Disable it if you want
+to preserve speed instead of quality when exact_rational fails.

@item exact_rational
For swr only, when enabled, try to use exact phase_count based on input and
output sample rate. However, if it is larger than @code{1 << phase_shift},
-the phase_count will be @code{1 << phase_shift} as fallback. Default is 
disabled.
+the phase_count will be @code{1 << phase_shift} as fallback. Default is 
enabled.

@item cutoff
Set cutoff frequency (swr: 6dB point; soxr: 0dB point) ratio; must be a float
diff --git a/libswresample/options.c b/libswresample/options.c
index 4abf5e0..00d4f7c 100644
--- a/libswresample/options.c
+++ b/libswresample/options.c
@@ -84,8 +84,8 @@ static const AVOption options[]={

{"filter_size"  , "set swr resampling filter size", OFFSET(filter_size) 
 , AV_OPT_TYPE_INT  , {.i64=32}, 0  , INT_MAX   , PARAM },
{"phase_shift"  , "set swr resampling phase shift", OFFSET(phase_shift) 
 , AV_OPT_TYPE_INT  , {.i64=10}, 0  , 24, PARAM },
-{"linear_interp", "enable linear interpolation" , 
OFFSET(linear_interp)  , AV_OPT_TYPE_BOOL , {.i64=0 }, 0  , 1 , 
PARAM },
-{"exact_rational"   , "enable exact rational"   , 
OFFSET(exact_rational) , AV_OPT_TYPE_BOOL , {.i64=0 }, 0  , 1 , 
PARAM },
+{"linear_interp", "enable linear interpolation" , 
OFFSET(linear_interp)  , AV_OPT_TYPE_BOOL , {.i64=1 }, 0  , 1 , 
PARAM },
+{"exact_rational"   , "enable exact rational"   , 
OFFSET(exact_rational) , AV_OPT_TYPE_BOOL , {.i64=1 }, 0  , 1 , 
PARAM },
{"cutoff"   , "set cutoff frequency ratio"  , OFFSET(cutoff)
 , AV_OPT_TYPE_DOUBLE,{.dbl=0.}, 0  , 1 , PARAM },

/* duplicate option in order to work with avconv */
diff --git a/tests/fate/libswresample.mak b/tests/fate/libswresample.mak
index 78dbde7..13d7dba 100644
--- a/tests/fate/libswresample.mak
+++ b/tests/fate/libswresample.mak
@@ -11,10 +11,11 @@ SAMPLERATES_LITE = 8000 44100 48000

SAMPLERATES_NN = 8000 44100

+#note that the default is ARESAMPLE_EXACT_LIN
define ARESAMPLE
FATE_SWR_RESAMPLE += fate-swr-resample-$(3)-$(1)-$(2)
fate-swr-resample-$(3)-$(1)-$(2): tests/data/asynth-$(1)-1.wav
-fate-swr-resample-$(3)-$(1)-$(2): CMD = ffmpeg -i 
$(TARGET_PATH)/tests/data/asynth-$(1)-1.wav -af 
atrim=end_sample=10240,aresample=$(2):internal_sample_fmt=$(3),aformat=$(3),aresample=$(1):internal_sample_fmt=$(3)
 -f wav -acodec pcm_s16le -
+fate-swr-resample-$(3)-$(1)-$(2): CMD = ffmpeg -i 
$(TARGET_PATH)/tests/data/asynth-$(1)-1.wav -af 
atrim=end_sample=10240,aresample=$(2):internal_sample_fmt=$(3):exact_rational=0:linear_interp=0,aformat=$(3),aresample=$(1):internal_sample_fmt=$(3):exact_rational=0:linear_interp=0
 -f wav -acodec pcm_s16le -

fate-swr-resample-$(3)-$(1)-$(2): CMP = stddev
fate-swr-resample-$(3)-$(1)-$(2): CMP_UNIT = $(5)
@@ -270,7 +271,7 @@ fate-swr-resample-s32p-96000-8000: SIZE_TOLERANCE = 1152000 
- 20496
define ARESAMPLE_LIN
FATE_SWR_RESAMPLE += fate-swr-resample_lin-$(3)-$(1)-$(2)
fate-swr-resample_lin-$(3)-$(1)-$(2): tests/data/asynth-$(1)-1.wav
-fate-swr-resample_lin-$(3)-$(1)-$(2): CMD = ffmpeg -i 
$(TARGET_PATH)/tests/data/asynth-$(1)-1.wav -af 
atrim=end_sample=10240,aresample=$(2):linear_interp=1:internal_sample_fmt=$(3),aformat=$(3),aresample=$(1):linear_interp=1:internal_sample_fmt=$(3)
 -f wav -acodec pcm_s16le -
+fate-swr-resample_lin-$(3)-$(1)-$(2): CMD = ffmpeg -i 
$(TARGET_PATH)/tests/data/asynth-$(1)-1.wav -af 
atrim=end_sample=10240,aresample=$(2):linear_interp=1:exact_rational=0:internal_sample_fmt=$(3),aformat=$(3),aresample=$(1):linear_interp=1:exact_rational=0:internal_sample_fmt=$(3)
 -f wav -acodec pcm_s16le -

fate-swr-resample_lin-$(3)-$(1)-$(2): CMP = stddev
fate-swr-resample_lin-$(3)-$(1)-$(2): CMP_UNIT = $(5)
@@ -335,7 +336,7 @@ fate-swr-resample_lin-dblp-48000-44100: SIZE_TOLERANCE = 
576000 - 20480
define 

[FFmpeg-devel] [PATCH] swresample/options: enable linear_interp and exact_rational by default

[Muhammad Faiz]

for higher quality resampling

Signed-off-by: Muhammad Faiz 
---
 doc/resampler.texi   |   5 +-
 libswresample/options.c  |   4 +-
 tests/fate/libswresample.mak | 189 ---
 tests/ref/acodec/s302m   |   6 +-
 tests/ref/lavf/dv_fmt|   8 +-
 tests/ref/lavf/gxf   |   8 +-
 tests/ref/lavf/mxf   |  12 +--
 7 files changed, 201 insertions(+), 31 deletions(-)

diff --git a/doc/resampler.texi b/doc/resampler.texi
index d72677c..5ed3f43 100644
--- a/doc/resampler.texi
+++ b/doc/resampler.texi
@@ -132,12 +132,13 @@ For swr only, set resampling phase shift, default value 
is 10, and must be in
 the interval [0,30].
 
 @item linear_interp
-Use linear interpolation if set to 1, default value is 0.
+Use linear interpolation when enabled (the default). Disable it if you want
+to preserve speed instead of quality when exact_rational fails.
 
 @item exact_rational
 For swr only, when enabled, try to use exact phase_count based on input and
 output sample rate. However, if it is larger than @code{1 << phase_shift},
-the phase_count will be @code{1 << phase_shift} as fallback. Default is 
disabled.
+the phase_count will be @code{1 << phase_shift} as fallback. Default is 
enabled.
 
 @item cutoff
 Set cutoff frequency (swr: 6dB point; soxr: 0dB point) ratio; must be a float
diff --git a/libswresample/options.c b/libswresample/options.c
index 4abf5e0..00d4f7c 100644
--- a/libswresample/options.c
+++ b/libswresample/options.c
@@ -84,8 +84,8 @@ static const AVOption options[]={
 
 {"filter_size"  , "set swr resampling filter size", 
OFFSET(filter_size)  , AV_OPT_TYPE_INT  , {.i64=32}, 0  
, INT_MAX   , PARAM },
 {"phase_shift"  , "set swr resampling phase shift", 
OFFSET(phase_shift)  , AV_OPT_TYPE_INT  , {.i64=10}, 0  
, 24, PARAM },
-{"linear_interp", "enable linear interpolation" , 
OFFSET(linear_interp)  , AV_OPT_TYPE_BOOL , {.i64=0 }, 0
  , 1 , PARAM },
-{"exact_rational"   , "enable exact rational"   , 
OFFSET(exact_rational) , AV_OPT_TYPE_BOOL , {.i64=0 }, 0
  , 1 , PARAM },
+{"linear_interp", "enable linear interpolation" , 
OFFSET(linear_interp)  , AV_OPT_TYPE_BOOL , {.i64=1 }, 0
  , 1 , PARAM },
+{"exact_rational"   , "enable exact rational"   , 
OFFSET(exact_rational) , AV_OPT_TYPE_BOOL , {.i64=1 }, 0
  , 1 , PARAM },
 {"cutoff"   , "set cutoff frequency ratio"  , OFFSET(cutoff)   
  , AV_OPT_TYPE_DOUBLE,{.dbl=0.}, 0  , 1 , 
PARAM },
 
 /* duplicate option in order to work with avconv */
diff --git a/tests/fate/libswresample.mak b/tests/fate/libswresample.mak
index 78dbde7..13d7dba 100644
--- a/tests/fate/libswresample.mak
+++ b/tests/fate/libswresample.mak
@@ -11,10 +11,11 @@ SAMPLERATES_LITE = 8000 44100 48000
 
 SAMPLERATES_NN = 8000 44100
 
+#note that the default is ARESAMPLE_EXACT_LIN
 define ARESAMPLE
 FATE_SWR_RESAMPLE += fate-swr-resample-$(3)-$(1)-$(2)
 fate-swr-resample-$(3)-$(1)-$(2): tests/data/asynth-$(1)-1.wav
-fate-swr-resample-$(3)-$(1)-$(2): CMD = ffmpeg -i 
$(TARGET_PATH)/tests/data/asynth-$(1)-1.wav -af 
atrim=end_sample=10240,aresample=$(2):internal_sample_fmt=$(3),aformat=$(3),aresample=$(1):internal_sample_fmt=$(3)
 -f wav -acodec pcm_s16le -
+fate-swr-resample-$(3)-$(1)-$(2): CMD = ffmpeg -i 
$(TARGET_PATH)/tests/data/asynth-$(1)-1.wav -af 
atrim=end_sample=10240,aresample=$(2):internal_sample_fmt=$(3):exact_rational=0:linear_interp=0,aformat=$(3),aresample=$(1):internal_sample_fmt=$(3):exact_rational=0:linear_interp=0
 -f wav -acodec pcm_s16le -
 
 fate-swr-resample-$(3)-$(1)-$(2): CMP = stddev
 fate-swr-resample-$(3)-$(1)-$(2): CMP_UNIT = $(5)
@@ -270,7 +271,7 @@ fate-swr-resample-s32p-96000-8000: SIZE_TOLERANCE = 1152000 
- 20496
 define ARESAMPLE_LIN
 FATE_SWR_RESAMPLE += fate-swr-resample_lin-$(3)-$(1)-$(2)
 fate-swr-resample_lin-$(3)-$(1)-$(2): tests/data/asynth-$(1)-1.wav
-fate-swr-resample_lin-$(3)-$(1)-$(2): CMD = ffmpeg -i 
$(TARGET_PATH)/tests/data/asynth-$(1)-1.wav -af 
atrim=end_sample=10240,aresample=$(2):linear_interp=1:internal_sample_fmt=$(3),aformat=$(3),aresample=$(1):linear_interp=1:internal_sample_fmt=$(3)
 -f wav -acodec pcm_s16le -
+fate-swr-resample_lin-$(3)-$(1)-$(2): CMD = ffmpeg -i 
$(TARGET_PATH)/tests/data/asynth-$(1)-1.wav -af 
atrim=end_sample=10240,aresample=$(2):linear_interp=1:exact_rational=0:internal_sample_fmt=$(3),aformat=$(3),aresample=$(1):linear_interp=1:exact_rational=0:internal_sample_fmt=$(3)
 -f wav -acodec pcm_s16le -
 
 fate-swr-resample_lin-$(3)-$(1)-$(2): CMP = stddev
 fate-swr-resample_lin-$(3)-$(1)-$(2): CMP_UNIT = $(5)
@@ -335,7 +336,7 @@ fate-swr-resample_lin-dblp-48000-44100: SIZE_TOLERANCE = 
576000 - 20480
 define ARESAMPLE_NN
 FATE_SWR_RESAMPLE += 

[FFmpeg-devel] [PATCH V3] vf_hwupload: Add missing return value check

[Jun Zhao]

V3: just remove noop ff_formats_unref() and add missing return value checks to 
suppress build warning. 
From 67633ff014ee472a6494d792c8c8e057acc197c4 Mon Sep 17 00:00:00 2001
From: Jun Zhao 
Date: Fri, 3 Mar 2017 09:25:53 +0800
Subject: [PATCH] vf_hwupload: Add missing return value check

Add missing return value checks to suppress build warning and
remove noop ff_formats_unref() calling.

Note: most filters using ff_formats_ref() didn't have a suitable
error handling, it's a potential memory leak issue.

Signed-off-by: Jun Zhao 
---
 libavfilter/vf_hwupload.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/libavfilter/vf_hwupload.c b/libavfilter/vf_hwupload.c
index 08af2dd..f54ce9f 100644
--- a/libavfilter/vf_hwupload.c
+++ b/libavfilter/vf_hwupload.c
@@ -74,17 +74,15 @@ static int hwupload_query_formats(AVFilterContext *avctx)
 if (input_pix_fmts) {
 for (i = 0; input_pix_fmts[i] != AV_PIX_FMT_NONE; i++) {
 err = ff_add_format(_formats, input_pix_fmts[i]);
-if (err < 0) {
-ff_formats_unref(_formats);
+if (err < 0)
 goto fail;
-}
 }
 }
 
-ff_formats_ref(input_formats, >inputs[0]->out_formats);
-
-ff_formats_ref(ff_make_format_list(output_pix_fmts),
-   >outputs[0]->in_formats);
+if ((err = ff_formats_ref(input_formats, >inputs[0]->out_formats)) 
< 0 ||
+(err = ff_formats_ref(ff_make_format_list(output_pix_fmts),
+  >outputs[0]->in_formats)) < 0)
+goto fail;
 
 av_hwframe_constraints_free();
 return 0;
-- 
2.9.3

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

Re: [FFmpeg-devel] [PATCH] avcodec/vp8: Fix hang with slice threads

[Michael Niedermayer]

On Thu, Mar 09, 2017 at 08:17:37PM -0500, Ronald S. Bultje wrote:
> Hi,
> 
> On Thu, Mar 9, 2017 at 8:12 PM, Michael Niedermayer 
> wrote:
> 
> > From: Thomas Guilbert 
> >
> > Fixes: 447860.webm
> >
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/vp8.c | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/vp8.c b/libavcodec/vp8.c
> > index 6759b310f0..068223920e 100644
> > --- a/libavcodec/vp8.c
> > +++ b/libavcodec/vp8.c
> > @@ -2508,8 +2508,10 @@ int vp78_decode_mb_row_sliced(AVCodecContext
> > *avctx, void *tdata, int jobnr,
> >  for (mb_y = jobnr; mb_y < s->mb_height; mb_y += num_jobs) {
> >  td->thread_mb_pos = mb_y << 16;
> >  ret = s->decode_mb_row_no_filter(avctx, tdata, jobnr, threadnr);
> > -if (ret < 0)
> > +if (ret < 0) {
> > +update_pos(td, s->mb_height, INT_MAX & 0x);
> >  return ret;
> > +}
> >  if (s->deblock_filter)
> >  s->filter_mb_row(avctx, tdata, jobnr, threadnr);
> >  update_pos(td, mb_y, INT_MAX & 0x);
> > --
> > 2.11.0
> 
> 
> OK.

applied

thx

[...]
-- 
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] [PATCH] avcodec/vp8: Fix hang with slice threads

[Ronald S. Bultje]

Hi,

On Thu, Mar 9, 2017 at 8:12 PM, Michael Niedermayer 
wrote:

> From: Thomas Guilbert 
>
> Fixes: 447860.webm
>
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/vp8.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/vp8.c b/libavcodec/vp8.c
> index 6759b310f0..068223920e 100644
> --- a/libavcodec/vp8.c
> +++ b/libavcodec/vp8.c
> @@ -2508,8 +2508,10 @@ int vp78_decode_mb_row_sliced(AVCodecContext
> *avctx, void *tdata, int jobnr,
>  for (mb_y = jobnr; mb_y < s->mb_height; mb_y += num_jobs) {
>  td->thread_mb_pos = mb_y << 16;
>  ret = s->decode_mb_row_no_filter(avctx, tdata, jobnr, threadnr);
> -if (ret < 0)
> +if (ret < 0) {
> +update_pos(td, s->mb_height, INT_MAX & 0x);
>  return ret;
> +}
>  if (s->deblock_filter)
>  s->filter_mb_row(avctx, tdata, jobnr, threadnr);
>  update_pos(td, mb_y, INT_MAX & 0x);
> --
> 2.11.0


OK.

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

[FFmpeg-devel] [PATCH] avcodec/vp8: Fix hang with slice threads

[Michael Niedermayer]

From: Thomas Guilbert 

Fixes: 447860.webm

Signed-off-by: Michael Niedermayer 
---
 libavcodec/vp8.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/libavcodec/vp8.c b/libavcodec/vp8.c
index 6759b310f0..068223920e 100644
--- a/libavcodec/vp8.c
+++ b/libavcodec/vp8.c
@@ -2508,8 +2508,10 @@ int vp78_decode_mb_row_sliced(AVCodecContext *avctx, 
void *tdata, int jobnr,
 for (mb_y = jobnr; mb_y < s->mb_height; mb_y += num_jobs) {
 td->thread_mb_pos = mb_y << 16;
 ret = s->decode_mb_row_no_filter(avctx, tdata, jobnr, threadnr);
-if (ret < 0)
+if (ret < 0) {
+update_pos(td, s->mb_height, INT_MAX & 0x);
 return ret;
+}
 if (s->deblock_filter)
 s->filter_mb_row(avctx, tdata, jobnr, threadnr);
 update_pos(td, mb_y, INT_MAX & 0x);
-- 
2.11.0

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

Re: [FFmpeg-devel] [PATCH V2] vf_hwupload: Add missing return value check

[Jun Zhao]

On 2017/3/10 7:49, Mark Thompson wrote:
> On 09/03/17 00:33, Jun Zhao wrote:
>> On 2017/3/8 16:58, Mark Thompson wrote:
>>> On 08/03/17 01:25, Jun Zhao wrote:
 ping ?

 On 2017/3/3 9:35, Jun Zhao wrote:
> V2: Fix the potential memory leak.2
>
> From eb283d277679b5dac9c43e8d3c98bcc9367b592f Mon Sep 17 00:00:00 2001
> From: Jun Zhao 
> Date: Fri, 3 Mar 2017 09:25:53 +0800
> Subject: [PATCH] vf_hwupload: Add missing return value check
>
> Add missing return value checks and fix the potential memory leak.
>
> Signed-off-by: Jun Zhao 
> ---
>  libavfilter/vf_hwupload.c | 18 --
>  1 file changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/libavfilter/vf_hwupload.c b/libavfilter/vf_hwupload.c
> index 08af2dd..4b63a2a 100644
> --- a/libavfilter/vf_hwupload.c
> +++ b/libavfilter/vf_hwupload.c
> @@ -74,22 +74,28 @@ static int hwupload_query_formats(AVFilterContext 
> *avctx)
>  if (input_pix_fmts) {
>  for (i = 0; input_pix_fmts[i] != AV_PIX_FMT_NONE; i++) {
>  err = ff_add_format(_formats, input_pix_fmts[i]);
> -if (err < 0) {
> -ff_formats_unref(_formats);
> +if (err < 0)
>  goto fail;
> -}
>  }
>  }
>  
> -ff_formats_ref(input_formats, >inputs[0]->out_formats);
> +if ((err = ff_formats_ref(input_formats, 
> >inputs[0]->out_formats)) < 0)
> +goto fail;
>  
> -ff_formats_ref(ff_make_format_list(output_pix_fmts),
> -   >outputs[0]->in_formats);
> +if ((err = ff_formats_ref(ff_make_format_list(output_pix_fmts),
> +  >outputs[0]->in_formats)) < 0) {
> +ff_formats_unref(_formats);
> +goto fail;
> +}
>  
>  av_hwframe_constraints_free();
>  return 0;
>  
>  fail:
> +if (input_formats) {
> +av_free(input_formats->formats);
> +av_free(input_formats);
> +}
>  av_buffer_unref(>hwdevice_ref);
>  av_hwframe_constraints_free();
>  return err;
> -- 
> 2.9.3
>
>>>
>>> Crashes if the second ff_formats_ref() fails:
>>>
>>> ==32719== Invalid read of size 8
>>> ==32719==at 0x23F6E6: ff_formats_unref (formats.c:478)
>>> ==32719==by 0x22A028: free_link (avfilter.c:783)
>>> ==32719==by 0x22A103: avfilter_free (avfilter.c:805)
>>> ==32719==by 0x22C2EF: avfilter_graph_free (avfiltergraph.c:123)
>>> ==32719==by 0x1EF08C: cleanup_filtergraph (ffmpeg_filter.c:994)
>>> ==32719==by 0x1EFA81: configure_filtergraph (ffmpeg_filter.c:1168)
>>> ==32719==by 0x1F7B48: ifilter_send_frame (ffmpeg.c:2193)
>>> ==32719==by 0x1F7DC8: send_frame_to_filters (ffmpeg.c:2278)
>>> ==32719==by 0x1F8A89: decode_video (ffmpeg.c:2469)
>>> ==32719==by 0x1F9375: process_input_packet (ffmpeg.c:2614)
>>> ==32719==by 0x1FFC8A: process_input (ffmpeg.c:4350)
>>> ==32719==by 0x200104: transcode_step (ffmpeg.c:4461)
>>> ==32719==  Address 0x12f78798 is 24 bytes inside a block of size 32 free'd
>>> ==32719==at 0x4C2CDDB: free (in 
>>> /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
>>> ==32719==by 0x13BDC21: av_free (mem.c:239)
>>> ==32719==by 0x23F7E8: ff_formats_unref (formats.c:478)
>>> ==32719==by 0x2F8681: hwupload_query_formats (vf_hwupload.c:87)
>>> ==32719==by 0x22CA9C: filter_query_formats (avfiltergraph.c:317)
>>> ==32719==by 0x22D040: query_formats (avfiltergraph.c:445)
>>> ==32719==by 0x22F368: graph_config_formats (avfiltergraph.c:1159)
>>> ==32719==by 0x22F81A: avfilter_graph_config (avfiltergraph.c:1270)
>>> ==32719==by 0x1EF688: configure_filtergraph (ffmpeg_filter.c:1096)
>>> ==32719==by 0x1F7B48: ifilter_send_frame (ffmpeg.c:2193)
>>> ==32719==by 0x1F7DC8: send_frame_to_filters (ffmpeg.c:2278)
>>> ==32719==by 0x1F8A89: decode_video (ffmpeg.c:2469)
>>> ==32719==  Block was alloc'd at
>>> ==32719==at 0x4C2DF16: memalign (in 
>>> /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
>>> ==32719==by 0x4C2E021: posix_memalign (in 
>>> /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
>>> ==32719==by 0x13BD9DD: av_malloc (mem.c:97)
>>> ==32719==by 0x13BDC75: av_mallocz (mem.c:254)
>>> ==32719==by 0x23EF33: ff_make_format_list (formats.c:285)
>>> ==32719==by 0x2F85A2: hwupload_query_formats (vf_hwupload.c:69)
>>> ==32719==by 0x22CA9C: filter_query_formats (avfiltergraph.c:317)
>>> ==32719==by 0x22D040: query_formats (avfiltergraph.c:445)
>>> ==32719==by 0x22F368: graph_config_formats (avfiltergraph.c:1159)
>>> ==32719==by 0x22F81A: avfilter_graph_config (avfiltergraph.c:1270)
>>> ==32719==by 0x1EF688: configure_filtergraph (ffmpeg_filter.c:1096)
>>> ==32719==by 0x1F7B48: 

[FFmpeg-devel] [PATCH] swresample/swresample: do not reset tsf on swr_alloc_set_opts

[Muhammad Faiz]

so tsf option in aresample will have effect

Signed-off-by: Muhammad Faiz 
---
 libswresample/swresample.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/libswresample/swresample.c b/libswresample/swresample.c
index dea6139..f2e6600 100644
--- a/libswresample/swresample.c
+++ b/libswresample/swresample.c
@@ -84,9 +84,6 @@ struct SwrContext *swr_alloc_set_opts(struct SwrContext *s,
 if (av_opt_set_int(s, "isr", in_sample_rate,  0) < 0)
 goto fail;
 
-if (av_opt_set_int(s, "tsf", AV_SAMPLE_FMT_NONE,   0) < 0)
-goto fail;
-
 if (av_opt_set_int(s, "ich", av_get_channel_layout_nb_channels(s-> 
user_in_ch_layout), 0) < 0)
 goto fail;
 
-- 
2.9.3

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

Re: [FFmpeg-devel] [PATCH V2] vf_hwupload: Add missing return value check

[Mark Thompson]

On 09/03/17 00:33, Jun Zhao wrote:
> On 2017/3/8 16:58, Mark Thompson wrote:
>> On 08/03/17 01:25, Jun Zhao wrote:
>>> ping ?
>>>
>>> On 2017/3/3 9:35, Jun Zhao wrote:
 V2: Fix the potential memory leak.2

 From eb283d277679b5dac9c43e8d3c98bcc9367b592f Mon Sep 17 00:00:00 2001
 From: Jun Zhao 
 Date: Fri, 3 Mar 2017 09:25:53 +0800
 Subject: [PATCH] vf_hwupload: Add missing return value check

 Add missing return value checks and fix the potential memory leak.

 Signed-off-by: Jun Zhao 
 ---
  libavfilter/vf_hwupload.c | 18 --
  1 file changed, 12 insertions(+), 6 deletions(-)

 diff --git a/libavfilter/vf_hwupload.c b/libavfilter/vf_hwupload.c
 index 08af2dd..4b63a2a 100644
 --- a/libavfilter/vf_hwupload.c
 +++ b/libavfilter/vf_hwupload.c
 @@ -74,22 +74,28 @@ static int hwupload_query_formats(AVFilterContext 
 *avctx)
  if (input_pix_fmts) {
  for (i = 0; input_pix_fmts[i] != AV_PIX_FMT_NONE; i++) {
  err = ff_add_format(_formats, input_pix_fmts[i]);
 -if (err < 0) {
 -ff_formats_unref(_formats);
 +if (err < 0)
  goto fail;
 -}
  }
  }
  
 -ff_formats_ref(input_formats, >inputs[0]->out_formats);
 +if ((err = ff_formats_ref(input_formats, 
 >inputs[0]->out_formats)) < 0)
 +goto fail;
  
 -ff_formats_ref(ff_make_format_list(output_pix_fmts),
 -   >outputs[0]->in_formats);
 +if ((err = ff_formats_ref(ff_make_format_list(output_pix_fmts),
 +  >outputs[0]->in_formats)) < 0) {
 +ff_formats_unref(_formats);
 +goto fail;
 +}
  
  av_hwframe_constraints_free();
  return 0;
  
  fail:
 +if (input_formats) {
 +av_free(input_formats->formats);
 +av_free(input_formats);
 +}
  av_buffer_unref(>hwdevice_ref);
  av_hwframe_constraints_free();
  return err;
 -- 
 2.9.3

>>
>> Crashes if the second ff_formats_ref() fails:
>>
>> ==32719== Invalid read of size 8
>> ==32719==at 0x23F6E6: ff_formats_unref (formats.c:478)
>> ==32719==by 0x22A028: free_link (avfilter.c:783)
>> ==32719==by 0x22A103: avfilter_free (avfilter.c:805)
>> ==32719==by 0x22C2EF: avfilter_graph_free (avfiltergraph.c:123)
>> ==32719==by 0x1EF08C: cleanup_filtergraph (ffmpeg_filter.c:994)
>> ==32719==by 0x1EFA81: configure_filtergraph (ffmpeg_filter.c:1168)
>> ==32719==by 0x1F7B48: ifilter_send_frame (ffmpeg.c:2193)
>> ==32719==by 0x1F7DC8: send_frame_to_filters (ffmpeg.c:2278)
>> ==32719==by 0x1F8A89: decode_video (ffmpeg.c:2469)
>> ==32719==by 0x1F9375: process_input_packet (ffmpeg.c:2614)
>> ==32719==by 0x1FFC8A: process_input (ffmpeg.c:4350)
>> ==32719==by 0x200104: transcode_step (ffmpeg.c:4461)
>> ==32719==  Address 0x12f78798 is 24 bytes inside a block of size 32 free'd
>> ==32719==at 0x4C2CDDB: free (in 
>> /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
>> ==32719==by 0x13BDC21: av_free (mem.c:239)
>> ==32719==by 0x23F7E8: ff_formats_unref (formats.c:478)
>> ==32719==by 0x2F8681: hwupload_query_formats (vf_hwupload.c:87)
>> ==32719==by 0x22CA9C: filter_query_formats (avfiltergraph.c:317)
>> ==32719==by 0x22D040: query_formats (avfiltergraph.c:445)
>> ==32719==by 0x22F368: graph_config_formats (avfiltergraph.c:1159)
>> ==32719==by 0x22F81A: avfilter_graph_config (avfiltergraph.c:1270)
>> ==32719==by 0x1EF688: configure_filtergraph (ffmpeg_filter.c:1096)
>> ==32719==by 0x1F7B48: ifilter_send_frame (ffmpeg.c:2193)
>> ==32719==by 0x1F7DC8: send_frame_to_filters (ffmpeg.c:2278)
>> ==32719==by 0x1F8A89: decode_video (ffmpeg.c:2469)
>> ==32719==  Block was alloc'd at
>> ==32719==at 0x4C2DF16: memalign (in 
>> /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
>> ==32719==by 0x4C2E021: posix_memalign (in 
>> /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
>> ==32719==by 0x13BD9DD: av_malloc (mem.c:97)
>> ==32719==by 0x13BDC75: av_mallocz (mem.c:254)
>> ==32719==by 0x23EF33: ff_make_format_list (formats.c:285)
>> ==32719==by 0x2F85A2: hwupload_query_formats (vf_hwupload.c:69)
>> ==32719==by 0x22CA9C: filter_query_formats (avfiltergraph.c:317)
>> ==32719==by 0x22D040: query_formats (avfiltergraph.c:445)
>> ==32719==by 0x22F368: graph_config_formats (avfiltergraph.c:1159)
>> ==32719==by 0x22F81A: avfilter_graph_config (avfiltergraph.c:1270)
>> ==32719==by 0x1EF688: configure_filtergraph (ffmpeg_filter.c:1096)
>> ==32719==by 0x1F7B48: ifilter_send_frame (ffmpeg.c:2193)
>>
>> ... more invalid reads ...
>>
>> ==32719== Process terminating with default action of signal 11 (SIGSEGV)
>> ==32719==  

Re: [FFmpeg-devel] [PATCH]lsws/input: Do not define unused functions

[Carl Eugen Hoyos]

2017-03-07 9:55 GMT+01:00 Paul B Mahol :
> On 3/7/17, Carl Eugen Hoyos  wrote:
>> Hi!
>>
>> Attached patch fixes a few warnings when compiling with newer gcc.
>>
>> Please comment, Carl Eugen
>>
>
> lgtm

Patch applied.

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

Re: [FFmpeg-devel] [PATCH]lsws/slice: Move a misplaced const, fix a warning

[Carl Eugen Hoyos]

2017-02-26 11:20 GMT+01:00 Carl Eugen Hoyos :
> Hi!
>
> Attached patch fixes two warnings when compiling libswscale/slice.o.

Patch (that did not show up in patchwork afaict) applied.

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

Re: [FFmpeg-devel] [PATCH]lavc/libx265: Add gray10 and gray12 encoding support

[Carl Eugen Hoyos]

2017-02-23 0:30 GMT+01:00 Carl Eugen Hoyos :

> Attached patch adds gray10 and gray12 native endian encoding support
> to libx265.

Tested and applied.

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

Re: [FFmpeg-devel] [PATCH 6/6] avcodec/movtextdec: run mov_text_cleanup() before overwriting pointers

[Michael Niedermayer]

On Wed, Mar 08, 2017 at 11:28:43PM +0100, Michael Niedermayer wrote:
> Fixes: memleak
> Fixes: 741/clusterfuzz-testcase-586996200452915
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/movtextdec.c | 2 ++
>  1 file changed, 2 insertions(+)

applied

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

Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
then the original author, trying to rewrite it will not make it better.


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/6] avcodec/mpeg4videodec: Fix runtime error: signed integer overflow: -135088512 * 16 cannot be represented in type 'int'

[Michael Niedermayer]

On Wed, Mar 08, 2017 at 11:28:42PM +0100, Michael Niedermayer wrote:
> Fixes: 736/clusterfuzz-testcase-5580263943831552
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/mpeg4videodec.c | 12 +++-
>  1 file changed, 11 insertions(+), 1 deletion(-)

applied

[...]
-- 
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 4/6] avcodec/h264_mvpred: Fix runtime error: left shift of negative value -1

[Michael Niedermayer]

On Wed, Mar 08, 2017 at 11:28:41PM +0100, Michael Niedermayer wrote:
> Fixes: 734/clusterfuzz-testcase-4821293192970240
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/h264_mvpred.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

applied

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

No great genius has ever existed without some touch of madness. -- Aristotle


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

Re: [FFmpeg-devel] [PATCH 3/6] avcodec/mjpegdec: Fix runtime error: left shift of negative value -127

[Michael Niedermayer]

On Wed, Mar 08, 2017 at 11:28:40PM +0100, Michael Niedermayer wrote:
> Fixes: 733/clusterfuzz-testcase-4682158096515072
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/mjpegdec.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

applied

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

During times of universal deceit, telling the truth becomes a
revolutionary act. -- George Orwell


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] avcodec/mpegaudiodec_template: Check for negative e

[Michael Niedermayer]

On Wed, Mar 08, 2017 at 11:28:38PM +0100, Michael Niedermayer wrote:
> Fixes: undefined shift
> Fixes: 631/clusterfuzz-testcase-6725491035734016
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/mpegaudiodec_template.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

applied

[...]
-- 
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] libavfilter/avf_showwaves: make sqrt and cbrt scale option values available to showwavespic by name

[Paul B Mahol]

On 3/9/17, Moritz Barsnick  wrote:
> The 'sqrt' and 'cbrt' scalers were added in commit
> 80262d8c86e94ff9a4bb3a9e3c2d734e04ccb399, but their symbolic option values
> only made available to the showwaves filter, not showwavespic, despite
> the scalers working properly by their numerical option values.
>
> Signed-off-by: Moritz Barsnick 
> ---
>  doc/filters.texi| 18 +-
>  libavfilter/avf_showwaves.c |  2 ++
>  2 files changed, 19 insertions(+), 1 deletion(-)
>

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

[FFmpeg-devel] [PATCH v2] Allow 'concat' filter to support inputs with different frame rates

[Calvin Walton]

Right now, the concat filter does not set the frame_rate value on any of
the out links. As a result, the default ffmpeg behaviour kicks in - to
copy the framerate from the first input to the outputs.

If a later input is higher framerate, this results in dropped frames; if
a later input is lower framerate it might cause judder.

This patch checks if all of the video inputs have the same framerate, and
if not it sets the out link to use '1/0' as the frame rate, the value
meaning "unknown/vfr".

A test is added to verify the VFR behaviour. The existing test for CFR
behaviour passes unchanged.
---
 libavfilter/avf_concat.c |  15 ++-
 tests/fate/filter-video.mak  |   4 +-
 tests/ref/fate/filter-concat-vfr | 224 +++
 3 files changed, 241 insertions(+), 2 deletions(-)
 create mode 100644 tests/ref/fate/filter-concat-vfr

diff --git a/libavfilter/avf_concat.c b/libavfilter/avf_concat.c
index 56e4179..2258663 100644
--- a/libavfilter/avf_concat.c
+++ b/libavfilter/avf_concat.c
@@ -133,8 +133,21 @@ static int config_output(AVFilterLink *outlink)
 outlink->h   = inlink->h;
 outlink->sample_aspect_ratio = inlink->sample_aspect_ratio;
 outlink->format  = inlink->format;
+outlink->frame_rate  = inlink->frame_rate;
+
+for (seg = 1; seg < cat->nb_segments; seg++) {
+inlink = ctx->inputs[in_no + seg * ctx->nb_outputs];
+if (outlink->frame_rate.num != inlink->frame_rate.num ||
+outlink->frame_rate.den != outlink->frame_rate.den) {
+av_log(ctx, AV_LOG_VERBOSE,
+"Video inputs have different frame rates, output will be 
VFR");
+outlink->frame_rate = av_make_q(1, 0);
+break;
+}
+}
+
 for (seg = 1; seg < cat->nb_segments; seg++) {
-inlink = ctx->inputs[in_no += ctx->nb_outputs];
+inlink = ctx->inputs[in_no + seg * ctx->nb_outputs];
 if (!outlink->sample_aspect_ratio.num)
 outlink->sample_aspect_ratio = inlink->sample_aspect_ratio;
 /* possible enhancement: unsafe mode, do not check */
diff --git a/tests/fate/filter-video.mak b/tests/fate/filter-video.mak
index c57c9c7..5a814e2 100644
--- a/tests/fate/filter-video.mak
+++ b/tests/fate/filter-video.mak
@@ -358,9 +358,11 @@ FATE_FILTER_SAMPLES-$(call ALLYES, VMD_DEMUXER 
VMDVIDEO_DECODER FORMAT_FILTER PE
 fate-filter-gradfun-sample: tests/data/filtergraphs/gradfun
 fate-filter-gradfun-sample: CMD = framecrc -i $(TARGET_SAMPLES)/vmd/12.vmd 
-filter_script $(TARGET_PATH)/tests/data/filtergraphs/gradfun -an -frames:v 20
 
-FATE_FILTER-$(call ALLYES, TESTSRC_FILTER SINE_FILTER CONCAT_FILTER) += 
fate-filter-concat
+FATE_FILTER-$(call ALLYES, TESTSRC_FILTER SINE_FILTER CONCAT_FILTER) += 
fate-filter-concat fate-filter-concat-vfr
 fate-filter-concat: tests/data/filtergraphs/concat
 fate-filter-concat: CMD = framecrc -filter_complex_script 
$(TARGET_PATH)/tests/data/filtergraphs/concat
+fate-filter-concat-vfr: tests/data/filtergraphs/concat-vfr
+fate-filter-concat-vfr: CMD = framecrc -filter_complex_script 
$(TARGET_PATH)/tests/data/filtergraphs/concat-vfr
 
 FATE_FILTER-$(call ALLYES, TESTSRC2_FILTER FPS_FILTER MPDECIMATE_FILTER) += 
fate-filter-mpdecimate
 fate-filter-mpdecimate: CMD = framecrc -lavfi 
testsrc2=r=2:d=10,fps=3,mpdecimate -r 3 -pix_fmt yuv420p
diff --git a/tests/ref/fate/filter-concat-vfr b/tests/ref/fate/filter-concat-vfr
new file mode 100644
index 000..0dece67
--- /dev/null
+++ b/tests/ref/fate/filter-concat-vfr
@@ -0,0 +1,224 @@
+#tb 0: 1/100
+#media_type 0: video
+#codec_id 0: rawvideo
+#dimensions 0: 320x240
+#sar 0: 1/1
+#tb 1: 1/44100
+#media_type 1: audio
+#codec_id 1: pcm_s16le
+#sample_rate 1: 44100
+#channel_layout 1: 4
+#channel_layout_name 1: mono
+0,  0,  0,0,   230400, 0x88c4d19a
+1,  0,  0, 1024, 2048, 0xb3f10192
+1,   1024,   1024, 1024, 2048, 0xb340fe4e
+1,   2048,   2048, 1024, 2048, 0x0a5f0111
+1,   3072,   3072, 1024, 2048, 0x51be06b8
+1,   4096,   4096, 1024, 2048, 0x71a1ffcb
+1,   5120,   5120, 1024, 2048, 0x7f64f50f
+1,   6144,   6144, 1024, 2048, 0x70a8fa17
+1,   7168,   7168, 1024, 2048, 0x0dad072a
+1,   8192,   8192, 1024, 2048, 0x5e810c51
+0, 20, 20,0,   230400, 0x0d77c977
+1,   9216,   9216, 1024, 2048, 0xbe5bf462
+1,  10240,  10240, 1024, 2048, 0xbcd9faeb
+1,  11264,  11264, 1024, 2048, 0x0d5bfe9c
+1,  12288,  12288, 1024, 2048, 0x97d80297
+1,  13312,  13312, 1024, 2048, 0xba0f0894
+1,  14336,  14336, 1024, 2048, 0xcc22f291
+1,  15360,  15360, 1024, 2048, 0x11a9fa03
+1,  16384,  16384, 1024, 2048, 0x9a920378
+1,  17408,  17408, 1024, 2048, 0x901b0525

Re: [FFmpeg-devel] fate: Do not report side data size

[wm4]

On Thu, 9 Mar 2017 20:48:51 +0100
Michael Niedermayer  wrote:

> On Thu, Mar 09, 2017 at 07:48:53AM +0100, wm4 wrote:
> > On Thu, 9 Mar 2017 02:20:03 +0100
> > Michael Niedermayer  wrote:
> >   
> > > On Wed, Mar 08, 2017 at 11:54:59PM +0100, Hendrik Leppkes wrote:  
> > > > On Wed, Mar 8, 2017 at 3:42 PM, Ronald S. Bultje  
> > > > wrote:
> > > > > Hi,
> > > > >
> > > > > On Wed, Mar 8, 2017 at 9:31 AM, wm4  wrote:
> > > > >
> > > > >> On Wed, 8 Mar 2017 14:09:53 +0100
> > > > >> Michael Niedermayer  wrote:
> > > > >>
> > > > >> If the size printing is removed then other code should be added
> > > > >> > to test for the size to match the correct value
> > > > >>
> > > > >> Then it would be more reasonable to make av_packet_add_side_data()
> > > > >> check whether the size is correct for the given side data type.
> > > > >
> > > > >
> > > > > I think you're both right here, this is a pretty good idea (for 
> > > > > fixed-size
> > > > > side-data types).
> > > > >
> > > > 
> > > > So how do we fix fate now? Change the datatypes to uint32_t, remove
> > > > the size print out?
> > >   
> > > > Shouldn't keep all 32-bit fate clients broken for much longer.
> > > 
> > > +1
> > >   
> > 
> > You're the one stopping the simple fix.  
> 
> If you or anyone belives this, you can just ask me privatly if i meant
> to object to the patch. Noone asked
> one can even ask me in public, as in "do you object to this patch
> being pushed ?"
> and to save everyone the delay and troubble the awnser is
> 
> I do NOT object to it.
> I would prefer if the final implementation would still print the size
> where it is relevant. That can be done in a seperate patch. Its
> important to fix this issue so it should not be delayed by this
> discussion (thats the long form of the "+1" above really)
> 
> But instead of asking, you publically claim that iam stoping the fix.
> that is not ok IMO

OK, so after this long, exhausting discussion that seemed to lead
nowhere, you actually were never against this patch all along. Maybe
you should be more explicit about whether you think a patch needs
requires more changes, or if it's fine to push. Because this sort
of thing seemed to happen multiple times in the past.

A patch author can't push a patch if there are still open requests for
amendments, so this should be made clear to not block application
unnecessarily.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] fate: Do not report side data size

[Michael Niedermayer]

On Thu, Mar 09, 2017 at 07:48:53AM +0100, wm4 wrote:
> On Thu, 9 Mar 2017 02:20:03 +0100
> Michael Niedermayer  wrote:
> 
> > On Wed, Mar 08, 2017 at 11:54:59PM +0100, Hendrik Leppkes wrote:
> > > On Wed, Mar 8, 2017 at 3:42 PM, Ronald S. Bultje  
> > > wrote:  
> > > > Hi,
> > > >
> > > > On Wed, Mar 8, 2017 at 9:31 AM, wm4  wrote:
> > > >  
> > > >> On Wed, 8 Mar 2017 14:09:53 +0100
> > > >> Michael Niedermayer  wrote:
> > > >>
> > > >> If the size printing is removed then other code should be added  
> > > >> > to test for the size to match the correct value  
> > > >>
> > > >> Then it would be more reasonable to make av_packet_add_side_data()
> > > >> check whether the size is correct for the given side data type.  
> > > >
> > > >
> > > > I think you're both right here, this is a pretty good idea (for 
> > > > fixed-size
> > > > side-data types).
> > > >  
> > > 
> > > So how do we fix fate now? Change the datatypes to uint32_t, remove
> > > the size print out?  
> > 
> > > Shouldn't keep all 32-bit fate clients broken for much longer.  
> > 
> > +1
> > 
> 
> You're the one stopping the simple fix.

If you or anyone belives this, you can just ask me privatly if i meant
to object to the patch. Noone asked
one can even ask me in public, as in "do you object to this patch
being pushed ?"
and to save everyone the delay and troubble the awnser is

I do NOT object to it.
I would prefer if the final implementation would still print the size
where it is relevant. That can be done in a seperate patch. Its
important to fix this issue so it should not be delayed by this
discussion (thats the long form of the "+1" above really)

But instead of asking, you publically claim that iam stoping the fix.
that is not ok IMO


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

It is what and why we do it that matters, not just one of them.


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

[FFmpeg-devel] [PATCH] lavf/vf_framerate: Fix frame leak when increasing framerate.

[Alexis Ballier]

---
Can be reproduced with: ffmpeg -f lavfi -i cellauto,framerate=fps=100 -t 1 -f 
null -
(and your favorite memory debugger).
---
 libavfilter/vf_framerate.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavfilter/vf_framerate.c b/libavfilter/vf_framerate.c
index 237a4873b3..b4a74f7f7d 100644
--- a/libavfilter/vf_framerate.c
+++ b/libavfilter/vf_framerate.c
@@ -526,7 +526,7 @@ static av_cold void uninit(AVFilterContext *ctx)
 FrameRateContext *s = ctx->priv;
 int i;
 
-for (i = s->frst + 1; i < s->last; i++) {
+for (i = s->frst; i < s->last; i++) {
 if (s->srce[i] && (s->srce[i] != s->srce[i + 1]))
 av_frame_free(>srce[i]);
 }
-- 
2.12.0

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

[FFmpeg-devel] [PATCH] libavfilter/vf_detelecine: Added documentation to clarify the workings of the filter.

[gabriel . dalimonte]

From: Gabriel D'Alimonte 

Hi!

I hope this patch adding code documentation to the detelecine filter will help 
with maintenance.

---
 libavfilter/vf_detelecine.c | 115 +---
 1 file changed, 86 insertions(+), 29 deletions(-)

diff --git a/libavfilter/vf_detelecine.c b/libavfilter/vf_detelecine.c
index 0d5f88d..f6f9776 100644
--- a/libavfilter/vf_detelecine.c
+++ b/libavfilter/vf_detelecine.c
@@ -34,24 +34,31 @@
 
 typedef struct {
 const AVClass *class;
-int first_field;
-char *pattern;
-int start_frame;
-int init_len;
-unsigned int pattern_pos;
-unsigned int nskip_fields;
-int64_t start_time;
-
-AVRational pts;
-AVRational ts_unit;
-int occupied;
-
-int nb_planes;
-int planeheight[4];
-int stride[4];
-
-AVFrame *frame[2];
-AVFrame *temp;
+int first_field;///< 0 = top first field, 1 = bottom first 
field.
+char *pattern;  /**< The telecine pattern representing the 
original
+ frames -> fields mapping. */
+int start_frame;/**< Describes the input frame position offset
+ into pattern. */
+int init_len;   /**< Number of stray fields at the beginning
+ resulting from a cut. */
+unsigned int pattern_pos;   ///< The current position within pattern.
+unsigned int nskip_fields;  /**< Number of fields from input to skip 
writing
+  to the output. */
+int64_t start_time; ///< The PTS value of the first frame.
+
+AVRational pts; ///< PTS multiplier, telecined 
frames/detelecined frames.
+AVRational ts_unit; ///< Timestamp interval of one output frame.
+int occupied;   ///< Boolean, indicates whether temp has data 
in it.
+
+int nb_planes;  ///< The number of planes in the video format.
+int planeheight[4]; /**< The height of each plane in nb_planes 
from the
+ video context. */
+int stride[4];  /**< The number of bytes in one row of data 
for each
+ plane in nb_planes. */
+
+AVFrame *frame[2];  ///< Detelecined output frames.
+AVFrame *temp;  /**< Buffered frame needed to contribute 
fields to the
+ next output frame. */
 } DetelecineContext;
 
 #define OFFSET(x) offsetof(DetelecineContext, x)
@@ -73,9 +80,9 @@ AVFILTER_DEFINE_CLASS(detelecine);
 static av_cold int init(AVFilterContext *ctx)
 {
 DetelecineContext *s = ctx->priv;
-const char *p;
-int max = 0;
-int sum = 0;
+const char *p; ///< Induction variable for loops.
+int max = 0;   ///< Max of the field values in pattern.
+int sum = 0;   ///< Sum of the field values in pattern.
 
 if (!strlen(s->pattern)) {
 av_log(ctx, AV_LOG_ERROR, "No pattern provided.\n");
@@ -105,6 +112,11 @@ static av_cold int init(AVFilterContext *ctx)
 s->init_len = 0;
 
 if (s->start_frame != 0) {
+/**
+ *  Calculates the number of residual frames as the result of a cut so 
the
+ *  pattern will begin at the proper position while accounting for any
+ *  residual frames from the previous number in the pattern.
+ */
 int nfields = 0;
 for (p = s->pattern; *p; p++) {
 nfields += *p - '0';
@@ -129,6 +141,7 @@ static int query_formats(AVFilterContext *ctx)
 
 for (fmt = 0; av_pix_fmt_desc_get(fmt); fmt++) {
 const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(fmt);
+// Skip over formats which pack data unconventionally.
 if (!(desc->flags & AV_PIX_FMT_FLAG_HWACCEL ||
   desc->flags & AV_PIX_FMT_FLAG_PAL ||
   desc->flags & AV_PIX_FMT_FLAG_BITSTREAM) &&
@@ -199,7 +212,10 @@ static int filter_frame(AVFilterLink *inlink, AVFrame 
*inpicref)
 AVFilterContext *ctx = inlink->dst;
 AVFilterLink *outlink = ctx->outputs[0];
 DetelecineContext *s = ctx->priv;
-int i, len = 0, ret = 0, out = 0;
+int i; //< For loop inductive variable.
+int len = 0; ///< Number of fields the current output frame spans.
+int ret = 0; ///< The result of the next filter in the filtergraph.
+int out = 0; ///< Number of output frames.
 
 if (s->start_time == AV_NOPTS_VALUE)
 s->start_time = inpicref->pts;
@@ -208,6 +224,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame 
*inpicref)
 s->nskip_fields -= 2;
 return 0;
 } else if (s->nskip_fields >= 1) {
+// One of the fields from the current frame will be needed.
 for (i = 0; i < s->nb_planes; i++) {
 av_image_copy_plane(s->temp->data[i], s->temp->linesize[i],
 inpicref->data[i], inpicref->linesize[i],

Re: [FFmpeg-devel] [PATCH v2] avformat/matroskaenc: add support for Spherical Video elements

[James Almer]

On 3/8/2017 6:24 PM, James Almer wrote:
> Signed-off-by: James Almer 
> ---
>  libavformat/matroskaenc.c | 75 
> +++
>  1 file changed, 75 insertions(+)
> 
> diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
> index 1605f0cafe..70b0ced226 100644
> --- a/libavformat/matroskaenc.c
> +++ b/libavformat/matroskaenc.c
> @@ -918,6 +918,78 @@ static int mkv_write_video_color(AVIOContext *pb, 
> AVCodecParameters *par, AVStre
>  return 0;
>  }
>  
> +static int mkv_write_video_projection(AVIOContext *pb, AVStream *st) {
> +int side_data_size = 0;
> +const AVSphericalMapping *spherical =
> +(const AVSphericalMapping*) av_stream_get_side_data(st, 
> AV_PKT_DATA_SPHERICAL,
> +_data_size);
> +
> +if (side_data_size) {
> +AVIOContext *dyn_cp;
> +uint8_t *projection_ptr;
> +int ret, projection_size;
> +
> +ret = avio_open_dyn_buf(_cp);
> +if (ret < 0)
> +return ret;
> +
> +switch (spherical->projection) {
> +case AV_SPHERICAL_EQUIRECTANGULAR_TILE:
> +{
> +uint8_t private[20];
> +AVIOContext b;
> +ffio_init_context(, private, sizeof(private),
> +  1, NULL, NULL, NULL, NULL);
> +put_ebml_uint(dyn_cp, MATROSKA_ID_VIDEOPROJECTIONTYPE,
> +  MATROSKA_VIDEO_PROJECTION_TYPE_EQUIRECTANGULAR);
> +avio_wb32(, 0); // version + flags
> +avio_wb32(, spherical->bound_top);
> +avio_wb32(, spherical->bound_bottom);
> +avio_wb32(, spherical->bound_left);
> +avio_wb32(, spherical->bound_right);
> +put_ebml_binary(dyn_cp, MATROSKA_ID_VIDEOPROJECTIONPRIVATE, 
> private, sizeof(private));
> +break;
> +}
> +case AV_SPHERICAL_EQUIRECTANGULAR:
> +put_ebml_uint(dyn_cp, MATROSKA_ID_VIDEOPROJECTIONTYPE,
> +  MATROSKA_VIDEO_PROJECTION_TYPE_EQUIRECTANGULAR);
> +break;
> +case AV_SPHERICAL_CUBEMAP:
> +{
> +uint8_t private[12];
> +AVIOContext b;
> +ffio_init_context(, private, sizeof(private),
> +  1, NULL, NULL, NULL, NULL);
> +put_ebml_uint(dyn_cp, MATROSKA_ID_VIDEOPROJECTIONTYPE,
> +  MATROSKA_VIDEO_PROJECTION_TYPE_CUBEMAP);
> +avio_wb32(, 0); // version + flags
> +avio_wb32(, 0); // layout
> +avio_wb32(, spherical->padding);
> +put_ebml_binary(dyn_cp, MATROSKA_ID_VIDEOPROJECTIONPRIVATE, 
> private, sizeof(private));
> +break;
> +}
> +default:
> +// TODO: Mesh projection once implemented in AVSphericalMapping
> +goto end;
> +}
> +
> +put_ebml_float(dyn_cp, MATROSKA_ID_VIDEOPROJECTIONPOSEYAW,   
> (double)spherical->yaw   / (1 << 16));
> +put_ebml_float(dyn_cp, MATROSKA_ID_VIDEOPROJECTIONPOSEPITCH, 
> (double)spherical->pitch / (1 << 16));
> +put_ebml_float(dyn_cp, MATROSKA_ID_VIDEOPROJECTIONPOSEROLL,  
> (double)spherical->roll  / (1 << 16));
> +
> +end:
> +projection_size = avio_close_dyn_buf(dyn_cp, _ptr);
> +if (projection_size) {
> +ebml_master projection = start_ebml_master(pb, 
> MATROSKA_ID_VIDEOPROJECTION, projection_size);
> +avio_write(pb, projection_ptr, projection_size);
> +end_ebml_master(pb, projection);
> +}
> +av_freep(_ptr);
> +}
> +
> +return 0;
> +}
> +
>  static void mkv_write_field_order(AVIOContext *pb, int mode,
>enum AVFieldOrder field_order)
>  {
> @@ -1268,6 +1340,9 @@ static int mkv_write_track(AVFormatContext *s, 
> MatroskaMuxContext *mkv,
>  ret = mkv_write_video_color(pb, par, st);
>  if (ret < 0)
>  return ret;
> +ret = mkv_write_video_projection(pb, st);
> +if (ret < 0)
> +return ret;
>  end_ebml_master(pb, subinfo);
>  break;

Added a log message on unknown projections as requested and pushed.

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

[FFmpeg-devel] [PATCH] avcodec/vp56: Reset have_undamaged_frame on resolution changes

[Michael Niedermayer]

Fixes: timeout in 758/clusterfuzz-testcase-4720832028868608

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

diff --git a/libavcodec/vp56.c b/libavcodec/vp56.c
index 0010408847..9d4162bb96 100644
--- a/libavcodec/vp56.c
+++ b/libavcodec/vp56.c
@@ -507,6 +507,8 @@ static int vp56_size_changed(VP56Context *s)
 s->plane_height[0] = s->plane_height[3] = avctx->coded_height;
 s->plane_height[1] = s->plane_height[2] = avctx->coded_height/2;
 
+s->have_undamaged_frame = 0;
+
 for (i=0; i<4; i++)
 s->stride[i] = s->flip * s->frames[VP56_FRAME_CURRENT]->linesize[i];
 
-- 
2.11.0

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

Re: [FFmpeg-devel] [PATCH 1/3] concatdec: pass AVFormatContext flags to sub demuxer

[wm4]

On Thu, 9 Mar 2017 22:48:52 +0800
Steven Liu  wrote:

> 2017-03-09 22:45 GMT+08:00 wm4 :
> 
> > ---
> >  libavformat/concatdec.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/libavformat/concatdec.c b/libavformat/concatdec.c
> > index 5cc239a1b6..8649916ff2 100644
> > --- a/libavformat/concatdec.c
> > +++ b/libavformat/concatdec.c
> > @@ -322,6 +322,7 @@ static int open_file(AVFormatContext *avf, unsigned
> > fileno)
> >  if (!cat->avf)
> >  return AVERROR(ENOMEM);
> >
> > +cat->avf->flags |= avf->flags;
> >  cat->avf->interrupt_callback = avf->interrupt_callback;
> >
> >  if ((ret = ff_copy_whiteblacklists(cat->avf, avf)) < 0)
> > --
> > 2.11.0
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >  
> 
> LGTM

Thanks for the review. Applied patches 1 and 2, the first with a FATE
update from patch 3. (Didn't notice that before I ran FATE without
patch 3. The reason is that FATE sometimes runs ffprobe with +keepside.)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/3] concatdec: pass AVFormatContext flags to sub demuxer

[Steven Liu]

2017-03-09 22:45 GMT+08:00 wm4 :

> ---
>  libavformat/concatdec.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/libavformat/concatdec.c b/libavformat/concatdec.c
> index 5cc239a1b6..8649916ff2 100644
> --- a/libavformat/concatdec.c
> +++ b/libavformat/concatdec.c
> @@ -322,6 +322,7 @@ static int open_file(AVFormatContext *avf, unsigned
> fileno)
>  if (!cat->avf)
>  return AVERROR(ENOMEM);
>
> +cat->avf->flags |= avf->flags;
>  cat->avf->interrupt_callback = avf->interrupt_callback;
>
>  if ((ret = ff_copy_whiteblacklists(cat->avf, avf)) < 0)
> --
> 2.11.0
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

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

Re: [FFmpeg-devel] [PATCH 2/3] hls: pass AVFormatContext flags to sub demuxer

[Steven Liu]

2017-03-09 22:45 GMT+08:00 wm4 :

> ---
>  libavformat/hls.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/libavformat/hls.c b/libavformat/hls.c
> index 3ae3c7cc5c..c65a9f9e87 100644
> --- a/libavformat/hls.c
> +++ b/libavformat/hls.c
> @@ -1761,6 +1761,7 @@ static int hls_read_header(AVFormatContext *s)
>  }
>  pls->ctx->pb   = >pb;
>  pls->ctx->io_open  = nested_io_open;
> +pls->ctx->flags   |= s->flags;
>
>  if ((ret = ff_copy_whiteblacklists(pls->ctx, s)) < 0)
>  goto fail;
> --
> 2.11.0
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


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

[FFmpeg-devel] [PATCH 2/3] hls: pass AVFormatContext flags to sub demuxer

[wm4]

---
 libavformat/hls.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavformat/hls.c b/libavformat/hls.c
index 3ae3c7cc5c..c65a9f9e87 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -1761,6 +1761,7 @@ static int hls_read_header(AVFormatContext *s)
 }
 pls->ctx->pb   = >pb;
 pls->ctx->io_open  = nested_io_open;
+pls->ctx->flags   |= s->flags;
 
 if ((ret = ff_copy_whiteblacklists(pls->ctx, s)) < 0)
 goto fail;
-- 
2.11.0

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

[FFmpeg-devel] [PATCH 3/3] ffmpeg, ffprobe: don't "merge" side data into packet data by default

[wm4]

Preparation for potentially disabling merged side data by default in the
libs. Do this in particular because it affects fate tests.

The changed tests either reflect added packet side data, or the changed
packet size due to merged side data removal reducing the packet size.

The previous patches are needed because there is apparently no other way
for ffmpeg.c to pass the flag down to sub demuxers without potentially
overriding command line settings.
---
 ffmpeg_opt.c  |   2 +
 ffprobe.c |   8 ++
 libavformat/tests/seek.c  |   2 +
 tests/ref/fate/concat-demuxer-simple2-lavf-ts | 192 +-
 tests/ref/fate/gaplessenc-itunes-to-ipod-aac  |   4 +-
 tests/ref/fate/gaplessenc-pcm-to-mov-aac  |   4 +-
 tests/ref/fate/gaplessinfo-itunes1|   4 +-
 tests/ref/fate/gaplessinfo-itunes2|   4 +-
 tests/ref/fate/mov-aac-2048-priming   |   3 +-
 tests/ref/seek/cache-pipe |  10 +-
 tests/ref/seek/extra-mp3  |  18 +--
 tests/ref/seek/lavf-ts|  54 
 tests/ref/seek/mkv-codec-delay|  14 +-
 13 files changed, 198 insertions(+), 121 deletions(-)

diff --git a/ffmpeg_opt.c b/ffmpeg_opt.c
index e2c0176e14..fc885dfac3 100644
--- a/ffmpeg_opt.c
+++ b/ffmpeg_opt.c
@@ -927,6 +927,7 @@ static int open_input_file(OptionsContext *o, const char 
*filename)
 print_error(filename, AVERROR(ENOMEM));
 exit_program(1);
 }
+ic->flags |= AVFMT_FLAG_KEEP_SIDE_DATA;
 if (o->nb_audio_sample_rate) {
 av_dict_set_int(>g->format_opts, "sample_rate", 
o->audio_sample_rate[o->nb_audio_sample_rate - 1].u.i, 0);
 }
@@ -1912,6 +1913,7 @@ static int read_ffserver_streams(OptionsContext *o, 
AVFormatContext *s, const ch
 int i, err;
 AVFormatContext *ic = avformat_alloc_context();
 
+ic->flags |= AVFMT_FLAG_KEEP_SIDE_DATA;
 ic->interrupt_callback = int_cb;
 err = avformat_open_input(, filename, NULL, NULL);
 if (err < 0)
diff --git a/ffprobe.c b/ffprobe.c
index c85c3a104b..c3b010388d 100644
--- a/ffprobe.c
+++ b/ffprobe.c
@@ -2575,6 +2575,14 @@ static int open_input_file(InputFile *ifile, const char 
*filename)
 AVDictionary **opts;
 int scan_all_pmts_set = 0;
 
+fmt_ctx = avformat_alloc_context();
+if (!fmt_ctx) {
+print_error(filename, AVERROR(ENOMEM));
+exit_program(1);
+}
+
+fmt_ctx->flags |= AVFMT_FLAG_KEEP_SIDE_DATA;
+
 if (!av_dict_get(format_opts, "scan_all_pmts", NULL, AV_DICT_MATCH_CASE)) {
 av_dict_set(_opts, "scan_all_pmts", "1", 
AV_DICT_DONT_OVERWRITE);
 scan_all_pmts_set = 1;
diff --git a/libavformat/tests/seek.c b/libavformat/tests/seek.c
index 7ed56ba4ef..5cf3a123e3 100644
--- a/libavformat/tests/seek.c
+++ b/libavformat/tests/seek.c
@@ -67,6 +67,8 @@ int main(int argc, char **argv)
 int frame_count = 1;
 int duration = 4;
 
+ic->flags |= AVFMT_FLAG_KEEP_SIDE_DATA;
+
 for(i=2; i

[FFmpeg-devel] [PATCH 1/3] concatdec: pass AVFormatContext flags to sub demuxer

[wm4]

---
 libavformat/concatdec.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavformat/concatdec.c b/libavformat/concatdec.c
index 5cc239a1b6..8649916ff2 100644
--- a/libavformat/concatdec.c
+++ b/libavformat/concatdec.c
@@ -322,6 +322,7 @@ static int open_file(AVFormatContext *avf, unsigned fileno)
 if (!cat->avf)
 return AVERROR(ENOMEM);
 
+cat->avf->flags |= avf->flags;
 cat->avf->interrupt_callback = avf->interrupt_callback;
 
 if ((ret = ff_copy_whiteblacklists(cat->avf, avf)) < 0)
-- 
2.11.0

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

[FFmpeg-devel] fate on x86_64-netbsd-gcc46 (Was: Re: [PATCH] swresample/resample: use uniform normalization)

[Moritz Barsnick]

On Wed, Mar 08, 2017 at 13:15:47 +0100, Hendrik Leppkes wrote:
> This seems to have tripped up fate on some boxes, ie. here:
> http://fate.ffmpeg.org/report.cgi?time=20170308111534=x86_64-netbsd-gcc46

On that platform, tests/md5.sh seems to find "md5sum", but the fate log
shows "md5sum: not found" for every such test (3315 times). Am I right
in guessing that this is extremely reducing coverage? Does tests/md5.sh
need to be fixed?

Disclaimer: I have no such platform. I just happened to check the
quoted log.

Just wondering,
Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/vp56: Require not any undamaged frame for concealment but one of comparable size

[Michael Niedermayer]

On Thu, Mar 09, 2017 at 07:59:37AM -0500, Ronald S. Bultje wrote:
> Hi,
> 
> On Wed, Mar 8, 2017 at 10:07 PM, Michael Niedermayer  > wrote:
> 
> > Fixes: timeout in 758/clusterfuzz-testcase-4720832028868608
> >
> > Found-by: continuous fuzzing process https://github.com/google/oss-
> > fuzz/tree/master/targets/ffmpeg
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/vp56.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavcodec/vp56.c b/libavcodec/vp56.c
> > index 0010408847..bccb424903 100644
> > --- a/libavcodec/vp56.c
> > +++ b/libavcodec/vp56.c
> > @@ -710,7 +710,7 @@ static int ff_vp56_decode_mbs(AVCodecContext *avctx,
> > void *data,
> >  int ret = vp56_decode_mb(s, mb_row, mb_col, is_alpha);
> >  if (ret < 0) {
> >  damaged = 1;
> > -if (!s->have_undamaged_frame) {
> > +if (s->have_undamaged_frame < s->mb_width *
> > s->mb_height) {
> >  s->discard_frame = 1;
> >  return AVERROR_INVALIDDATA;
> >  }
> > @@ -732,7 +732,7 @@ static int ff_vp56_decode_mbs(AVCodecContext *avctx,
> > void *data,
> >  }
> >
> >  if (!damaged)
> > -s->have_undamaged_frame = 1;
> > +s->have_undamaged_frame = s->mb_width * s->mb_height;
> 
> 
> You know very well that this makes the memory issue go away but isn't doing
> the right thing if width1!=width2 && height1!=height2 but width1*height1 ==
>  width2*height2. This is obviously because vpN codecs up to and including
> vp8 don't include scalable MC.
> 
> Can you do this right and only allow this if frame/ref width and height
> both match, not just their product?

you assume that there is a out of array access and this is fixing it
and argue that this is the wrong fix for it.

You are correct that this would be the wrong fix if that was the bug.

Its possible there is such a bug, but i have not seen that.
What this is about is a timeout, as described in the commit message

a small file with a tiny initial
frame followed by frames with huge resolution but very few bits
the code is timing out as the error concealment takes alot of time
for high resolutions, no memory anomalies occured here when the
concealment code runs so any reference frame must be large enough.

The solution this patch implements is to require at least a undamagd
frame with X MBs before allowing concealment of similarly high
resolution frames. This undamagd frame is quite possibly not used
by the concealment its rather a check to make sure the file is not
just "empty"
This directly combats the issue of crafted files that are very small
bytewise but take a huge amount of time to decode.
Its quite possible the fuzzer will find a hole in this and we may
require to count undamaged mbs over several frames to weed out
these slow to decode empty timeout cases, we will only know once
the easier case is closed

[...]
-- 
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 2/2] avcodec/vp56: Require not any undamaged frame for concealment but one of comparable size

[Ronald S. Bultje]

Hi,

On Wed, Mar 8, 2017 at 10:07 PM, Michael Niedermayer  wrote:

> Fixes: timeout in 758/clusterfuzz-testcase-4720832028868608
>
> Found-by: continuous fuzzing process https://github.com/google/oss-
> fuzz/tree/master/targets/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/vp56.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/vp56.c b/libavcodec/vp56.c
> index 0010408847..bccb424903 100644
> --- a/libavcodec/vp56.c
> +++ b/libavcodec/vp56.c
> @@ -710,7 +710,7 @@ static int ff_vp56_decode_mbs(AVCodecContext *avctx,
> void *data,
>  int ret = vp56_decode_mb(s, mb_row, mb_col, is_alpha);
>  if (ret < 0) {
>  damaged = 1;
> -if (!s->have_undamaged_frame) {
> +if (s->have_undamaged_frame < s->mb_width *
> s->mb_height) {
>  s->discard_frame = 1;
>  return AVERROR_INVALIDDATA;
>  }
> @@ -732,7 +732,7 @@ static int ff_vp56_decode_mbs(AVCodecContext *avctx,
> void *data,
>  }
>
>  if (!damaged)
> -s->have_undamaged_frame = 1;
> +s->have_undamaged_frame = s->mb_width * s->mb_height;


You know very well that this makes the memory issue go away but isn't doing
the right thing if width1!=width2 && height1!=height2 but width1*height1 ==
 width2*height2. This is obviously because vpN codecs up to and including
vp8 don't include scalable MC.

Can you do this right and only allow this if frame/ref width and height
both match, not just their product?

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

[FFmpeg-devel] [PATCH] avcodec/h264_ps: Forward errors from decode_scaling_list()

[Michael Niedermayer]

Signed-off-by: Michael Niedermayer 
---
 libavcodec/h264_ps.c | 44 ++--
 1 file changed, 26 insertions(+), 18 deletions(-)

diff --git a/libavcodec/h264_ps.c b/libavcodec/h264_ps.c
index f384ef23c3..c330efddcb 100644
--- a/libavcodec/h264_ps.c
+++ b/libavcodec/h264_ps.c
@@ -247,7 +247,7 @@ static inline int decode_vui_parameters(GetBitContext *gb, 
AVCodecContext *avctx
 return 0;
 }
 
-static void decode_scaling_list(GetBitContext *gb, uint8_t *factors, int size,
+static int decode_scaling_list(GetBitContext *gb, uint8_t *factors, int size,
 const uint8_t *jvt_list,
 const uint8_t *fallback_list)
 {
@@ -261,7 +261,7 @@ static void decode_scaling_list(GetBitContext *gb, uint8_t 
*factors, int size,
 int v = get_se_golomb(gb);
 if (v < -128 || v > 127) {
 av_log(NULL, AV_LOG_ERROR, "delta scale %d is invalid\n", 
v);
-v = -last;
+return AVERROR_INVALIDDATA;
 }
 next = (last + v) & 0xff;
 }
@@ -271,6 +271,7 @@ static void decode_scaling_list(GetBitContext *gb, uint8_t 
*factors, int size,
 }
 last = factors[scan[i]] = next ? next : last;
 }
+return 0;
 }
 
 /* returns non zero if the provided SPS scaling matrix has been filled */
@@ -288,23 +289,24 @@ static int decode_scaling_matrices(GetBitContext *gb, 
const SPS *sps,
 };
 int ret = 0;
 if (get_bits1(gb)) {
-ret = is_sps;
-decode_scaling_list(gb, scaling_matrix4[0], 16, default_scaling4[0], 
fallback[0]);// Intra, Y
-decode_scaling_list(gb, scaling_matrix4[1], 16, default_scaling4[0], 
scaling_matrix4[0]); // Intra, Cr
-decode_scaling_list(gb, scaling_matrix4[2], 16, default_scaling4[0], 
scaling_matrix4[1]); // Intra, Cb
-decode_scaling_list(gb, scaling_matrix4[3], 16, default_scaling4[1], 
fallback[1]);// Inter, Y
-decode_scaling_list(gb, scaling_matrix4[4], 16, default_scaling4[1], 
scaling_matrix4[3]); // Inter, Cr
-decode_scaling_list(gb, scaling_matrix4[5], 16, default_scaling4[1], 
scaling_matrix4[4]); // Inter, Cb
+ret |= decode_scaling_list(gb, scaling_matrix4[0], 16, 
default_scaling4[0], fallback[0]);// Intra, Y
+ret |= decode_scaling_list(gb, scaling_matrix4[1], 16, 
default_scaling4[0], scaling_matrix4[0]); // Intra, Cr
+ret |= decode_scaling_list(gb, scaling_matrix4[2], 16, 
default_scaling4[0], scaling_matrix4[1]); // Intra, Cb
+ret |= decode_scaling_list(gb, scaling_matrix4[3], 16, 
default_scaling4[1], fallback[1]);// Inter, Y
+ret |= decode_scaling_list(gb, scaling_matrix4[4], 16, 
default_scaling4[1], scaling_matrix4[3]); // Inter, Cr
+ret |= decode_scaling_list(gb, scaling_matrix4[5], 16, 
default_scaling4[1], scaling_matrix4[4]); // Inter, Cb
 if (is_sps || pps->transform_8x8_mode) {
-decode_scaling_list(gb, scaling_matrix8[0], 64, 
default_scaling8[0], fallback[2]); // Intra, Y
-decode_scaling_list(gb, scaling_matrix8[3], 64, 
default_scaling8[1], fallback[3]); // Inter, Y
+ret |= decode_scaling_list(gb, scaling_matrix8[0], 64, 
default_scaling8[0], fallback[2]); // Intra, Y
+ret |= decode_scaling_list(gb, scaling_matrix8[3], 64, 
default_scaling8[1], fallback[3]); // Inter, Y
 if (sps->chroma_format_idc == 3) {
-decode_scaling_list(gb, scaling_matrix8[1], 64, 
default_scaling8[0], scaling_matrix8[0]); // Intra, Cr
-decode_scaling_list(gb, scaling_matrix8[4], 64, 
default_scaling8[1], scaling_matrix8[3]); // Inter, Cr
-decode_scaling_list(gb, scaling_matrix8[2], 64, 
default_scaling8[0], scaling_matrix8[1]); // Intra, Cb
-decode_scaling_list(gb, scaling_matrix8[5], 64, 
default_scaling8[1], scaling_matrix8[4]); // Inter, Cb
+ret |= decode_scaling_list(gb, scaling_matrix8[1], 64, 
default_scaling8[0], scaling_matrix8[0]); // Intra, Cr
+ret |= decode_scaling_list(gb, scaling_matrix8[4], 64, 
default_scaling8[1], scaling_matrix8[3]); // Inter, Cr
+ret |= decode_scaling_list(gb, scaling_matrix8[2], 64, 
default_scaling8[0], scaling_matrix8[1]); // Intra, Cb
+ret |= decode_scaling_list(gb, scaling_matrix8[5], 64, 
default_scaling8[1], scaling_matrix8[4]); // Inter, Cb
 }
 }
+if (!ret)
+ret = is_sps;
 }
 
 return ret;
@@ -335,6 +337,7 @@ int ff_h264_decode_seq_parameter_set(GetBitContext *gb, 
AVCodecContext *avctx,
 unsigned int sps_id;
 int i, log2_max_frame_num_minus4;
 SPS *sps;
+int ret;
 
 sps_buf = av_buffer_allocz(sizeof(*sps));
 if (!sps_buf)
@@ -413,8 +416,11 @@ int ff_h264_decode_seq_parameter_set(GetBitContext *gb, 

Re: [FFmpeg-devel] [PATCH 3/3] avformat: don't "merge" side data into packet data by default

[Michael Niedermayer]

On Thu, Mar 09, 2017 at 10:22:39AM +0100, wm4 wrote:
> On Wed, 8 Mar 2017 15:44:36 +0100
> Michael Niedermayer  wrote:
> 
> > On Wed, Mar 08, 2017 at 01:40:12PM +0100, wm4 wrote:
> > > Side data are separate AVPacket fields for a reason. Merging side data
> > > requires reallocating all packets, is complex, potentially clashes with
> > > "actual" packet data (you could probably come up with PCM data that
> > > looks like merged side data, or such), and could for example cause
> > > trouble to people trying to feed packets with merged side data to
> > > non-libavcodec decoders.
> > > 
> > > Disable it by default.
> > > 
> > > I do not consider this a real API change, because the AVPacket side data
> > > fields have been part of the API for at least a decade.
> > > 
> > > The changed tests either reflect added packet side data, or the changed
> > > packet size due to merged side data removal reducing the packet size.
> > > 
> > > ---  
> > 
> > > Missing: minor libavformat API bump, maybe a warning in APIchanges  
> > 
> > this is a ABI change and cannot be done before the next
> > major version bump
> > 
> > Applications did not need to preserve side data between layers and
> > this patch would add this requirement
> > 

> > The change of the default could be done conditional on the major
> > version or related API/ABI define
> 
> So what's the status on this? I consider it a bug fix, not an API
> change.

Then we disagree here i think

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

Dictatorship naturally arises out of democracy, and the most aggravated
form of tyranny and slavery out of the most extreme liberty. -- 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 2/3] avformat: reject FFmpeg-style merged side data in raw packets

[Nicolas George]

Le nonidi 19 ventôse, an CCXXV, Michael Niedermayer a écrit :
> yes, i was trying to clarify a reply that was apparently unclear and
> not understood.
> its like
> statement -> point out disagreement -> do not understand -> clarify
> and
> clarify -> "You are rehashing a lot of obvious facts"
> 
> Sorry if that felt off topic, it probably was

Ok, but please answer the actual question in my mail.

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 2/3] avformat: reject FFmpeg-style merged side data in raw packets

[Michael Niedermayer]

On Thu, Mar 09, 2017 at 12:16:09PM +0100, Nicolas George wrote:
> Le nonidi 19 ventôse, an CCXXV, Michael Niedermayer a écrit :
> > This is very basic really but lets elaborate
> > for each side data type T
> > possiblity A
> > nothing uses side data type T
> > 
> > possiblity B
> > something uses side data type T
> > 
> > Its the same with a codec, either a codec is used in some case or
> > its used in no case.
> > 
> > If something is used in no case then it has been eliminated as you
> > describe.
> > If somehing is still used in a case it has not been eliminated
> > 
> > If as you describe side data has been eliminated then you could
> > remove side data as a whole from the source code.
> > 
> > If you cannot remove side data or a specific side data type from
> > the source code then it has not been eliminated
> > 
> > your change removes one way for an attacker to set side data but
> > by the fact that you dont remove any of the side data types its
> > clear you are aware of that every is still in use in some code path.
> > 
> > a attacker may need to use a specific container format to set a
> > specific side data type or may depend on a specific demuxer lib or
> > application that allows him to set a side data type.
> > 
> > now if you remove every way to set side data for an attacker then
> > you can remove that side data type as a whole from the code.
> > Of course that removes whatever the side data is for.
> > 
> > Let me provide a specific example
> > If a container suports changing extradata mid stream it will either
> > be support or not.
> > if any demuxer supports it then you have not eliminated the possiblity
> > for an attacker
> > 
> > I hope writing a elaborate reply will not lead to this discussion
> > to shift onto some unrelated detail
> 
> You are rehashing a lot of obvious facts, but you do not address the
> important questions.

yes, i was trying to clarify a reply that was apparently unclear and
not understood.
its like
statement -> point out disagreement -> do not understand -> clarify
and
clarify -> "You are rehashing a lot of obvious facts"

Sorry if that felt off topic, it probably was

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Does the universe only have a finite lifespan? No, its going to go on
forever, its just that you wont like living in it. -- Hiranya Peiri


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/3] avformat: reject FFmpeg-style merged side data in raw packets

[wm4]

On Thu, 9 Mar 2017 12:16:09 +0100
Nicolas George  wrote:

> Now, please answer this very specific question:
> 
> If someone were to REMOVE ALL AND EVERY use of
> av_packet_merge_side_data() and av_packet_split_side_data(), what would
> be the actual bad consequences?

Simply that API users, which pass only the packet data itself from
libavformat to libavcodec, will break in cases where the side data is
"required". The argument is that such API users exist because they
cannot pass the AVPacket reference along, but have to go through their
own layers, which can transport only the raw packet data itself and
maybe timestamps.

> But before you start with fuzzing or anything similar, let me stop you:
> fuzzing exposes bugs that can be triggered by crafted inputs. If fuzzing
> can not trigger it, that means the bug does not exist, period.

I think the argument is that it's easier to fuzz side-data related
things if side data can be accidentally read from raw packets that look
like they have merged side data.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/3] avformat: reject FFmpeg-style merged side data in raw packets

[wm4]

On Thu, 9 Mar 2017 12:00:38 +0100
Michael Niedermayer  wrote:

> On Thu, Mar 09, 2017 at 07:50:14AM +0100, wm4 wrote:
> > On Wed, 8 Mar 2017 23:34:39 +0100
> > Michael Niedermayer  wrote:
> >   
> > > On Wed, Mar 08, 2017 at 09:01:32PM +0100, wm4 wrote:  
> > > > On Wed, 8 Mar 2017 20:54:43 +0100
> > > > Michael Niedermayer  wrote:
> > > > 
> > > > > On Wed, Mar 08, 2017 at 07:32:26PM +0100, wm4 wrote:
> > > > > > On Wed, 8 Mar 2017 19:20:15 +0100
> > > > > > Michael Niedermayer  wrote:
> > > > > >   
> > > > > > > On Wed, Mar 08, 2017 at 05:26:57PM +0100, wm4 wrote:  
> > > > > > > > On Wed, 8 Mar 2017 17:11:12 +0100
> > > > > > > > Michael Niedermayer  wrote:
> > > > > > > > 
> > > > > > > > > On Wed, Mar 08, 2017 at 04:06:20PM +0100, wm4 wrote:
> > > > > > > > > > On Wed, 8 Mar 2017 15:36:25 +0100
> > > > > > > > > > Michael Niedermayer  wrote:
> > > > > > > > > >   
> > > > > > > > > > > On Wed, Mar 08, 2017 at 01:40:11PM +0100, wm4 wrote:  
> > > > > > > > > > > 
> > > > > > > [...]  
> > > > > > > > >
> > > > > > > > > >   
> > > > > > > > > > > also it may be interresting to disable this check for 
> > > > > > > > > > > fuzzing so
> > > > > > > > > > > side data can be fuzzed in a wider range of cases and any 
> > > > > > > > > > > past
> > > > > > > > > > > testcases that happen to use this can still be used for 
> > > > > > > > > > > regression
> > > > > > > > > > > testing  
> > > > > > > > > > 
> > > > > > > > > > I think what you want is fault injection for memory errors, 
> > > > > > > > > > seems out
> > > > > > > > > > of scope here.  
> > > > > > > > > 
> > > > > > > > > no, i want fuzzing to continue to fuzz side data, it did so 
> > > > > > > > > in the
> > > > > > > > > past and it should continue to do so.
> > > > > > > > 
> > > > > > > > You can fuzz side data as much as you can fuzz AVFrame or
> > > > > > > > AVCodecContext. I believe randomly changing in-memory data 
> > > > > > > > structures
> > > > > > > > is referred to as fault injection, not fuzzing.
> > > > > > > 
> > > > > > > it doesnt really matter what you call it, but it was done and the
> > > > > > > patch breaks it if theres no option to disable it or something 
> > > > > > > else  
> > > > > > 
> > > > > > Well, you can't do it anymore. Why are you so afraid that a 
> > > > > > potential
> > > > > > error source is being eliminated?  
> > > > > 
> > > > > well its rather hidden, harder to test for not eliminated.
> > > > 
> > > > How is it not eliminated?
> > > 
> > > every side data we support can be generated by something otherwise  
> > 
> > Like what? You're not answering, just spouting confused stuff. What
> > kind of reply is this? 
> >   
> > > we wouldnt have that side data type  
> > 
> >   
> 
> This is very basic really but lets elaborate
> for each side data type T
> possiblity A
> nothing uses side data type T
> 
> possiblity B
> something uses side data type T
> 
> 
> Its the same with a codec, either a codec is used in some case or
> its used in no case.
> 
> If something is used in no case then it has been eliminated as you
> describe.
> If somehing is still used in a case it has not been eliminated
> 
> If as you describe side data has been eliminated then you could
> remove side data as a whole from the source code.
> 
> If you cannot remove side data or a specific side data type from
> the source code then it has not been eliminated
> 
> your change removes one way for an attacker to set side data but
> by the fact that you dont remove any of the side data types its
> clear you are aware of that every is still in use in some code path.
> 
> a attacker may need to use a specific container format to set a
> specific side data type or may depend on a specific demuxer lib or
> application that allows him to set a side data type.
> 
> now if you remove every way to set side data for an attacker then
> you can remove that side data type as a whole from the code.
> Of course that removes whatever the side data is for.
> 
> Let me provide a specific example
> If a container suports changing extradata mid stream it will either
> be support or not.
> if any demuxer supports it then you have not eliminated the possiblity
> for an attacker
> 
> I hope writing a elaborate reply will not lead to this discussion
> to shift onto some unrelated detail

OK, but that has absolutely nothing to do with the issue at hand.

Of course side data can still be used after this patch!

Now if you could get back on topic...
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/3] avformat: reject FFmpeg-style merged side data in raw packets

[Nicolas George]

Le nonidi 19 ventôse, an CCXXV, Michael Niedermayer a écrit :
> This is very basic really but lets elaborate
> for each side data type T
> possiblity A
> nothing uses side data type T
> 
> possiblity B
> something uses side data type T
> 
> Its the same with a codec, either a codec is used in some case or
> its used in no case.
> 
> If something is used in no case then it has been eliminated as you
> describe.
> If somehing is still used in a case it has not been eliminated
> 
> If as you describe side data has been eliminated then you could
> remove side data as a whole from the source code.
> 
> If you cannot remove side data or a specific side data type from
> the source code then it has not been eliminated
> 
> your change removes one way for an attacker to set side data but
> by the fact that you dont remove any of the side data types its
> clear you are aware of that every is still in use in some code path.
> 
> a attacker may need to use a specific container format to set a
> specific side data type or may depend on a specific demuxer lib or
> application that allows him to set a side data type.
> 
> now if you remove every way to set side data for an attacker then
> you can remove that side data type as a whole from the code.
> Of course that removes whatever the side data is for.
> 
> Let me provide a specific example
> If a container suports changing extradata mid stream it will either
> be support or not.
> if any demuxer supports it then you have not eliminated the possiblity
> for an attacker
> 
> I hope writing a elaborate reply will not lead to this discussion
> to shift onto some unrelated detail

You are rehashing a lot of obvious facts, but you do not address the
important questions.

Side data is useful. It is a badly designed API, because it adds a lot
of complexity for a hypothetical benefit but fails to reap that benefit.
As such, it should be kept but enhanced, either by removing the
complexity or by actually reaping the benefit.

But it is not the topic of this discussion.

MERGED side data is a completely brainded design that should never have
been written.

I am purposefully not looking at the archive to find out who is
responsible for this mess. Now is not the time to point fingers but to
fix the code.

Now, please answer this very specific question:

If someone were to REMOVE ALL AND EVERY use of
av_packet_merge_side_data() and av_packet_split_side_data(), what would
be the actual bad consequences?

But before you start with fuzzing or anything similar, let me stop you:
fuzzing exposes bugs that can be triggered by crafted inputs. If fuzzing
can not trigger it, that means the bug does not exist, period.

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 2/3] avformat: reject FFmpeg-style merged side data in raw packets

[Michael Niedermayer]

On Thu, Mar 09, 2017 at 07:50:14AM +0100, wm4 wrote:
> On Wed, 8 Mar 2017 23:34:39 +0100
> Michael Niedermayer  wrote:
> 
> > On Wed, Mar 08, 2017 at 09:01:32PM +0100, wm4 wrote:
> > > On Wed, 8 Mar 2017 20:54:43 +0100
> > > Michael Niedermayer  wrote:
> > >   
> > > > On Wed, Mar 08, 2017 at 07:32:26PM +0100, wm4 wrote:  
> > > > > On Wed, 8 Mar 2017 19:20:15 +0100
> > > > > Michael Niedermayer  wrote:
> > > > > 
> > > > > > On Wed, Mar 08, 2017 at 05:26:57PM +0100, wm4 wrote:
> > > > > > > On Wed, 8 Mar 2017 17:11:12 +0100
> > > > > > > Michael Niedermayer  wrote:
> > > > > > >   
> > > > > > > > On Wed, Mar 08, 2017 at 04:06:20PM +0100, wm4 wrote:  
> > > > > > > > > On Wed, 8 Mar 2017 15:36:25 +0100
> > > > > > > > > Michael Niedermayer  wrote:
> > > > > > > > > 
> > > > > > > > > > On Wed, Mar 08, 2017 at 01:40:11PM +0100, wm4 wrote:
> > > > > > [...]
> > > > > > > >  
> > > > > > > > > 
> > > > > > > > > > also it may be interresting to disable this check for 
> > > > > > > > > > fuzzing so
> > > > > > > > > > side data can be fuzzed in a wider range of cases and any 
> > > > > > > > > > past
> > > > > > > > > > testcases that happen to use this can still be used for 
> > > > > > > > > > regression
> > > > > > > > > > testing
> > > > > > > > > 
> > > > > > > > > I think what you want is fault injection for memory errors, 
> > > > > > > > > seems out
> > > > > > > > > of scope here.
> > > > > > > > 
> > > > > > > > no, i want fuzzing to continue to fuzz side data, it did so in 
> > > > > > > > the
> > > > > > > > past and it should continue to do so.  
> > > > > > > 
> > > > > > > You can fuzz side data as much as you can fuzz AVFrame or
> > > > > > > AVCodecContext. I believe randomly changing in-memory data 
> > > > > > > structures
> > > > > > > is referred to as fault injection, not fuzzing.  
> > > > > > 
> > > > > > it doesnt really matter what you call it, but it was done and the
> > > > > > patch breaks it if theres no option to disable it or something else 
> > > > > >
> > > > > 
> > > > > Well, you can't do it anymore. Why are you so afraid that a potential
> > > > > error source is being eliminated?
> > > > 
> > > > well its rather hidden, harder to test for not eliminated.  
> > > 
> > > How is it not eliminated?  
> > 
> > every side data we support can be generated by something otherwise
> 
> Like what? You're not answering, just spouting confused stuff. What
> kind of reply is this? 
> 
> > we wouldnt have that side data type
> 
> 

This is very basic really but lets elaborate
for each side data type T
possiblity A
nothing uses side data type T

possiblity B
something uses side data type T


Its the same with a codec, either a codec is used in some case or
its used in no case.

If something is used in no case then it has been eliminated as you
describe.
If somehing is still used in a case it has not been eliminated

If as you describe side data has been eliminated then you could
remove side data as a whole from the source code.

If you cannot remove side data or a specific side data type from
the source code then it has not been eliminated

your change removes one way for an attacker to set side data but
by the fact that you dont remove any of the side data types its
clear you are aware of that every is still in use in some code path.

a attacker may need to use a specific container format to set a
specific side data type or may depend on a specific demuxer lib or
application that allows him to set a side data type.

now if you remove every way to set side data for an attacker then
you can remove that side data type as a whole from the code.
Of course that removes whatever the side data is for.

Let me provide a specific example
If a container suports changing extradata mid stream it will either
be support or not.
if any demuxer supports it then you have not eliminated the possiblity
for an attacker

I hope writing a elaborate reply will not lead to this discussion
to shift onto some unrelated detail


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

While the State exists there can be no freedom; when there is freedom there
will be no State. -- 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] fate: Do not report side data size

[Nicolas George]

Le nonidi 19 ventôse, an CCXXV, Michael Niedermayer a écrit :
> it is a property of the file in multiple cases
> 
> through the split side data code but even if this is removed
> for example
> AV_PKT_DATA_NEW_EXTRADATA is just binary data from the file the
> length is from the file
> 
> or AV_PKT_DATA_STRINGS_METADATA, which are multiple zero terminated
> strings
> 
> and there is AV_PKT_DATA_MATROSKA_BLOCKADDITIONAL which again is
> basically binary data and length from the file
> 
> If you remove displaying the size based on the argumnet that it
> ideally should be the sizeof of a struct and thus should not be
> printed.
> Then that change should be limited to the cases where this
> argumnet applies

No, this is taking it the wrong way. Side data size being relevant is
the exception, not the rule. Even for AV_PKT_DATA_STRINGS_METADATA, it
is not the relevant information.

Treating it as the rule and not the exception is exactly what lead us to
this problem, and will cause still more maintainability problems in the
future.

The only sane way to go is to remove it now altogether, and only then
add back printing relevant information for specific kinds of side data.

Regards,

-- 
  Nicolas George


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

[FFmpeg-devel] [PATCH 0/2] lavc/libfdk-aacenc: VBR check message fix

[Moritz Barsnick]

This patch (series) adjusts the message of the vbr option check to
be clear about that it's making an adjustment of the option value.

The second patch is just an extremely minor style fix.

I am under the impression that Martin Storsjö  is
maintaining the libfdk_aac wrapper, but primarily on "libav". He is
listed in MAINTAINERS, but not for libfdk_aac. I'm not sure whether
he monitors this list though. This is of interest to me as I have
another change to propose...

Moritz Barsnick (2):
  lavc/libfdk-aacenc: make message clearer about action taken
  lavc/libfdk-aacenc: fix whitespace

 libavcodec/libfdk-aacenc.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

-- 
2.9.3

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

[FFmpeg-devel] [PATCH 2/2] lavc/libfdk-aacenc: fix whitespace

[Moritz Barsnick]

Signed-off-by: Moritz Barsnick 
---
 libavcodec/libfdk-aacenc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/libfdk-aacenc.c b/libavcodec/libfdk-aacenc.c
index 5f84fb2..2504b84 100644
--- a/libavcodec/libfdk-aacenc.c
+++ b/libavcodec/libfdk-aacenc.c
@@ -186,7 +186,7 @@ static av_cold int aac_encode_init(AVCodecContext *avctx)
 
 if (avctx->flags & AV_CODEC_FLAG_QSCALE || s->vbr) {
 int modenew, mode = s->vbr ? s->vbr : avctx->global_quality;
-if (mode <  1 || mode > 5) {
+if (mode < 1 || mode > 5) {
 modenew = av_clip(mode, 1, 5);
 av_log(avctx, AV_LOG_WARNING,
"VBR quality %d is out of range, should be 1-5, using 
%d\n", mode, modenew);
-- 
2.9.3

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

[FFmpeg-devel] [PATCH 1/2] lavc/libfdk-aacenc: make message clearer about action taken

[Moritz Barsnick]

A user option is being checked and adjusted, don't just warn about
about the failed range check, but also mention the adjustment.

Signed-off-by: Moritz Barsnick 
---
 libavcodec/libfdk-aacenc.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/libavcodec/libfdk-aacenc.c b/libavcodec/libfdk-aacenc.c
index 98a817b..5f84fb2 100644
--- a/libavcodec/libfdk-aacenc.c
+++ b/libavcodec/libfdk-aacenc.c
@@ -185,11 +185,12 @@ static av_cold int aac_encode_init(AVCodecContext *avctx)
 }
 
 if (avctx->flags & AV_CODEC_FLAG_QSCALE || s->vbr) {
-int mode = s->vbr ? s->vbr : avctx->global_quality;
+int modenew, mode = s->vbr ? s->vbr : avctx->global_quality;
 if (mode <  1 || mode > 5) {
+modenew = av_clip(mode, 1, 5);
 av_log(avctx, AV_LOG_WARNING,
-   "VBR quality %d out of range, should be 1-5\n", mode);
-mode = av_clip(mode, 1, 5);
+   "VBR quality %d is out of range, should be 1-5, using 
%d\n", mode, modenew);
+mode = modenew;
 }
 av_log(avctx, AV_LOG_WARNING,
"Note, the VBR setting is unsupported and only works with "
-- 
2.9.3

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

[FFmpeg-devel] [PATCH] avfilter: support for output samplerate fallbacking

[Takayuki 'January June' Suwa]

Thank you for reviewing @ #2781.

> I do not think this option should be global.

I agree that public global options should not be added (or removed :)
w/o discussion.

> Possibly, the good solution may be to extend the "sws_flags=" feature
> to allow to set more graph options from the graph description.

There are some reasons why I chose to add new ones to the AVFilter
context but not to extend the "swr_flags=",

1. The function swap_samplerates_on_filter() in avfiltergraph.c receives
   a pointer to AVFilterContext

2. Less elegant to pack a single value of the existing option with
   additional bit-chunks

But prepending of explicit aresample will be required because of
auto-inserted one cannot be received the info.

  -af "aresample=osr_fallback_method=highest,aformat=sample_rates=..."

> I would rather not have the numeric values of the option exposed to the
> user, only symbolic constants.

> Re-aligning other lines is normally done in a separate patch, if ever.

> I think this shoulw be "case 0" (except see below) and default should
> trigger an assert failure.

> Magic constants like that are not good design, they need to be expressed
> by an enum.

> Jumping from one case clause to another does not look like an acceptable
> use of goto in readable code.

Worth obeying :)

Finally, it's obvious "osr_fallback_method" is lengthy and ugly :(
Please suggest more concise and plain alternatives.
---
 libavfilter/avfilter.c  |  6 ++
 libavfilter/avfilter.h  | 11 +++
 libavfilter/avfiltergraph.c | 27 ++-
 3 files changed, 43 insertions(+), 1 deletion(-)

diff --git a/libavfilter/avfilter.c b/libavfilter/avfilter.c
index b431990..0d467ec 100644
--- a/libavfilter/avfilter.c
+++ b/libavfilter/avfilter.c
@@ -665,6 +665,12 @@ static const AVOption avfilter_options[] = {
 { "enable", "set enable expression", OFFSET(enable_str), 
AV_OPT_TYPE_STRING, {.str=NULL}, .flags = FLAGS },
 { "threads", "Allowed number of threads", OFFSET(nb_threads), 
AV_OPT_TYPE_INT,
 { .i64 = 0 }, 0, INT_MAX, FLAGS },
+{ "osr_fallback_method", "Output sample rate fallback method when no exact 
match found", OFFSET(osr_fallback_method), AV_OPT_TYPE_INT,
+{ .i64 = AVOSRFB_CLOSEST }, AVOSRFB_CLOSEST, AVOSRFB_HIGHEST, FLAGS, 
"osr_fallback_method" },
+{ "closest", "to the closest one, regardless of higher or lower", 0, 
AV_OPT_TYPE_CONST, { .i64 = AVOSRFB_CLOSEST }, 0, 0, FLAGS, 
"osr_fallback_method" },
+{ "higher", "to the closest higher one", 0, AV_OPT_TYPE_CONST, { .i64 
= AVOSRFB_HIGHER }, 0, 0, FLAGS, "osr_fallback_method" },
+{ "twice_higher", "to the closest twice higher one", 0, 
AV_OPT_TYPE_CONST, { .i64 = AVOSRFB_TWICE_HIGHER }, 0, 0, FLAGS, 
"osr_fallback_method" },
+{ "highest", "to the highest one", 0, AV_OPT_TYPE_CONST, { .i64 = 
AVOSRFB_HIGHEST }, 0, 0, FLAGS, "osr_fallback_method" },
 { NULL },
 };
 
diff --git a/libavfilter/avfilter.h b/libavfilter/avfilter.h
index b56615c..3eb455f 100644
--- a/libavfilter/avfilter.h
+++ b/libavfilter/avfilter.h
@@ -384,6 +384,17 @@ struct AVFilterContext {
 int nb_threads;
 
 /**
+ * Output sample rate fallback method when no exact match found in the next
+ * filter's available input sample rates.
+ */
+enum {
+AVOSRFB_CLOSEST = 0,   ///< to the closest one, regardless of higher 
or lower
+AVOSRFB_HIGHER,///< to the closest higher one
+AVOSRFB_TWICE_HIGHER,  ///< to the closest twice higher one
+AVOSRFB_HIGHEST,   ///< to the highest one
+} osr_fallback_method;
+
+/**
  * Ready status of the filter.
  * A non-0 value means that the filter needs activating;
  * a higher value suggests a more urgent activation.
diff --git a/libavfilter/avfiltergraph.c b/libavfilter/avfiltergraph.c
index 534c670..0f193ec 100644
--- a/libavfilter/avfiltergraph.c
+++ b/libavfilter/avfiltergraph.c
@@ -874,7 +874,32 @@ static void swap_samplerates_on_filter(AVFilterContext 
*filter)
 continue;
 
 for (j = 0; j < outlink->in_samplerates->nb_formats; j++) {
-int diff = abs(sample_rate - outlink->in_samplerates->formats[j]);
+int diff;
+switch(filter->osr_fallback_method) {
+case AVOSRFB_CLOSEST:
+diff = abs(sample_rate - outlink->in_samplerates->formats[j]);
+break;
+case AVOSRFB_HIGHER:
+if ((diff = outlink->in_samplerates->formats[j] - sample_rate) 
>= 0)
+break;
+diff = INT_MAX - outlink->in_samplerates->formats[j];
+break;
+case AVOSRFB_TWICE_HIGHER:
+if ((diff = outlink->in_samplerates->formats[j] - sample_rate) 
== 0)
+break;
+if ((diff = outlink->in_samplerates->formats[j] - sample_rate 
* 2) >= 0)
+break;
+diff = INT_MAX - 

[FFmpeg-devel] [PATCH] libavfilter/avf_showwaves: make sqrt and cbrt scale option values available to showwavespic by name

[Moritz Barsnick]

The 'sqrt' and 'cbrt' scalers were added in commit
80262d8c86e94ff9a4bb3a9e3c2d734e04ccb399, but their symbolic option values
only made available to the showwaves filter, not showwavespic, despite
the scalers working properly by their numerical option values.

Signed-off-by: Moritz Barsnick 
---
 doc/filters.texi| 18 +-
 libavfilter/avf_showwaves.c |  2 ++
 2 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index b5265d9..192a81a 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -17897,7 +17897,23 @@ Set if channels should be drawn separately or overlap. 
Default value is 0.
 Set colors separated by '|' which are going to be used for drawing of each 
channel.
 
 @item scale
-Set amplitude scale. Can be linear @code{lin} or logarithmic @code{log}.
+Set amplitude scale.
+
+Available values are:
+@table @samp
+@item lin
+Linear.
+
+@item log
+Logarithmic.
+
+@item sqrt
+Square root.
+
+@item cbrt
+Cubic root.
+@end table
+
 Default is linear.
 @end table
 
diff --git a/libavfilter/avf_showwaves.c b/libavfilter/avf_showwaves.c
index 05aa995..aadc5c1 100644
--- a/libavfilter/avf_showwaves.c
+++ b/libavfilter/avf_showwaves.c
@@ -676,6 +676,8 @@ static const AVOption showwavespic_options[] = {
 { "scale", "set amplitude scale", OFFSET(scale), AV_OPT_TYPE_INT, {.i64 = 
0 }, 0, SCALE_NB-1, FLAGS, .unit="scale" },
 { "lin", "linear", 0, AV_OPT_TYPE_CONST, {.i64=SCALE_LIN}, 
.flags=FLAGS, .unit="scale"},
 { "log", "logarithmic",0, AV_OPT_TYPE_CONST, {.i64=SCALE_LOG}, 
.flags=FLAGS, .unit="scale"},
+{ "sqrt", "square root",   0, AV_OPT_TYPE_CONST, {.i64=SCALE_SQRT}, 
.flags=FLAGS, .unit="scale"},
+{ "cbrt", "cubic root",0, AV_OPT_TYPE_CONST, {.i64=SCALE_CBRT}, 
.flags=FLAGS, .unit="scale"},
 { NULL }
 };
 
-- 
2.9.3

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

Re: [FFmpeg-devel] [PATCH 3/3] avformat: don't "merge" side data into packet data by default

[wm4]

On Wed, 8 Mar 2017 15:44:36 +0100
Michael Niedermayer  wrote:

> On Wed, Mar 08, 2017 at 01:40:12PM +0100, wm4 wrote:
> > Side data are separate AVPacket fields for a reason. Merging side data
> > requires reallocating all packets, is complex, potentially clashes with
> > "actual" packet data (you could probably come up with PCM data that
> > looks like merged side data, or such), and could for example cause
> > trouble to people trying to feed packets with merged side data to
> > non-libavcodec decoders.
> > 
> > Disable it by default.
> > 
> > I do not consider this a real API change, because the AVPacket side data
> > fields have been part of the API for at least a decade.
> > 
> > The changed tests either reflect added packet side data, or the changed
> > packet size due to merged side data removal reducing the packet size.
> > 
> > ---  
> 
> > Missing: minor libavformat API bump, maybe a warning in APIchanges  
> 
> this is a ABI change and cannot be done before the next
> major version bump
> 
> Applications did not need to preserve side data between layers and
> this patch would add this requirement
> 
> The change of the default could be done conditional on the major
> version or related API/ABI define

So what's the status on this? I consider it a bug fix, not an API
change.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/3] aacdec: do not mutate input packet metadata

[wm4]

On Wed, 8 Mar 2017 14:28:33 +0100
Michael Niedermayer  wrote:

> On Wed, Mar 08, 2017 at 01:40:10PM +0100, wm4 wrote:
> > Apparently the demuxer outputs the wrong padding for HE-AAC (based on
> > the raw sample rate, or so). aacdec contains a hack to adjust the muxer
> > padding accordingly before it's used to trim the decoder output. This
> > modified the packet side data, which in combination with the old
> > decoding API would change the packet the user passed to the decoder.
> > This is clearly not allowed, and it breaks running some gapless fate
> > tests with "-fflags +keepside" applied (without keepside, the packet
> > metadata is typically newly allocated, essentially making a copy and not
> > modifying the user's input packet).
> > 
> > This should probably be fixed in the demuxer (and consequently also the
> > muxer), but for now only fix the immediate problem.
> > 
> > Regression since 946ed78f5f8 (2012).
> > ---
> >  libavcodec/aacdec_template.c | 8 ++--
> >  libavcodec/internal.h| 2 ++
> >  libavcodec/utils.c   | 4 +++-
> >  3 files changed, 7 insertions(+), 7 deletions(-)  
> 
> this patch LGTM
> 

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

[FFmpeg-devel] [PATCH] ffprobe: add AVCodecContext help message into ffprobe

[Steven Liu]

because the ffprobe can use AVCodecContext parameters

Signed-off-by: Steven Liu 
---
 ffprobe.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/ffprobe.c b/ffprobe.c
index c85c3a1..b104390 100644
--- a/ffprobe.c
+++ b/ffprobe.c
@@ -3004,6 +3004,7 @@ void show_help_default(const char *opt, const char *arg)
 printf("\n");
 
 show_help_children(avformat_get_class(), AV_OPT_FLAG_DECODING_PARAM);
+show_help_children(avcodec_get_class(), AV_OPT_FLAG_DECODING_PARAM);
 }
 
 /**
-- 
2.10.1.382.ga23ca1b.dirty



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

Re: [FFmpeg-devel] [PATCH] ffprobe: add show_video_keyframes option

[Steven Liu]

2017-03-09 15:51 GMT+08:00 wm4 :

> On Thu,  9 Mar 2017 15:43:21 +0800
> Steven Liu  wrote:
>
> > add a option for show video keyframes info only when use show_packets
> > or show_frames
> >
> > Signed-off-by: Steven Liu 
> > ---
> >  ffprobe.c | 14 ++
> >  1 file changed, 14 insertions(+)
> >
> > diff --git a/ffprobe.c b/ffprobe.c
> > index c85c3a1..3beceb2 100644
> > --- a/ffprobe.c
> > +++ b/ffprobe.c
> > @@ -81,6 +81,7 @@ static int do_show_programs = 0;
> >  static int do_show_streams = 0;
> >  static int do_show_stream_disposition = 0;
> >  static int do_show_data= 0;
> > +static int do_show_video_keyframes  = 0;
> >  static int do_show_program_version  = 0;
> >  static int do_show_library_versions = 0;
> >  static int do_show_pixel_formats = 0;
> > @@ -1820,6 +1821,12 @@ static void show_packet(WriterContext *w,
> InputFile *ifile, AVPacket *pkt, int p
> >  AVBPrint pbuf;
> >  const char *s;
> >
> > +if (do_show_video_keyframes) {
> > +if ((st->codecpar->codec_type != AVMEDIA_TYPE_VIDEO) ||
> !(pkt->flags & AV_PKT_FLAG_KEY)) {
> > +return;
> > +}
> > +}
> > +
> >  av_bprint_init(, 1, AV_BPRINT_SIZE_UNLIMITED);
> >
> >  writer_print_section_header(w, SECTION_ID_PACKET);
> > @@ -1899,6 +1906,12 @@ static void show_frame(WriterContext *w, AVFrame
> *frame, AVStream *stream,
> >  const char *s;
> >  int i;
> >
> > +if (do_show_video_keyframes) {
> > +if ((stream->codecpar->codec_type != AVMEDIA_TYPE_VIDEO) ||
> !(frame->key_frame)) {
> > +return;
> > +}
> > +}
> > +
> >  av_bprint_init(, 1, AV_BPRINT_SIZE_UNLIMITED);
> >
> >  writer_print_section_header(w, SECTION_ID_FRAME);
> > @@ -3225,6 +3238,7 @@ static const OptionDef real_options[] = {
> >  { "select_streams", OPT_STRING | HAS_ARG,
> {(void*)_specifier}, "select the specified streams",
> "stream_specifier" },
> >  { "sections", OPT_EXIT, {.func_arg = opt_sections}, "print sections
> structure and section information, and exit" },
> >  { "show_data",OPT_BOOL, {(void*)_show_data}, "show packets
> data" },
> > +{ "show_video_keyframes",OPT_BOOL, 
> > {(void*)_show_video_keyframes},
> "show video keyframes info only" },
> >  { "show_data_hash", OPT_STRING | HAS_ARG, {(void*)_data_hash},
> "show packets data hash" },
> >  { "show_error",   0, {(void*)_show_error},  "show probing
> error" },
> >  { "show_format",  0, {(void*)_show_format}, "show
> format/container info" },
>
> Possibly redundant with -skip_frame nokey (not sure how codec dependent
> that option is).
>

I saw there have no AVCodecContext help message in ffprobe --help
What about add AVCodecContext help message into ffprobe?

> ___
> 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