Re: [FFmpeg-devel] [PATCH 1/2] ffmpeg.c can not process invalid PTS

[朱世奇]

diff --git a/ffmpeg.c b/ffmpeg.c
index f91fb7b..844a03c 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -3864,6 +3864,11 @@ static int process_input(int file_index)
 if (pkt.dts != AV_NOPTS_VALUE)
 pkt.dts *= ist->ts_scale;
 
+if (pkt.pts == AV_NOPTS_VALUE)
+pkt.pts = av_rescale_q(ist->next_pts, AV_TIME_BASE_Q, 
ist->st->time_base);
+if (pkt.dts == AV_NOPTS_VALUE)
+pkt.dts = av_rescale_q(ist->next_dts, AV_TIME_BASE_Q, 
ist->st->time_base);
+
 if ((ist->dec_ctx->codec_type == AVMEDIA_TYPE_VIDEO ||
  ist->dec_ctx->codec_type == AVMEDIA_TYPE_AUDIO) &&
 pkt.dts != AV_NOPTS_VALUE && ist->next_dts == AV_NOPTS_VALUE && 
!copy_ts


==
New patch

At 2015-10-30 10:08:43, "hiccupzhu"  wrote:
>diff --git a/ffmpeg.c b/ffmpeg.c
>index f91fb7b..22766b3 100644
>--- a/ffmpeg.c
>+++ b/ffmpeg.c
>@@ -3864,6 +3864,9 @@ static int process_input(int file_index)
> if (pkt.dts != AV_NOPTS_VALUE)
> pkt.dts *= ist->ts_scale;
> 
>+if(pkt.pts == AV_NOPTS_VALUE)
>+pkt.pts = ist->next_pts;
>+
> if ((ist->dec_ctx->codec_type == AVMEDIA_TYPE_VIDEO ||
>  ist->dec_ctx->codec_type == AVMEDIA_TYPE_AUDIO) &&
> pkt.dts != AV_NOPTS_VALUE && ist->next_dts == AV_NOPTS_VALUE && 
> !copy_ts
>
>
>Explanation:
>In function "process_input" ffmpeg just handle "pts != AV_NOPTS_VALUE", but 
>not handle "pts == AV_NOPTS_VALUE".Now I fixed it. 
>if ( current_pts == AV_NOPTS_VALUE) {
>current_pts  = predicted_pts;
>}
>
>
>Reproduce:
>1. Download test file http://pan.baidu.com/s/1eQsb9hK;
>2. Run command below:
>ffmpeg -i ./manga.01.ts -vcodec copy -bsf:v h264_mp4toannexb -hls_list_size 0 
>-hls_segment_filename "test_%04d.ts" playlist.m3u8
>3. If the bug not fixed, the HLS slice just one; Then fix the bug, HLS' slice 
>is normally.
>
>
>
>
>
>
> 
>___
>ffmpeg-devel mailing list
>ffmpeg-devel@ffmpeg.org
>http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/showcqt: fix dependency with avformat

[Michael Niedermayer]

On Fri, Oct 30, 2015 at 11:57:10PM +0700, Muhammad Faiz wrote:
> patch attached

>  configure|2 +-
>  libavfilter/Makefile |2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 10867dc567823f25a5cef17a30f5f8e60eaccc07  
> 0001-avfilter-showcqt-fix-dependency-with-avformat.patch
> From 1902fc28da0b7d03e0f329397691006f9b432079 Mon Sep 17 00:00:00 2001
> From: Muhammad Faiz 
> Date: Fri, 30 Oct 2015 23:35:02 +0700
> Subject: [PATCH] avfilter/showcqt: fix dependency with avformat

applied

thx

[...]

-- 
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] avfilter/vf_deshake: replace qsort with AV_QSORT

[Ganesh Ajjanagadde]

qsort is called indirectly in filter_frame, suggesting its performance
criticality. AV_QSORT is substantially faster due to the inlining of the
comparison callback. Thus, the increase in performance should be worth
the increase in binary size.

Sample benchmark (x86-64, Haswell, GNU/Linux):
File: original from https://trac.ffmpeg.org/ticket/1430
command: ffmpeg -stream_loop 8 -i file.webm -vf deshake=rx=64:ry=64 -f null -

Timer truncated at 1024 runs.
new:
28260 decicycles in qsort,   1 runs,  0 skips
35570 decicycles in qsort,   2 runs,  0 skips
39010 decicycles in qsort,   4 runs,  0 skips
46897 decicycles in qsort,   8 runs,  0 skips
40442 decicycles in qsort,  16 runs,  0 skips
41611 decicycles in qsort,  32 runs,  0 skips
40345 decicycles in qsort,  64 runs,  0 skips
38967 decicycles in qsort, 128 runs,  0 skips
38647 decicycles in qsort, 256 runs,  0 skips
40238 decicycles in qsort, 512 runs,  0 skips
39676 decicycles in qsort,1024 runs,  0 skips

old:
1740280 decicycles in qsort,   1 runs,  0 skips
 923560 decicycles in qsort,   2 runs,  0 skips
 511330 decicycles in qsort,   4 runs,  0 skips
 309720 decicycles in qsort,   8 runs,  0 skips
 194900 decicycles in qsort,  16 runs,  0 skips
 142686 decicycles in qsort,  32 runs,  0 skips
 112516 decicycles in qsort,  64 runs,  0 skips
  98166 decicycles in qsort, 128 runs,  0 skips
  88147 decicycles in qsort, 256 runs,  0 skips
  88706 decicycles in qsort, 512 runs,  0 skips
  86783 decicycles in qsort,1024 runs,  0 skips

Signed-off-by: Ganesh Ajjanagadde 
---
 libavfilter/vf_deshake.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavfilter/vf_deshake.c b/libavfilter/vf_deshake.c
index 885569a..e32436d 100644
--- a/libavfilter/vf_deshake.c
+++ b/libavfilter/vf_deshake.c
@@ -57,6 +57,7 @@
 #include "libavutil/mem.h"
 #include "libavutil/opt.h"
 #include "libavutil/pixdesc.h"
+#include "libavutil/qsort.h"
 
 #include "deshake.h"
 #include "deshake_opencl.h"
@@ -106,7 +107,7 @@ static double clean_mean(double *values, int count)
 int cut = count / 5;
 int x;
 
-qsort(values, count, sizeof(double), cmp);
+AV_QSORT(values, count, double, cmp);
 
 for (x = cut; x < count - cut; x++) {
 mean += values[x];
-- 
2.6.2

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

Re: [FFmpeg-devel] [PATCH] configure+libm.h: add fmin/fmax/fminf/fmaxf emulation

[Hendrik Leppkes]

On Fri, Oct 30, 2015 at 11:35 PM, Michael Niedermayer  wrote:
> From: Michael Niedermayer 
>
> This should fix the build failure of avf_showcqt.c
>
> An alternative solution would be to add a check for fmin/fmax to fate-source 
> and
> then to replace them by FFMIN/FFMAX, i can do that if preferred?
>
> Untested due to lack of a affected platform
>
> Signed-off-by: Michael Niedermayer 
> ---
>  configure|8 
>  libavutil/libm.h |   28 
>  2 files changed, 36 insertions(+)
>
> diff --git a/configure b/configure
> index 95790f4..e6f5d2c 100755
> --- a/configure
> +++ b/configure
> @@ -1770,6 +1770,10 @@ MATH_FUNCS="
>  exp2
>  exp2f
>  expf
> +fmax
> +fmaxf
> +fmin
> +fminf
>  isinf
>  isnan
>  ldexpf
> @@ -5304,6 +5308,10 @@ check_lib math.h sin -lm && LIBM="-lm"
>  disabled crystalhd || check_lib libcrystalhd/libcrystalhd_if.h 
> DtsCrystalHDVersion -lcrystalhd || disable crystalhd
>
>  atan2f_args=2
> +fmax_args=2
> +fmaxf_args=2
> +fmin_args=2
> +fminf_args=2
>  copysign_args=2
>  ldexpf_args=2
>  powf_args=2
> diff --git a/libavutil/libm.h b/libavutil/libm.h
> index 6c17b28..ba837a2 100644
> --- a/libavutil/libm.h
> +++ b/libavutil/libm.h
> @@ -43,6 +43,34 @@
>  #define atan2f(y, x) ((float)atan2(y, x))
>  #endif
>
> +#if !HAVE_FMAX
> +#undef fmax
> +static av_always_inline double fmax(double x, double y)
> +{
> +if (x < y) return y;
> +else   return x;
> +}
> +#endif
> +
> +#if !HAVE_FMIN
> +#undef fmin
> +static av_always_inline double fmin(double x, double y)
> +{
> +if (x < y) return x;
> +else   return y;
> +}
> +#endif

Wasn't there a concern that these emulations don't behave identical to
the C library versions in regards to NaN handling?
I faintly remember something in the previous discussion.

> +
> +#if !HAVE_FMAXF
> +#undef fmaxf
> +#define fmaxf(y, x) ((float)fmax(y, x))
> +#endif
> +
> +#if !HAVE_FMINF
> +#undef fminf
> +#define fminf(y, x) ((float)fmin(y, x))
> +#endif
> +
>  #if !HAVE_POWF
>  #undef powf
>  #define powf(x, y) ((float)pow(x, y))
> --
> 1.7.9.5
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] configure+libm.h: add fmin/fmax/fminf/fmaxf emulation

[Michael Niedermayer]

On Sat, Oct 31, 2015 at 12:14:44AM +0100, Hendrik Leppkes wrote:
> On Fri, Oct 30, 2015 at 11:35 PM, Michael Niedermayer  
> wrote:
> > From: Michael Niedermayer 
> >
> > This should fix the build failure of avf_showcqt.c
> >
> > An alternative solution would be to add a check for fmin/fmax to 
> > fate-source and
> > then to replace them by FFMIN/FFMAX, i can do that if preferred?
> >
> > Untested due to lack of a affected platform
> >
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  configure|8 
> >  libavutil/libm.h |   28 
> >  2 files changed, 36 insertions(+)
> >
> > diff --git a/configure b/configure
> > index 95790f4..e6f5d2c 100755
> > --- a/configure
> > +++ b/configure
> > @@ -1770,6 +1770,10 @@ MATH_FUNCS="
> >  exp2
> >  exp2f
> >  expf
> > +fmax
> > +fmaxf
> > +fmin
> > +fminf
> >  isinf
> >  isnan
> >  ldexpf
> > @@ -5304,6 +5308,10 @@ check_lib math.h sin -lm && LIBM="-lm"
> >  disabled crystalhd || check_lib libcrystalhd/libcrystalhd_if.h 
> > DtsCrystalHDVersion -lcrystalhd || disable crystalhd
> >
> >  atan2f_args=2
> > +fmax_args=2
> > +fmaxf_args=2
> > +fmin_args=2
> > +fminf_args=2
> >  copysign_args=2
> >  ldexpf_args=2
> >  powf_args=2
> > diff --git a/libavutil/libm.h b/libavutil/libm.h
> > index 6c17b28..ba837a2 100644
> > --- a/libavutil/libm.h
> > +++ b/libavutil/libm.h
> > @@ -43,6 +43,34 @@
> >  #define atan2f(y, x) ((float)atan2(y, x))
> >  #endif
> >
> > +#if !HAVE_FMAX
> > +#undef fmax
> > +static av_always_inline double fmax(double x, double y)
> > +{
> > +if (x < y) return y;
> > +else   return x;
> > +}
> > +#endif
> > +
> > +#if !HAVE_FMIN
> > +#undef fmin
> > +static av_always_inline double fmin(double x, double y)
> > +{
> > +if (x < y) return x;
> > +else   return y;
> > +}
> > +#endif
> 
> Wasn't there a concern that these emulations don't behave identical to
> the C library versions in regards to NaN handling?
> I faintly remember something in the previous discussion.

yes, i forgot about that :(
i replaced them by FFMIN / FFMAX

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

Those who are best at talking, realize last or never when they are wrong.


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

Re: [FFmpeg-devel] [PATCH] avfilter/avf_showcqt: rewrite showcqt and add features

[Michael Niedermayer]

On Thu, Oct 29, 2015 at 02:05:53AM -0300, James Almer wrote:
> On 10/27/2015 9:56 PM, Michael Niedermayer wrote:
> > On Mon, Oct 26, 2015 at 12:32:58AM +0700, Muhammad Faiz wrote:
> >> On Sun, Oct 25, 2015 at 9:51 AM, Michael Niedermayer
> >>  wrote:
> >>> On Sun, Oct 25, 2015 at 08:43:07AM +0700, Muhammad Faiz wrote:
>   doc/filters.texi  |  181 +++--
>   libavfilter/avf_showcqt.c | 1546 
>  +++---
>   libavfilter/avf_showcqt.h |  104 +++
>   libavfilter/version.h |2
>   4 files changed, 1294 insertions(+), 539 deletions(-)
>  3f83a0d334d780da3defa7d1fa3f09b3beb1db2d  
>  0001-avfilter-avf_showcqt-rewrite-showcqt-and-add-feature.patch
>  From 337a659f96ef5dcf87aad1d541e745b7c262cbb9 Mon Sep 17 00:00:00 2001
>  From: Muhammad Faiz 
>  Date: Sat, 24 Oct 2015 00:44:42 +0700
>  Subject: [PATCH] avfilter/avf_showcqt: rewrite showcqt and add features
> >>>
> >>> this fails to build on "arm-linux-gnueabi-gcc-4.5 (Ubuntu/Linaro 
> >>> 4.5.3-12ubuntu2) 4.5.3"
> >>> In file included from ffmpeg/libavfilter/avf_showcqt.c:41:0:
> >>> ffmpeg/libavfilter/avf_showcqt.h:39:30: warning: declaration does not 
> >>> declare anything
> >>> ffmpeg/libavfilter/avf_showcqt.h:40:30: warning: declaration does not 
> >>> declare anything
> >>> ffmpeg/libavfilter/avf_showcqt.c: In function ‘rgb_from_cqt’:
> >>> ffmpeg/libavfilter/avf_showcqt.c:668:13: error: ‘ColorFloat’ has no 
> >>> member named ‘r’
> >>> ffmpeg/libavfilter/avf_showcqt.c:669:13: error: ‘ColorFloat’ has no 
> >>> member named ‘g’
> >>> ffmpeg/libavfilter/avf_showcqt.c:670:13: error: ‘ColorFloat’ has no 
> >>> member named ‘b’
> >>> ffmpeg/libavfilter/avf_showcqt.c: In function ‘yuv_from_cqt’:
> >>> ffmpeg/libavfilter/avf_showcqt.c:682:13: error: ‘ColorFloat’ has no 
> >>> member named ‘y’
> >>> ffmpeg/libavfilter/avf_showcqt.c:683:13: error: ‘ColorFloat’ has no 
> >>> member named ‘u’
> >>> ffmpeg/libavfilter/avf_showcqt.c:684:13: error: ‘ColorFloat’ has no 
> >>> member named ‘v’
> >>
> >>
> >> revision: do not use anonymous struct, it seems it is not supported on
> >> some platforms
> >>
> >> thanks
> > 
> >>  doc/filters.texi  |  181 +++--
> >>  libavfilter/avf_showcqt.c | 1546 
> >> +++---
> >>  libavfilter/avf_showcqt.h |  112 +++
> >>  libavfilter/version.h |2 
> >>  4 files changed, 1302 insertions(+), 539 deletions(-)
> >> be583ed02fc82b34612c9c1782955795fb8b4259  
> >> 0001-avfilter-avf_showcqt-rewrite-showcqt-and-add-feature.patch
> >> From e6d6243e03439cffd2d58e30d9892c18e2ef0bc4 Mon Sep 17 00:00:00 2001
> >> From: Muhammad Faiz 
> >> Date: Mon, 26 Oct 2015 00:18:41 +0700
> >> Subject: [PATCH] avfilter/avf_showcqt: rewrite showcqt and add features
> >>
> >> add yuv444p, yuv422p, and yuv420p output format (lower cpu usage
> >> on ffplay playback because it does not do format conversion)
> >> custom size with size/s option (fullhd option is deprecated)
> >> custom layout with bar_h, axis_h, and sono_h option
> >> support rational frame rate (within fps/r/rate option)
> >> relaxed frame rate restriction (support fractional sample step)
> >> support all input sample rates
> >> separate sonogram and bargraph volume (with volume/sono_v and
> >> volume2/bar_v)
> >> timeclamp option alias (timeclamp/tc)
> >> fcount option
> >> gamma option alias (gamma/sono_g and gamma2/bar_g)
> >> support custom frequency range (basefreq and endfreq)
> >> support drawing axis using external image file (axisfile option)
> >> alias for disabling drawing to axis (text/axis)
> >> possibility to optimize it using arch specific asm code
> >> ---
> >>  doc/filters.texi  |  181 --
> >>  libavfilter/avf_showcqt.c | 1546 
> >> +++--
> >>  libavfilter/avf_showcqt.h |  112 
> >>  libavfilter/version.h |2 +-
> >>  4 files changed, 1302 insertions(+), 539 deletions(-)
> >>  create mode 100644 libavfilter/avf_showcqt.h
> > 
> > applied
> > 
> > thanks
> 
> C:/Dev/ffmpeg/fate/x86_32-msvc2012/src/libavfilter/avf_showcqt.c(316) : error 
> C4013: 'fmax' undefined; assuming extern returning int
> C:/Dev/ffmpeg/fate/x86_32-msvc2012/src/libavfilter/avf_showcqt.c(317) : error 
> C4013: 'fmin' undefined; assuming extern returning int
> C:/Dev/ffmpeg/fate/x86_32-msvc2012/src/libavfilter/avf_showcqt.c(668) : error 
> C4013: 'fminf' undefined; assuming extern returning int
> 
> If these can't be replaced with FFMIN/FFMAX then maybe a fallback version 
> should
> be added to libavutil/libm.h

posted a patch that would attempt that

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

If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.


signature.asc
Description: Digital signature

Re: [FFmpeg-devel] [PATCH] configure+libm.h: add fmin/fmax/fminf/fmaxf emulation

[Ganesh Ajjanagadde]

On Fri, Oct 30, 2015 at 6:35 PM, Michael Niedermayer  wrote:
> From: Michael Niedermayer 
>
> This should fix the build failure of avf_showcqt.c
>
> An alternative solution would be to add a check for fmin/fmax to fate-source 
> and
> then to replace them by FFMIN/FFMAX, i can do that if preferred?
>
> Untested due to lack of a affected platform

I recall some interest on my end to get fmin, fmax etc for different
reasons, and it was remarked that commit
4436a8f44dedc83767b3d9da9beb85d1fae2ca30 may be relevant. The summary
seems to be that getting it to work on all platforms is not so simple.
I am definitely interested in getting it to work in order to replace
FFMAX/FFMIN for floating point in especially libavfilter. This will
allow better nan signalling at a slight performance cost.

>
> Signed-off-by: Michael Niedermayer 
> ---
>  configure|8 
>  libavutil/libm.h |   28 
>  2 files changed, 36 insertions(+)
>
> diff --git a/configure b/configure
> index 95790f4..e6f5d2c 100755
> --- a/configure
> +++ b/configure
> @@ -1770,6 +1770,10 @@ MATH_FUNCS="
>  exp2
>  exp2f
>  expf
> +fmax
> +fmaxf
> +fmin
> +fminf
>  isinf
>  isnan
>  ldexpf
> @@ -5304,6 +5308,10 @@ check_lib math.h sin -lm && LIBM="-lm"
>  disabled crystalhd || check_lib libcrystalhd/libcrystalhd_if.h 
> DtsCrystalHDVersion -lcrystalhd || disable crystalhd
>
>  atan2f_args=2
> +fmax_args=2
> +fmaxf_args=2
> +fmin_args=2
> +fminf_args=2
>  copysign_args=2
>  ldexpf_args=2
>  powf_args=2
> diff --git a/libavutil/libm.h b/libavutil/libm.h
> index 6c17b28..ba837a2 100644
> --- a/libavutil/libm.h
> +++ b/libavutil/libm.h
> @@ -43,6 +43,34 @@
>  #define atan2f(y, x) ((float)atan2(y, x))
>  #endif
>
> +#if !HAVE_FMAX
> +#undef fmax
> +static av_always_inline double fmax(double x, double y)
> +{
> +if (x < y) return y;
> +else   return x;
> +}
> +#endif
> +
> +#if !HAVE_FMIN
> +#undef fmin
> +static av_always_inline double fmin(double x, double y)
> +{
> +if (x < y) return x;
> +else   return y;
> +}
> +#endif
> +
> +#if !HAVE_FMAXF
> +#undef fmaxf
> +#define fmaxf(y, x) ((float)fmax(y, x))
> +#endif
> +
> +#if !HAVE_FMINF
> +#undef fminf
> +#define fminf(y, x) ((float)fmin(y, x))
> +#endif
> +
>  #if !HAVE_POWF
>  #undef powf
>  #define powf(x, y) ((float)pow(x, y))
> --
> 1.7.9.5
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 11/11] avutil/rational: use frexp rather than ad-hoc log to get floating point exponent

[Michael Niedermayer]

On Thu, Oct 29, 2015 at 12:20:09AM -0400, Ganesh Ajjanagadde wrote:
> This simplifies and cleans up the code.
> Furthermore, it is much faster due to absence of the slow log computation.
> 
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavutil/rational.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

LGTM and nice speedup!


[...]
-- 
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] configure+libm.h: add fmin/fmax/fminf/fmaxf emulation

[Michael Niedermayer]

On Fri, Oct 30, 2015 at 06:53:34PM -0400, Ganesh Ajjanagadde wrote:
> On Fri, Oct 30, 2015 at 6:35 PM, Michael Niedermayer  wrote:
> > From: Michael Niedermayer 
> >
> > This should fix the build failure of avf_showcqt.c
> >
> > An alternative solution would be to add a check for fmin/fmax to 
> > fate-source and
> > then to replace them by FFMIN/FFMAX, i can do that if preferred?
> >
> > Untested due to lack of a affected platform
> 
> I recall some interest on my end to get fmin, fmax etc for different
> reasons, and it was remarked that commit
> 4436a8f44dedc83767b3d9da9beb85d1fae2ca30 may be relevant. The summary
> seems to be that getting it to work on all platforms is not so simple.

:/
ill replace the problematic ones by FFMIN/MAX for now so the build
failure on the affected msvc platforms is fixed
tieing a build fix to this complexity would be unwise


> I am definitely interested in getting it to work in order to replace
> FFMAX/FFMIN for floating point in especially libavfilter. This will
> allow better nan signalling at a slight performance cost.

would that performance cost affect all systems or just ones not
having fmin/fmax ?
i think affecting all systems would be bad

[...]
-- 
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 1/2] swresample/swresample: add av_warn_unused_result

[Michael Niedermayer]

On Thu, Oct 15, 2015 at 09:31:59PM -0400, Ganesh Ajjanagadde wrote:
> This will trigger a few warnings (e.g in avfilter) that need to be
> fixed.
> 
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libswresample/swresample.h | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/libswresample/swresample.h b/libswresample/swresample.h
> index 10eaebc..d21084f 100644
> --- a/libswresample/swresample.h
> +++ b/libswresample/swresample.h
> @@ -220,6 +220,7 @@ struct SwrContext *swr_alloc(void);
>   * @param[in,out]   s Swr context to initialize
>   * @return AVERROR error code in case of failure.
>   */
> +av_warn_unused_result
>  int swr_init(struct SwrContext *s);
>  
>  /**

> @@ -307,6 +308,7 @@ void swr_close(struct SwrContext *s);
>   *
>   * @return number of samples output per channel, negative value on error
>   */
> +av_warn_unused_result
>  int swr_convert(struct SwrContext *s, uint8_t **out, int out_count,
>  const uint8_t **in , int in_count);
>  

i dont think the user needs to check the return code for simple
sample format convertions for example


> @@ -354,6 +356,7 @@ int64_t swr_next_pts(struct SwrContext *s, int64_t pts);
>   *@li compensation unsupported by resampler, or
>   *@li swr_init() fails when called.
>   */
> +av_warn_unused_result
>  int swr_set_compensation(struct SwrContext *s, int sample_delta, int 
> compensation_distance);
>  
>  /**
> @@ -364,6 +367,7 @@ int swr_set_compensation(struct SwrContext *s, int 
> sample_delta, int compensatio
>   *indexes, -1 for a muted channel)
>   * @return >= 0 on success, or AVERROR error code in case of failure.
>   */
> +av_warn_unused_result
>  int swr_set_channel_mapping(struct SwrContext *s, const int *channel_map);
>  
>  /**

> @@ -375,6 +379,7 @@ int swr_set_channel_mapping(struct SwrContext *s, const 
> int *channel_map);
>   * @param stride  offset between lines of the matrix
>   * @return  >= 0 on success, or AVERROR error code in case of failure.
>   */
> +av_warn_unused_result
>  int swr_set_matrix(struct SwrContext *s, const double *matrix, int stride);

the only failure mode i see is EINVAL, so the user could know that
failure wont happen

its possible this applies to more functions

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

[FFmpeg-devel] [PATCH 2/3] tools/crypto_bench: macro-ize additional algorithms

[Rodger Combs]

This also moves additional libcrypto ciphers to the new (faster) EVP API
---
 tools/crypto_bench.c | 544 +++
 1 file changed, 110 insertions(+), 434 deletions(-)

diff --git a/tools/crypto_bench.c b/tools/crypto_bench.c
index 8a468ba..80d5f66 100644
--- a/tools/crypto_bench.c
+++ b/tools/crypto_bench.c
@@ -109,86 +109,32 @@ DEFINE_LAVU_MD(sha512,AVSHA512, sha512, 512);
 DEFINE_LAVU_MD(ripemd128, AVRIPEMD, ripemd, 128);
 DEFINE_LAVU_MD(ripemd160, AVRIPEMD, ripemd, 160);
 
-static void run_lavu_aes128(uint8_t *output,
-const uint8_t *input, unsigned size)
-{
-static struct AVAES *aes;
-if (!aes && !(aes = av_aes_alloc()))
-fatal_error("out of memory");
-av_aes_init(aes, hardcoded_key, 128, 0);
-av_aes_crypt(aes, output, input, size >> 4, NULL, 0);
-}
-
-static void run_lavu_aes192(uint8_t *output, const uint8_t *input, unsigned 
size)
-{
-static struct AVAES *aes;
-if (!aes && !(aes = av_aes_alloc()))
-fatal_error("out of memory");
-av_aes_init(aes, hardcoded_key, 192, 0);
-av_aes_crypt(aes, output, input, size >> 4, NULL, 0);
-}
-
-static void run_lavu_aes256(uint8_t *output, const uint8_t *input, unsigned 
size)
-{
-static struct AVAES *aes;
-if (!aes && !(aes = av_aes_alloc()))
-fatal_error("out of memory");
-av_aes_init(aes, hardcoded_key, 256, 0);
-av_aes_crypt(aes, output, input, size >> 4, NULL, 0);
-}
-
-static void run_lavu_aes128cbc(uint8_t *output, const uint8_t *input, unsigned 
size)
-{
-static struct AVAES *aes;
-static uint8_t *iv;
-if ((!aes && !(aes = av_aes_alloc())) || (!iv && !(iv = av_malloc(16
-fatal_error("out of memory");
-memcpy(iv, hardcoded_iv, 16);
-av_aes_init(aes, hardcoded_key, 128, 0);
-av_aes_crypt(aes, output, input, size >> 4, iv, 0);
-}
-
-static void run_lavu_aes192cbc(uint8_t *output, const uint8_t *input, unsigned 
size)
-{
-static struct AVAES *aes;
-static uint8_t *iv;
-if ((!aes && !(aes = av_aes_alloc())) || (!iv && !(iv = av_malloc(16
-fatal_error("out of memory");
-memcpy(iv, hardcoded_iv, 16);
-av_aes_init(aes, hardcoded_key, 192, 0);
-av_aes_crypt(aes, output, input, size >> 4, iv, 0);
-}
-
-static void run_lavu_aes256cbc(uint8_t *output, const uint8_t *input, unsigned 
size)
-{
-static struct AVAES *aes;
-static uint8_t *iv;
-if ((!aes && !(aes = av_aes_alloc())) || (!iv && !(iv = av_malloc(16
-fatal_error("out of memory");
-memcpy(iv, hardcoded_iv, 16);
-av_aes_init(aes, hardcoded_key, 256, 0);
-av_aes_crypt(aes, output, input, size >> 4, iv, 0);
-}
-
-static void run_lavu_blowfish(uint8_t *output,
-  const uint8_t *input, unsigned size)
-{
-static struct AVBlowfish *blowfish;
-if (!blowfish && !(blowfish = av_blowfish_alloc()))
-fatal_error("out of memory");
-av_blowfish_init(blowfish, hardcoded_key, 16);
-av_blowfish_crypt(blowfish, output, input, size >> 3, NULL, 0);
-}
-
-static void run_lavu_camellia(uint8_t *output,
-  const uint8_t *input, unsigned size)
-{
-static struct AVCAMELLIA *camellia;
-if (!camellia && !(camellia = av_camellia_alloc()))
-fatal_error("out of memory");
-av_camellia_init(camellia, hardcoded_key, 128);
-av_camellia_crypt(camellia, output, input, size >> 4, NULL, 0);
-}
+#define DEFINE_LAVU_CRYPT(suffix, type, namespace, ivsize, sshift, ...)  \
+static void run_lavu_ ## suffix(uint8_t *output, \
+const uint8_t *input, unsigned size) \
+{\
+static struct type *h;   \
+static uint8_t *iv = NULL;   \
+if (!h && !(h = av_ ## namespace ## _alloc()))   \
+fatal_error("out of memory");\
+if (ivsize && !iv && !(iv = av_malloc(ivsize)))  \
+fatal_error("out of memory");\
+if (ivsize)  \
+memcpy(iv, hardcoded_iv, ivsize);\
+av_ ## namespace ## _init(h, hardcoded_key, __VA_ARGS__);\
+av_ ## namespace ## _crypt(h, output, input, size >> sshift, iv, 0); \
+}
+
+DEFINE_LAVU_CRYPT(aes128,AVAES,  aes,  0,  4, 128, 0);
+DEFINE_LAVU_CRYPT(aes192,AVAES,  aes,  0,  4, 192, 0);
+DEFINE_LAVU_CRYPT(aes256,AVAES,  aes,  0,  4, 256, 0);
+DEFINE_LAVU_CRYPT(aes128cbc, AVAES,  aes,  16, 4, 128, 0);
+DEFINE_LAVU_CRYPT(aes192cbc, AVAES,  aes,  16, 4, 192, 0);
+DEFINE_LAVU_CRYPT(aes256cbc, AVAES,  aes,  16, 4, 256, 0);

[FFmpeg-devel] [PATCH 3/3] tools/crypto_bench: add support for multiple lavu versions by cpuflag

[Rodger Combs]

---
 tools/crypto_bench.c | 49 +
 1 file changed, 41 insertions(+), 8 deletions(-)

diff --git a/tools/crypto_bench.c b/tools/crypto_bench.c
index 80d5f66..ce61af1 100644
--- a/tools/crypto_bench.c
+++ b/tools/crypto_bench.c
@@ -32,6 +32,7 @@
 #include "libavutil/crc.h"
 #include "libavutil/intreadwrite.h"
 #include "libavutil/timer.h"
+#include "libavutil/cpu.h"
 
 #ifndef AV_READ_TIME
 #define AV_READ_TIME(x) 0
@@ -65,6 +66,7 @@ struct hash_impl {
 const char *name;
 void (*run)(uint8_t *output, const uint8_t *input, unsigned size);
 const char *output;
+int cpu_versions;
 };
 
 /***
@@ -343,6 +345,16 @@ static unsigned crc32(const uint8_t *data, unsigned size)
 return av_crc(av_crc_get_table(AV_CRC_32_IEEE), 0, data, size);
 }
 
+static const struct {
+int flag;
+const char *name;
+} cpu_flag_tab[] = {
+#if ARCH_X86
+{ AV_CPU_FLAG_AESNI, "aesni"  },
+#endif
+{ 0 }
+};
+
 static void run_implementation(const uint8_t *input, uint8_t *output,
struct hash_impl *impl, unsigned size)
 {
@@ -353,6 +365,27 @@ static void run_implementation(const uint8_t *input, 
uint8_t *output,
 double mtime, ttime = 0, ttime2 = 0, stime;
 uint8_t outref[MAX_OUTPUT_SIZE];
 
+if (!strcmp(impl->lib, "lavu")) {
+char lib_name[32];
+struct hash_impl impl2 = *impl;
+int real_flags = av_get_cpu_flags();
+int current_flags = real_flags;
+impl2.cpu_versions = 0;
+impl2.lib = lib_name;
+for (i = 0; cpu_flag_tab[i].flag; i++) {
+if (cpu_flag_tab[i].flag & impl->cpu_versions & real_flags) {
+snprintf(lib_name, sizeof(lib_name), "lavu_%s", 
cpu_flag_tab[i].name);
+run_implementation(input, output, , size);
+current_flags &= ~cpu_flag_tab[i].flag;
+av_force_cpu_flags(current_flags);
+}
+}
+impl2.lib = "lavu_c";
+run_implementation(input, output, , size);
+av_force_cpu_flags(real_flags);
+return;
+}
+
 if (enabled_libs  && !av_stristr(enabled_libs,  impl->lib) ||
 enabled_algos && !av_stristr(enabled_algos, impl->name))
 return;
@@ -394,8 +427,8 @@ static void run_implementation(const uint8_t *input, 
uint8_t *output,
 fflush(stdout);
 }
 
-#define IMPL_USE(lib, name, symbol, output) \
-{ #lib, name, run_ ## lib ## _ ## symbol, output },
+#define IMPL_USE(lib, name, symbol, output, ...) \
+{ #lib, name, run_ ## lib ## _ ## symbol, output, __VA_ARGS__ },
 #define IMPL(lib, ...) IMPL_USE_ ## lib(lib, __VA_ARGS__)
 #define IMPL_ALL(...) \
 IMPL(lavu,   __VA_ARGS__) \
@@ -412,12 +445,12 @@ struct hash_impl implementations[] = {
 IMPL(lavu, "RIPEMD-128", ripemd128, "9ab8bfba2ddccc5d99c9d4cdfb844a5f")
 IMPL(tomcrypt, "RIPEMD-128", ripemd128, "9ab8bfba2ddccc5d99c9d4cdfb844a5f")
 IMPL_ALL("RIPEMD-160", ripemd160, 
"62a5321e4fc8784903bb43ab7752c75f8b25af00")
-IMPL_ALL("AES-128-ECB",aes128,"crc:ff6bc888")
-IMPL_ALL("AES-192-ECB",aes192,"crc:1022815b")
-IMPL_ALL("AES-256-ECB",aes256,"crc:792e4e8a")
-IMPL_ALL("AES-128-CBC",aes128cbc, "crc:0efebabe")
-IMPL_ALL("AES-192-CBC",aes192cbc, "crc:ee2e34e8")
-IMPL_ALL("AES-256-CBC",aes256cbc, "crc:0c9b875c")
+IMPL_ALL("AES-128-ECB",aes128,"crc:ff6bc888", AV_CPU_FLAG_AESNI)
+IMPL_ALL("AES-192-ECB",aes192,"crc:1022815b", AV_CPU_FLAG_AESNI)
+IMPL_ALL("AES-256-ECB",aes256,"crc:792e4e8a", AV_CPU_FLAG_AESNI)
+IMPL_ALL("AES-128-CBC",aes128cbc, "crc:0efebabe", AV_CPU_FLAG_AESNI)
+IMPL_ALL("AES-192-CBC",aes192cbc, "crc:ee2e34e8", AV_CPU_FLAG_AESNI)
+IMPL_ALL("AES-256-CBC",aes256cbc, "crc:0c9b875c", AV_CPU_FLAG_AESNI)
 IMPL_ALL("CAMELLIA",   camellia,  "crc:7abb59a7")
 IMPL_ALL("CAST-128",   cast128,   "crc:456aa584")
 IMPL_ALL("BLOWFISH",   blowfish,  "crc:33e8aa74")
-- 
2.6.2

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

Re: [FFmpeg-devel] [PATCH] ffmpeg_filter: check encoder before using it to set frame size.

[Nicolas George]

Le sextidi 6 brumaire, an CCXXIV, Michael Niedermayer a écrit :
> LGTM

Thanks, pushed.

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 2/3] avformat/segafilm: set audio stream duration

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 libavformat/segafilm.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libavformat/segafilm.c b/libavformat/segafilm.c
index b4f9b3d..9c346e6 100644
--- a/libavformat/segafilm.c
+++ b/libavformat/segafilm.c
@@ -247,6 +247,9 @@ static int film_read_header(AVFormatContext *s)
 }
 }
 
+if (film->audio_type)
+s->streams[film->audio_stream_index]->duration = audio_frame_counter;
+
 film->current_sample = 0;
 
 return 0;
-- 
1.9.1

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

Re: [FFmpeg-devel] [PATCH] avutil/wchar_filename: add av_warn_unused_result

[Michael Niedermayer]

On Thu, Oct 15, 2015 at 08:01:56PM -0400, Ganesh Ajjanagadde wrote:
> Current code is fine, this just adds robustness.
> 
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavutil/wchar_filename.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/libavutil/wchar_filename.h b/libavutil/wchar_filename.h
> index c553c46..2ade321 100644
> --- a/libavutil/wchar_filename.h
> +++ b/libavutil/wchar_filename.h
> @@ -23,6 +23,7 @@
>  #include 
>  #include "mem.h"
>  
> +av_warn_unused_result
>  static inline int utf8towchar(const char *filename_utf8, wchar_t 
> **filename_w)
>  {
>  int num_chars;

LGTM

thanks

[...]
-- 
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][RFC] avcodec: disallow hwaccel with frame threads

[Hendrik Leppkes]

On Thu, Oct 29, 2015 at 8:31 PM, Andy Furniss  wrote:
> Hendrik Leppkes wrote:
>>
>> On Thu, Oct 22, 2015 at 11:27 AM, Wang Bin 
>> wrote:
>>>
>>> VLC is using frame threading with hwaccel
>>
>>
>> Then they should fix their usage, its broken by design, as explained
>> in detail my post earlier in this thread.
>
>
> Seems ffmpeg cli does the same by default - OK so users can specify
> -threads 1 if they use -hwaccel vdpau.
>

I thought about a patch to disable threads if hwaccel is requested on
the command line, might try to do that in a bit.

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

Re: [FFmpeg-devel] [PATCH 2/5] fate: add concat demuxer tests

[Nicolas George]

Le quartidi 4 brumaire, an CCXXIV, Marton Balint a écrit :
> I used this many (25 1-frame segment) because this is also a seek test for
> open gop mxf. I can reduce it but in that case I will have to maintain my
> own out of tree tests for it which is counter-productive IMHO.

It seems that the your script is ready to use several templates: maybe do
just that: a short one with full output in the ref file to make testing and
debugging easy, and a long one to cover your full MXF test. But only if it
is not too much work.

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] avutil/file_open: avoid file handle inheritance on Windows

[Tobias Rapp]

On 29.10.2015 09:38, Tobias Rapp wrote:

Attached patch fixes file lock issues in my Windows application when a
child process is started with handle inheritance enabled (standard
input/output redirection) while a FFmpeg transcoding is running in the
parent process.

BTW: It would be great if the patch could also be applied to the 2.7/2.8
release branches.


Forgot to add links relevant to the subject.

[1] https://msdn.microsoft.com/en-us/library/w7sa2b22.aspx

Describes the _wsopen() function and the O_NOINHERIT flag. File handles 
opened by _wsopen() are inheritable by default.


[2] 
https://msdn.microsoft.com/en-us/library/windows/desktop/aa363858%28v=vs.85%29.aspx


Describes the CreateFile() function. Not directly relevant here, often 
used in cases outside of C/libc. Opens file without inheritance by 
default (lpSecurityAttributes is NULL).


[3] 
https://msdn.microsoft.com/en-us/library/windows/desktop/ms682425%28v=vs.85%29.aspx


Describes handle inheritance when creating new processes. Handle 
inheritance must be enabled (bInheritHandles = TRUE) e.g. when you want 
to pass handles for stdin/stdout via lpStartupInfo.


Regards,
Tobias

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

[FFmpeg-devel] possible farewell; dev policy clarification

[Ganesh Ajjanagadde]

Hi all,

Apologies for the length of the email, but there is a lot of stuff I
would like to cover due to my absence on IRC or other venues for "non
patch related" discussion.

There has been a lot said and still being said regarding some patches
I sent and associated discussion. Issues not related to patches in a
technical sense are being discussed privately.

In the meantime, I have noticed an increased level of hostility on
ffmpeg-devel lately, both from my end as well as from others. I do not
wish to escalate it further, and want to let work progress as smoothly
as possible.

In fact, I repeat a statement I made earlier: if overall people think
that if I leave better and more work will be done for the project, I
will gladly do so. That is the only thing I wish for: FFmpeg becoming
better. To clarify a possible confusion on IRC: I by no means intend
to work on Libav - either I work for FFmpeg, or not work at all on
multimedia. This statement holds true regardless of what people
express about the work I do here, whether I am kicked out, etc.

The reason I repeat this question of leaving is because I dug through
IRC archives, trying to understand better what people here think of
the work I do in light of the increasing hostility on the ML. I got
the sense that a lot of information that I could have received did not
reach me as I am, and will not be on IRC. I also got the sense that
there is a section of FFmpeg developers who are deeply against the
kinds of things I do and the way I handle them, hence prompting the
question.

Assuming that you feel I give a net positive benefit to the project,
please read on.

I am quite puzzled with some of the sentiments expressed there. I
illustrate below what puzzles me, and ask what I can do on my end:

1. "Sloppy" patches - I tend to give more verbose commit messages to
explain rationale than many here. I also outlined why I did not post
benchmarks initially. I myself still think they are unnecessary and
not useful for many of my proposed changes, but the community here
seemed to think otherwise. I have hence started posting benchmarks.
I generally try to give evidence for things that are more "universal"
in character when possible, so as not to skew towards any particular
machine architecture, etc. I do not agree that the log patches were
"sloppy" - bit accuracy improvements for log10 over log should have
been obvious. Simplification of the code, a subjective aspect, should
have been quite a reasonable assumption. Do people here not think such
things are obvious?

2. "Increasing warnings" - There were only 2 instances AFAIK where I
made a mistake, one in apedec. Another was in a test build. Both were
very quickly resolved. These issues were tiny compared to the general
level of warning cleanups achieved. Both were reasonable mistakes that
missed the eyes of reviewers. Please do let me know when I do increase
such things, I try to test things the best I can on my end. I will
strive to be more cautious in the future by incorporating the lessons
learnt with these two failures.

3. Patch sending mechanism - I have tried both approaches, namely an
en-masse single patch, versus individual tiny patches. Both were
frowned upon: the en-masse as "not fond of mass changes", and the
single patches as "incredibly noisy". Regarding pinging, I pinged a
single patch in a set of similar patches with a phrase regarding the
fact that the ping extends to other such similar patches. This ping
was ignored. I push (following the dev policy) one change after
sufficient delay, and it was frowned upon. I did not know what to do,
so I subsequently pinged each of the patches. This resulted in a bunch
of comments on IRC. For reference, these are the av_warn_unused_result
patches for avutil. Any suggestions for the future?

4. av_warn_unused_result not being useful en-masse for all headers -
This was something remarked upon in IRC. I did not get this
information in the form of reviews. Please suggest which headers to
target first: I am currently just going one by one in a natural order
(so that I can keep track of which ones have been addressed). Of
course, if people think av_warn_unused_result is inherently bad, that
is a separate issue that reflects an even deeper gulf.

5. General communication failures - Clearly, a lot of important stuff
from IRC is not reaching the ML. I (and some others here) do not use
IRC, and are pretty firm about not using it. What can be done to
address the communication gap? I would have at least understood the
deep hostility to the work I do if I had seen IRC logs a few weeks
back. The ML got only the "effects" and little of the "causes".
Overall, my sense is that people let the negative reaction bottle up,
venting every now and then on IRC, since for whatever reason it is
more comfortable, although technically both are publicly recorded and
nearly as easily referenced in mails or commit messages. As a side
note, even some patch review is done on IRC, a situation I 

Re: [FFmpeg-devel] [PATCH] Update Cookies on Setcookie playlist response

[Michael Niedermayer]

On Tue, Oct 27, 2015 at 11:28:32AM +, Lucas Andrade wrote:
> Here is the patch to backport it to release/2.8. To be fixed on 2.8.2.
> Anything else I should do?
> 
> ps. Sorry, that's my first time on opensource project, I'm a little
> confused that I needed to add it to the release branch.

>  hls.c |   31 +++
>  1 file changed, 15 insertions(+), 16 deletions(-)
> 6b3c2cdc68e5fe0d9665a22a78837bca7d7b39b9  
> b3f3eab029eb429660fc1651a33dafe097cbac0e.patch
> From b3f3eab029eb429660fc1651a33dafe097cbac0e Mon Sep 17 00:00:00 2001
> From: Lucas de Andrade 
> Date: Mon, 26 Oct 2015 10:47:08 -0200
> Subject: [PATCH] Update Cookies response with Setcookie
> 
> Context cookies must be updated when a playlist response return Setcookie 
> header.
> Backported to release/2.8
> ---
>  libavformat/hls.c | 31 +++
>  1 file changed, 15 insertions(+), 16 deletions(-)

this patch is against n2.8 not release/2.8

git checkout release/2.8
git cherry-pick ...
error: patch failed: libavformat/hls.c:962
error: libavformat/hls.c: patch does not apply
Patch failed at 0001 Update Cookies response with Setcookie
The copy of the patch that failed is found in:
   ffmpeg/.git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.


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

[FFmpeg-devel] [PATCH 1/3] tools/crypto_bench: switch to OpenSSL's faster AES API

[Rodger Combs]

Before: crypto AES-128-CBC  size: 1048576  runs: 1024  time: 16.224 +- 2.347
After:  crypto AES-128-CBC  size: 1048576  runs: 1024  time:  3.056 +- 0.366
---
 tools/crypto_bench.c | 85 +---
 1 file changed, 47 insertions(+), 38 deletions(-)

diff --git a/tools/crypto_bench.c b/tools/crypto_bench.c
index 15bb5f1..8a468ba 100644
--- a/tools/crypto_bench.c
+++ b/tools/crypto_bench.c
@@ -244,6 +244,7 @@ static void run_lavu_xtea(uint8_t *output,
 #include 
 #include 
 #include 
+#include 
 
 #define DEFINE_CRYPTO_WRAPPER(suffix, function)  \
 static void run_crypto_ ## suffix(uint8_t *output,   \
@@ -258,74 +259,82 @@ DEFINE_CRYPTO_WRAPPER(sha256,SHA256)
 DEFINE_CRYPTO_WRAPPER(sha512,SHA512)
 DEFINE_CRYPTO_WRAPPER(ripemd160, RIPEMD160)
 
-static void run_crypto_aes128(uint8_t *output,
-  const uint8_t *input, unsigned size)
+static void run_crypto_aes128(uint8_t *output, const uint8_t *input, unsigned 
size)
 {
-AES_KEY aes;
-unsigned i;
+static EVP_CIPHER_CTX *ctx = NULL;
+int len = 0;
 
-AES_set_encrypt_key(hardcoded_key, 128, );
-size -= 15;
-for (i = 0; i < size; i += 16)
-AES_encrypt(input + i, output + i, );
+if (!ctx && !(ctx = EVP_CIPHER_CTX_new()))
+fatal_error("out of memory");
+
+EVP_EncryptInit(ctx, EVP_aes_128_ecb(), hardcoded_key, hardcoded_iv);
+EVP_EncryptUpdate(ctx, output, , input, size);
+EVP_CIPHER_CTX_cleanup(ctx);
 }
 
 static void run_crypto_aes192(uint8_t *output, const uint8_t *input, unsigned 
size)
 {
-AES_KEY aes;
-unsigned i;
+static EVP_CIPHER_CTX *ctx = NULL;
+int len = 0;
 
-AES_set_encrypt_key(hardcoded_key, 192, );
-size -= 15;
-for (i = 0; i < size; i += 16)
-AES_encrypt(input + i, output + i, );
+if (!ctx && !(ctx = EVP_CIPHER_CTX_new()))
+fatal_error("out of memory");
+
+EVP_EncryptInit(ctx, EVP_aes_192_ecb(), hardcoded_key, hardcoded_iv);
+EVP_EncryptUpdate(ctx, output, , input, size);
+EVP_CIPHER_CTX_cleanup(ctx);
 }
 
 static void run_crypto_aes256(uint8_t *output, const uint8_t *input, unsigned 
size)
 {
-AES_KEY aes;
-unsigned i;
+static EVP_CIPHER_CTX *ctx = NULL;
+int len = 0;
 
-AES_set_encrypt_key(hardcoded_key, 256, );
-size -= 15;
-for (i = 0; i < size; i += 16)
-AES_encrypt(input + i, output + i, );
+if (!ctx && !(ctx = EVP_CIPHER_CTX_new()))
+fatal_error("out of memory");
+
+EVP_EncryptInit(ctx, EVP_aes_256_ecb(), hardcoded_key, hardcoded_iv);
+EVP_EncryptUpdate(ctx, output, , input, size);
+EVP_CIPHER_CTX_cleanup(ctx);
 }
 
 static void run_crypto_aes128cbc(uint8_t *output, const uint8_t *input, 
unsigned size)
 {
-AES_KEY aes;
-static uint8_t *iv;
-if ((!iv && !(iv = av_malloc(16
+static EVP_CIPHER_CTX *ctx = NULL;
+int len = 0;
+
+if (!ctx && !(ctx = EVP_CIPHER_CTX_new()))
 fatal_error("out of memory");
-memcpy(iv, hardcoded_iv, 16);
 
-AES_set_encrypt_key(hardcoded_key, 128, );
-AES_cbc_encrypt(input, output, size, , iv, 1);
+EVP_EncryptInit(ctx, EVP_aes_128_cbc(), hardcoded_key, hardcoded_iv);
+EVP_EncryptUpdate(ctx, output, , input, size);
+EVP_CIPHER_CTX_cleanup(ctx);
 }
 
 static void run_crypto_aes192cbc(uint8_t *output, const uint8_t *input, 
unsigned size)
 {
-AES_KEY aes;
-static uint8_t *iv;
-if ((!iv && !(iv = av_malloc(16
+static EVP_CIPHER_CTX *ctx = NULL;
+int len = 0;
+
+if (!ctx && !(ctx = EVP_CIPHER_CTX_new()))
 fatal_error("out of memory");
-memcpy(iv, hardcoded_iv, 16);
 
-AES_set_encrypt_key(hardcoded_key, 192, );
-AES_cbc_encrypt(input, output, size, , iv, 1);
+EVP_EncryptInit(ctx, EVP_aes_192_cbc(), hardcoded_key, hardcoded_iv);
+EVP_EncryptUpdate(ctx, output, , input, size);
+EVP_CIPHER_CTX_cleanup(ctx);
 }
 
 static void run_crypto_aes256cbc(uint8_t *output, const uint8_t *input, 
unsigned size)
 {
-AES_KEY aes;
-static uint8_t *iv;
-if ((!iv && !(iv = av_malloc(16
+static EVP_CIPHER_CTX *ctx = NULL;
+int len = 0;
+
+if (!ctx && !(ctx = EVP_CIPHER_CTX_new()))
 fatal_error("out of memory");
-memcpy(iv, hardcoded_iv, 16);
 
-AES_set_encrypt_key(hardcoded_key, 256, );
-AES_cbc_encrypt(input, output, size, , iv, 1);
+EVP_EncryptInit(ctx, EVP_aes_256_cbc(), hardcoded_key, hardcoded_iv);
+EVP_EncryptUpdate(ctx, output, , input, size);
+EVP_CIPHER_CTX_cleanup(ctx);
 }
 
 static void run_crypto_blowfish(uint8_t *output,
-- 
2.6.2

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

[FFmpeg-devel] [PATCH 1/3] avformat/segafilm: implement seeking

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 libavformat/segafilm.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/libavformat/segafilm.c b/libavformat/segafilm.c
index 44fa683..b4f9b3d 100644
--- a/libavformat/segafilm.c
+++ b/libavformat/segafilm.c
@@ -239,6 +239,11 @@ static int film_read_header(AVFormatContext *s)
 film->sample_table[i].stream = film->video_stream_index;
 film->sample_table[i].pts = AV_RB32([8]) & 0x7FFF;
 film->sample_table[i].keyframe = (scratch[8] & 0x80) ? 0 : 1;
+av_add_index_entry(s->streams[film->video_stream_index],
+   film->sample_table[i].sample_offset,
+   film->sample_table[i].pts,
+   film->sample_table[i].sample_size, 0,
+   film->sample_table[i].keyframe);
 }
 }
 
@@ -279,6 +284,21 @@ static int film_read_packet(AVFormatContext *s,
 return ret;
 }
 
+static int film_read_seek(AVFormatContext *s, int stream_index, int64_t 
timestamp, int flags)
+{
+FilmDemuxContext *film = s->priv_data;
+AVStream *st = s->streams[stream_index];
+int index = av_index_search_timestamp(st, timestamp, flags);
+if (index < 0)
+return -1;
+if (avio_seek(s->pb, st->index_entries[index].pos, SEEK_SET) < 0)
+return -1;
+
+film->current_sample = index;
+
+return 0;
+}
+
 AVInputFormat ff_segafilm_demuxer = {
 .name   = "film_cpk",
 .long_name  = NULL_IF_CONFIG_SMALL("Sega FILM / CPK"),
@@ -287,4 +307,5 @@ AVInputFormat ff_segafilm_demuxer = {
 .read_header= film_read_header,
 .read_packet= film_read_packet,
 .read_close = film_read_close,
+.read_seek  = film_read_seek,
 };
-- 
1.9.1

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

Re: [FFmpeg-devel] PATCH: gdigrab work for DPI in windows

[Roger Pack]

On 10/28/15, Matt Oliver  wrote:
> On 5 October 2015 at 20:05, Matt Oliver  wrote:
>
>> On 5 October 2015 at 19:29, Matt Oliver  wrote:
>>
>>> On 30 September 2015 at 02:48, wm4  wrote:
>>>
 On Wed, 23 Sep 2015 12:04:43 -0600
 Roger Pack  wrote:

 > From 6a972dda58bd5ab31524cd4e5326b4bcdeaeaa8c Mon Sep 17 00:00:00 2001
 > From: rogerdpack 
 > Date: Wed, 23 Sep 2015 12:03:27 -0600
 > Subject: [PATCH] gdigrab: grab right desktop size if DPI in use, based
 on
 >  patch from Alexander Brotzge
 >
 > Signed-off-by: rogerdpack 
 > ---
 >  libavdevice/gdigrab.c | 44
 +---
 >  1 file changed, 29 insertions(+), 15 deletions(-)
 >
 > diff --git a/libavdevice/gdigrab.c b/libavdevice/gdigrab.c
 > index 9a185d4..b0faf45 100644
 > --- a/libavdevice/gdigrab.c
 > +++ b/libavdevice/gdigrab.c
 > @@ -235,6 +235,9 @@ gdigrab_read_header(AVFormatContext *s1)
 >  AVStream   *st   = NULL;
 >
 >  int bpp;
 > +int vertres;
 > +int desktopvertres;
 > +float scale;
 >  RECT virtual_rect;
 >  RECT clip_rect;
 >  BITMAP bmp;
 > @@ -263,14 +266,34 @@ gdigrab_read_header(AVFormatContext *s1)
 >  goto error;
 >  }
 >
 > -if (hwnd) {
 > -GetClientRect(hwnd, _rect);
 > -} else {
 > +/* This will get the device context for the selected window, or
 > if
 > + * none, the primary screen */
 > +source_hdc = GetDC(hwnd);
 > +if (!source_hdc) {
 > +WIN32_API_ERROR("Couldn't get window device context");
 > +ret = AVERROR(EIO);
 > +goto error;
 > +}
 > +bpp = GetDeviceCaps(source_hdc, BITSPIXEL);
 > +
 > +scale = 1.0;
 > +if (hwnd == NULL) {
 > +  /* desktop -- get the right height and width for scaling DPI */
 > +  vertres = GetDeviceCaps(source_hdc, VERTRES);
 > +  desktopvertres = GetDeviceCaps(source_hdc, DESKTOPVERTRES);
 > +  scale = (float) desktopvertres / (float) vertres;
 > +}

>>>
>>> This seems a little redundant as scale is only being set when hwnd is
>>> null however in the below lines its then being used in the opposite
>>> conditional. Since this checks for hwnd essentially being non null then
>>> scale is always going to be the inital value of 1.
>>>
>>>
 > + if (hwnd) {
 > + GetClientRect(hwnd, _rect);
 > + virtual_rect.right = virtual_rect.right * scale;
 > + virtual_rect.bottom = virtual_rect.bottom * scale;
 > + } else {
 >  virtual_rect.left = GetSystemMetrics(SM_XVIRTUALSCREEN);
 >  virtual_rect.top = GetSystemMetrics(SM_YVIRTUALSCREEN);
 > -virtual_rect.right = virtual_rect.left +
 GetSystemMetrics(SM_CXVIRTUALSCREEN);
 > -virtual_rect.bottom = virtual_rect.top +
 GetSystemMetrics(SM_CYVIRTUALSCREEN);
 > -}
 > +virtual_rect.right = (virtual_rect.left +
 GetSystemMetrics(SM_CXVIRTUALSCREEN)) * scale;
 > +virtual_rect.bottom = (virtual_rect.top +
 GetSystemMetrics(SM_CYVIRTUALSCREEN)) * scale;
 > + }

>>>
>>> This if else could be combined with the above if as scale is only a value
>>> different to 1 in the 'else' case. Also as wm4 said it would probably be
>>> better to keep the scale factors as ints.
>>>
>>>
 >
 >  /* If no width or height set, use full screen/window area */
 >  if (!gdigrab->width || !gdigrab->height) {
 > @@ -299,15 +322,6 @@ gdigrab_read_header(AVFormatContext *s1)
 >  goto error;
 >  }
 >
 > -/* This will get the device context for the selected window, or
 > if
 > - * none, the primary screen */
 > -source_hdc = GetDC(hwnd);
 > -if (!source_hdc) {
 > -WIN32_API_ERROR("Couldn't get window device context");
 > -ret = AVERROR(EIO);
 > -goto error;
 > -}
 > -bpp = GetDeviceCaps(source_hdc, BITSPIXEL);
 >
 >  if (name) {
 >  av_log(s1, AV_LOG_INFO,
>>>
>>>
>>> However I think the basic dpi scaling technique is correct. However I
>>> would think it should be more along the lines of the modifications Ive
>>> attached.
>>>
>>
>> Woops, allow me to try that again without windows messing up the patches
>> line endings.
>>
>
> Does anyone have any issues with the updated patch or can it be pushed?

OK sorry for the delay finally got around to testing it and LGTM
recommend commit (I'm a gdigrab maintainer).
Cheers!
-roger-
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org

Re: [FFmpeg-devel] possible farewell; dev policy clarification

[Rostislav Pehlivanov]

I agree with the others. There's quite a lot of noise on the ML and having
some of
your trivial patches (e.g. replacing functions with FFmpeg defined ones)
merged into
one would help to decrease it.

>Currently I am trying to get rid of a
>lot of the last aspect to create a foundation for myself to work on
>other things.
Huh? What's so unclean about the current codebase that you simply can't
work on
anything else? Can you really not sleep at night if you know there's an
unchecked malloc
call (never a problem with a non-ancient OS) somewhere in an obscure 90's
video game
decoder which theoretically works but people lost the only available
samples 5 years ago?
What other things? Also be careful, the definition of a "foundation to work
on" could vary
between people. Hence a reason for reviews.

>Part of that defense (for me) is examining compiler warnings,
Many compilers (don't) warn about things that other compilers would. There
compilers
have versions which (don't) warn about some things that other versions do.
It's pointless
and conforming to a method that most compilers don't warn about can be
hacky and may
cause some compilers difficulty in actually compiling. It's best to choose
the absolute
least hacky way which works well with the newest (if sane, if not, newest
sane) version (!) of
the most popular compiler and doesn't emit a warning with the current "-W*"
arguments or
just keep the current status quo.

>fixing undefined behavior,
How does one fixed something undefined? Anyway, absolutely nothing wrong
with justified
undefined behavior, it's just working around the fact that:
>conforming to standards when possible
the standards are not that well defined or policed or sometimes sane (not
really the case with C) to
begin with. Rust wants to change that but it just takes away the fun of
programming (in C & others).
Any compiler which does something different than what other compilers do
under
undefined behavior which you rely on is in fact a not-very-sane compiler
and makes people
sad because if many people are stuck with that not-very-sane compiler it
means there is a
need for a special workaround for the not-very-sane compiler. Which then
encourages other
compilers to also have some other special way of doing undefined behavior and
thus bring more
ugly hacks. So yeah, sticking to the standard when possible is the best.

From another email in this thread:

>None of these things are satisfying, but to be honest, I am not
>looking for satisfaction from FFmpeg.
So you're not finding your work satisfying, you're probably not getting
paid, you're bothering
yourself over getting other people bothered by your work, yet you still do
it? This is beyond logic.
I suggest you make your mind up and either find joy from doing something or
money or both.

>I am looking for a way to channel frittered away energy obtained
>during my transition from undergraduate to graduate life and its
>associated increase in flexibility of time allocation.
>In other words, I want a way to spend my down-time that is technical
>in character.
You wrote this as if writing a job application; this is a mailing list of
equal adults (more or less)
interested in drama, popcorn and the development of FFmpeg, in that order :)
Though if you wrote this in a job application I'd hire you. Which is again
more or less what anyone
would do after they graduate: finding a job. Though nowadays there are
other alternatives becoming
popular: "finding yourself (by exploring the world)", "football!",
"NEETdom", "soccer", "FOOTBALL!",
"professional Quake 3 player", etc.

>av_gcd patches
>algorithmic improvements
Yes, your work on ff_ctz was very nice, kudos, I liked it.

On 30 October 2015 at 11:34, Ganesh Ajjanagadde  wrote:

> Hi all,
>
> Apologies for the length of the email, but there is a lot of stuff I
> would like to cover due to my absence on IRC or other venues for "non
> patch related" discussion.
>
> There has been a lot said and still being said regarding some patches
> I sent and associated discussion. Issues not related to patches in a
> technical sense are being discussed privately.
>
> In the meantime, I have noticed an increased level of hostility on
> ffmpeg-devel lately, both from my end as well as from others. I do not
> wish to escalate it further, and want to let work progress as smoothly
> as possible.
>
> In fact, I repeat a statement I made earlier: if overall people think
> that if I leave better and more work will be done for the project, I
> will gladly do so. That is the only thing I wish for: FFmpeg becoming
> better. To clarify a possible confusion on IRC: I by no means intend
> to work on Libav - either I work for FFmpeg, or not work at all on
> multimedia. This statement holds true regardless of what people
> express about the work I do here, whether I am kicked out, etc.
>
> The reason I repeat this question of leaving is because I dug through
> IRC archives, trying to understand better what people here 

Re: [FFmpeg-devel] [PATCH] configure+libm.h: add fmin/fmax/fminf/fmaxf emulation

[Ganesh Ajjanagadde]

On Fri, Oct 30, 2015 at 7:33 PM, Michael Niedermayer
 wrote:
> On Sat, Oct 31, 2015 at 12:14:44AM +0100, Hendrik Leppkes wrote:
>> On Fri, Oct 30, 2015 at 11:35 PM, Michael Niedermayer  
>> wrote:
>> > From: Michael Niedermayer 
>> >
>> > This should fix the build failure of avf_showcqt.c
>> >
>> > An alternative solution would be to add a check for fmin/fmax to 
>> > fate-source and
>> > then to replace them by FFMIN/FFMAX, i can do that if preferred?
>> >
>> > Untested due to lack of a affected platform
>> >
>> > Signed-off-by: Michael Niedermayer 
>> > ---
>> >  configure|8 
>> >  libavutil/libm.h |   28 
>> >  2 files changed, 36 insertions(+)
>> >
>> > diff --git a/configure b/configure
>> > index 95790f4..e6f5d2c 100755
>> > --- a/configure
>> > +++ b/configure
>> > @@ -1770,6 +1770,10 @@ MATH_FUNCS="
>> >  exp2
>> >  exp2f
>> >  expf
>> > +fmax
>> > +fmaxf
>> > +fmin
>> > +fminf
>> >  isinf
>> >  isnan
>> >  ldexpf
>> > @@ -5304,6 +5308,10 @@ check_lib math.h sin -lm && LIBM="-lm"
>> >  disabled crystalhd || check_lib libcrystalhd/libcrystalhd_if.h 
>> > DtsCrystalHDVersion -lcrystalhd || disable crystalhd
>> >
>> >  atan2f_args=2
>> > +fmax_args=2
>> > +fmaxf_args=2
>> > +fmin_args=2
>> > +fminf_args=2
>> >  copysign_args=2
>> >  ldexpf_args=2
>> >  powf_args=2
>> > diff --git a/libavutil/libm.h b/libavutil/libm.h
>> > index 6c17b28..ba837a2 100644
>> > --- a/libavutil/libm.h
>> > +++ b/libavutil/libm.h
>> > @@ -43,6 +43,34 @@
>> >  #define atan2f(y, x) ((float)atan2(y, x))
>> >  #endif
>> >
>> > +#if !HAVE_FMAX
>> > +#undef fmax
>> > +static av_always_inline double fmax(double x, double y)
>> > +{
>> > +if (x < y) return y;
>> > +else   return x;
>> > +}
>> > +#endif
>> > +
>> > +#if !HAVE_FMIN
>> > +#undef fmin
>> > +static av_always_inline double fmin(double x, double y)
>> > +{
>> > +if (x < y) return x;
>> > +else   return y;
>> > +}
>> > +#endif
>>
>> Wasn't there a concern that these emulations don't behave identical to
>> the C library versions in regards to NaN handling?
>> I faintly remember something in the previous discussion.
>
> yes, i forgot about that :(
> i replaced them by FFMIN / FFMAX

I might be missing your exact usage of FFMIN/FFMAX, but note
FFMIN/FFMAX by themselves do not do any NaN handling. Maybe this
confusion will be clarified when you post v2. Ideas of achieving this
may be easily obtained in the commit I mentioned above:
4436a8f44dedc83767b3d9da9beb85d1fae2ca30.

>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Those who are best at talking, realize last or never when they are wrong.
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] configure+libm.h: add fmin/fmax/fminf/fmaxf emulation

[Ganesh Ajjanagadde]

On Fri, Oct 30, 2015 at 7:29 PM, Michael Niedermayer
 wrote:
> On Fri, Oct 30, 2015 at 06:53:34PM -0400, Ganesh Ajjanagadde wrote:
>> On Fri, Oct 30, 2015 at 6:35 PM, Michael Niedermayer  
>> wrote:
>> > From: Michael Niedermayer 
>> >
>> > This should fix the build failure of avf_showcqt.c
>> >
>> > An alternative solution would be to add a check for fmin/fmax to 
>> > fate-source and
>> > then to replace them by FFMIN/FFMAX, i can do that if preferred?
>> >
>> > Untested due to lack of a affected platform
>>
>> I recall some interest on my end to get fmin, fmax etc for different
>> reasons, and it was remarked that commit
>> 4436a8f44dedc83767b3d9da9beb85d1fae2ca30 may be relevant. The summary
>> seems to be that getting it to work on all platforms is not so simple.
>
> :/
> ill replace the problematic ones by FFMIN/MAX for now so the build
> failure on the affected msvc platforms is fixed
> tieing a build fix to this complexity would be unwise
>
>
>> I am definitely interested in getting it to work in order to replace
>> FFMAX/FFMIN for floating point in especially libavfilter. This will
>> allow better nan signalling at a slight performance cost.
>
> would that performance cost affect all systems or just ones not
> having fmin/fmax ?
> i think affecting all systems would be bad

A correct fmin and fmax will be slower than FFMIN/FFMAX, simply
because they do NaN handling. How much slower, I have not tested. Also
note that flags may be passed to the compiler to ignore NaN's,
something which can possibly be done locally if desired. However, I
view FFMAX/FFMIN as the cleaner solution if NaN signalling/propagation
is not an issue, so I may not pursue this.

>
> [...]
> --
> 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.
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 11/11] avutil/rational: use frexp rather than ad-hoc log to get floating point exponent

[Ganesh Ajjanagadde]

On Fri, Oct 30, 2015 at 7:14 PM, Michael Niedermayer
 wrote:
> On Thu, Oct 29, 2015 at 12:20:09AM -0400, Ganesh Ajjanagadde wrote:
>> This simplifies and cleans up the code.
>> Furthermore, it is much faster due to absence of the slow log computation.
>>
>> Signed-off-by: Ganesh Ajjanagadde 
>> ---
>>  libavutil/rational.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> LGTM and nice speedup!

pushed, thanks.

>
>
> [...]
> --
> 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
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/vf_deshake: replace qsort with AV_QSORT

[Michael Niedermayer]

On Fri, Oct 30, 2015 at 07:10:52PM -0400, Ganesh Ajjanagadde wrote:
> qsort is called indirectly in filter_frame, suggesting its performance
> criticality. AV_QSORT is substantially faster due to the inlining of the
> comparison callback. Thus, the increase in performance should be worth
> the increase in binary size.
> 
> Sample benchmark (x86-64, Haswell, GNU/Linux):
> File: original from https://trac.ffmpeg.org/ticket/1430
> command: ffmpeg -stream_loop 8 -i file.webm -vf deshake=rx=64:ry=64 -f null -
> 
> Timer truncated at 1024 runs.
> new:
> 28260 decicycles in qsort,   1 runs,  0 skips
> 35570 decicycles in qsort,   2 runs,  0 skips
> 39010 decicycles in qsort,   4 runs,  0 skips
> 46897 decicycles in qsort,   8 runs,  0 skips
> 40442 decicycles in qsort,  16 runs,  0 skips
> 41611 decicycles in qsort,  32 runs,  0 skips
> 40345 decicycles in qsort,  64 runs,  0 skips
> 38967 decicycles in qsort, 128 runs,  0 skips
> 38647 decicycles in qsort, 256 runs,  0 skips
> 40238 decicycles in qsort, 512 runs,  0 skips
> 39676 decicycles in qsort,1024 runs,  0 skips
> 
> old:
> 1740280 decicycles in qsort,   1 runs,  0 skips
>  923560 decicycles in qsort,   2 runs,  0 skips
>  511330 decicycles in qsort,   4 runs,  0 skips
>  309720 decicycles in qsort,   8 runs,  0 skips
>  194900 decicycles in qsort,  16 runs,  0 skips
>  142686 decicycles in qsort,  32 runs,  0 skips
>  112516 decicycles in qsort,  64 runs,  0 skips
>   98166 decicycles in qsort, 128 runs,  0 skips
>   88147 decicycles in qsort, 256 runs,  0 skips
>   88706 decicycles in qsort, 512 runs,  0 skips
>   86783 decicycles in qsort,1024 runs,  0 skips
> 
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavfilter/vf_deshake.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

LGTM

nice speedup

thanks

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

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


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

Re: [FFmpeg-devel] [PATCH] Update Cookies on Setcookie playlist response

[Lucas Andrade]

Em sex, 30 de out de 2015 às 07:44, Michael Niedermayer
 escreveu:

> On Tue, Oct 27, 2015 at 11:28:32AM +, Lucas Andrade wrote:
> > Here is the patch to backport it to release/2.8. To be fixed on 2.8.2.
> > Anything else I should do?
> >
> > ps. Sorry, that's my first time on opensource project, I'm a little
> > confused that I needed to add it to the release branch.
>
> >  hls.c |   31 +++
> >  1 file changed, 15 insertions(+), 16 deletions(-)
> > 6b3c2cdc68e5fe0d9665a22a78837bca7d7b39b9
> b3f3eab029eb429660fc1651a33dafe097cbac0e.patch
> > From b3f3eab029eb429660fc1651a33dafe097cbac0e Mon Sep 17 00:00:00 2001
> > From: Lucas de Andrade 
> > Date: Mon, 26 Oct 2015 10:47:08 -0200
> > Subject: [PATCH] Update Cookies response with Setcookie
> >
> > Context cookies must be updated when a playlist response return
> Setcookie header.
> > Backported to release/2.8
> > ---
> >  libavformat/hls.c | 31 +++
> >  1 file changed, 15 insertions(+), 16 deletions(-)
>
> this patch is against n2.8 not release/2.8
>
> git checkout release/2.8
> git cherry-pick ...
> error: patch failed: libavformat/hls.c:962
> error: libavformat/hls.c: patch does not apply
> Patch failed at 0001 Update Cookies response with Setcookie
> The copy of the patch that failed is found in:
>ffmpeg/.git/rebase-apply/patch
> When you have resolved this problem, run "git am --continue".
> If you prefer to skip this patch, run "git am --skip" instead.
> To restore the original branch and stop patching, run "git am --abort".
>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker.
> User
> questions about the command line tools should be sent to the ffmpeg-user
> ML.
> And questions about how to use libav* should be sent to the libav-user ML.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Sorry, I needed to update release/2.8. It was a previous version.
Here it is.


update cookies on setcookie response.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 8/8] FATE: add crypto protocol test

[Michael Niedermayer]

On Wed, Oct 28, 2015 at 05:39:39AM -0500, Rodger Combs wrote:
> ---
>  tests/Makefile   | 5 +
>  tests/fate/avformat.mak  | 1 +
>  tests/lavf-regression.sh | 9 +
>  tests/ref/lavf/crypto| 3 +++
>  4 files changed, 18 insertions(+)
>  create mode 100644 tests/ref/lavf/crypto
>
> diff --git a/tests/Makefile b/tests/Makefile
> index 7ee4a46..c501813 100644
> --- a/tests/Makefile
> +++ b/tests/Makefile
> @@ -82,6 +82,11 @@ ENCDEC2 = $(call ALLYES, $(firstword $(1))_ENCODER 
> $(lastword $(1))_DECODER  \
>   $(firstword $(2))_ENCODER $(lastword $(2))_DECODER  
> \
>   $(firstword $(3))_MUXER   $(lastword $(3))_DEMUXER)
>
> +ENCDEC2PRO = $(call ALLYES, $(firstword $(1))_ENCODER $(lastword 
> $(1))_DECODER  \
> +$(firstword $(2))_ENCODER $(lastword 
> $(2))_DECODER  \
> +$(firstword $(3))_MUXER   $(lastword 
> $(3))_DEMUXER  \
> +$(firstword $(4))_PROTOCOL)
> +
>  DEMDEC  = $(call ALLYES, $(1)_DEMUXER $(2:%=%_DECODER))
>  ENCMUX  = $(call ALLYES, $(1:%=%_ENCODER) $(2)_MUXER)
>
> diff --git a/tests/fate/avformat.mak b/tests/fate/avformat.mak
> index 1d13434..e65c3f9 100644
> --- a/tests/fate/avformat.mak
> +++ b/tests/fate/avformat.mak
> @@ -6,6 +6,7 @@ FATE_LAVF-$(call ENCDEC,  PCM_S16BE, AU)  
>+= au
>  FATE_LAVF-$(call ENCDEC2, MPEG4,  MP2,   AVI)+= avi
>  FATE_LAVF-$(call ENCDEC,  BMP,   IMAGE2) += bmp
>  FATE_LAVF-$(call ENCDEC,  PCM_S16BE, CAF)+= caf
> +FATE_LAVF-$(call ENCDEC2PRO, MPEG4,   MP2,   NUT, CRYPTO)+= 
> crypto
>  FATE_LAVF-$(call ENCDEC,  DPX,   IMAGE2) += dpx
>  FATE_LAVF-$(call ENCDEC2, DVVIDEO,PCM_S16LE, AVI)+= 
> dv_fmt
>  FATE_LAVF-$(call ENCDEC2, MPEG1VIDEO, MP2,   FFM)+= ffm
> diff --git a/tests/lavf-regression.sh b/tests/lavf-regression.sh
> index a37f714..58287ff 100755

> --- a/tests/lavf-regression.sh
> +++ b/tests/lavf-regression.sh

iam not sure if new fate tests should use lavf-regression.sh
other then that the patch LGTM
also tested on mips qemu, mingw32/64

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

Observe your enemies, for they first find out your faults. -- Antisthenes


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

Re: [FFmpeg-devel] possible farewell; dev policy clarification

[Paul B Mahol]

On 10/30/15, Ganesh Ajjanagadde  wrote:
> Hi all,
>
> Apologies for the length of the email, but there is a lot of stuff I
> would like to cover due to my absence on IRC or other venues for "non
> patch related" discussion.
>
> There has been a lot said and still being said regarding some patches
> I sent and associated discussion. Issues not related to patches in a
> technical sense are being discussed privately.
>
> In the meantime, I have noticed an increased level of hostility on
> ffmpeg-devel lately, both from my end as well as from others. I do not
> wish to escalate it further, and want to let work progress as smoothly
> as possible.
>
> In fact, I repeat a statement I made earlier: if overall people think
> that if I leave better and more work will be done for the project, I
> will gladly do so. That is the only thing I wish for: FFmpeg becoming
> better. To clarify a possible confusion on IRC: I by no means intend
> to work on Libav - either I work for FFmpeg, or not work at all on
> multimedia. This statement holds true regardless of what people
> express about the work I do here, whether I am kicked out, etc.
>
> The reason I repeat this question of leaving is because I dug through
> IRC archives, trying to understand better what people here think of
> the work I do in light of the increasing hostility on the ML. I got
> the sense that a lot of information that I could have received did not
> reach me as I am, and will not be on IRC. I also got the sense that
> there is a section of FFmpeg developers who are deeply against the
> kinds of things I do and the way I handle them, hence prompting the
> question.
>
> Assuming that you feel I give a net positive benefit to the project,
> please read on.
>
> I am quite puzzled with some of the sentiments expressed there. I
> illustrate below what puzzles me, and ask what I can do on my end:
>
> 1. "Sloppy" patches - I tend to give more verbose commit messages to
> explain rationale than many here. I also outlined why I did not post
> benchmarks initially. I myself still think they are unnecessary and
> not useful for many of my proposed changes, but the community here
> seemed to think otherwise. I have hence started posting benchmarks.
> I generally try to give evidence for things that are more "universal"
> in character when possible, so as not to skew towards any particular
> machine architecture, etc. I do not agree that the log patches were
> "sloppy" - bit accuracy improvements for log10 over log should have
> been obvious. Simplification of the code, a subjective aspect, should
> have been quite a reasonable assumption. Do people here not think such
> things are obvious?
>
> 2. "Increasing warnings" - There were only 2 instances AFAIK where I
> made a mistake, one in apedec. Another was in a test build. Both were
> very quickly resolved. These issues were tiny compared to the general
> level of warning cleanups achieved. Both were reasonable mistakes that
> missed the eyes of reviewers. Please do let me know when I do increase
> such things, I try to test things the best I can on my end. I will
> strive to be more cautious in the future by incorporating the lessons
> learnt with these two failures.
>
> 3. Patch sending mechanism - I have tried both approaches, namely an
> en-masse single patch, versus individual tiny patches. Both were
> frowned upon: the en-masse as "not fond of mass changes", and the
> single patches as "incredibly noisy". Regarding pinging, I pinged a
> single patch in a set of similar patches with a phrase regarding the
> fact that the ping extends to other such similar patches. This ping
> was ignored. I push (following the dev policy) one change after
> sufficient delay, and it was frowned upon. I did not know what to do,
> so I subsequently pinged each of the patches. This resulted in a bunch
> of comments on IRC. For reference, these are the av_warn_unused_result
> patches for avutil. Any suggestions for the future?
>
> 4. av_warn_unused_result not being useful en-masse for all headers -
> This was something remarked upon in IRC. I did not get this
> information in the form of reviews. Please suggest which headers to
> target first: I am currently just going one by one in a natural order
> (so that I can keep track of which ones have been addressed). Of
> course, if people think av_warn_unused_result is inherently bad, that
> is a separate issue that reflects an even deeper gulf.
>
> 5. General communication failures - Clearly, a lot of important stuff
> from IRC is not reaching the ML. I (and some others here) do not use
> IRC, and are pretty firm about not using it. What can be done to
> address the communication gap? I would have at least understood the
> deep hostility to the work I do if I had seen IRC logs a few weeks
> back. The ML got only the "effects" and little of the "causes".
> Overall, my sense is that people let the negative reaction bottle up,
> venting every now and then on IRC, since 

Re: [FFmpeg-devel] possible farewell; dev policy clarification

[Derek Buitenhuis]

Hi,

I'll chime in on a few points.

On 10/30/2015 11:34 AM, Ganesh Ajjanagadde wrote:
> 1. "Sloppy" patches - I tend to give more verbose commit messages to
> explain rationale than many here. I also outlined why I did not post
> benchmarks initially. I myself still think they are unnecessary and
> not useful for many of my proposed changes, but the community here
> seemed to think otherwise. I have hence started posting benchmarks.
> I generally try to give evidence for things that are more "universal"
> in character when possible, so as not to skew towards any particular
> machine architecture, etc. I do not agree that the log patches were
> "sloppy" - bit accuracy improvements for log10 over log should have
> been obvious. Simplification of the code, a subjective aspect, should
> have been quite a reasonable assumption. Do people here not think such
> things are obvious?

I am sorry to say, this comes off as a bit arrogant. The onus of proving
a patchset's worth is on its author, and "it's obvious" is not a valid
reasoning. There's no reason to be offended when asked to defend a patch's
value; it's one of the main reasons for reviews in the first place.

> 3. Patch sending mechanism - I have tried both approaches, namely an
> en-masse single patch, versus individual tiny patches. Both were
> frowned upon: the en-masse as "not fond of mass changes", and the
> single patches as "incredibly noisy". Regarding pinging, I pinged a
> single patch in a set of similar patches with a phrase regarding the
> fact that the ping extends to other such similar patches. This ping
> was ignored. I push (following the dev policy) one change after
> sufficient delay, and it was frowned upon. I did not know what to do,
> so I subsequently pinged each of the patches. This resulted in a bunch
> of comments on IRC. For reference, these are the av_warn_unused_result
> patches for avutil. Any suggestions for the future?

One thing you could do is provide a little more rigorous testing / 
investigation.
Example: Making sure libm.h was included everywhere where log10 was used.

Part of the reason people got a bit annoyed is that they are large changesets 
that
are easy to write, and tedious to review and confirm correct. Providing some 
info
to that aspect in the cover letter, for example, can go a long way.

> 5. General communication failures - Clearly, a lot of important stuff
> from IRC is not reaching the ML. I (and some others here) do not use
> IRC, and are pretty firm about not using it. What can be done to
> address the communication gap? I would have at least understood the
> deep hostility to the work I do if I had seen IRC logs a few weeks
> back. The ML got only the "effects" and little of the "causes".
> Overall, my sense is that people let the negative reaction bottle up,
> venting every now and then on IRC, since for whatever reason it is
> more comfortable, although technically both are publicly recorded and
> nearly as easily referenced in mails or commit messages. As a side
> note, even some patch review is done on IRC, a situation I do not like
> but have not raised so far as I am not affected by it.

Valid point, yes.

I do think it is beneficial to have real-time conversation to discuss changes,
sometimes, however. Summaries should probably sent to the ML, though, for
"archival"

Overall, I think you may be too defensive of your own code / ideas sometimes.
That's understandable, but it's important to not take critical reviews so 
harshly,
I believe.

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

Re: [FFmpeg-devel] possible farewell; dev policy clarification

[Clément Bœsch]

On Fri, Oct 30, 2015 at 07:34:29AM -0400, Ganesh Ajjanagadde wrote:
[...]

TL;DR

Reviews are not meant to encourage, reviews are meant to find problems. A
good review is a review where problems are found and pointed out.
Sometimes, reviews mean suggesting way to find issues (which is then
generally up to you). The general state of mind is a defense one.

As a result, you should not take things personally. If you want more
casual communications, you may try IRC. Otherwise, no need to overreact,
just focus on the technical aspect.

Keep up your good work.

Best regards,

-- 
Clément B.


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

Re: [FFmpeg-devel] [PATCH] avutil/file_open: avoid file handle inheritance on Windows

[wm4]

On Fri, 30 Oct 2015 11:30:40 +0100
Tobias Rapp  wrote:

> On 29.10.2015 09:38, Tobias Rapp wrote:
> > Attached patch fixes file lock issues in my Windows application when a
> > child process is started with handle inheritance enabled (standard
> > input/output redirection) while a FFmpeg transcoding is running in the
> > parent process.
> >
> > BTW: It would be great if the patch could also be applied to the 2.7/2.8
> > release branches.  
> 
> Forgot to add links relevant to the subject.
> 
> [1] https://msdn.microsoft.com/en-us/library/w7sa2b22.aspx
> 
> Describes the _wsopen() function and the O_NOINHERIT flag. File handles 
> opened by _wsopen() are inheritable by default.
> 
> [2] 
> https://msdn.microsoft.com/en-us/library/windows/desktop/aa363858%28v=vs.85%29.aspx
> 
> Describes the CreateFile() function. Not directly relevant here, often 
> used in cases outside of C/libc. Opens file without inheritance by 
> default (lpSecurityAttributes is NULL).
> 
> [3] 
> https://msdn.microsoft.com/en-us/library/windows/desktop/ms682425%28v=vs.85%29.aspx
> 
> Describes handle inheritance when creating new processes. Handle 
> inheritance must be enabled (bInheritHandles = TRUE) e.g. when you want 
> to pass handles for stdin/stdout via lpStartupInfo.

Would be great if you could put all this stuff into the commit message.

Would it make sense to define O_CLOEXEC to O_NOINHERIT on Windows?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] possible farewell; dev policy clarification

[Nicolas George]

Hi.

I am not on IRC either, so I can not comment on what happen there. I hope I
have not shown myself what you consider hostility on this list. I will try
to explain what I think may irritate people in your actions on this list.

I will not comment on the issue of pushing without having addressed
comments and similar issues, they are basically misunderstandings that time
will fix.

In short: you should have already moved to the next level.

In less short: you have found a few easy ways of enhancing the code
(consistency in variable naming, enabling warnings and fixing them), and
made good of them. Very well. There is nothing wrong with starting easy,
almost everybody did.

But now, you continue digging in the same veins, although they are mostly
dry. For example, the integer stuff: yes, theoretically it violates the C
standard, but most of it will never be an issue, because the extra
assumptions it makes (32-bits integer, two's complement for sign) will be
kept for ever. Remember that FFmpeg's code is significantly above standard
when it comes to portability: if FFmpeg breaks, a lot more program break
too, and that would not be acceptable for the people who design compilers.

After your first contributions, people will expect that you would have
become capable of evaluating the value of these bugfixes. Remember that even
a small and obviously correct fix has drawbacks: it may cause merge
conflicts, and therefore more work for Hendrik, it pollutes the output of
git blame and may take one more git bissect step. And simply it may make the
code slightly less readable.

For example, the log10 stuff: yes, the change is valid, but in most places,
it does not matter at all, the extra accuracy and speed are irrelevant. So
do not waste your time, and the time of the people you ask to review your
patches, on this. If you find a place where the difference is critical, then
of course go ahead, well done; if you see new code that should use log10,
comment before it is applied; all this is worthy. But for most of the
existing code, leave it be, because the enhancement is too small compared to
the drawbacks.

And for yourself: how much thinking efforts did you need to produce the
log10 patches? My guess is: almost none at all, you noticed the possible
change and the rest was completely straightforward. Does it satisfy you?

Instead, start spending your efforts on more difficult tasks. That is what I
meant by "next level". Unless I am misremembering, all your changes only had
a local influence: the syntax of an integer constant, a formula or a
function call, at most, a whole mathematical function. But you have the
skill to try to understand how the function interact with each other, to
address issues that require understanding how a whole subsystem works.

If you need ideas on what to try, look at the trac ticket, especially the
ones that are "reproduced by developer" (so you know it is not just a
PEBKAC) but not "analyzed by developer". But if dealing with people's bugs
annoy you, there are plenty of tasks where your skills could be useful: just
find some aspect of FFmpeg's behaviour that you find annoying and try to
find a way of enhancing it. Error messages drowned under information
messages, more readable output for the stream summaries, etc. And of course,
there are many ideas floating around: non-blocking demuxers (hard), more
FATE coverage, simplifying codex context cleanup, DATA media type in lavfi
(hard), merging the libraries in a single one. And of course, you can come
up with your own ideas completely out of the box: a GUI to explore codec
options? make an API to access the documentation? a web interface to manage
patches?

So to summary my advice: try to attack harder problems, you are ready for it
and that would make your contributions even more valuable and well received.

HTH

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] possible farewell; dev policy clarification

[Ganesh Ajjanagadde]

On Fri, Oct 30, 2015 at 10:07 AM, Nicolas George  wrote:
> Hi.
>
> I am not on IRC either, so I can not comment on what happen there. I hope I
> have not shown myself what you consider hostility on this list. I will try
> to explain what I think may irritate people in your actions on this list.
>
> I will not comment on the issue of pushing without having addressed
> comments and similar issues, they are basically misunderstandings that time
> will fix.
>
> In short: you should have already moved to the next level.
>
> In less short: you have found a few easy ways of enhancing the code
> (consistency in variable naming, enabling warnings and fixing them), and
> made good of them. Very well. There is nothing wrong with starting easy,
> almost everybody did.

I guess this boiled down to a question of timing: I kept postponing
the plan to move to the "next level". Maybe I took too much comfort in
simple changes, without considering the negative "social aspects". I
personally had set roughly Jan/Feb of next year for such a move. Your
comments and other reactions have convinced me that is best if I do so
ASAP.

Here is the solution I propose. I do not want to leave mini-projects I
began unfinished. However, I understand the negative reactions. I will
limit "cosmetic/simple changes" to one patch per day (at max) to not
flood the ML. This will slowly let me get rid of e.g
av_warn_unused_result baggage, while transitioning to other work. Does
this sound agreeable to all?

>
> But now, you continue digging in the same veins, although they are mostly
> dry. For example, the integer stuff: yes, theoretically it violates the C
> standard, but most of it will never be an issue, because the extra
> assumptions it makes (32-bits integer, two's complement for sign) will be
> kept for ever. Remember that FFmpeg's code is significantly above standard
> when it comes to portability: if FFmpeg breaks, a lot more program break
> too, and that would not be acceptable for the people who design compilers.
>
> After your first contributions, people will expect that you would have
> become capable of evaluating the value of these bugfixes. Remember that even
> a small and obviously correct fix has drawbacks: it may cause merge
> conflicts, and therefore more work for Hendrik, it pollutes the output of
> git blame and may take one more git bissect step. And simply it may make the
> code slightly less readable.

Point noted.

>
> For example, the log10 stuff: yes, the change is valid, but in most places,
> it does not matter at all, the extra accuracy and speed are irrelevant. So
> do not waste your time, and the time of the people you ask to review your
> patches, on this. If you find a place where the difference is critical, then
> of course go ahead, well done; if you see new code that should use log10,
> comment before it is applied; all this is worthy. But for most of the
> existing code, leave it be, because the enhancement is too small compared to
> the drawbacks.
>
> And for yourself: how much thinking efforts did you need to produce the
> log10 patches? My guess is: almost none at all, you noticed the possible
> change and the rest was completely straightforward. Does it satisfy you?

I would have been ok if it did not result in this much ML noise. But
given the overall episode, I do regret it.
None of these things are satisfying, but to be honest, I am not
looking for satisfaction from FFmpeg.
I am looking for a way to channel frittered away energy obtained
during my transition from undergraduate to graduate life and its
associated increase in flexibility of time allocation.
In other words, I want a way to spend my down-time that is technical
in character.

>
> Instead, start spending your efforts on more difficult tasks. That is what I
> meant by "next level". Unless I am misremembering, all your changes only had
> a local influence: the syntax of an integer constant, a formula or a
> function call, at most, a whole mathematical function. But you have the
> skill to try to understand how the function interact with each other, to
> address issues that require understanding how a whole subsystem works.

Looking back, I think the first commits I made were perhaps among the
best ones I did: they were simple, but fixed tickets in clean ways. I
can take it to the next level by focusing on ones that require
understanding of interactions. Or perhaps the closest example to what
you have in mind is the ffplay volume control, it is something I
personally found annoying (I solely use ffplay for playback, mpv and
vlc are not even installed on my system). On a lighthearted note, the
reason for my setup is because by default, ffplay displays a
spectrogram for audio files which appealed a lot to some of my signal
processing background :). Any mpv/VLC people can take this as an
informal "feature request" - VLC definitely did not do this a year
back.

>
> If you need ideas on what to try, look at the trac ticket, 

Re: [FFmpeg-devel] [PATCH] avutil/mathematics: correct documentation for av_gcd

[Clément Bœsch]

On Thu, Oct 29, 2015 at 07:49:44PM -0400, Ganesh Ajjanagadde wrote:
[...]
> although you did explain to me where optimizations could be useful at
> an algorithmic level privately, I take this as an opportunity to
> request for general comments on places that people think could benefit
> from performance at a C/algorithmic level (NOT asm/simd stuff for me
> personally): yet another ping for Clement.

Mmh... without SIMD let me think...

You may look at the TODO in libavfilter/f_ebur128.c. There is a PRE-filter
and a RLB-filter to merge into one to reduce computation time. This is an
already solved mathematical problem. You may want to have a look, it's
most likely a good way to speed up that filter algorithmically.

Then maybe you can look into adding threading support in some codecs or
filters.

No other idea that do not involve SIMD right now.

[...]

-- 
Clément B.


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

Re: [FFmpeg-devel] possible farewell; dev policy clarification

[Michael Niedermayer]

On Fri, Oct 30, 2015 at 01:42:30PM +0100, Paul B Mahol wrote:
> On 10/30/15, Ganesh Ajjanagadde  wrote:
[...]
> > e) I have no personal interest in asm optimizations (to address a
> > suggestion on IRC). I do appreciate the hard work there, it just does
> > not appeal to me for reasons that I can answer privately. I am
> > interested in security aspects, algorithmic improvements, bug fixes,
> > and clean up (in that order). Currently I am trying to get rid of a
> > lot of the last aspect to create a foundation for myself to work on
> > other things. Part of that transition is already under way - see e.g
> > av_gcd patches as an algorithmic improvement.
> >
> > Please feel free to add things, send private email, or public
> > questions so that we can come to a better understanding.
> 
> I'm just going to tell you that you should ask before pushing something
> that was not explicitly approved or even worse, was rejected.

There where alot of patches, and i mean alot of good patches
but its sometimes difficult to keep track of who said what in patch
review. I do think i checked and approved the log* patches that where
pushed yesterday.

more generally
Its possible for review comments to be misunderstood, or even
forgotten, both by other reviewers, the author or commiter,
I do not think that this leads to any technical problem in practice
as people notice very quickly when their comments have not been taken
care of the way they expected
What i like to ask people is to, if that happens not to assume mallice
because that is neither likely nor would it be productive to assume
that.
If something gets ignored it is IMO basically always some
misunderstanding or mistake.

Now maybe there are also some simple and small technical changes that
could reduce confusion.
One would maybe be to add a "Approved-by:" or "Reviewed-by:" line to
commit messages when the reviewer differs from the commiter and
author
This way one can see at a first glance who approved/reviewed each
patch. I dont think this needs to be always added but maybe in cases
where there is already some confusion it
could maybe avoid further misuderstandings

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

DNS cache poisoning attacks, popular search engine, Google internet authority
dont be evil, please


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

Re: [FFmpeg-devel] [PATCH] avutil/file_open: avoid file handle inheritance on Windows

[Tobias Rapp]

On 30.10.2015 11:54, Hendrik Leppkes wrote:

On Fri, Oct 30, 2015 at 11:30 AM, Tobias Rapp  wrote:

On 29.10.2015 09:38, Tobias Rapp wrote:


Attached patch fixes file lock issues in my Windows application when a
child process is started with handle inheritance enabled (standard
input/output redirection) while a FFmpeg transcoding is running in the
parent process.

BTW: It would be great if the patch could also be applied to the 2.7/2.8
release branches.



Forgot to add links relevant to the subject.

[1] https://msdn.microsoft.com/en-us/library/w7sa2b22.aspx

Describes the _wsopen() function and the O_NOINHERIT flag. File handles
opened by _wsopen() are inheritable by default.

[2]
https://msdn.microsoft.com/en-us/library/windows/desktop/aa363858%28v=vs.85%29.aspx

Describes the CreateFile() function. Not directly relevant here, often used
in cases outside of C/libc. Opens file without inheritance by default
(lpSecurityAttributes is NULL).

[3]
https://msdn.microsoft.com/en-us/library/windows/desktop/ms682425%28v=vs.85%29.aspx

Describes handle inheritance when creating new processes. Handle inheritance
must be enabled (bInheritHandles = TRUE) e.g. when you want to pass handles
for stdin/stdout via lpStartupInfo.



Its probably fine, the only concerns I can think of is what happens if
you try use ffmpeg.exe as a subprocess operating on a pipe fed by the
parent process, would this still work?


Yes, in that case you can still create your pipe handle and explicitly 
set bInheritHandle = TRUE in the security attributes. Then pass the 
handle to ffmpeg.exe. This is basically what I'm currently doing except 
that I pass the pipe handles as stdin/stdout to the client ffmpeg.exe 
process instead of using them within some "pipe:1234" protocol URL.


Regards,
Tobias

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

[FFmpeg-devel] [PATCH] configure+libm.h: add fmin/fmax/fminf/fmaxf emulation

[Michael Niedermayer]

From: Michael Niedermayer 

This should fix the build failure of avf_showcqt.c

An alternative solution would be to add a check for fmin/fmax to fate-source and
then to replace them by FFMIN/FFMAX, i can do that if preferred?

Untested due to lack of a affected platform

Signed-off-by: Michael Niedermayer 
---
 configure|8 
 libavutil/libm.h |   28 
 2 files changed, 36 insertions(+)

diff --git a/configure b/configure
index 95790f4..e6f5d2c 100755
--- a/configure
+++ b/configure
@@ -1770,6 +1770,10 @@ MATH_FUNCS="
 exp2
 exp2f
 expf
+fmax
+fmaxf
+fmin
+fminf
 isinf
 isnan
 ldexpf
@@ -5304,6 +5308,10 @@ check_lib math.h sin -lm && LIBM="-lm"
 disabled crystalhd || check_lib libcrystalhd/libcrystalhd_if.h 
DtsCrystalHDVersion -lcrystalhd || disable crystalhd
 
 atan2f_args=2
+fmax_args=2
+fmaxf_args=2
+fmin_args=2
+fminf_args=2
 copysign_args=2
 ldexpf_args=2
 powf_args=2
diff --git a/libavutil/libm.h b/libavutil/libm.h
index 6c17b28..ba837a2 100644
--- a/libavutil/libm.h
+++ b/libavutil/libm.h
@@ -43,6 +43,34 @@
 #define atan2f(y, x) ((float)atan2(y, x))
 #endif
 
+#if !HAVE_FMAX
+#undef fmax
+static av_always_inline double fmax(double x, double y)
+{
+if (x < y) return y;
+else   return x;
+}
+#endif
+
+#if !HAVE_FMIN
+#undef fmin
+static av_always_inline double fmin(double x, double y)
+{
+if (x < y) return x;
+else   return y;
+}
+#endif
+
+#if !HAVE_FMAXF
+#undef fmaxf
+#define fmaxf(y, x) ((float)fmax(y, x))
+#endif
+
+#if !HAVE_FMINF
+#undef fminf
+#define fminf(y, x) ((float)fmin(y, x))
+#endif
+
 #if !HAVE_POWF
 #undef powf
 #define powf(x, y) ((float)pow(x, y))
-- 
1.7.9.5

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

Re: [FFmpeg-devel] [PATCHv2] avutil/file_open: avoid file handle inheritance on Windows

[Tobias Rapp]

On 30.10.2015 15:06, wm4 wrote:

On Fri, 30 Oct 2015 11:30:40 +0100
Tobias Rapp  wrote:


On 29.10.2015 09:38, Tobias Rapp wrote:

Attached patch fixes file lock issues in my Windows application when a
child process is started with handle inheritance enabled (standard
input/output redirection) while a FFmpeg transcoding is running in the
parent process.

BTW: It would be great if the patch could also be applied to the 2.7/2.8
release branches.


Forgot to add links relevant to the subject.

[1] https://msdn.microsoft.com/en-us/library/w7sa2b22.aspx

Describes the _wsopen() function and the O_NOINHERIT flag. File handles
opened by _wsopen() are inheritable by default.

[2]
https://msdn.microsoft.com/en-us/library/windows/desktop/aa363858%28v=vs.85%29.aspx

Describes the CreateFile() function. Not directly relevant here, often
used in cases outside of C/libc. Opens file without inheritance by
default (lpSecurityAttributes is NULL).

[3]
https://msdn.microsoft.com/en-us/library/windows/desktop/ms682425%28v=vs.85%29.aspx

Describes handle inheritance when creating new processes. Handle
inheritance must be enabled (bInheritHandles = TRUE) e.g. when you want
to pass handles for stdin/stdout via lpStartupInfo.


Would be great if you could put all this stuff into the commit message.


Have attached a more verbose version of the patch.


Would it make sense to define O_CLOEXEC to O_NOINHERIT on Windows?


Although to my knowledge O_CLOEXEC and O_NOINHERIT cause the same 
behavior it would be confusing to trace when O_CLOEXEC maps to the 
original Linux definition and when it maps to the Windows override when 
reading source code. If someone finds it useful a definition like 
FF_O_CLOEXEC could be added (to which file?) that maps to the correct 
flag depending on the platform.


Regards,
Tobias
>From c2b599c18a173ce3a2f053701bc4ef1f14ef7aea Mon Sep 17 00:00:00 2001
From: Tobias Rapp 
Date: Thu, 29 Oct 2015 09:11:37 +0100
Subject: [PATCH] avutil/file_open: avoid file handle inheritance on Windows

Avoids inheritance of file handles on Windows systems similar to the
O_CLOEXEC/FD_CLOEXEC flag on Linux.

Fixes file lock issues in Windows applications when a child process
is started with handle inheritance enabled (standard input/output
redirection) while a FFmpeg transcoding is running in the parent
process.

Links relevant to the subject:

https://msdn.microsoft.com/en-us/library/w7sa2b22.aspx

Describes the _wsopen() function and the O_NOINHERIT flag. File handles
opened by _wsopen() are inheritable by default.

https://msdn.microsoft.com/en-us/library/windows/desktop/ms682425%28v=vs.85%29.aspx

Describes handle inheritance when creating new processes. Handle
inheritance must be enabled (bInheritHandles = TRUE) e.g. when you want
to pass handles for stdin/stdout via lpStartupInfo.

Signed-off-by: Tobias Rapp 
---
 libavutil/file_open.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libavutil/file_open.c b/libavutil/file_open.c
index 3f9a67c..9e76127 100644
--- a/libavutil/file_open.c
+++ b/libavutil/file_open.c
@@ -77,6 +77,9 @@ int avpriv_open(const char *filename, int flags, ...)
 #ifdef O_CLOEXEC
 flags |= O_CLOEXEC;
 #endif
+#ifdef O_NOINHERIT
+flags |= O_NOINHERIT;
+#endif
 
 fd = open(filename, flags, mode);
 #if HAVE_FCNTL
-- 
1.9.1

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

Re: [FFmpeg-devel] possible farewell; dev policy clarification

[Ganesh Ajjanagadde]

On Fri, Oct 30, 2015 at 8:42 AM, Paul B Mahol  wrote:
> On 10/30/15, Ganesh Ajjanagadde  wrote:
>> Hi all,
>>
>> Apologies for the length of the email, but there is a lot of stuff I
>> would like to cover due to my absence on IRC or other venues for "non
>> patch related" discussion.
>>
>> There has been a lot said and still being said regarding some patches
>> I sent and associated discussion. Issues not related to patches in a
>> technical sense are being discussed privately.
>>
>> In the meantime, I have noticed an increased level of hostility on
>> ffmpeg-devel lately, both from my end as well as from others. I do not
>> wish to escalate it further, and want to let work progress as smoothly
>> as possible.
>>
>> In fact, I repeat a statement I made earlier: if overall people think
>> that if I leave better and more work will be done for the project, I
>> will gladly do so. That is the only thing I wish for: FFmpeg becoming
>> better. To clarify a possible confusion on IRC: I by no means intend
>> to work on Libav - either I work for FFmpeg, or not work at all on
>> multimedia. This statement holds true regardless of what people
>> express about the work I do here, whether I am kicked out, etc.
>>
>> The reason I repeat this question of leaving is because I dug through
>> IRC archives, trying to understand better what people here think of
>> the work I do in light of the increasing hostility on the ML. I got
>> the sense that a lot of information that I could have received did not
>> reach me as I am, and will not be on IRC. I also got the sense that
>> there is a section of FFmpeg developers who are deeply against the
>> kinds of things I do and the way I handle them, hence prompting the
>> question.
>>
>> Assuming that you feel I give a net positive benefit to the project,
>> please read on.
>>
>> I am quite puzzled with some of the sentiments expressed there. I
>> illustrate below what puzzles me, and ask what I can do on my end:
>>
>> 1. "Sloppy" patches - I tend to give more verbose commit messages to
>> explain rationale than many here. I also outlined why I did not post
>> benchmarks initially. I myself still think they are unnecessary and
>> not useful for many of my proposed changes, but the community here
>> seemed to think otherwise. I have hence started posting benchmarks.
>> I generally try to give evidence for things that are more "universal"
>> in character when possible, so as not to skew towards any particular
>> machine architecture, etc. I do not agree that the log patches were
>> "sloppy" - bit accuracy improvements for log10 over log should have
>> been obvious. Simplification of the code, a subjective aspect, should
>> have been quite a reasonable assumption. Do people here not think such
>> things are obvious?
>>
>> 2. "Increasing warnings" - There were only 2 instances AFAIK where I
>> made a mistake, one in apedec. Another was in a test build. Both were
>> very quickly resolved. These issues were tiny compared to the general
>> level of warning cleanups achieved. Both were reasonable mistakes that
>> missed the eyes of reviewers. Please do let me know when I do increase
>> such things, I try to test things the best I can on my end. I will
>> strive to be more cautious in the future by incorporating the lessons
>> learnt with these two failures.
>>
>> 3. Patch sending mechanism - I have tried both approaches, namely an
>> en-masse single patch, versus individual tiny patches. Both were
>> frowned upon: the en-masse as "not fond of mass changes", and the
>> single patches as "incredibly noisy". Regarding pinging, I pinged a
>> single patch in a set of similar patches with a phrase regarding the
>> fact that the ping extends to other such similar patches. This ping
>> was ignored. I push (following the dev policy) one change after
>> sufficient delay, and it was frowned upon. I did not know what to do,
>> so I subsequently pinged each of the patches. This resulted in a bunch
>> of comments on IRC. For reference, these are the av_warn_unused_result
>> patches for avutil. Any suggestions for the future?
>>
>> 4. av_warn_unused_result not being useful en-masse for all headers -
>> This was something remarked upon in IRC. I did not get this
>> information in the form of reviews. Please suggest which headers to
>> target first: I am currently just going one by one in a natural order
>> (so that I can keep track of which ones have been addressed). Of
>> course, if people think av_warn_unused_result is inherently bad, that
>> is a separate issue that reflects an even deeper gulf.
>>
>> 5. General communication failures - Clearly, a lot of important stuff
>> from IRC is not reaching the ML. I (and some others here) do not use
>> IRC, and are pretty firm about not using it. What can be done to
>> address the communication gap? I would have at least understood the
>> deep hostility to the work I do if I had seen IRC logs a few weeks
>> back. The ML got 

Re: [FFmpeg-devel] [PATCH] avutil/mathematics: correct documentation for av_gcd

[Michael Niedermayer]

On Tue, Oct 27, 2015 at 08:18:34PM -0400, Ganesh Ajjanagadde wrote:
> av_gcd is now always defined regardless of input. This documents this
> change in the "documented API". Two benefits (closely related):
> 1. The function is robust, and there is no need to worry about INT64_MIN, etc.
> 
> 2. Clients of av_gcd, like av_reduce, can now be made fully correct. 
> Currently,
> av_reduce can trigger undefined behavior if e.g num is INT64_MIN due to
> integer overflow in the FFABS. Furthermore, this undefined behavior is
> completely undocumented, and could be a fuzzer's paradise. The FFABS was 
> needed in the past as
> av_gcd was undefined for negative inputs. In order to make av_reduce
> robust, it is essential to guarantee that av_gcd works for all int64_t.
> 
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavutil/mathematics.h | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/libavutil/mathematics.h b/libavutil/mathematics.h
> index ac94488..6fc2577 100644
> --- a/libavutil/mathematics.h
> +++ b/libavutil/mathematics.h
> @@ -77,9 +77,9 @@ enum AVRounding {
>  };
>  
>  /**
> - * Return the greatest common divisor of a and b.
> - * If both a and b are 0 or either or both are <0 then behavior is
> - * undefined.
> + * Compute the greatest common divisor of a and b.
> + *
> + * @return gcd of a and b up to sign; if a and b are both zero returns 0
>   */
>  int64_t av_const av_gcd(int64_t a, int64_t b);

LGTM

thanks

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

Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope


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

Re: [FFmpeg-devel] [PATCHv3] all: fix enum definition for large values

[Ronald S. Bultje]

Hi,

On Fri, Oct 30, 2015 at 2:11 PM, Ganesh Ajjanagadde 
wrote:

> ISO C restricts enumerator values to the range of int. Thus (for instance)
> 0x8000
> unfortunately does not work, and throws a warning with -Wpedantic on
> clang 3.7.
>
> This fixes it by using alternative expressions that result in identical
> values but do not have this issue.
>
> Tested with FATE.
>
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavcodec/dca_syncwords.h | 26 --
>  libavformat/cinedec.c  | 10 +-
>  libavformat/mov_chan.c |  2 +-
>  3 files changed, 18 insertions(+), 20 deletions(-)
>
> diff --git a/libavcodec/dca_syncwords.h b/libavcodec/dca_syncwords.h
> index 3466b6b..6981cb8 100644
> --- a/libavcodec/dca_syncwords.h
> +++ b/libavcodec/dca_syncwords.h
> @@ -19,19 +19,17 @@
>  #ifndef AVCODEC_DCA_SYNCWORDS_H
>  #define AVCODEC_DCA_SYNCWORDS_H
>
> -enum DCASyncwords {
> -DCA_SYNCWORD_CORE_BE= 0x7FFE8001U,
> -DCA_SYNCWORD_CORE_LE= 0xFE7F0180U,
> -DCA_SYNCWORD_CORE_14B_BE= 0x1FFFE800U,
> -DCA_SYNCWORD_CORE_14B_LE= 0xFF1F00E8U,
> -DCA_SYNCWORD_XCH= 0x5A5A5A5AU,
> -DCA_SYNCWORD_XXCH   = 0x47004A03U,
> -DCA_SYNCWORD_X96= 0x1D95F262U,
> -DCA_SYNCWORD_XBR= 0x655E315EU,
> -DCA_SYNCWORD_LBR= 0x0A801921U,
> -DCA_SYNCWORD_XLL= 0x41A29547U,
> -DCA_SYNCWORD_SUBSTREAM  = 0x64582025U,
> -DCA_SYNCWORD_SUBSTREAM_CORE = 0x02B09261U,
> -};
> +#defineDCA_SYNCWORD_CORE_BE  0x7FFE8001U
> +#defineDCA_SYNCWORD_CORE_LE  0xFE7F0180U
> +#defineDCA_SYNCWORD_CORE_14B_BE  0x1FFFE800U
> +#defineDCA_SYNCWORD_CORE_14B_LE  0xFF1F00E8U
> +#defineDCA_SYNCWORD_XCH  0x5A5A5A5AU
> +#defineDCA_SYNCWORD_XXCH 0x47004A03U
> +#defineDCA_SYNCWORD_X96  0x1D95F262U
> +#defineDCA_SYNCWORD_XBR  0x655E315EU
> +#defineDCA_SYNCWORD_LBR  0x0A801921U
> +#defineDCA_SYNCWORD_XLL  0x41A29547U
> +#defineDCA_SYNCWORD_SUBSTREAM0x64582025U
> +#defineDCA_SYNCWORD_SUBSTREAM_CORE   0x02B09261U
>
>  #endif /* AVCODEC_DCA_SYNCWORDS_H */
> diff --git a/libavformat/cinedec.c b/libavformat/cinedec.c
> index 632f46c..3184084 100644
> --- a/libavformat/cinedec.c
> +++ b/libavformat/cinedec.c
> @@ -49,13 +49,13 @@ enum {
>  CFA_VRIV6 = 2,  /**< BGGR/GRBG */
>  CFA_BAYER = 3,  /**< GB/RG */
>  CFA_BAYERFLIP = 4,  /**< RG/GB */
> -
> -CFA_TLGRAY= 0x8000,
> -CFA_TRGRAY= 0x4000,
> -CFA_BLGRAY= 0x2000,
> -CFA_BRGRAY= 0x1000
>  };
>
> +#define CFA_TLGRAY  0x8000U
> +#define CFA_TRGRAY  0x4000U
> +#define CFA_BLGRAY  0x2000U
> +#define CFA_BRGRAY  0x1000U
> +
>  static int cine_read_probe(AVProbeData *p)
>  {
>  int HeaderSize;
> diff --git a/libavformat/mov_chan.c b/libavformat/mov_chan.c
> index a2fa8d6..cba07c5 100644
> --- a/libavformat/mov_chan.c
> +++ b/libavformat/mov_chan.c
> @@ -45,7 +45,7 @@
>   *do not specify a particular ordering of those channels."
>   */
>  enum MovChannelLayoutTag {
> -MOV_CH_LAYOUT_UNKNOWN   = 0x,
> +#define MOV_CH_LAYOUT_UNKNOWN 0x
>  MOV_CH_LAYOUT_USE_DESCRIPTIONS  = (  0 << 16) | 0,
>  MOV_CH_LAYOUT_USE_BITMAP= (  1 << 16) | 0,
>  MOV_CH_LAYOUT_DISCRETEINORDER   = (147 << 16) | 0,
> --
> 2.6.2


That last one is admittedly quirky, but I guess that's OK.

lgtm.

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

Re: [FFmpeg-devel] [PATCHv3] all: fix enum definition for large values

[Ganesh Ajjanagadde]

On Fri, Oct 30, 2015 at 2:59 PM, Ronald S. Bultje  wrote:
> Hi,
>
> On Fri, Oct 30, 2015 at 2:11 PM, Ganesh Ajjanagadde 
> wrote:
>>
>> ISO C restricts enumerator values to the range of int. Thus (for instance)
>> 0x8000
>> unfortunately does not work, and throws a warning with -Wpedantic on
>> clang 3.7.
>>
>> This fixes it by using alternative expressions that result in identical
>> values but do not have this issue.
>>
>> Tested with FATE.
>>
>> Signed-off-by: Ganesh Ajjanagadde 
>> ---
>>  libavcodec/dca_syncwords.h | 26 --
>>  libavformat/cinedec.c  | 10 +-
>>  libavformat/mov_chan.c |  2 +-
>>  3 files changed, 18 insertions(+), 20 deletions(-)
>>
>> diff --git a/libavcodec/dca_syncwords.h b/libavcodec/dca_syncwords.h
>> index 3466b6b..6981cb8 100644
>> --- a/libavcodec/dca_syncwords.h
>> +++ b/libavcodec/dca_syncwords.h
>> @@ -19,19 +19,17 @@
>>  #ifndef AVCODEC_DCA_SYNCWORDS_H
>>  #define AVCODEC_DCA_SYNCWORDS_H
>>
>> -enum DCASyncwords {
>> -DCA_SYNCWORD_CORE_BE= 0x7FFE8001U,
>> -DCA_SYNCWORD_CORE_LE= 0xFE7F0180U,
>> -DCA_SYNCWORD_CORE_14B_BE= 0x1FFFE800U,
>> -DCA_SYNCWORD_CORE_14B_LE= 0xFF1F00E8U,
>> -DCA_SYNCWORD_XCH= 0x5A5A5A5AU,
>> -DCA_SYNCWORD_XXCH   = 0x47004A03U,
>> -DCA_SYNCWORD_X96= 0x1D95F262U,
>> -DCA_SYNCWORD_XBR= 0x655E315EU,
>> -DCA_SYNCWORD_LBR= 0x0A801921U,
>> -DCA_SYNCWORD_XLL= 0x41A29547U,
>> -DCA_SYNCWORD_SUBSTREAM  = 0x64582025U,
>> -DCA_SYNCWORD_SUBSTREAM_CORE = 0x02B09261U,
>> -};
>> +#defineDCA_SYNCWORD_CORE_BE  0x7FFE8001U
>> +#defineDCA_SYNCWORD_CORE_LE  0xFE7F0180U
>> +#defineDCA_SYNCWORD_CORE_14B_BE  0x1FFFE800U
>> +#defineDCA_SYNCWORD_CORE_14B_LE  0xFF1F00E8U
>> +#defineDCA_SYNCWORD_XCH  0x5A5A5A5AU
>> +#defineDCA_SYNCWORD_XXCH 0x47004A03U
>> +#defineDCA_SYNCWORD_X96  0x1D95F262U
>> +#defineDCA_SYNCWORD_XBR  0x655E315EU
>> +#defineDCA_SYNCWORD_LBR  0x0A801921U
>> +#defineDCA_SYNCWORD_XLL  0x41A29547U
>> +#defineDCA_SYNCWORD_SUBSTREAM0x64582025U
>> +#defineDCA_SYNCWORD_SUBSTREAM_CORE   0x02B09261U
>>
>>  #endif /* AVCODEC_DCA_SYNCWORDS_H */
>> diff --git a/libavformat/cinedec.c b/libavformat/cinedec.c
>> index 632f46c..3184084 100644
>> --- a/libavformat/cinedec.c
>> +++ b/libavformat/cinedec.c
>> @@ -49,13 +49,13 @@ enum {
>>  CFA_VRIV6 = 2,  /**< BGGR/GRBG */
>>  CFA_BAYER = 3,  /**< GB/RG */
>>  CFA_BAYERFLIP = 4,  /**< RG/GB */
>> -
>> -CFA_TLGRAY= 0x8000,
>> -CFA_TRGRAY= 0x4000,
>> -CFA_BLGRAY= 0x2000,
>> -CFA_BRGRAY= 0x1000
>>  };
>>
>> +#define CFA_TLGRAY  0x8000U
>> +#define CFA_TRGRAY  0x4000U
>> +#define CFA_BLGRAY  0x2000U
>> +#define CFA_BRGRAY  0x1000U
>> +
>>  static int cine_read_probe(AVProbeData *p)
>>  {
>>  int HeaderSize;
>> diff --git a/libavformat/mov_chan.c b/libavformat/mov_chan.c
>> index a2fa8d6..cba07c5 100644
>> --- a/libavformat/mov_chan.c
>> +++ b/libavformat/mov_chan.c
>> @@ -45,7 +45,7 @@
>>   *do not specify a particular ordering of those channels."
>>   */
>>  enum MovChannelLayoutTag {
>> -MOV_CH_LAYOUT_UNKNOWN   = 0x,
>> +#define MOV_CH_LAYOUT_UNKNOWN 0x
>>  MOV_CH_LAYOUT_USE_DESCRIPTIONS  = (  0 << 16) | 0,
>>  MOV_CH_LAYOUT_USE_BITMAP= (  1 << 16) | 0,
>>  MOV_CH_LAYOUT_DISCRETEINORDER   = (147 << 16) | 0,
>> --
>> 2.6.2
>
>
> That last one is admittedly quirky, but I guess that's OK.

Yes, I would not classify it as a win-win compromise.

>
> lgtm.

Thanks for the review, pushed.

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

[FFmpeg-devel] [PATCH] avfilter: add audio noise source

[Kyle Swanson]

Signed-off-by: Kyle Swanson 
---
 Changelog|   1 +
 doc/filters.texi |  30 ++
 libavfilter/Makefile |   1 +
 libavfilter/allfilters.c |   1 +
 libavfilter/asrc_noise.c | 141 +++
 libavfilter/version.h|   2 +-
 6 files changed, 175 insertions(+), 1 deletion(-)
 create mode 100644 libavfilter/asrc_noise.c

diff --git a/Changelog b/Changelog
index c49e383..d2ea2e1 100644
--- a/Changelog
+++ b/Changelog
@@ -29,6 +29,7 @@ version :
 - vibrato filter
 - innoHeim/Rsupport Screen Capture Codec decoder
 - ADPCM AICA decoder
+- noise audio source
 
 
 version 2.8:
diff --git a/doc/filters.texi b/doc/filters.texi
index 15ea77a..0d901cc 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -3193,6 +3193,36 @@ ffplay -f lavfi flite=text='No more be grieved for which 
that thou hast done.'
 For more information about libflite, check:
 @url{http://www.speech.cs.cmu.edu/flite/}
 
+@section noise
+
+Generate a white noise audio signal.
+
+The filter accepts the following options:
+
+@table @option
+
+@item sample_rate, r
+Specify the sample rate. Default value is 48000 Hz.
+
+@item duration, d
+Specify the duration of the generated audio stream. Default value is 10 
seconds.
+
+@item amplitude, a
+Specify the amplitude (0.0 - 1.0) of the generated audio stream. Default value 
is 1.0.
+
+@end table
+
+@subsection Examples
+
+@itemize
+
+@item
+Generate 60 seconds of white noise, with a 44.1 kHz sampling rate and an 
amplitude of 0.5:
+@example
+noise=d=60:r=44100:a=0.5
+@end example
+@end itemize
+
 @section sine
 
 Generate an audio signal made of a sine wave with amplitude 1/8.
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index c5819d4..a0b2232 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -93,6 +93,7 @@ OBJS-$(CONFIG_VOLUMEDETECT_FILTER)   += 
af_volumedetect.o
 OBJS-$(CONFIG_AEVALSRC_FILTER)   += aeval.o
 OBJS-$(CONFIG_ANULLSRC_FILTER)   += asrc_anullsrc.o
 OBJS-$(CONFIG_FLITE_FILTER)  += asrc_flite.o
+OBJS-$(CONFIG_NOISE_FILTER)  += asrc_noise.o
 OBJS-$(CONFIG_SINE_FILTER)   += asrc_sine.o
 
 OBJS-$(CONFIG_ANULLSINK_FILTER)  += asink_anullsink.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index a538b81..f820441 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -115,6 +115,7 @@ void avfilter_register_all(void)
 REGISTER_FILTER(AEVALSRC,   aevalsrc,   asrc);
 REGISTER_FILTER(ANULLSRC,   anullsrc,   asrc);
 REGISTER_FILTER(FLITE,  flite,  asrc);
+REGISTER_FILTER(NOISE,  noise,  asrc);
 REGISTER_FILTER(SINE,   sine,   asrc);
 
 REGISTER_FILTER(ANULLSINK,  anullsink,  asink);
diff --git a/libavfilter/asrc_noise.c b/libavfilter/asrc_noise.c
new file mode 100644
index 000..00370a6
--- /dev/null
+++ b/libavfilter/asrc_noise.c
@@ -0,0 +1,141 @@
+/*
+ * Copyright (c) 2015 Kyle Swanson .
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public License
+ * as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public License
+ * along with FFmpeg; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include 
+
+#include "libavutil/opt.h"
+#include "audio.h"
+#include "avfilter.h"
+#include "internal.h"
+#include "libavutil/lfg.h"
+
+typedef struct {
+const AVClass *class;
+int sample_rate;
+double amplitude;
+double dur_sec;
+int64_t dur_samp;
+AVLFG c;
+} NoiseContext;
+
+#define OFFSET(x) offsetof(NoiseContext, x)
+#define FLAGS AV_OPT_FLAG_AUDIO_PARAM|AV_OPT_FLAG_FILTERING_PARAM
+
+static const AVOption noise_options[] = {
+{ "sample_rate", "set sample rate",OFFSET(sample_rate),
AV_OPT_TYPE_INT, {.i64 = 48000}, 15,   INT_MAX,  FLAGS },
+{ "r",   "set sample rate",OFFSET(sample_rate),
AV_OPT_TYPE_INT, {.i64 = 48000}, 15,   INT_MAX,  FLAGS },
+{ "amplitude",   "set amplitude",  OFFSET(amplitude),  
AV_OPT_TYPE_DOUBLE,  {.dbl = 1.},0.,   1.,   FLAGS },
+{ "a",   "set amplitude",  OFFSET(amplitude),  
AV_OPT_TYPE_DOUBLE,  {.dbl = 1.},0.,   1.,   FLAGS },
+{ "duration","set duration",   OFFSET(dur_sec),
AV_OPT_TYPE_DOUBLE,  {.dbl = 10.},   0.,   DBL_MAX,  FLAGS },
+{ 

Re: [FFmpeg-devel] [PATCHv2] avutil/file_open: avoid file handle inheritance on Windows

[wm4]

On Fri, 30 Oct 2015 16:15:30 +0100
Tobias Rapp  wrote:

> On 30.10.2015 15:06, wm4 wrote:
> > On Fri, 30 Oct 2015 11:30:40 +0100
> > Tobias Rapp  wrote:
> >  
> >> On 29.10.2015 09:38, Tobias Rapp wrote:  
> >>> Attached patch fixes file lock issues in my Windows application when a
> >>> child process is started with handle inheritance enabled (standard
> >>> input/output redirection) while a FFmpeg transcoding is running in the
> >>> parent process.
> >>>
> >>> BTW: It would be great if the patch could also be applied to the 2.7/2.8
> >>> release branches.  
> >>
> >> Forgot to add links relevant to the subject.
> >>
> >> [1] https://msdn.microsoft.com/en-us/library/w7sa2b22.aspx
> >>
> >> Describes the _wsopen() function and the O_NOINHERIT flag. File handles
> >> opened by _wsopen() are inheritable by default.
> >>
> >> [2]
> >> https://msdn.microsoft.com/en-us/library/windows/desktop/aa363858%28v=vs.85%29.aspx
> >>
> >> Describes the CreateFile() function. Not directly relevant here, often
> >> used in cases outside of C/libc. Opens file without inheritance by
> >> default (lpSecurityAttributes is NULL).
> >>
> >> [3]
> >> https://msdn.microsoft.com/en-us/library/windows/desktop/ms682425%28v=vs.85%29.aspx
> >>
> >> Describes handle inheritance when creating new processes. Handle
> >> inheritance must be enabled (bInheritHandles = TRUE) e.g. when you want
> >> to pass handles for stdin/stdout via lpStartupInfo.  
> >
> > Would be great if you could put all this stuff into the commit message.  
> 
> Have attached a more verbose version of the patch.

Thanks.

> > Would it make sense to define O_CLOEXEC to O_NOINHERIT on Windows?  
> 
> Although to my knowledge O_CLOEXEC and O_NOINHERIT cause the same 
> behavior it would be confusing to trace when O_CLOEXEC maps to the 
> original Linux definition and when it maps to the Windows override when 
> reading source code. If someone finds it useful a definition like 
> FF_O_CLOEXEC could be added (to which file?) that maps to the correct 
> flag depending on the platform.

OK, since we use it only in 1 place anyway, this is probably not needed.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avfilter/showcqt: fix dependency with avformat

[Muhammad Faiz]

patch attached
From 1902fc28da0b7d03e0f329397691006f9b432079 Mon Sep 17 00:00:00 2001
From: Muhammad Faiz 
Date: Fri, 30 Oct 2015 23:35:02 +0700
Subject: [PATCH] avfilter/showcqt: fix dependency with avformat

---
 configure| 2 +-
 libavfilter/Makefile | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/configure b/configure
index 3f0ef0d..95790f4 100755
--- a/configure
+++ b/configure
@@ -2832,7 +2832,7 @@ scale_filter_deps="swscale"
 scale2ref_filter_deps="swscale"
 select_filter_select="pixelutils"
 smartblur_filter_deps="gpl swscale"
-showcqt_filter_deps="avcodec swscale"
+showcqt_filter_deps="avcodec avformat swscale"
 showcqt_filter_select="fft"
 showfreqs_filter_deps="avcodec"
 showfreqs_filter_select="fft"
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index c5819d4..1b23085 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -272,7 +272,7 @@ OBJS-$(CONFIG_ADRAWGRAPH_FILTER) += f_drawgraph.o
 OBJS-$(CONFIG_APHASEMETER_FILTER)+= avf_aphasemeter.o
 OBJS-$(CONFIG_AVECTORSCOPE_FILTER)   += avf_avectorscope.o
 OBJS-$(CONFIG_CONCAT_FILTER) += avf_concat.o
-OBJS-$(CONFIG_SHOWCQT_FILTER)+= avf_showcqt.o lswsutils.o
+OBJS-$(CONFIG_SHOWCQT_FILTER)+= avf_showcqt.o lswsutils.o lavfutils.o
 OBJS-$(CONFIG_SHOWFREQS_FILTER)  += avf_showfreqs.o
 OBJS-$(CONFIG_SHOWSPECTRUM_FILTER)   += avf_showspectrum.o
 OBJS-$(CONFIG_SHOWVOLUME_FILTER) += avf_showvolume.o
-- 
1.8.3.1

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

Re: [FFmpeg-devel] [PATCH] avutil/wchar_filename: add av_warn_unused_result

[Ganesh Ajjanagadde]

On Fri, Oct 30, 2015 at 6:07 AM, Michael Niedermayer
 wrote:
> On Thu, Oct 15, 2015 at 08:01:56PM -0400, Ganesh Ajjanagadde wrote:
>> Current code is fine, this just adds robustness.
>>
>> Signed-off-by: Ganesh Ajjanagadde 
>> ---
>>  libavutil/wchar_filename.h | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/libavutil/wchar_filename.h b/libavutil/wchar_filename.h
>> index c553c46..2ade321 100644
>> --- a/libavutil/wchar_filename.h
>> +++ b/libavutil/wchar_filename.h
>> @@ -23,6 +23,7 @@
>>  #include 
>>  #include "mem.h"
>>
>> +av_warn_unused_result
>>  static inline int utf8towchar(const char *filename_utf8, wchar_t 
>> **filename_w)
>>  {
>>  int num_chars;
>
> LGTM
>
> thanks

thanks, will push later. Please consider all other
av_warn_unused_result patches dropped; I am going to add in a much
more targeted fashion first. Please don't waste time reviewing them.

>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Asymptotically faster algorithms should always be preferred if you have
> asymptotical amounts of data
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter: add audio noise source

[Paul B Mahol]

On 10/30/15, Kyle Swanson  wrote:
> Signed-off-by: Kyle Swanson 
> ---
>  Changelog|   1 +
>  doc/filters.texi |  30 ++
>  libavfilter/Makefile |   1 +
>  libavfilter/allfilters.c |   1 +
>  libavfilter/asrc_noise.c | 141

asrc_anoisesrc

> +++
>  libavfilter/version.h|   2 +-
>  6 files changed, 175 insertions(+), 1 deletion(-)
>  create mode 100644 libavfilter/asrc_noise.c
>
> diff --git a/Changelog b/Changelog
> index c49e383..d2ea2e1 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -29,6 +29,7 @@ version :
>  - vibrato filter
>  - innoHeim/Rsupport Screen Capture Codec decoder
>  - ADPCM AICA decoder
> +- noise audio source

anoisesrc

>
>
>  version 2.8:
> diff --git a/doc/filters.texi b/doc/filters.texi
> index 15ea77a..0d901cc 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -3193,6 +3193,36 @@ ffplay -f lavfi flite=text='No more be grieved for
> which that thou hast done.'
>  For more information about libflite, check:
>  @url{http://www.speech.cs.cmu.edu/flite/}
>
> +@section noise

anoisesrc

> +
> +Generate a white noise audio signal.

Please add pink and brown noise in same filter, it should be trivial.

> +
> +The filter accepts the following options:
> +
> +@table @option
> +
> +@item sample_rate, r
> +Specify the sample rate. Default value is 48000 Hz.
> +
> +@item duration, d
> +Specify the duration of the generated audio stream. Default value is 10
> seconds.
> +
> +@item amplitude, a
> +Specify the amplitude (0.0 - 1.0) of the generated audio stream. Default
> value is 1.0.
> +
> +@end table
> +
> +@subsection Examples
> +
> +@itemize
> +
> +@item
> +Generate 60 seconds of white noise, with a 44.1 kHz sampling rate and an
> amplitude of 0.5:
> +@example
> +noise=d=60:r=44100:a=0.5
> +@end example
> +@end itemize
> +
>  @section sine
>
>  Generate an audio signal made of a sine wave with amplitude 1/8.
> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> index c5819d4..a0b2232 100644
> --- a/libavfilter/Makefile
> +++ b/libavfilter/Makefile
> @@ -93,6 +93,7 @@ OBJS-$(CONFIG_VOLUMEDETECT_FILTER)   +=
> af_volumedetect.o
>  OBJS-$(CONFIG_AEVALSRC_FILTER)   += aeval.o
>  OBJS-$(CONFIG_ANULLSRC_FILTER)   += asrc_anullsrc.o
>  OBJS-$(CONFIG_FLITE_FILTER)  += asrc_flite.o
> +OBJS-$(CONFIG_NOISE_FILTER)  += asrc_noise.o
>  OBJS-$(CONFIG_SINE_FILTER)   += asrc_sine.o
>
>  OBJS-$(CONFIG_ANULLSINK_FILTER)  += asink_anullsink.o
> diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
> index a538b81..f820441 100644
> --- a/libavfilter/allfilters.c
> +++ b/libavfilter/allfilters.c
> @@ -115,6 +115,7 @@ void avfilter_register_all(void)
>  REGISTER_FILTER(AEVALSRC,   aevalsrc,   asrc);
>  REGISTER_FILTER(ANULLSRC,   anullsrc,   asrc);
>  REGISTER_FILTER(FLITE,  flite,  asrc);
> +REGISTER_FILTER(NOISE,  noise,  asrc);
>  REGISTER_FILTER(SINE,   sine,   asrc);
>
>  REGISTER_FILTER(ANULLSINK,  anullsink,  asink);
> diff --git a/libavfilter/asrc_noise.c b/libavfilter/asrc_noise.c
> new file mode 100644
> index 000..00370a6
> --- /dev/null
> +++ b/libavfilter/asrc_noise.c
> @@ -0,0 +1,141 @@
> +/*
> + * Copyright (c) 2015 Kyle Swanson .
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public License
> + * as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public License
> + * along with FFmpeg; if not, write to the Free Software Foundation, Inc.,
> + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
> + */
> +
> +#include 
> +
> +#include "libavutil/opt.h"
> +#include "audio.h"
> +#include "avfilter.h"
> +#include "internal.h"
> +#include "libavutil/lfg.h"
> +
> +typedef struct {
> +const AVClass *class;
> +int sample_rate;
> +double amplitude;
> +double dur_sec;
> +int64_t dur_samp;
> +AVLFG c;
> +} NoiseContext;
> +
> +#define OFFSET(x) offsetof(NoiseContext, x)
> +#define FLAGS AV_OPT_FLAG_AUDIO_PARAM|AV_OPT_FLAG_FILTERING_PARAM
> +
> +static const AVOption noise_options[] = {
> +{ "sample_rate", "set sample rate",OFFSET(sample_rate),
> AV_OPT_TYPE_INT, {.i64 = 48000}, 15,   INT_MAX,  FLAGS },
> +{ "r",   "set sample rate",OFFSET(sample_rate),
> AV_OPT_TYPE_INT, {.i64 = 48000}, 15,  

Re: [FFmpeg-devel] Idea for a better filter that reduces noise

[Robert Krüger]

On Fri, Oct 30, 2015 at 2:14 AM, P. van Gaans  wrote:

> On 10/29/2015 09:42 AM, Paul B Mahol wrote:
>
>> On 10/29/15, P. van Gaans  wrote:
>>
>>> You all know the CSI episodes where they read a license plate by
>>> "enhancing" some super-grainy security footage. Nonsense, right? Well,
>>> maybe not.. If the car was parked. And it seems what I found doesn't
>>> exist yet. (but perhaps I overlooked it)
>>>
>>> If you quickly want to know what I'm on about, take a look at these
>>> images:
>>>
>>> http://members.ziggo.nl/sinaasappel/images/1_original.jpg (original)
>>> http://members.ziggo.nl/sinaasappel/images/2_40framewind.jpg (40f WIND)
>>> http://members.ziggo.nl/sinaasappel/images/3_wind_hqdn3d.jpg (comparison
>>> with hqdn3d and pp=tn)
>>>
>>> All have limited jpeg compression, but I can deliver PNG files and an
>>> XCF to experiment for yourself if desired.
>>>
>>> So what is WIND? It's what you see if you forget/fail to do motion
>>> detection. (like I did in the images) Also, Wind Is Not a Denoiser. ;-)
>>> It's a way to increase the exposure time of the camera used to shoot a
>>> movie after it's been shot. For the images, I took a 2-second somewhat
>>> grainy clip of a building with nearly no motion. I output the frames to
>>> PNG and load them as layers in The GIMP. I set the opacity for the
>>> bottom layer to 100. The layer above that 50. (100/2) Above that 33.3.
>>> (100/3) 25, 20, 16.7 and so on. Every image with noise is "wrong", some
>>> too dark and some too light. On average, they are spot-on. The
>>> advantage: improved quality and better compression.
>>>
>>> To make this into a proper useable filter, it would need to do this:
>>>
>>> 1. Deshake/stabilize the image.
>>> 2. Divide image in blocks. (e.g. 8x8 pixels)
>>> 3. Figure out it the average color of an 8x8 block is changing during
>>> the next X frames. If not, it's probably not moving and you can average
>>> the values. If it is or is about to, it should be averaged over fewer
>>> frames or not at all. Any area that is about to move will gradually pick
>>> up noise so it doesn't look too unnatural.
>>> 4. Reshake the image.
>>>
>>> Will I do this myself? Maybe, but don't hold your breath. I'm just
>>> sharing this in case somebody finds it interesting and to make sure
>>> nobody can patent it. (assuming it hasn't been done already)
>>>
>>
>> See atadenoise.
>>
>>
>>> Best regards,
>>>
>>> P. van Gaans
>>> ___
>>> 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
>>
>>
> Thanks Paul! I think I scrolled past atadenoise in the docs a while ago
> but had otherwise never heard of it. While searching for it there is little
> to find besides the docs and source code. (i.e. no forum threads or
> mentions in guides or anything) My ffmpeg doesn't even have it so I guess
> it's quite a new thing. I'll first compile a fresh one and get testing. I
> hope atadenoise also performs the deshaking internally as I described since
> I noticed the camera is usually not fixed, without deshaking it won't be
> able to match much.
>
> I still think WIND would have been a funnier name than atadenoise, but I
> don't complain. This will be great if it works as well as my pictures. :-)
>
> afaik it does not deshake but try it anyway. You can read the paper it's
based on, if you're interested in more details. It's mentioned in the
source code.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/5] concatdec: move duration calculating code to open_file

[Nicolas George]

Le quartidi 4 brumaire, an CCXXIV, Marton Balint a écrit :
> Hmm. I need this computed here for the next patch. Maybe we could calcualate
> the duration here and then update it in open_next_file as well?

That is probably possible somehow but a bit tricky. Can you explain why you
need the duration at this point?

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 4/5] concatdec: add metadata for file start time and duration

[Nicolas George]

Le quartidi 4 brumaire, an CCXXIV, Marton Balint a écrit :
> I'd rather keep this as it is, the user has to control the metadata he wants
> in his output, we never promised there won't be additional packet string
> metadata in a certain format, and the way I see it only NUT muxer actually
> parses AV_PKT_DATA_STRINGS_METADATA, and none of the encoders parse AVFrame
> metadata, so it does not really affect anybody.

At some point, some encoders or muxers will take it into account.

> If you still think this is problematic, I can do one or both of these
> options:
> - Add a demuxer option which controls if the demuxer produces this
> metadata or not.
> - Add an ffconcat file global option which controls this.

A demuxer option seems the most natural to me.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH] avutil/frame: add av_warn_unused_result

[Michael Niedermayer]

On Thu, Oct 15, 2015 at 07:47:47PM -0400, Ganesh Ajjanagadde wrote:
> This is going to trigger a lot of warnings all over the place that need
> fixing. Main culprits are in avfilter, when one tries to copy a frame
> without checking whether src and dest formats actually are compatible.

if a filter allocated both source and destination itself with the
same parameters then i think it does not need to check if copy fails

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

The worst form of inequality is to try to make unequal things equal.
-- Aristotle


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

Re: [FFmpeg-devel] [PATCHv2] avutil/buffer: add av_warn_unused_result

[Michael Niedermayer]

On Thu, Oct 15, 2015 at 07:10:47PM -0400, Ganesh Ajjanagadde wrote:
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavutil/buffer.h | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/libavutil/buffer.h b/libavutil/buffer.h
> index b4399fd..e0dbc8a 100644
> --- a/libavutil/buffer.h
> +++ b/libavutil/buffer.h
> @@ -26,6 +26,7 @@
>  #define AVUTIL_BUFFER_H
>  
>  #include 
> +#include "attributes.h"
>  
>  /**
>   * @defgroup lavu_buffer AVBuffer
> @@ -178,6 +179,7 @@ int av_buffer_get_ref_count(const AVBufferRef *buf);
>   *written in its place. On failure, buf is left untouched.
>   * @return 0 on success, a negative AVERROR on failure.
>   */
> +av_warn_unused_result
>  int av_buffer_make_writable(AVBufferRef **buf);

>  
>  /**
> @@ -195,6 +197,7 @@ int av_buffer_make_writable(AVBufferRef **buf);
>   * reference to it (i.e. the one passed to this function). In all other cases
>   * a new buffer is allocated and the data is copied.
>   */
> +av_warn_unused_result
>  int av_buffer_realloc(AVBufferRef **buf, int size);

libavutil/buffer.c in one case checks av_buffer_realloc()
for failure by checking the buf poiner after the call instead
of the return code. This use seems valid


[...]
-- 
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] avutil/file_open: avoid file handle inheritance on Windows

[Hendrik Leppkes]

On Fri, Oct 30, 2015 at 11:30 AM, Tobias Rapp  wrote:
> On 29.10.2015 09:38, Tobias Rapp wrote:
>>
>> Attached patch fixes file lock issues in my Windows application when a
>> child process is started with handle inheritance enabled (standard
>> input/output redirection) while a FFmpeg transcoding is running in the
>> parent process.
>>
>> BTW: It would be great if the patch could also be applied to the 2.7/2.8
>> release branches.
>
>
> Forgot to add links relevant to the subject.
>
> [1] https://msdn.microsoft.com/en-us/library/w7sa2b22.aspx
>
> Describes the _wsopen() function and the O_NOINHERIT flag. File handles
> opened by _wsopen() are inheritable by default.
>
> [2]
> https://msdn.microsoft.com/en-us/library/windows/desktop/aa363858%28v=vs.85%29.aspx
>
> Describes the CreateFile() function. Not directly relevant here, often used
> in cases outside of C/libc. Opens file without inheritance by default
> (lpSecurityAttributes is NULL).
>
> [3]
> https://msdn.microsoft.com/en-us/library/windows/desktop/ms682425%28v=vs.85%29.aspx
>
> Describes handle inheritance when creating new processes. Handle inheritance
> must be enabled (bInheritHandles = TRUE) e.g. when you want to pass handles
> for stdin/stdout via lpStartupInfo.
>

Its probably fine, the only concerns I can think of is what happens if
you try use ffmpeg.exe as a subprocess operating on a pipe fed by the
parent process, would this still work?

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

Re: [FFmpeg-devel] [PATCH] avfilter: add audio noise source

[Nicolas George]

Le nonidi 9 brumaire, an CCXXIV, Kyle Swanson a écrit :
> Signed-off-by: Kyle Swanson 
> ---
>  Changelog|   1 +
>  doc/filters.texi |  30 ++
>  libavfilter/Makefile |   1 +
>  libavfilter/allfilters.c |   1 +
>  libavfilter/asrc_noise.c | 141 
> +++
>  libavfilter/version.h|   2 +-
>  6 files changed, 175 insertions(+), 1 deletion(-)
>  create mode 100644 libavfilter/asrc_noise.c
> 
> diff --git a/Changelog b/Changelog
> index c49e383..d2ea2e1 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -29,6 +29,7 @@ version :
>  - vibrato filter
>  - innoHeim/Rsupport Screen Capture Codec decoder
>  - ADPCM AICA decoder
> +- noise audio source

Thanks for the patch. See comments below.

>  version 2.8:
> diff --git a/doc/filters.texi b/doc/filters.texi
> index 15ea77a..0d901cc 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -3193,6 +3193,36 @@ ffplay -f lavfi flite=text='No more be grieved for 
> which that thou hast done.'
>  For more information about libflite, check:
>  @url{http://www.speech.cs.cmu.edu/flite/}
>  
> +@section noise
> +
> +Generate a white noise audio signal.
> +
> +The filter accepts the following options:
> +
> +@table @option
> +
> +@item sample_rate, r
> +Specify the sample rate. Default value is 48000 Hz.
> +
> +@item duration, d
> +Specify the duration of the generated audio stream. Default value is 10 
> seconds.
> +
> +@item amplitude, a
> +Specify the amplitude (0.0 - 1.0) of the generated audio stream. Default 
> value is 1.0.
> +
> +@end table
> +
> +@subsection Examples
> +
> +@itemize
> +
> +@item
> +Generate 60 seconds of white noise, with a 44.1 kHz sampling rate and an 
> amplitude of 0.5:
> +@example
> +noise=d=60:r=44100:a=0.5
> +@end example
> +@end itemize
> +
>  @section sine
>  
>  Generate an audio signal made of a sine wave with amplitude 1/8.
> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> index c5819d4..a0b2232 100644
> --- a/libavfilter/Makefile
> +++ b/libavfilter/Makefile
> @@ -93,6 +93,7 @@ OBJS-$(CONFIG_VOLUMEDETECT_FILTER)   += 
> af_volumedetect.o
>  OBJS-$(CONFIG_AEVALSRC_FILTER)   += aeval.o
>  OBJS-$(CONFIG_ANULLSRC_FILTER)   += asrc_anullsrc.o
>  OBJS-$(CONFIG_FLITE_FILTER)  += asrc_flite.o
> +OBJS-$(CONFIG_NOISE_FILTER)  += asrc_noise.o
>  OBJS-$(CONFIG_SINE_FILTER)   += asrc_sine.o
>  
>  OBJS-$(CONFIG_ANULLSINK_FILTER)  += asink_anullsink.o
> diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
> index a538b81..f820441 100644
> --- a/libavfilter/allfilters.c
> +++ b/libavfilter/allfilters.c
> @@ -115,6 +115,7 @@ void avfilter_register_all(void)
>  REGISTER_FILTER(AEVALSRC,   aevalsrc,   asrc);
>  REGISTER_FILTER(ANULLSRC,   anullsrc,   asrc);
>  REGISTER_FILTER(FLITE,  flite,  asrc);
> +REGISTER_FILTER(NOISE,  noise,  asrc);
>  REGISTER_FILTER(SINE,   sine,   asrc);
>  
>  REGISTER_FILTER(ANULLSINK,  anullsink,  asink);
> diff --git a/libavfilter/asrc_noise.c b/libavfilter/asrc_noise.c
> new file mode 100644
> index 000..00370a6
> --- /dev/null
> +++ b/libavfilter/asrc_noise.c
> @@ -0,0 +1,141 @@
> +/*
> + * Copyright (c) 2015 Kyle Swanson .
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public License
> + * as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public License
> + * along with FFmpeg; if not, write to the Free Software Foundation, Inc.,
> + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
> + */
> +
> +#include 
> +
> +#include "libavutil/opt.h"
> +#include "audio.h"
> +#include "avfilter.h"
> +#include "internal.h"
> +#include "libavutil/lfg.h"
> +
> +typedef struct {
> +const AVClass *class;
> +int sample_rate;
> +double amplitude;
> +double dur_sec;
> +int64_t dur_samp;

> +AVLFG c;

The doxy for it says:

 * Please also consider a simple LCG like state= state*1664525+1013904223,
 * it may be good enough and faster for your specific use case.

Did you test in terms of speed and noise quality? I used this exact LCG for
the pink noise and it sounds fine. The LCG has an additional bonus on top of
speed: it is seekable; it may come in handy at a later time.

> +} NoiseContext;
> +
> +#define OFFSET(x) offsetof(NoiseContext, x)
> +#define FLAGS 

Re: [FFmpeg-devel] [PATCH] avutil/mathematics: correct documentation for av_gcd

[Ganesh Ajjanagadde]

On Fri, Oct 30, 2015 at 12:16 PM, Michael Niedermayer
 wrote:
> On Tue, Oct 27, 2015 at 08:18:34PM -0400, Ganesh Ajjanagadde wrote:
>> av_gcd is now always defined regardless of input. This documents this
>> change in the "documented API". Two benefits (closely related):
>> 1. The function is robust, and there is no need to worry about INT64_MIN, 
>> etc.
>>
>> 2. Clients of av_gcd, like av_reduce, can now be made fully correct. 
>> Currently,
>> av_reduce can trigger undefined behavior if e.g num is INT64_MIN due to
>> integer overflow in the FFABS. Furthermore, this undefined behavior is
>> completely undocumented, and could be a fuzzer's paradise. The FFABS was 
>> needed in the past as
>> av_gcd was undefined for negative inputs. In order to make av_reduce
>> robust, it is essential to guarantee that av_gcd works for all int64_t.
>>
>> Signed-off-by: Ganesh Ajjanagadde 
>> ---
>>  libavutil/mathematics.h | 6 +++---
>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/libavutil/mathematics.h b/libavutil/mathematics.h
>> index ac94488..6fc2577 100644
>> --- a/libavutil/mathematics.h
>> +++ b/libavutil/mathematics.h
>> @@ -77,9 +77,9 @@ enum AVRounding {
>>  };
>>
>>  /**
>> - * Return the greatest common divisor of a and b.
>> - * If both a and b are 0 or either or both are <0 then behavior is
>> - * undefined.
>> + * Compute the greatest common divisor of a and b.
>> + *
>> + * @return gcd of a and b up to sign; if a and b are both zero returns 0
>>   */
>>  int64_t av_const av_gcd(int64_t a, int64_t b);
>
> LGTM
>
> thanks

pushed, thanks

>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avutil/wchar_filename: add av_warn_unused_result

[Ganesh Ajjanagadde]

On Fri, Oct 30, 2015 at 12:57 PM, Ganesh Ajjanagadde  wrote:
> On Fri, Oct 30, 2015 at 6:07 AM, Michael Niedermayer
>  wrote:
>> On Thu, Oct 15, 2015 at 08:01:56PM -0400, Ganesh Ajjanagadde wrote:
>>> Current code is fine, this just adds robustness.
>>>
>>> Signed-off-by: Ganesh Ajjanagadde 
>>> ---
>>>  libavutil/wchar_filename.h | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/libavutil/wchar_filename.h b/libavutil/wchar_filename.h
>>> index c553c46..2ade321 100644
>>> --- a/libavutil/wchar_filename.h
>>> +++ b/libavutil/wchar_filename.h
>>> @@ -23,6 +23,7 @@
>>>  #include 
>>>  #include "mem.h"
>>>
>>> +av_warn_unused_result
>>>  static inline int utf8towchar(const char *filename_utf8, wchar_t 
>>> **filename_w)
>>>  {
>>>  int num_chars;
>>
>> LGTM
>>
>> thanks
>
> thanks, will push later. Please consider all other
> av_warn_unused_result patches dropped; I am going to add in a much
> more targeted fashion first. Please don't waste time reviewing them.

pushed
>
>>
>> [...]
>> --
>> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>>
>> Asymptotically faster algorithms should always be preferred if you have
>> asymptotical amounts of data
>>
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCHv3] all: fix enum definition for large values

[Ganesh Ajjanagadde]

ISO C restricts enumerator values to the range of int. Thus (for instance) 
0x8000
unfortunately does not work, and throws a warning with -Wpedantic on
clang 3.7.

This fixes it by using alternative expressions that result in identical
values but do not have this issue.

Tested with FATE.

Signed-off-by: Ganesh Ajjanagadde 
---
 libavcodec/dca_syncwords.h | 26 --
 libavformat/cinedec.c  | 10 +-
 libavformat/mov_chan.c |  2 +-
 3 files changed, 18 insertions(+), 20 deletions(-)

diff --git a/libavcodec/dca_syncwords.h b/libavcodec/dca_syncwords.h
index 3466b6b..6981cb8 100644
--- a/libavcodec/dca_syncwords.h
+++ b/libavcodec/dca_syncwords.h
@@ -19,19 +19,17 @@
 #ifndef AVCODEC_DCA_SYNCWORDS_H
 #define AVCODEC_DCA_SYNCWORDS_H
 
-enum DCASyncwords {
-DCA_SYNCWORD_CORE_BE= 0x7FFE8001U,
-DCA_SYNCWORD_CORE_LE= 0xFE7F0180U,
-DCA_SYNCWORD_CORE_14B_BE= 0x1FFFE800U,
-DCA_SYNCWORD_CORE_14B_LE= 0xFF1F00E8U,
-DCA_SYNCWORD_XCH= 0x5A5A5A5AU,
-DCA_SYNCWORD_XXCH   = 0x47004A03U,
-DCA_SYNCWORD_X96= 0x1D95F262U,
-DCA_SYNCWORD_XBR= 0x655E315EU,
-DCA_SYNCWORD_LBR= 0x0A801921U,
-DCA_SYNCWORD_XLL= 0x41A29547U,
-DCA_SYNCWORD_SUBSTREAM  = 0x64582025U,
-DCA_SYNCWORD_SUBSTREAM_CORE = 0x02B09261U,
-};
+#defineDCA_SYNCWORD_CORE_BE  0x7FFE8001U
+#defineDCA_SYNCWORD_CORE_LE  0xFE7F0180U
+#defineDCA_SYNCWORD_CORE_14B_BE  0x1FFFE800U
+#defineDCA_SYNCWORD_CORE_14B_LE  0xFF1F00E8U
+#defineDCA_SYNCWORD_XCH  0x5A5A5A5AU
+#defineDCA_SYNCWORD_XXCH 0x47004A03U
+#defineDCA_SYNCWORD_X96  0x1D95F262U
+#defineDCA_SYNCWORD_XBR  0x655E315EU
+#defineDCA_SYNCWORD_LBR  0x0A801921U
+#defineDCA_SYNCWORD_XLL  0x41A29547U
+#defineDCA_SYNCWORD_SUBSTREAM0x64582025U
+#defineDCA_SYNCWORD_SUBSTREAM_CORE   0x02B09261U
 
 #endif /* AVCODEC_DCA_SYNCWORDS_H */
diff --git a/libavformat/cinedec.c b/libavformat/cinedec.c
index 632f46c..3184084 100644
--- a/libavformat/cinedec.c
+++ b/libavformat/cinedec.c
@@ -49,13 +49,13 @@ enum {
 CFA_VRIV6 = 2,  /**< BGGR/GRBG */
 CFA_BAYER = 3,  /**< GB/RG */
 CFA_BAYERFLIP = 4,  /**< RG/GB */
-
-CFA_TLGRAY= 0x8000,
-CFA_TRGRAY= 0x4000,
-CFA_BLGRAY= 0x2000,
-CFA_BRGRAY= 0x1000
 };
 
+#define CFA_TLGRAY  0x8000U
+#define CFA_TRGRAY  0x4000U
+#define CFA_BLGRAY  0x2000U
+#define CFA_BRGRAY  0x1000U
+
 static int cine_read_probe(AVProbeData *p)
 {
 int HeaderSize;
diff --git a/libavformat/mov_chan.c b/libavformat/mov_chan.c
index a2fa8d6..cba07c5 100644
--- a/libavformat/mov_chan.c
+++ b/libavformat/mov_chan.c
@@ -45,7 +45,7 @@
  *do not specify a particular ordering of those channels."
  */
 enum MovChannelLayoutTag {
-MOV_CH_LAYOUT_UNKNOWN   = 0x,
+#define MOV_CH_LAYOUT_UNKNOWN 0x
 MOV_CH_LAYOUT_USE_DESCRIPTIONS  = (  0 << 16) | 0,
 MOV_CH_LAYOUT_USE_BITMAP= (  1 << 16) | 0,
 MOV_CH_LAYOUT_DISCRETEINORDER   = (147 << 16) | 0,
-- 
2.6.2

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

Re: [FFmpeg-devel] [PATCH] Update Cookies on Setcookie playlist response

[Michael Niedermayer]

On Fri, Oct 30, 2015 at 12:26:55PM +, Lucas Andrade wrote:
> Em sex, 30 de out de 2015 às 07:44, Michael Niedermayer
>  escreveu:
> 
> > On Tue, Oct 27, 2015 at 11:28:32AM +, Lucas Andrade wrote:
> > > Here is the patch to backport it to release/2.8. To be fixed on 2.8.2.
> > > Anything else I should do?
> > >
> > > ps. Sorry, that's my first time on opensource project, I'm a little
> > > confused that I needed to add it to the release branch.
> >
> > >  hls.c |   31 +++
> > >  1 file changed, 15 insertions(+), 16 deletions(-)
> > > 6b3c2cdc68e5fe0d9665a22a78837bca7d7b39b9
> > b3f3eab029eb429660fc1651a33dafe097cbac0e.patch
> > > From b3f3eab029eb429660fc1651a33dafe097cbac0e Mon Sep 17 00:00:00 2001
> > > From: Lucas de Andrade 
> > > Date: Mon, 26 Oct 2015 10:47:08 -0200
> > > Subject: [PATCH] Update Cookies response with Setcookie
> > >
> > > Context cookies must be updated when a playlist response return
> > Setcookie header.
> > > Backported to release/2.8
> > > ---
> > >  libavformat/hls.c | 31 +++
> > >  1 file changed, 15 insertions(+), 16 deletions(-)
> >
> > this patch is against n2.8 not release/2.8
> >
> > git checkout release/2.8
> > git cherry-pick ...
> > error: patch failed: libavformat/hls.c:962
> > error: libavformat/hls.c: patch does not apply
> > Patch failed at 0001 Update Cookies response with Setcookie
> > The copy of the patch that failed is found in:
> >ffmpeg/.git/rebase-apply/patch
> > When you have resolved this problem, run "git am --continue".
> > If you prefer to skip this patch, run "git am --skip" instead.
> > To restore the original branch and stop patching, run "git am --abort".
> >
> > [...]
> >
> > --
> > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> >
> > Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker.
> > User
> > questions about the command line tools should be sent to the ffmpeg-user
> > ML.
> > And questions about how to use libav* should be sent to the libav-user ML.
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> 
> Sorry, I needed to update release/2.8. It was a previous version.
> Here it is.

>  hls.c |   31 +++
>  1 file changed, 15 insertions(+), 16 deletions(-)
> 245150aacbd311302c9c7ee3e293aeae684323b0  
> update_cookies_on_setcookie_response.patch
> From 94b7fd78b6e4a50ffe19a3b0523fb88c9036ea5d Mon Sep 17 00:00:00 2001
> From: Lucas de Andrade 
> Date: Fri, 30 Oct 2015 09:51:26 -0200
> Subject: [PATCH] avformat/hls: update cookies on setcookie response
> 
> Context cookies must be updated when a playlist response return Setcookie 
> header.
> ---
>  libavformat/hls.c | 31 +++
>  1 file changed, 15 insertions(+), 16 deletions(-)

applied to release/2.8

[...]

-- 
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 1/5] ffprobe: add support for printing packet strings metadata as packet tags

[Marton Balint]

On Fri, 30 Oct 2015, Stefano Sabatini wrote:


On date Saturday 2015-10-24 22:42:12 +0200, Marton Balint encoded:

ffprobe.xsd already contains the tag element.

Signed-off-by: Marton Balint 
---
 ffprobe.c | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)



[...]



LGTM, thanks.


Applied, thanks.

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

Re: [FFmpeg-devel] possible farewell; dev policy clarification

[Ronald S. Bultje]

Hi,

On Fri, Oct 30, 2015 at 11:35 AM, Ganesh Ajjanagadde 
wrote:

> Most, and perhaps all of them boil down to misunderstanding. This will
> hopefully improve over time. I apologize to all who did not like
> recent pushes from me. In fact, I can freely let go of my commit
> access if these were deemed sufficiently out of line - I do not ask
> for a formal "DECISION" or vote.


No, that's not necessary. (Punishing for minor, honest mistakes - or
misunderstandings - is silly.)

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

Re: [FFmpeg-devel] [PATCH] avfilter: add audio noise source

[Moritz Barsnick]

On Fri, Oct 30, 2015 at 12:00:23 -0500, Kyle Swanson wrote:
> +- noise audio source

I actually anticipated this for quite some while, but thought I had
figured it out using some random source of input. I can't reproduce my
findings (or even my search), so thanks. :-)

> +@item duration, d
> +Specify the duration of the generated audio stream. Default value is 10 
> seconds.

Is there a way to specify infinity? Actually, why not let it go
infinitely by default, like the sine audio source does?

As Nicolas pointed out, AV_OPT_TYPE_DURATION is more generic for
durations.

I second the notion for other colors of sound (pink).

Question: If I use two of these, will they be seeded identically or
independantly and randomly? (Like for merging to a left and right
channel, and not achieving a mono sound.)

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