[FFmpeg-devel] [PATCH] avutil/opt: print more meaningful default flags values

[Clément Bœsch]

Example:
% ./ffmpeg -h encoder=gif
[...]
GIF encoder AVOptions:
  -gifflagsE..V set GIF flags (default 
offsetting+transdiff)
 offsetting   E..V enable picture offsetting
 transdiffE..V enable transparency detection 
between frames
---
 libavutil/opt.c| 32 ++--
 tests/ref/fate/opt |  2 +-
 2 files changed, 31 insertions(+), 3 deletions(-)

diff --git a/libavutil/opt.c b/libavutil/opt.c
index 36eeeb0..da1eb16 100644
--- a/libavutil/opt.c
+++ b/libavutil/opt.c
@@ -941,6 +941,27 @@ static const char *get_opt_const_name(void *obj, const 
char *unit, int64_t value
 return NULL;
 }
 
+static char *get_opt_flags_string(void *obj, const char *unit, int64_t value)
+{
+const AVOption *opt = NULL;
+char flags[512];
+
+flags[0] = 0;
+if (!unit)
+return NULL;
+while ((opt = av_opt_next(obj, opt))) {
+if (opt->type == AV_OPT_TYPE_CONST && !strcmp(opt->unit, unit) &&
+opt->default_val.i64 & value) {
+if (flags[0])
+av_strlcatf(flags, sizeof(flags), "+");
+av_strlcatf(flags, sizeof(flags), "%s", opt->name);
+}
+}
+if (flags[0])
+return av_strdup(flags);
+return NULL;
+}
+
 static void opt_list(void *obj, void *av_log_obj, const char *unit,
  int req_flags, int rej_flags)
 {
@@ -1066,9 +1087,16 @@ static void opt_list(void *obj, void *av_log_obj, const 
char *unit,
 case AV_OPT_TYPE_BOOL:
 av_log(av_log_obj, AV_LOG_INFO, "%s", (char 
*)av_x_if_null(get_bool_name(opt->default_val.i64), "invalid"));
 break;
-case AV_OPT_TYPE_FLAGS:
-av_log(av_log_obj, AV_LOG_INFO, "%"PRIX64, 
opt->default_val.i64);
+case AV_OPT_TYPE_FLAGS: {
+char *def_flags = get_opt_flags_string(obj, opt->unit, 
opt->default_val.i64);
+if (def_flags) {
+av_log(av_log_obj, AV_LOG_INFO, "%s", def_flags);
+av_freep(_flags);
+} else {
+av_log(av_log_obj, AV_LOG_INFO, "%"PRIX64, 
opt->default_val.i64);
+}
 break;
+}
 case AV_OPT_TYPE_DURATION:
 log_value(av_log_obj, AV_LOG_INFO, opt->default_val.i64);
 break;
diff --git a/tests/ref/fate/opt b/tests/ref/fate/opt
index 307da37..e9132a5 100644
--- a/tests/ref/fate/opt
+++ b/tests/ref/fate/opt
@@ -23,7 +23,7 @@ TestContext AVOptions:
   -rational E... set rational (from 0 to 10) 
(default 1/1)
   -string E... set string (default "default")
   -escape E... set escape str (default "\=,")
-  -flags   E... set flags (default 1)
+  -flags   E... set flags (default cool)
  cool E... set cool flag
  lame E... set lame flag
  mu   E... set mu flag
-- 
2.6.1

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

[FFmpeg-devel] [PATCH 2/5] all: fix incorrect usage of %p format specifier

[Ganesh Ajjanagadde]

Hi all,

Apologies for the copy/pasted patch, but can't send via send-email.
Copy pasted for review below, attached also for a non-clobbered
version.

--

>From 99cd052b614553757efa1954bf8bf4dd3caf66d0 Mon Sep 17 00:00:00 2001
From: Ganesh Ajjanagadde 
Date: Fri, 23 Oct 2015 11:59:40 -0400
Subject: [PATCH 2/5] all: fix incorrect usage of %p format specifier

ISO C %p format specifier applies to void * data pointers. This casts
relevant pointers to void * in order to be strictly correct C.

Found by -Wpedantic on clang 3.7 (in particular -Wformat-pedantic).

Signed-off-by: Ganesh Ajjanagadde 
---
 libavcodec/alsdec.c  | 8 
 libavcodec/h264_refs.c   | 6 +++---
 libavcodec/libopencore-amr.c | 2 +-
 libavcodec/mjpegdec.c| 2 +-
 libavcodec/mpegpicture.c | 2 +-
 libavcodec/mpegvideo.c   | 8 
 libavcodec/options.c | 2 +-
 libavcodec/pthread_frame.c   | 6 +++---
 libavcodec/utils.c   | 4 ++--
 libavcodec/vaapi_h264.c  | 2 +-
 libavcodec/vaapi_hevc.c  | 2 +-
 libavcodec/vaapi_mpeg2.c | 2 +-
 libavcodec/vaapi_mpeg4.c | 2 +-
 libavcodec/vaapi_vc1.c   | 2 +-
 libavcodec/vorbisdec.c   | 2 +-
 libavfilter/avfilter.c   | 6 +++---
 libavformat/asfdec_f.c   | 2 +-
 libavformat/rtpdec_h264.c| 2 +-
 libavformat/utils.c  | 2 +-
 libswscale/swscale.c | 8 
 20 files changed, 36 insertions(+), 36 deletions(-)

diff --git a/libavcodec/alsdec.c b/libavcodec/alsdec.c
index ebd364e..19bdbbd 100644
--- a/libavcodec/alsdec.c
+++ b/libavcodec/alsdec.c
@@ -1308,8 +1308,8 @@ static int
revert_channel_correlation(ALSDecContext *ctx, ALSBlockData *bd,
 FFMAX(end   + 1,   end + 1 + t) > ctx->raw_buffer +
channels * channel_size - master) {
 av_log(ctx->avctx, AV_LOG_ERROR,
"sample pointer range [%p, %p] not contained
in raw_buffer [%p, %p].\n",
-   master + FFMIN(begin - 1, begin - 1 + t),
master + FFMAX(end + 1,   end + 1 + t),
-   ctx->raw_buffer, ctx->raw_buffer + channels *
channel_size);
+   (void *)(master + FFMIN(begin - 1, begin - 1 +
t)), (void *)(master + FFMAX(end + 1, end + 1 + t)),
+   (void *)ctx->raw_buffer, (void
*)(ctx->raw_buffer + channels * channel_size));
 return AVERROR_INVALIDDATA;
 }

@@ -1330,8 +1330,8 @@ static int
revert_channel_correlation(ALSDecContext *ctx, ALSBlockData *bd,
 end   + 1 > ctx->raw_buffer + channels * channel_size
- master) {
 av_log(ctx->avctx, AV_LOG_ERROR,
"sample pointer range [%p, %p] not contained
in raw_buffer [%p, %p].\n",
-   master + begin - 1, master + end + 1,
-   ctx->raw_buffer, ctx->raw_buffer + channels *
channel_size);
+   (void *)(master + begin - 1), (void *)(master
+ end + 1),
+   (void *)(ctx->raw_buffer), (void
*)(ctx->raw_buffer + channels * channel_size));
 return AVERROR_INVALIDDATA;
 }

diff --git a/libavcodec/h264_refs.c b/libavcodec/h264_refs.c
index 619f2ed..da6e7fd 100644
--- a/libavcodec/h264_refs.c
+++ b/libavcodec/h264_refs.c
@@ -437,7 +437,7 @@ static H264Picture *find_short(H264Context *h, int
frame_num, int *idx)
 for (i = 0; i < h->short_ref_count; i++) {
 H264Picture *pic = h->short_ref[i];
 if (h->avctx->debug & FF_DEBUG_MMCO)
-av_log(h->avctx, AV_LOG_DEBUG, "%d %d %p\n", i,
pic->frame_num, pic);
+av_log(h->avctx, AV_LOG_DEBUG, "%d %d %p\n", i,
pic->frame_num, (void *)pic);
 if (pic->frame_num == frame_num) {
 *idx = i;
 return pic;
@@ -543,7 +543,7 @@ static void print_short_term(H264Context *h)
 for (i = 0; i < h->short_ref_count; i++) {
 H264Picture *pic = h->short_ref[i];
 av_log(h->avctx, AV_LOG_DEBUG, "%"PRIu32" fn:%d poc:%d %p\n",
-   i, pic->frame_num, pic->poc, pic->f->data[0]);
+   i, pic->frame_num, pic->poc, (void *)pic->f->data[0]);
 }
 }
 }
@@ -560,7 +560,7 @@ static void print_long_term(H264Context *h)
 H264Picture *pic = h->long_ref[i];
 if (pic) {
 av_log(h->avctx, AV_LOG_DEBUG, "%"PRIu32" fn:%d poc:%d %p\n",
-   i, pic->frame_num, pic->poc, pic->f->data[0]);
+   i, pic->frame_num, pic->poc, (void *)pic->f->data[0]);
 }
 }
 }
diff --git a/libavcodec/libopencore-amr.c b/libavcodec/libopencore-amr.c
index f0e3426..850ad94 100644
--- a/libavcodec/libopencore-amr.c
+++ b/libavcodec/libopencore-amr.c
@@ -100,7 +100,7 @@ static int amr_nb_decode_frame(AVCodecContext
*avctx, void *data,
 int packet_size, ret;

 

Re: [FFmpeg-devel] [PATCH 2/2] libzvbi-teletextdec: fix AVSubtitleRect pict compatiblity code

[Marton Balint]

On Fri, 23 Oct 2015, Marton Balint wrote:


Only set pict if we got a valid rect.

Signed-off-by: Marton Balint 
---
libavcodec/libzvbi-teletextdec.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)


Applied.

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

Re: [FFmpeg-devel] [PATCH 4/5] avfilter: avoid zero arguments to variadic macro

[Ganesh Ajjanagadde]

On Sat, Oct 24, 2015 at 9:52 AM, Nicolas George  wrote:
> Le tridi 3 brumaire, an CCXXIV, Ganesh Ajjanagadde a écrit :
>> Thanks for the super quick review. Will apply shortly. Do you (or
>> others) think adding -Wgnu-zero-variadic-macro-arguments to configure
>> is a good idea?
>
> Considering that each additional option takes ~15 ms in configure on a
> fairly powerful box, not counting maintenance burden, I would say rather no.
>
> Let us enable by default warnings that detect common or sever mistakes,
> extra warnings can be enabled manually once in a while to check for harmless
> mistakes.

ok, agreed. Someone (if they feel these things are useful) can set up
a FATE client with them that sporadically runs, similar to the
sanitizer builds. Of course, it can be done in an unsystematic way
(like the way I did here) instead.

>
> Regards,
>
> --
>   Nicolas George
>
> ___
> 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 3/5] all: use function pointer instead of void * data pointer

[wm4]

On Sat, 24 Oct 2015 09:28:52 -0400
Ganesh Ajjanagadde  wrote:

> ISO C does not guarantee that functions and data live in the same
> address space. It is thus (strictly speaking) illegal to assign to a

POSIX does.

> void * (which is a data pointer) from a function pointer.
> 
> Found by enabling -Wpedantic on clang 3.7.
> 
> Signed-off-by: Ganesh Ajjanagadde 

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

Re: [FFmpeg-devel] Can we drop OpenJPEG 1.5 in favor of 2.x?

[Carl Eugen Hoyos]

James Almer  gmail.com> writes:

> Why does configure even check for 2.x if the actual 
> lavc wrappers don't currently support it?

It is possible to use openjpeg2 with current 
FFmpeg (I use it for testing) but it is 
everything but user-friendly.

Carl Eugen

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

Re: [FFmpeg-devel] [PATCH][RFC] avcodec/pthread_frame: fix null pointer dereference

[Nicolas George]

Le tridi 3 brumaire, an CCXXIV, Ganesh Ajjanagadde a écrit :
> Fixes CID 1322329.
> 
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavcodec/pthread_frame.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c
> index 7651211..ca06e3d 100644
> --- a/libavcodec/pthread_frame.c
> +++ b/libavcodec/pthread_frame.c
> @@ -305,7 +305,7 @@ static void release_delayed_buffers(PerThreadContext *p)
>  pthread_mutex_lock(>buffer_mutex);
>  
>  // fix extended data in case the caller screwed it up
> -av_assert0(p->avctx->codec_type == AVMEDIA_TYPE_VIDEO ||

> +av_assert0(p->avctx && p->avctx->codec_type == AVMEDIA_TYPE_VIDEO ||

I think the commit message should explain in what circumstances p->avctx can
be NULL. Otherwise, the extra test is only hiding a problem earlier in the
code.

> p->avctx->codec_type == AVMEDIA_TYPE_AUDIO);
>  f = >released_buffers[--p->num_released_buffers];
>  f->extended_data = f->data;

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] swresample: Add support for clipping float/double to -1.0..1.0 range

[Clément Bœsch]

On Fri, Oct 23, 2015 at 12:41:18PM -0400, Ronald S. Bultje wrote:
[...]
> ffmpeg -h full, searching to -sws_flags, gives this:
>   -sws_flags   E..V scaler flags (default 4)
>  fast_bilinearE..V fast bilinear
>  bilinear E..V bilinear
>  bicubic  E..V bicubic
>  experimental E..V experimental
>  neighbor E..V nearest neighbor
>  area E..V averaging area
>  bicublin E..V luma bicubic, chroma bilinear
>  gaussE..V Gaussian
>  sinc E..V sinc
>  lanczos  E..V Lanczos
>  spline   E..V natural bicubic spline
>  print_info   E..V print info
>  accurate_rnd E..V accurate rounding
>  full_chroma_int  E..V full chroma interpolation
>  full_chroma_inp  E..V full chroma input
>  bitexact E..V
>  error_diffusion  E..V error diffusion dither
> 
> OK, so first, there's so many things wrong here, we're using flags as a way
> to indicate the scaling method, and mixing up boolean flags. By the way,
> did you know "experimental" is a scaling method? Fantastic help.

> The default is "4", but we don't know what flag "4" corresponds to.

(Just sent for this ♥)

[...]

-- 
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 4/5] avfilter: avoid zero arguments to variadic macro

[Ganesh Ajjanagadde]

On Sat, Oct 24, 2015 at 9:33 AM, Nicolas George  wrote:
> Le tridi 3 brumaire, an CCXXIV, Ganesh Ajjanagadde a écrit :
>> ISO C requires at least one argument in the place of the ellipsis in a
>> variadic macro. In particular, under -pedantic, this triggers the
>> warning -Wgnu-zero-variadic-macro-arguments on clang 3.7.
>>
>> Signed-off-by: Ganesh Ajjanagadde 
>> ---
>>  libavfilter/af_asetrate.c |  4 ++--
>>  libavfilter/asrc_sine.c   | 18 +-
>>  2 files changed, 11 insertions(+), 11 deletions(-)
>
> Ok. Good catch.

Thanks for the super quick review. Will apply shortly. Do you (or
others) think adding -Wgnu-zero-variadic-macro-arguments to configure
is a good idea?

>
> Regards,
>
> --
>   Nicolas George
>
> ___
> 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 4/5] avfilter: avoid zero arguments to variadic macro

[Nicolas George]

Le tridi 3 brumaire, an CCXXIV, Ganesh Ajjanagadde a écrit :
> Thanks for the super quick review. Will apply shortly. Do you (or
> others) think adding -Wgnu-zero-variadic-macro-arguments to configure
> is a good idea?

Considering that each additional option takes ~15 ms in configure on a
fairly powerful box, not counting maintenance burden, I would say rather no.

Let us enable by default warnings that detect common or sever mistakes,
extra warnings can be enabled manually once in a while to check for harmless
mistakes.

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] videodsp: don't overread edges in vfix3 emu_edge.

[Andreas Cadhalpun]

On 24.10.2015 14:47, Ronald S. Bultje wrote:
> ---
>  libavcodec/x86/videodsp.asm | 15 +++
>  1 file changed, 11 insertions(+), 4 deletions(-)
> 
> diff --git a/libavcodec/x86/videodsp.asm b/libavcodec/x86/videodsp.asm
> index 25d4364..48f5ac0 100644
> --- a/libavcodec/x86/videodsp.asm
> +++ b/libavcodec/x86/videodsp.asm
> @@ -194,8 +194,12 @@ hvar_fn
>  %elif (%2-%%off) == 2
>  movvalw, [srcq+%2-2]
>  %elifidn %1, body
> -movvald, [srcq+%2-3]
> -%else
> +movvalb, [srcq+%2-1]
> +salvald, 16
> +movvalw, [srcq+%2-3]
> +%elifidn %1, bottom
> +movd mm %+ %%mmx_idx, [srcq+%2-4]
> +%else ; top
>  movd mm %+ %%mmx_idx, [srcq+%2-3]
>  %endif
>  %endif ; (%2-%%off) >= 1
> @@ -251,12 +255,15 @@ hvar_fn
>  mov [dstq+%2-2], valw
>  %elifidn %1, body
>  mov [dstq+%2-3], valw
> -shrvald, 16
> +sarvald, 16
>  mov [dstq+%2-1], valb
>  %else
>  movd   vald, mm %+ %%mmx_idx
> +%ifidn %1, bottom
> +sarvald, 8
> +%endif
>  mov [dstq+%2-3], valw
> -shrvald, 16
> +sarvald, 16
>  mov [dstq+%2-1], valb
>  %endif
>  %endif ; (%2-%%off) >= 1
> 

This fixes the crash and passes FATE, so looks good to me.
Maybe mention the bug report in the commit message, e.g.:
Bug-Debian: https://bugs.debian.org/801745

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

Re: [FFmpeg-devel] [PATCH] videodsp: don't overread edges in vfix3 emu_edge.

[Andreas Cadhalpun]

Hi Ronald,

On 24.10.2015 17:55, Ronald S. Bultje wrote:
> On Sat, Oct 24, 2015 at 11:41 AM, Andreas Cadhalpun <
> andreas.cadhal...@googlemail.com> wrote:
> 
>> On 24.10.2015 14:47, Ronald S. Bultje wrote:
>>> ---
>>>  libavcodec/x86/videodsp.asm | 15 +++
>>>  1 file changed, 11 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/libavcodec/x86/videodsp.asm b/libavcodec/x86/videodsp.asm
>>> index 25d4364..48f5ac0 100644
>>> --- a/libavcodec/x86/videodsp.asm
>>> +++ b/libavcodec/x86/videodsp.asm
>>> @@ -194,8 +194,12 @@ hvar_fn
>>>  %elif (%2-%%off) == 2
>>>  movvalw, [srcq+%2-2]
>>>  %elifidn %1, body
>>> -movvald, [srcq+%2-3]
>>> -%else
>>> +movvalb, [srcq+%2-1]
>>> +salvald, 16
>>> +movvalw, [srcq+%2-3]
>>> +%elifidn %1, bottom
>>> +movd mm %+ %%mmx_idx, [srcq+%2-4]
>>> +%else ; top
>>>  movd mm %+ %%mmx_idx, [srcq+%2-3]
>>>  %endif
>>>  %endif ; (%2-%%off) >= 1
>>> @@ -251,12 +255,15 @@ hvar_fn
>>>  mov [dstq+%2-2], valw
>>>  %elifidn %1, body
>>>  mov [dstq+%2-3], valw
>>> -shrvald, 16
>>> +sarvald, 16
>>>  mov [dstq+%2-1], valb
>>>  %else
>>>  movd   vald, mm %+ %%mmx_idx
>>> +%ifidn %1, bottom
>>> +sarvald, 8
>>> +%endif
>>>  mov [dstq+%2-3], valw
>>> -shrvald, 16
>>> +sarvald, 16
>>>  mov [dstq+%2-1], valb
>>>  %endif
>>>  %endif ; (%2-%%off) >= 1
>>>
>>
>> This fixes the crash and passes FATE, so looks good to me.
>> Maybe mention the bug report in the commit message, e.g.:
>> Bug-Debian: https://bugs.debian.org/801745
> 
> 
> Thanks for testing, so this does actually fix the bug?

Yes, at least I couldn't reproduce the crash anymore with this patch applied.

Best regards,
Andreas

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

Re: [FFmpeg-devel] Can we drop OpenJPEG 1.5 in favor of 2.x?

[Carl Eugen Hoyos]

Michael Bradshaw  gmail.com> writes:

> tl;dr: I've got a patch that updates OpenJPEG to 2.0/2.1. 
> Currently, I've opted to drop OpenJPEG 1.5. Should I 
> proceed with preparing this patch for submission, or 
> should I alter it to keep 1.5 support?

Do distributions support (contain) 2.x?

Carl Eugen

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

Re: [FFmpeg-devel] Can we drop OpenJPEG 1.5 in favor of 2.x?

[Michael Niedermayer]

On Sat, Oct 24, 2015 at 09:03:43AM -0700, Michael Bradshaw wrote:
> tl;dr: I've got a patch that updates OpenJPEG to 2.0/2.1. Currently, I've
> opted to drop OpenJPEG 1.5. Should I proceed with preparing this patch for
> submission, or should I alter it to keep 1.5 support?
> 
> 
> 
> The OpenJPEG API went through a bit of an overhaul in the 1.x to 2.x
> transition. This means that supporting 1.5 and 2.x concurrently in ffmpeg
> would be possible, but would require some (ugly) macros.
> 
> Given that v2.0 was released ~19 months ago, I think it's been long enough
> that users should, most likely, have access to a modern 2.x OpenJPEG on
> their machine. So I don't think dropping 1.5 would be catastrophic.
> 
> But, on the other hand, it's nice to be a swiss army knife that works with
> everything, so I can understand if others think supporting 1.5 is important.
> 
> I don't want to submit my patch (as is) if I'm just going to be told to go
> back and keep 1.5 support. If ya'll still want 1.5 support, I'd rather
> include that from the get-go rather than revising the patch during the
> review.
> 
> Opinions on whether 1.5 should be dropped in favor of 2.x?

If we consider the set of distributions which are supported by their
upstreams still, how many of these ship 2.x and how many an older
OpenJPEG version ?

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

It is dangerous to be right in matters on which the established authorities
are wrong. -- Voltaire


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

Re: [FFmpeg-devel] Can we drop OpenJPEG 1.5 in favor of 2.x?

[Nicolas George]

Le tridi 3 brumaire, an CCXXIV, Ganesh Ajjanagadde a écrit :
> Definitely not. Even Arch Linux, generally an early adopter, does not
> use openjpeg2, but instead openjpeg for most things.

https://www.archlinux.org/packages/community/x86_64/openjpeg2/

Are you sure of your statement?

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] Can we drop OpenJPEG 1.5 in favor of 2.x?

[Andreas Cadhalpun]

On 24.10.2015 18:59, Carl Eugen Hoyos wrote:
> Michael Bradshaw  gmail.com> writes:
> 
>> tl;dr: I've got a patch that updates OpenJPEG to 2.0/2.1. 
>> Currently, I've opted to drop OpenJPEG 1.5. Should I 
>> proceed with preparing this patch for submission, or 
>> should I alter it to keep 1.5 support?
> 
> Do distributions support (contain) 2.x?

Debian has a separate openjpeg2 package [1], even in stable.
So from my point of view there is no need to keep compatibility with
openjpeg 1.5, if that's too difficult/ugly.

Best regards,
Andreas

1: https://tracker.debian.org/pkg/openjpeg2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] vp9: uses ff_set_dimensions (which sets coded_width/height).

[wm4]

On Fri, 23 Oct 2015 21:40:14 -0400
"Ronald S. Bultje"  wrote:

> Fixes ticket 4935.
> ---
>  libavcodec/vp9.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
> index 3753e89..cee17d9 100644
> --- a/libavcodec/vp9.c
> +++ b/libavcodec/vp9.c
> @@ -222,8 +222,7 @@ static int update_size(AVCodecContext *ctx, int w, int h, 
> enum AVPixelFormat fmt
>  if (s->intra_pred_data[0] && w == ctx->width && h == ctx->height && 
> ctx->pix_fmt == fmt)
>  return 0;
>  
> -ctx->width   = w;
> -ctx->height  = h;
> +ff_set_dimensions(ctx, w, h);
>  ctx->pix_fmt = fmt;
>  s->sb_cols   = (w + 63) >> 6;
>  s->sb_rows   = (h + 63) >> 6;

ff_set_dimensions() can fail.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Use ff_thread_once() to initialize sin/cos static tables.

[wm4]

On Fri, 23 Oct 2015 15:35:15 -0700
Dale Curtis  wrote:

> Changes from partial initialization which happens for every
> initialize call to a full initialization once per process. Changes
> as discussed on list by wm4 and rbultje.
> 
> Passes fft-test and fate suite.
> 
> Signed-off-by: Dale Curtis 
> ---
>  libavcodec/fft_template.c | 33 -
>  libavcodec/rdft.c | 41 +
>  libavcodec/rdft.h |  1 +
>  3 files changed, 58 insertions(+), 17 deletions(-)
> 
> diff --git a/libavcodec/fft_template.c b/libavcodec/fft_template.c
> index 23ea453..a9a3797 100644
> --- a/libavcodec/fft_template.c
> +++ b/libavcodec/fft_template.c
> @@ -28,7 +28,9 @@
> 
>  #include 
>  #include 
> +#include "libavutil/avassert.h"
>  #include "libavutil/mathematics.h"
> +#include "libavutil/thread.h"
>  #include "fft.h"
>  #include "fft-internal.h"
> 
> @@ -85,17 +87,30 @@ static int split_radix_permutation(int i, int n,
> int inverse)
>  else  return split_radix_permutation(i, m, inverse)*4 - 
> 1;
>  }
> 
> -av_cold void ff_init_ff_cos_tabs(int index)
> +#if (!CONFIG_HARDCODED_TABLES) && (!FFT_FIXED_32)
> +static AVOnce ff_cos_tabs_init = AV_ONCE_INIT;
> +static av_cold void ff_init_ff_cos_static_table_init(void)
> +{
> +int nbits;
> +for (nbits = 4; nbits < 16; nbits++) {
> +int i;
> +int m = 1 << nbits;
> +double freq = 2*M_PI/m;
> +FFTSample *tab = FFT_NAME(ff_cos_tabs)[nbits];
> +for (i = 0; i <= m/4; i++)
> +tab[i] = FIX15(cos(i*freq));
> +for (i = 1; i < m/4; i++)
> +tab[m/2-i] = tab[i];
> +}
> +}
> +#endif
> +
> +av_cold void ff_init_ff_cos_tabs(int nbits)
>  {
>  #if (!CONFIG_HARDCODED_TABLES) && (!FFT_FIXED_32)
> -int i;
> -int m = 1< -double freq = 2*M_PI/m;
> -FFTSample *tab = FFT_NAME(ff_cos_tabs)[index];
> -for(i=0; i<=m/4; i++)
> -tab[i] = FIX15(cos(i*freq));
> -for(i=1; i -tab[m/2-i] = tab[i];
> +av_assert0(nbits >= 4 && nbits <= 16);
> +if (ff_thread_once(_cos_tabs_init, _init_ff_cos_static_table_init))
> +av_log(NULL, AV_LOG_ERROR, "failed to initialize cosine tables.\n");
>  #endif
>  }

Hm, the fact that fft_template.c is included in several other files via
#include makes this quite confusing. In fft.h I see:

#define ff_init_ff_cos_tabs FFT_NAME(ff_init_ff_cos_tabs)

Well, I guess it's somehow working out.

> diff --git a/libavcodec/rdft.c b/libavcodec/rdft.c
> index c318aa8..d5a5d50 100644
> --- a/libavcodec/rdft.c
> +++ b/libavcodec/rdft.c
> @@ -20,7 +20,9 @@
>   */
>  #include 
>  #include 
> +#include "libavutil/avassert.h"
>  #include "libavutil/mathematics.h"
> +#include "libavutil/thread.h"
>  #include "rdft.h"
> 
>  /**
> @@ -96,6 +98,36 @@ static void rdft_calc_c(RDFTContext *s, FFTSample *data)
>  }
>  }
> 
> +#if !CONFIG_HARDCODED_TABLES
> +static AVOnce ff_sin_tabs_init = AV_ONCE_INIT;
> +static av_cold void ff_init_ff_sin_static_table_init(void)
> +{
> +int nbits;
> +for (nbits = 4; nbits < 16; nbits++) {
> +int n = 1 << nbits;
> +int m = n >> 2;
> +int offset;
> +for (offset = 0; offset < 2; offset++) {
> +int i;
> +FFTSample* tab = ff_sin_tabs[nbits]+offset*m;
> +const double theta = (offset ? -1 : 1) * 2 * M_PI / n;
> +for (i = 0; i < m; i++)
> +tab[i] = sin(i * theta);
> +}
> +}
> +}
> +#endif
> +
> +av_cold void ff_init_ff_sin_tabs(int nbits, enum RDFTransformType trans)
> +{
> +#if !CONFIG_HARDCODED_TABLES
> +av_assert0(trans == DFT_R2C || trans == IDFT_C2R || trans ==
> IDFT_R2C || trans == DFT_C2R);
> +av_assert0(nbits >= 4 && nbits <= 16);
> +if (ff_thread_once(_sin_tabs_init, _init_ff_sin_static_table_init))
> +av_log(NULL, AV_LOG_ERROR, "Failed to initialize sin tables.\n");
> +#endif
> +}
> +
>  av_cold int ff_rdft_init(RDFTContext *s, int nbits, enum
> RDFTransformType trans)
>  {
>  int n = 1 << nbits;
> @@ -112,16 +144,9 @@ av_cold int ff_rdft_init(RDFTContext *s, int
> nbits, enum RDFTransformType trans)
>  return ret;
> 
>  ff_init_ff_cos_tabs(nbits);
> +ff_init_ff_sin_tabs(nbits, trans);
>  s->tcos = ff_cos_tabs[nbits];
>  s->tsin = ff_sin_tabs[nbits]+(trans == DFT_R2C || trans == 
> DFT_C2R)*(n>>2);
> -#if !CONFIG_HARDCODED_TABLES
> -{
> -int i;
> -const double theta = (trans == DFT_R2C || trans == DFT_C2R ?
> -1 : 1) * 2 * M_PI / n;

Your mail client is breaking long lines. Either send the patch as
attachment, or use git send-email.

> -for (i = 0; i < (n >> 2); i++)
> -s->tsin[i] = sin(i * theta);
> -}
> -#endif
>  s->rdft_calc   = rdft_calc_c;
> 
>  if (ARCH_ARM) ff_rdft_init_arm(s);
> diff --git a/libavcodec/rdft.h b/libavcodec/rdft.h
> index 37c40e7..75bb6b5 

Re: [FFmpeg-devel] [PATCH 01/11] libavformat/mxfdec.c: klv_read_packet: Properly check klv_decode_ber_length return value.

[Tomas Härdin]

On Thu, 2015-10-22 at 19:25 +0200, Alexis Ballier wrote:
> On Wed, 21 Oct 2015 23:31:29 +0200
> Tomas Härdin  wrote:
> 
> > On Wed, 2015-10-21 at 18:00 +0200, Alexis Ballier wrote:
> > > klv_decode_ber_length cannot return -1, but can return
> > > AVERROR_INVALIDDATA. Store its return value in a signed integer
> > > (instead of unsigned KLVPacket.length) and forward the error
> > > appropriately. --- libavformat/mxfdec.c | 6 --
> > >  1 file changed, 4 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> > > index 00d420b..94a953b 100644
> > > --- a/libavformat/mxfdec.c
> > > +++ b/libavformat/mxfdec.c
> > > @@ -366,13 +366,15 @@ static int mxf_read_sync(AVIOContext *pb,
> > > const uint8_t *key, unsigned size) 
> > >  static int klv_read_packet(KLVPacket *klv, AVIOContext *pb)
> > >  {
> > > +int64_t len;
> > >  if (!mxf_read_sync(pb, mxf_klv_key, 4))
> > >  return AVERROR_INVALIDDATA;
> > >  klv->offset = avio_tell(pb) - 4;
> > >  memcpy(klv->key, mxf_klv_key, 4);
> > >  avio_read(pb, klv->key + 4, 12);
> > > -klv->length = klv_decode_ber_length(pb);
> > > -return klv->length == -1 ? -1 : 0;
> > > +len = klv_decode_ber_length(pb);
> > > +klv->length = FFMAX(len, 0);
> > > +return FFMIN(len, 0);
> > >  }  
> > 
> > Can't klv_read_packet() return int64_t instead?
> 
> you mean change the return type and return klv->length ?
> that might work, but note that what I'm trying to fix is
> klv_read_packet setting length to (unsigned)AVERROR_INVALIDDATA, i.e.,
> something close to 2^64, and returning 0.
> I don't see any problem by doing that, so it is as you prefer.

Oh, of course - don't let length be some bogus value :)
Actually, maybe it doesn't matter so much. Hm

/Tomas

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

Re: [FFmpeg-devel] [PATCH][RFC] avcodec/pthread_frame: fix null pointer dereference

[Ganesh Ajjanagadde]

On Sat, Oct 24, 2015 at 9:15 AM, Nicolas George  wrote:
> Le tridi 3 brumaire, an CCXXIV, Ganesh Ajjanagadde a écrit :
>> Fixes CID 1322329.
>>
>> Signed-off-by: Ganesh Ajjanagadde 
>> ---
>>  libavcodec/pthread_frame.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c
>> index 7651211..ca06e3d 100644
>> --- a/libavcodec/pthread_frame.c
>> +++ b/libavcodec/pthread_frame.c
>> @@ -305,7 +305,7 @@ static void release_delayed_buffers(PerThreadContext *p)
>>  pthread_mutex_lock(>buffer_mutex);
>>
>>  // fix extended data in case the caller screwed it up
>> -av_assert0(p->avctx->codec_type == AVMEDIA_TYPE_VIDEO ||
>
>> +av_assert0(p->avctx && p->avctx->codec_type == AVMEDIA_TYPE_VIDEO ||
>
> I think the commit message should explain in what circumstances p->avctx can
> be NULL. Otherwise, the extra test is only hiding a problem earlier in the
> code.

Ok, will check in more detail. Thanks.

>
>> p->avctx->codec_type == AVMEDIA_TYPE_AUDIO);
>>  f = >released_buffers[--p->num_released_buffers];
>>  f->extended_data = f->data;
>
> Regards,
>
> --
>   Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 5/5] all: fix enum definition for large values

[wm4]

On Sat, 24 Oct 2015 09:29:23 -0400
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 such errors by explicitly casting as an int, doing the
> desired unsigned to signed conversion. This method works on all current
> architectures. Tested with FATE.
> 

What is the point of trying to fix warnings with -Wpedantic? We don't
even use this flag.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 5/5] all: fix enum definition for large values

[Ganesh Ajjanagadde]

On Sat, Oct 24, 2015 at 11:08 AM, wm4  wrote:
> On Sat, 24 Oct 2015 09:29:23 -0400
> 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 such errors by explicitly casting as an int, doing the
>> desired unsigned to signed conversion. This method works on all current
>> architectures. Tested with FATE.
>>
>
> What is the point of trying to fix warnings with -Wpedantic? We don't
> even use this flag.

We don't. There are some things it shows that needed fixing (e.g the
variadic macros thing), some things which may improve readability,
some things which are highly subjective, and some things which are
utterly useless.

As an example of the useless things that I did not bother at all with,
ISO C99 only guarantees correct handling of string literals only up to
4095 characters (C89 was ~500, forgot the number). Clang has
-Woverlength-strings for this. This is completely pointless in my
view, even though (as you can clearly tell), I fall on the more
conservative end with respect to warnings.

You may ask: why do I even bother with all this? I would like to
know/understand C better, and seeing what ISO does and does not
guarantee is educative for me. The fact that FFmpeg can (sometimes)
benefit, e.g via the variadic macros thing, is a side benefit.

> _
__
> 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 2/5] all: fix incorrect usage of %p format specifier

[Ganesh Ajjanagadde]

On Sat, Oct 24, 2015 at 9:44 AM, Nicolas George  wrote:
> Le tridi 3 brumaire, an CCXXIV, Ganesh Ajjanagadde a écrit :
>> Apologies for the copy/pasted patch, but can't send via send-email.
>
> Maybe you should take some time to tackle your email troubles?

I have spent some time on this. Given up on gmail, as it is not in my
control, and is inconsistent. I have tried following my university's
mail configuration, but it does not work. Will need to speak with them
at some point. Until then, I view this is a reasonable compromise for
large patches.

>
>> ISO C %p format specifier applies to void * data pointers. This casts
>> relevant pointers to void * in order to be strictly correct C.
>>
>> Found by -Wpedantic on clang 3.7 (in particular -Wformat-pedantic).
>
> I am rather against this change, it makes the code significantly less
> readable, and this instance I see zero chances of it fixing an actual issue
> any time.
>
> There is a reason these warnings are called "pedantic": there are often
> irrelevant.
>
> Regards,
>
> --
>   Nicolas George
> ___
> 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] Can we drop OpenJPEG 1.5 in favor of 2.x?

[Michael Bradshaw]

tl;dr: I've got a patch that updates OpenJPEG to 2.0/2.1. Currently, I've
opted to drop OpenJPEG 1.5. Should I proceed with preparing this patch for
submission, or should I alter it to keep 1.5 support?



The OpenJPEG API went through a bit of an overhaul in the 1.x to 2.x
transition. This means that supporting 1.5 and 2.x concurrently in ffmpeg
would be possible, but would require some (ugly) macros.

Given that v2.0 was released ~19 months ago, I think it's been long enough
that users should, most likely, have access to a modern 2.x OpenJPEG on
their machine. So I don't think dropping 1.5 would be catastrophic.

But, on the other hand, it's nice to be a swiss army knife that works with
everything, so I can understand if others think supporting 1.5 is important.

I don't want to submit my patch (as is) if I'm just going to be told to go
back and keep 1.5 support. If ya'll still want 1.5 support, I'd rather
include that from the get-go rather than revising the patch during the
review.

Opinions on whether 1.5 should be dropped in favor of 2.x?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/5] all: use function pointer instead of void * data pointer

[Michael Niedermayer]

On Sat, Oct 24, 2015 at 09:28:52AM -0400, Ganesh Ajjanagadde wrote:
> ISO C does not guarantee that functions and data live in the same
> address space. It is thus (strictly speaking) illegal to assign to a
> void * (which is a data pointer) from a function pointer.
> 
> Found by enabling -Wpedantic on clang 3.7.
> 
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  ffmpeg_opt.c  | 8 
>  libavcodec/hevc.c | 2 +-
>  libavfilter/vf_drawtext.c | 2 +-
>  libavfilter/vf_lut.c  | 6 +++---
>  libavformat/async.c   | 2 +-
>  5 files changed, 10 insertions(+), 10 deletions(-)

if these dont add any new warnings then LGTM
but the commit message should rather point to code cleanup and
not ISO C

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

The bravest are surely those who have the clearest vision
of what is before them, glory and danger alike, and yet
notwithstanding go out to meet it. -- Thucydides


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

Re: [FFmpeg-devel] [PATCH 2/5] all: fix incorrect usage of %p format specifier

[Nicolas George]

Le tridi 3 brumaire, an CCXXIV, Ganesh Ajjanagadde a écrit :
> Apologies for the copy/pasted patch, but can't send via send-email.

Maybe you should take some time to tackle your email troubles?

> ISO C %p format specifier applies to void * data pointers. This casts
> relevant pointers to void * in order to be strictly correct C.
> 
> Found by -Wpedantic on clang 3.7 (in particular -Wformat-pedantic).

I am rather against this change, it makes the code significantly less
readable, and this instance I see zero chances of it fixing an actual issue
any time.

There is a reason these warnings are called "pedantic": there are often
irrelevant.

Regards,

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

Re: [FFmpeg-devel] [PATCHv2 1/2] ffplay: use a separate struct for the rescaled YUVA AVSubtitle rectangles

[Marton Balint]

On Sat, 24 Oct 2015, Marton Balint wrote:


Current code segfaults since the deprecation of AVSubtitleRect.pict because it
freed/realloced AVSubtitleRect.pict.data by itself.

The new code stores the generated YUVA AVSubtitle rectangles in their own
struct and keeps the original AVSubtitle structure untouched, because
overwriting it is considered invalid API usage.

Signed-off-by: Marton Balint 
---
ffplay.c | 48 ++--
1 file changed, 26 insertions(+), 22 deletions(-)



Applied.

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

Re: [FFmpeg-devel] [PATCH 4/5] avfilter: avoid zero arguments to variadic macro

[Ganesh Ajjanagadde]

On Sat, Oct 24, 2015 at 10:16 AM, Ganesh Ajjanagadde  wrote:
> On Sat, Oct 24, 2015 at 9:52 AM, Nicolas George  wrote:
>> Le tridi 3 brumaire, an CCXXIV, Ganesh Ajjanagadde a écrit :
>>> Thanks for the super quick review. Will apply shortly. Do you (or
>>> others) think adding -Wgnu-zero-variadic-macro-arguments to configure
>>> is a good idea?
>>
>> Considering that each additional option takes ~15 ms in configure on a
>> fairly powerful box, not counting maintenance burden, I would say rather no.
>>
>> Let us enable by default warnings that detect common or sever mistakes,
>> extra warnings can be enabled manually once in a while to check for harmless
>> mistakes.
>
> ok, agreed. Someone (if they feel these things are useful) can set up
> a FATE client with them that sporadically runs, similar to the
> sanitizer builds. Of course, it can be done in an unsystematic way
> (like the way I did here) instead.

pushed

>
>>
>> Regards,
>>
>> --
>>   Nicolas George
>>
>> ___
>> 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 2/5] all: fix incorrect usage of %p format specifier

[Hendrik Leppkes]

On Sat, Oct 24, 2015 at 5:29 PM, Ganesh Ajjanagadde  wrote:
> On Sat, Oct 24, 2015 at 9:44 AM, Nicolas George  wrote:
>> Le tridi 3 brumaire, an CCXXIV, Ganesh Ajjanagadde a écrit :
>>> Apologies for the copy/pasted patch, but can't send via send-email.
>>
>> Maybe you should take some time to tackle your email troubles?
>
> I have spent some time on this. Given up on gmail, as it is not in my
> control, and is inconsistent. I have tried following my university's
> mail configuration, but it does not work. Will need to speak with them
> at some point. Until then, I view this is a reasonable compromise for
> large patches.
>

I've never had a problem sending any size of patch using gmail's smtp server.

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

[FFmpeg-devel] [PATCH 3/7] lavfi/fifo: do not assume request_frame() returns a frame.

[Nicolas George]

Signed-off-by: Nicolas George 
---
 libavfilter/fifo.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/libavfilter/fifo.c b/libavfilter/fifo.c
index e477cff..f0b77ff 100644
--- a/libavfilter/fifo.c
+++ b/libavfilter/fifo.c
@@ -201,7 +201,8 @@ static int return_audio_frame(AVFilterContext *ctx)
 break;
 } else if (ret < 0)
 return ret;
-av_assert0(s->root.next); // If ff_request_frame() succeeded 
then we should have a frame
+if (!s->root.next)
+return 0;
 }
 head = s->root.next->frame;
 
@@ -237,7 +238,8 @@ static int request_frame(AVFilterLink *outlink)
 return return_audio_frame(outlink->src);
 return ret;
 }
-av_assert0(fifo->root.next);
+if (!fifo->root.next)
+return 0;
 }
 
 if (outlink->request_samples) {
-- 
2.6.1

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

[FFmpeg-devel] [PATCH 2/7] lavfi/avf_concat: return immediately after requesting a frame on input.

[Nicolas George]

Signed-off-by: Nicolas George 
---
 libavfilter/avf_concat.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/libavfilter/avf_concat.c b/libavfilter/avf_concat.c
index 5a4b356..4fa9447 100644
--- a/libavfilter/avf_concat.c
+++ b/libavfilter/avf_concat.c
@@ -347,10 +347,9 @@ static int request_frame(AVFilterLink *outlink)
 if (cat->in[str].eof)
 continue;
 ret = ff_request_frame(ctx->inputs[str]);
-if (ret == AVERROR_EOF)
-close_input(ctx, str);
-else if (ret < 0)
+if (ret != AVERROR_EOF)
 return ret;
+close_input(ctx, str);
 }
 ret = flush_segment(ctx);
 if (ret < 0)
-- 
2.6.1

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

Re: [FFmpeg-devel] Can we drop OpenJPEG 1.5 in favor of 2.x?

[Ganesh Ajjanagadde]

On Sat, Oct 24, 2015 at 12:59 PM, Carl Eugen Hoyos  wrote:
> Michael Bradshaw  gmail.com> writes:
>
>> tl;dr: I've got a patch that updates OpenJPEG to 2.0/2.1.
>> Currently, I've opted to drop OpenJPEG 1.5. Should I
>> proceed with preparing this patch for submission, or
>> should I alter it to keep 1.5 support?
>
> Do distributions support (contain) 2.x?

Definitely not. Even Arch Linux, generally an early adopter, does not
use openjpeg2, but instead openjpeg for most things. 1.5 support is
very much needed for now.

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

Re: [FFmpeg-devel] [PATCH] avcodec/huffman: replace qsort with AV_QSORT

[Ganesh Ajjanagadde]

On Thu, Oct 22, 2015 at 10:25 PM, Ganesh Ajjanagadde
 wrote:
>
> On Thu, Oct 22, 2015 at 9:28 PM, Timothy Gu  wrote:
> > On Thu, Oct 22, 2015 at 5:01 PM Ganesh Ajjanagadde 
> > wrote:
> >>
> >> Sample benchmark (x86-64, Haswell, GNU/Linux), fraps-v2 from FATE:
> >> new:
> >> 280110 decicycles in qsort,   1 runs,  0 skips
> >> 268260 decicycles in qsort,   2 runs,  0 skips
> >>
> >> old:
> >> 1469910 decicycles in qsort,   1 runs,  0 skips
> >>  952950 decicycles in qsort,   2 runs,  0 skips
> >
> >
> > Usually it takes more than 2 runs to make sure something is faster than the
> > other (try -stream_loop 1 on the input).
>
> In this case the gain should be obvious due to inlining. Nevertheless,
> here are new numbers. I chose vp6 for two reasons:
> 1. Above was for fraps-v2, giving vp6 for more "completeness".
> 2. stream_loop throws errors: Error while decoding stream #0:0:
> Invalid data found when processing input for fraps-v2.
>
> Here they are:
> vp6 (old):
>   78930 decicycles in qsort,   1 runs,  0 skips
>   45330 decicycles in qsort,   2 runs,  0 skips
>   27825 decicycles in qsort,   4 runs,  0 skips
>   17471 decicycles in qsort,   8 runs,  0 skips
>   12296 decicycles in qsort,  16 runs,  0 skips
>9554 decicycles in qsort,  32 runs,  0 skips
>8404 decicycles in qsort,  64 runs,  0 skips
>7405 decicycles in qsort, 128 runs,  0 skips
>6740 decicycles in qsort, 256 runs,  0 skips
>7540 decicycles in qsort, 512 runs,  0 skips
>9498 decicycles in qsort,1024 runs,  0 skips
>9938 decicycles in qsort,2048 runs,  0 skips
>8043 decicycles in qsort,4095 runs,  1 skips
>
> vp6 (new):
>   15880 decicycles in qsort,   1 runs,  0 skips
>   10730 decicycles in qsort,   2 runs,  0 skips
>   10155 decicycles in qsort,   4 runs,  0 skips
>7805 decicycles in qsort,   8 runs,  0 skips
>6883 decicycles in qsort,  16 runs,  0 skips
>6305 decicycles in qsort,  32 runs,  0 skips
>5854 decicycles in qsort,  64 runs,  0 skips
>5152 decicycles in qsort, 128 runs,  0 skips
>4452 decicycles in qsort, 256 runs,  0 skips
>4161 decicycles in qsort, 511 runs,  1 skips
>4081 decicycles in qsort,1023 runs,  1 skips
>4072 decicycles in qsort,2047 runs,  1 skips
>4004 decicycles in qsort,4095 runs,  1 skips

ping

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

Re: [FFmpeg-devel] [PATCH] Don't needlessly reinitialize ff_cos_## tables.

[wm4]

On Sat, 24 Oct 2015 04:13:18 +0200
Michael Niedermayer  wrote:

> On Thu, Oct 22, 2015 at 09:48:30PM -0700, Dale Curtis wrote:
> > On Wed, Oct 21, 2015 at 6:52 PM, Dale Curtis 
> > wrote:
> >   
> > > On Tue, Oct 20, 2015 at 11:50 PM, Michael Niedermayer <  
> > > mich...@niedermayer.cc> wrote:
> > >>
> > >> the last element to be written should be checked, so that if
> > >> initialization is done by 2 threads at the same time, neither can
> > >> return from this function without initialization having finished
> > >>
> > >> also the race detectors are broken if they complain about cases where
> > >> a variable that has value a is set to value a, that cannot be part of
> > >> a race, not even if a is written byte per byte instead of atomically
> > >> unless theres something iam missing
> > >> Is this something that can be fixed or disabled on the side of the
> > >> race detectors?
> > >> It might reduce false positives in FFmpeg and potentially other
> > >> tools.
> > >>  
> > >
> > > We can suppress it, which I think is more reasonable then the overhead
> > > it'd take to make this "race" go away. I notice the sin tables are
> > > initialized within the fft context so there's no "race." Is there a reason
> > > the cosine tables aren't done this way?
> > >  
> > 
> > Actually it looks like sin may suffer from the same issues -- it doesn't
> > make a copy like I was thinking it did. One of the TSAN folk detailed why
> > suppression isn't a good idea here  
> 
> > https://codereview.chromium.org/1412123007/#msg7 -- which roughly says we
> > can't rely on the compiler to do the right thing here.  
> 
> quite independant of the sin/cos discussion here, This statement is
> IMHO somewhat problematic
> It may be strictly true in a language lawyer sense but
> 
> Lets assume that compilers did add random writes into writable arrays
> as long as they restore it before the next function call or return.
> like it seems assumed in the linked discussion
> 
> Frame multithreading has one thread decoding a frame and the next
> using that frame after it has been written, the individual accesses
> are not protected by mutexes nor could they, it would defeat the
> idea of parallel decoding ...
> Now if the compiler could randomly add writes that exist nowhere in
> the C code as long as the thread itself doesnt access it at that time,
> then this would break.

All what matters is if there are memory barriers between the accesses.
So for example if one thread is done with decoding a frame, and is
handed off to other threads as reference frame, then the
synchronization that takes care of this "handing off" will perform the
required memory barrier. Or am I getting this wrong?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH][RFC] avcodec/pthread_frame: fix null pointer dereference

[Hendrik Leppkes]

On Sat, Oct 24, 2015 at 3:26 PM, Ganesh Ajjanagadde
 wrote:
> On Sat, Oct 24, 2015 at 9:15 AM, Nicolas George  wrote:
>> Le tridi 3 brumaire, an CCXXIV, Ganesh Ajjanagadde a écrit :
>>> Fixes CID 1322329.
>>>
>>> Signed-off-by: Ganesh Ajjanagadde 
>>> ---
>>>  libavcodec/pthread_frame.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c
>>> index 7651211..ca06e3d 100644
>>> --- a/libavcodec/pthread_frame.c
>>> +++ b/libavcodec/pthread_frame.c
>>> @@ -305,7 +305,7 @@ static void release_delayed_buffers(PerThreadContext *p)
>>>  pthread_mutex_lock(>buffer_mutex);
>>>
>>>  // fix extended data in case the caller screwed it up
>>> -av_assert0(p->avctx->codec_type == AVMEDIA_TYPE_VIDEO ||
>>
>>> +av_assert0(p->avctx && p->avctx->codec_type == AVMEDIA_TYPE_VIDEO 
>>> ||
>>
>> I think the commit message should explain in what circumstances p->avctx can
>> be NULL. Otherwise, the extra test is only hiding a problem earlier in the
>> code.
>
> Ok, will check in more detail. Thanks.
>

More the the point, if this actually can be NULL, then an assert is
not what should check that, since asserts are just like crashes (even
if safer from a security point)
If it can't be NULL, then it seems like a false positive.

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

[FFmpeg-devel] [PATCH] lavfi/vf_decimate: do not compare the first frame to itself.

[Nicolas George]

This is a waste of computing power and will result to 0,
making it always dropped.
Use maximum difference values instead.

Signed-off-by: Nicolas George 
---
 libavfilter/vf_decimate.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/libavfilter/vf_decimate.c b/libavfilter/vf_decimate.c
index 26f3ce0..3b146cd 100644
--- a/libavfilter/vf_decimate.c
+++ b/libavfilter/vf_decimate.c
@@ -167,9 +167,12 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
 if (in) {
 /* update frame metrics */
 prv = dm->fid ? dm->queue[dm->fid - 1].frame : dm->last;
-if (!prv)
-prv = in;
-calc_diffs(dm, >queue[dm->fid], prv, in);
+if (!prv) {
+dm->queue[dm->fid].maxbdiff = INT64_MAX;
+dm->queue[dm->fid].totdiff  = INT64_MAX;
+} else {
+calc_diffs(dm, >queue[dm->fid], prv, in);
+}
 if (++dm->fid != dm->cycle)
 return 0;
 av_frame_free(>last);
-- 
2.6.1

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

Re: [FFmpeg-devel] [PATCH] videodsp: don't overread edges in vfix3 emu_edge.

[Carl Eugen Hoyos]

Ronald S. Bultje  gmail.com> writes:

> Great, thanks for verifying that. I'll apply with 
> your suggested addition to the commit message.

Please do, you could also mention ticket #3226: I 
was never able to reproduce (I can reproduce the 
Debian bug) but it has a very similar description 
iirc.
(And you could mention Andreas' analysis.)

Thank you, Carl Eugen

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

Re: [FFmpeg-devel] [PATCH] videodsp: don't overread edges in vfix3 emu_edge.

[Ronald S. Bultje]

Hi Andreas,

On Sat, Oct 24, 2015 at 11:41 AM, Andreas Cadhalpun <
andreas.cadhal...@googlemail.com> wrote:

> On 24.10.2015 14:47, Ronald S. Bultje wrote:
> > ---
> >  libavcodec/x86/videodsp.asm | 15 +++
> >  1 file changed, 11 insertions(+), 4 deletions(-)
> >
> > diff --git a/libavcodec/x86/videodsp.asm b/libavcodec/x86/videodsp.asm
> > index 25d4364..48f5ac0 100644
> > --- a/libavcodec/x86/videodsp.asm
> > +++ b/libavcodec/x86/videodsp.asm
> > @@ -194,8 +194,12 @@ hvar_fn
> >  %elif (%2-%%off) == 2
> >  movvalw, [srcq+%2-2]
> >  %elifidn %1, body
> > -movvald, [srcq+%2-3]
> > -%else
> > +movvalb, [srcq+%2-1]
> > +salvald, 16
> > +movvalw, [srcq+%2-3]
> > +%elifidn %1, bottom
> > +movd mm %+ %%mmx_idx, [srcq+%2-4]
> > +%else ; top
> >  movd mm %+ %%mmx_idx, [srcq+%2-3]
> >  %endif
> >  %endif ; (%2-%%off) >= 1
> > @@ -251,12 +255,15 @@ hvar_fn
> >  mov [dstq+%2-2], valw
> >  %elifidn %1, body
> >  mov [dstq+%2-3], valw
> > -shrvald, 16
> > +sarvald, 16
> >  mov [dstq+%2-1], valb
> >  %else
> >  movd   vald, mm %+ %%mmx_idx
> > +%ifidn %1, bottom
> > +sarvald, 8
> > +%endif
> >  mov [dstq+%2-3], valw
> > -shrvald, 16
> > +sarvald, 16
> >  mov [dstq+%2-1], valb
> >  %endif
> >  %endif ; (%2-%%off) >= 1
> >
>
> This fixes the crash and passes FATE, so looks good to me.
> Maybe mention the bug report in the commit message, e.g.:
> Bug-Debian: https://bugs.debian.org/801745


Thanks for testing, so this does actually fix the bug?

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

[FFmpeg-devel] [PATCH 4/7] lavfi/af_join: partially fix scheduling.

[Nicolas George]

Signed-off-by: Nicolas George 
---
 libavfilter/af_join.c | 50 +-
 1 file changed, 33 insertions(+), 17 deletions(-)

diff --git a/libavfilter/af_join.c b/libavfilter/af_join.c
index f5a1c50..bd780cc 100644
--- a/libavfilter/af_join.c
+++ b/libavfilter/af_join.c
@@ -78,11 +78,13 @@ static const AVOption join_options[] = {
 
 AVFILTER_DEFINE_CLASS(join);
 
+static int try_push_frame(AVFilterContext *ctx);
+
 static int filter_frame(AVFilterLink *link, AVFrame *frame)
 {
 AVFilterContext *ctx = link->dst;
 JoinContext   *s = ctx->priv;
-int i;
+int i, j;
 
 for (i = 0; i < ctx->nb_inputs; i++)
 if (link == ctx->inputs[i])
@@ -91,7 +93,17 @@ static int filter_frame(AVFilterLink *link, AVFrame *frame)
 av_assert0(!s->input_frames[i]);
 s->input_frames[i] = frame;
 
-return 0;
+/* request the same number of samples on all inputs */
+/* FIXME that means a frame arriving asynchronously on a different input
+   will not have the requested number of samples */
+if (i == 0) {
+int nb_samples = s->input_frames[0]->nb_samples;
+
+for (j = 1; !i && j < ctx->nb_inputs; j++)
+ctx->inputs[j]->request_samples = nb_samples;
+}
+
+return try_push_frame(ctx);
 }
 
 static int parse_maps(AVFilterContext *ctx)
@@ -387,27 +399,31 @@ static int join_request_frame(AVFilterLink *outlink)
 {
 AVFilterContext *ctx = outlink->src;
 JoinContext *s   = ctx->priv;
-AVFrame *frame;
-int linesize   = INT_MAX;
-int nb_samples = 0;
-int nb_buffers = 0;
-int i, j, ret;
+int i;
 
 /* get a frame on each input */
 for (i = 0; i < ctx->nb_inputs; i++) {
 AVFilterLink *inlink = ctx->inputs[i];
+if (!s->input_frames[i])
+return ff_request_frame(inlink);
+}
+return 0;
+}
 
-if (!s->input_frames[i] &&
-(ret = ff_request_frame(inlink)) < 0)
-return ret;
-
-/* request the same number of samples on all inputs */
-if (i == 0) {
-nb_samples = s->input_frames[0]->nb_samples;
+static int try_push_frame(AVFilterContext *ctx)
+{
+AVFilterLink *outlink = ctx->outputs[0];
+JoinContext *s   = ctx->priv;
+AVFrame *frame;
+int linesize   = INT_MAX;
+int nb_samples = INT_MAX;
+int nb_buffers = 0;
+int i, j, ret;
 
-for (j = 1; !i && j < ctx->nb_inputs; j++)
-ctx->inputs[j]->request_samples = nb_samples;
-}
+for (i = 0; i < ctx->nb_inputs; i++) {
+if (!s->input_frames[i])
+return 0;
+nb_samples = FFMIN(nb_samples, s->input_frames[i]->nb_samples);
 }
 
 /* setup the output frame */
-- 
2.6.1

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

[FFmpeg-devel] [PATCH 6/7] lavfi/af_amix: mostly fix scheduling.

[Nicolas George]

Signed-off-by: Nicolas George 
---
 libavfilter/af_amix.c | 142 ++
 1 file changed, 62 insertions(+), 80 deletions(-)

diff --git a/libavfilter/af_amix.c b/libavfilter/af_amix.c
index 434dd90..223328b 100644
--- a/libavfilter/af_amix.c
+++ b/libavfilter/af_amix.c
@@ -44,9 +44,8 @@
 #include "formats.h"
 #include "internal.h"
 
-#define INPUT_OFF  0/**< input has reached EOF */
 #define INPUT_ON   1/**< input is active */
-#define INPUT_INACTIVE 2/**< input is on, but is currently inactive */
+#define INPUT_EOF  2/**< input has reached EOF (may still be active) */
 
 #define DURATION_LONGEST  0
 #define DURATION_SHORTEST 1
@@ -209,7 +208,7 @@ static void calculate_scales(MixContext *s, int nb_samples)
 }
 
 for (i = 0; i < s->nb_inputs; i++) {
-if (s->input_state[i] == INPUT_ON)
+if (s->input_state[i] & INPUT_ON)
 s->input_scale[i] = 1.0f / s->scale_norm;
 else
 s->input_scale[i] = 0.0f;
@@ -264,15 +263,52 @@ static int config_output(AVFilterLink *outlink)
 return 0;
 }
 
+static int calc_active_inputs(MixContext *s);
+
 /**
  * Read samples from the input FIFOs, mix, and write to the output link.
  */
-static int output_frame(AVFilterLink *outlink, int nb_samples)
+static int output_frame(AVFilterLink *outlink)
 {
 AVFilterContext *ctx = outlink->src;
 MixContext  *s = ctx->priv;
 AVFrame *out_buf, *in_buf;
-int i;
+int nb_samples, ns, ret, i;
+
+ret = calc_active_inputs(s);
+if (ret < 0)
+return ret;
+
+if (s->input_state[0] & INPUT_ON) {
+/* first input live: use the corresponding frame size */
+nb_samples = frame_list_next_frame_size(s->frame_list);
+for (i = 1; i < s->nb_inputs; i++) {
+if (s->input_state[i] & INPUT_ON) {
+ns = av_audio_fifo_size(s->fifos[i]);
+if (ns < nb_samples) {
+if (!(s->input_state[i] & INPUT_EOF))
+/* unclosed input with not enough samples */
+return 0;
+/* closed input to drain */
+nb_samples = ns;
+}
+}
+}
+} else {
+/* first input closed: use the available samples */
+nb_samples = INT_MAX;
+for (i = 1; i < s->nb_inputs; i++) {
+if (s->input_state[i] & INPUT_ON) {
+ns = av_audio_fifo_size(s->fifos[i]);
+nb_samples = FFMIN(nb_samples, ns);
+}
+}
+if (nb_samples == INT_MAX)
+return AVERROR_EOF;
+}
+
+s->next_pts = frame_list_next_pts(s->frame_list);
+frame_list_remove_samples(s->frame_list, nb_samples);
 
 calculate_scales(s, nb_samples);
 
@@ -287,7 +323,7 @@ static int output_frame(AVFilterLink *outlink, int 
nb_samples)
 }
 
 for (i = 0; i < s->nb_inputs; i++) {
-if (s->input_state[i] == INPUT_ON) {
+if (s->input_state[i] & INPUT_ON) {
 int planes, plane_size, p;
 
 av_audio_fifo_read(s->fifos[i], (void **)in_buf->extended_data,
@@ -314,29 +350,6 @@ static int output_frame(AVFilterLink *outlink, int 
nb_samples)
 }
 
 /**
- * Returns the smallest number of samples available in the input FIFOs other
- * than that of the first input.
- */
-static int get_available_samples(MixContext *s)
-{
-int i;
-int available_samples = INT_MAX;
-
-av_assert0(s->nb_inputs > 1);
-
-for (i = 1; i < s->nb_inputs; i++) {
-int nb_samples;
-if (s->input_state[i] == INPUT_OFF)
-continue;
-nb_samples = av_audio_fifo_size(s->fifos[i]);
-available_samples = FFMIN(available_samples, nb_samples);
-}
-if (available_samples == INT_MAX)
-return 0;
-return available_samples;
-}
-
-/**
  * Requests a frame, if needed, from each input link other than the first.
  */
 static int request_samples(AVFilterContext *ctx, int min_samples)
@@ -348,19 +361,21 @@ static int request_samples(AVFilterContext *ctx, int 
min_samples)
 
 for (i = 1; i < s->nb_inputs; i++) {
 ret = 0;
-if (s->input_state[i] == INPUT_OFF)
+if (!(s->input_state[i] & INPUT_ON))
 continue;
-while (!ret && av_audio_fifo_size(s->fifos[i]) < min_samples)
-ret = ff_request_frame(ctx->inputs[i]);
+if (av_audio_fifo_size(s->fifos[i]) >= min_samples)
+continue;
+ret = ff_request_frame(ctx->inputs[i]);
 if (ret == AVERROR_EOF) {
+s->input_state[i] |= INPUT_EOF;
 if (av_audio_fifo_size(s->fifos[i]) == 0) {
-s->input_state[i] = INPUT_OFF;
+s->input_state[i] = 0;
 continue;
 }
 } else if (ret < 0)
 return ret;
 }
-return 0;
+return output_frame(ctx->outputs[0]);
 }
 
 /**
@@ -374,11 +389,11 @@ 

Re: [FFmpeg-devel] Can we drop OpenJPEG 1.5 in favor of 2.x?

[Ganesh Ajjanagadde]

On Sat, Oct 24, 2015 at 1:09 PM, Nicolas George  wrote:
> Le tridi 3 brumaire, an CCXXIV, Ganesh Ajjanagadde a écrit :
>> Definitely not. Even Arch Linux, generally an early adopter, does not
>> use openjpeg2, but instead openjpeg for most things.
>
> https://www.archlinux.org/packages/community/x86_64/openjpeg2/
>
> Are you sure of your statement?

I did not say it is not present, just that more packages rely on
openjpeg instead of openjpeg2. For instance, openjpeg2 is not even
installed on my system.
Or just look at the repo classification:
openjpeg2 is in community, while openjpeg is in extra, a more "core"
group of packages.

>
> Regards,
>
> --
>   Nicolas George
>
> ___
> 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 4/5] avfilter: avoid zero arguments to variadic macro

[Ganesh Ajjanagadde]

On Sat, Oct 24, 2015 at 1:48 PM, Michael Niedermayer
 wrote:
> On Sat, Oct 24, 2015 at 03:52:25PM +0200, Nicolas George wrote:
>> Le tridi 3 brumaire, an CCXXIV, Ganesh Ajjanagadde a écrit :
>> > Thanks for the super quick review. Will apply shortly. Do you (or
>> > others) think adding -Wgnu-zero-variadic-macro-arguments to configure
>> > is a good idea?
>>
>> Considering that each additional option takes ~15 ms in configure on a
>> fairly powerful box, not counting maintenance burden, I would say rather no.
>
> about 10ms here with
> time ./configure
> about 1.5ms here with
> time ./configure --cc='ccache gcc'  --tempprefix=/home/michael/ffconftemp
>
> also we could speed configure up with something like this:
> (or a more generic "all before each" checker)
>
> diff --git a/configure b/configure
> index a38b290..6fa3273 100755
> --- a/configure
> +++ b/configure
> @@ -5637,6 +5637,9 @@ disabled iconv || check_func_headers iconv.h iconv || 
> check_lib2 iconv.h iconv -
>  enabled debug && add_cflags -g"$debuglevel" && add_asflags -g"$debuglevel"
>
>  # add some useful compiler flags if supported
> +if ! check_cflags -Wdeclaration-after-statement -Wall 
> -Wdisabled-optimization -Wpointer-arith -Wredundant-decls \
> +  -Wwrite-strings -Wtype-limits -Wundef -Wmissing-prototypes 
> -Wno-pointer-to-int-cast -Wstrict-prototypes -Wempty-body ; then
> +
>  check_cflags -Wdeclaration-after-statement
>  check_cflags -Wall
>  check_cflags -Wdisabled-optimization
> @@ -5649,6 +5652,9 @@ check_cflags -Wmissing-prototypes
>  check_cflags -Wno-pointer-to-int-cast
>  check_cflags -Wstrict-prototypes
>  check_cflags -Wempty-body
> +#Note, if you add a check_cflags here, also add it to the if above
> +fi
> +
>  enabled extra_warnings && check_cflags -Winline
>
>  check_disable_warning(){

Will leave it to you (or others) for such patches (to speed up
configure and/or add warnings), I am fine either way.

>
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> No snowflake in an avalanche ever feels responsible. -- Voltaire
>
> ___
> 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] Wanted to contribute

[rishi shah]

Hi !
 I wanted to contribute in FFMpeg organization. What can be the good
starting point? I have Mac OS.


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

Re: [FFmpeg-devel] [PATCH] version.sh: add note that ffversion.h is auto-generated

[Ganesh Ajjanagadde]

On Thu, Oct 15, 2015 at 7:04 PM, Ganesh Ajjanagadde
 wrote:
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  version.sh | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/version.sh b/version.sh
> index f9754eb..a9d7e39 100755
> --- a/version.sh
> +++ b/version.sh
> @@ -54,6 +54,7 @@ GUARD=$(echo "$2" | sed 's/\//_/' | sed 's/\./_/' | tr 
> '[:lower:]' '[:upper:]' |
>  # Update version header only on revision changes to avoid spurious rebuilds
>  if test "$NEW_REVISION" != "$OLD_REVISION"; then
>  cat << EOF > "$2"
> +/* Automatically generated by version.sh, do not manually edit! */
>  #ifndef $GUARD
>  #define $GUARD
>  $NEW_REVISION
> --
> 2.6.1
>

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

[FFmpeg-devel] [PATCH][RFC] avcodec/pthread_frame: fix null pointer dereference

[Ganesh Ajjanagadde]

Fixes CID 1322329.

Signed-off-by: Ganesh Ajjanagadde 
---
 libavcodec/pthread_frame.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c
index 7651211..ca06e3d 100644
--- a/libavcodec/pthread_frame.c
+++ b/libavcodec/pthread_frame.c
@@ -305,7 +305,7 @@ static void release_delayed_buffers(PerThreadContext *p)
 pthread_mutex_lock(>buffer_mutex);
 
 // fix extended data in case the caller screwed it up
-av_assert0(p->avctx->codec_type == AVMEDIA_TYPE_VIDEO ||
+av_assert0(p->avctx && p->avctx->codec_type == AVMEDIA_TYPE_VIDEO ||
p->avctx->codec_type == AVMEDIA_TYPE_AUDIO);
 f = >released_buffers[--p->num_released_buffers];
 f->extended_data = f->data;
-- 
2.6.2

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

Re: [FFmpeg-devel] Wanted to contribute

[wm4]

On Sat, 24 Oct 2015 18:21:45 +0530
rishi shah  wrote:

> Hi !
>  I wanted to contribute in FFMpeg organization. What can be the good
> starting point? I have Mac OS.

Here's an overview: http://ffmpeg.org/developer.html#Contributing
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] swresample: Add support for clipping float/double to -1.0..1.0 range

[Clément Bœsch]

On Sat, Oct 24, 2015 at 03:16:15PM +0200, Clément Bœsch wrote:
> On Fri, Oct 23, 2015 at 12:41:18PM -0400, Ronald S. Bultje wrote:
> [...]
> > ffmpeg -h full, searching to -sws_flags, gives this:
> >   -sws_flags   E..V scaler flags (default 4)
> >  fast_bilinearE..V fast bilinear
> >  bilinear E..V bilinear
> >  bicubic  E..V bicubic
> >  experimental E..V experimental
> >  neighbor E..V nearest neighbor
> >  area E..V averaging area
> >  bicublin E..V luma bicubic, chroma bilinear
> >  gaussE..V Gaussian
> >  sinc E..V sinc
> >  lanczos  E..V Lanczos
> >  spline   E..V natural bicubic spline
> >  print_info   E..V print info
> >  accurate_rnd E..V accurate rounding
> >  full_chroma_int  E..V full chroma interpolation
> >  full_chroma_inp  E..V full chroma input
> >  bitexact E..V
> >  error_diffusion  E..V error diffusion dither
> > 
> > OK, so first, there's so many things wrong here, we're using flags as a way
> > to indicate the scaling method, and mixing up boolean flags. By the way,
> > did you know "experimental" is a scaling method? Fantastic help.
> 
> > The default is "4", but we don't know what flag "4" corresponds to.
> 
> (Just sent for this ♥)
> 

*a patch*

-- 
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 4/5] avfilter: avoid zero arguments to variadic macro

[Nicolas George]

Le tridi 3 brumaire, an CCXXIV, Ganesh Ajjanagadde a écrit :
> ISO C requires at least one argument in the place of the ellipsis in a
> variadic macro. In particular, under -pedantic, this triggers the
> warning -Wgnu-zero-variadic-macro-arguments on clang 3.7.
> 
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavfilter/af_asetrate.c |  4 ++--
>  libavfilter/asrc_sine.c   | 18 +-
>  2 files changed, 11 insertions(+), 11 deletions(-)

Ok. Good catch.

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 1/5] all: fix -Wextra-semi reported on clang

[Ganesh Ajjanagadde]

Hi all,

Apologies for the copy/pasted patch, but can't send via send-email.
Copy pasted for review below, attached also for a non-clobbered
version.

--

>From 82b889a359925d1f9f7496c916cf24146b44e648 Mon Sep 17 00:00:00 2001
From: Ganesh Ajjanagadde 
Date: Fri, 23 Oct 2015 11:23:42 -0400
Subject: [PATCH 1/5] all: fix -Wextra-semi reported on clang

This fixes extra semicolons that clang 3.7 on GNU/Linux warns about.
These were trigggered when built under -Wpedantic, which essentially
checks for strict ISO compliance in numerous ways.

Signed-off-by: Ganesh Ajjanagadde 
---
 ffprobe.c   |  20 +-
 libavcodec/x86/hevcdsp_init.c   | 637 ++--
 libavcodec/x86/rv40dsp_init.c   |   2 +-
 libavcodec/x86/vp9dsp_init.c|  14 +-
 libavcodec/x86/vp9dsp_init.h|   6 +-
 libavcodec/x86/vp9dsp_init_16bpp_template.c |  36 +-
 libavdevice/alsa.c  |   6 +-
 7 files changed, 358 insertions(+), 363 deletions(-)

diff --git a/ffprobe.c b/ffprobe.c
index ac03689..00584d2 100644
--- a/ffprobe.c
+++ b/ffprobe.c
@@ -3062,16 +3062,16 @@ static int opt_show_versions(const char *opt,
const char *arg)
 return 0;   \
 }

-DEFINE_OPT_SHOW_SECTION(chapters, CHAPTERS);
-DEFINE_OPT_SHOW_SECTION(error,ERROR);
-DEFINE_OPT_SHOW_SECTION(format,   FORMAT);
-DEFINE_OPT_SHOW_SECTION(frames,   FRAMES);
-DEFINE_OPT_SHOW_SECTION(library_versions, LIBRARY_VERSIONS);
-DEFINE_OPT_SHOW_SECTION(packets,  PACKETS);
-DEFINE_OPT_SHOW_SECTION(pixel_formats,PIXEL_FORMATS);
-DEFINE_OPT_SHOW_SECTION(program_version,  PROGRAM_VERSION);
-DEFINE_OPT_SHOW_SECTION(streams,  STREAMS);
-DEFINE_OPT_SHOW_SECTION(programs, PROGRAMS);
+DEFINE_OPT_SHOW_SECTION(chapters, CHAPTERS)
+DEFINE_OPT_SHOW_SECTION(error,ERROR)
+DEFINE_OPT_SHOW_SECTION(format,   FORMAT)
+DEFINE_OPT_SHOW_SECTION(frames,   FRAMES)
+DEFINE_OPT_SHOW_SECTION(library_versions, LIBRARY_VERSIONS)
+DEFINE_OPT_SHOW_SECTION(packets,  PACKETS)
+DEFINE_OPT_SHOW_SECTION(pixel_formats,PIXEL_FORMATS)
+DEFINE_OPT_SHOW_SECTION(program_version,  PROGRAM_VERSION)
+DEFINE_OPT_SHOW_SECTION(streams,  STREAMS)
+DEFINE_OPT_SHOW_SECTION(programs, PROGRAMS)

 static const OptionDef real_options[] = {
 #include "cmdutils_common_opts.h"
diff --git a/libavcodec/x86/hevcdsp_init.c b/libavcodec/x86/hevcdsp_init.c
index ddc876d..2181f6d 100644
--- a/libavcodec/x86/hevcdsp_init.c
+++ b/libavcodec/x86/hevcdsp_init.c
@@ -119,8 +119,8 @@ void
ff_hevc_put_hevc_bi_##name##W##_##bitd##_##opt(uint8_t *_dst,
ptrdiff_t dst
 }

 #define mc_rep_funcs(name, bitd, step, W, opt)\
-mc_rep_func(name, bitd, step, W, opt);\
-mc_rep_uni_func(name, bitd, step, W, opt);\
+mc_rep_func(name, bitd, step, W, opt)\
+mc_rep_uni_func(name, bitd, step, W, opt)\
 mc_rep_bi_func(name, bitd, step, W, opt)

 #define mc_rep_func2(name, bitd, step1, step2, W, opt) \
@@ -153,14 +153,9 @@ void
ff_hevc_put_hevc_bi_##name##W##_##bitd##_##opt(uint8_t *dst, ptrdiff_t
dsts
src2 + step1,
height, mx, my, width);\
 }

-#define mc_rep_funcs(name, bitd, step, W, opt)\
-mc_rep_func(name, bitd, step, W, opt);\
-mc_rep_uni_func(name, bitd, step, W, opt);\
-mc_rep_bi_func(name, bitd, step, W, opt)
-
 #define mc_rep_funcs2(name, bitd, step1, step2, W, opt) \
-mc_rep_func2(name, bitd, step1, step2, W, opt); \
-mc_rep_uni_func2(name, bitd, step1, step2, W, opt); \
+mc_rep_func2(name, bitd, step1, step2, W, opt)  \
+mc_rep_uni_func2(name, bitd, step1, step2, W, opt)  \
 mc_rep_bi_func2(name, bitd, step1, step2, W, opt)

 #if ARCH_X86_64 && HAVE_SSE4_EXTERNAL
@@ -196,9 +191,9 @@ void
ff_hevc_put_hevc_uni_##name##width1##_10_##opt1(uint8_t *dst,
ptrdiff_t dst
   height, mx, my,
width); \
 }

-#define mc_rep_mixs_10(name, width1, width2, width3, opt1, opt2, width4)\
-mc_rep_mix_10(name, width1, width2, width3, opt1, opt2, width4);\
-mc_bi_rep_mix_10(name, width1, width2, width3, opt1, opt2, width4); \
+#define mc_rep_mixs_10(name, width1, width2, width3, opt1, opt2, width4)   \
+mc_rep_mix_10(name, width1, width2, width3, opt1, opt2, width4)\
+mc_bi_rep_mix_10(name, width1, width2, width3, opt1, opt2, width4) \
 mc_uni_rep_mix_10(name, width1, width2, width3, opt1, opt2, width4)

 #define mc_rep_mix_8(name, width1, width2, width3, opt1, opt2)
\
@@ -232,199 +227,199 @@ void

Re: [FFmpeg-devel] [PATCH 3/5] all: use function pointer instead of void * data pointer

[Ganesh Ajjanagadde]

On Sat, Oct 24, 2015 at 11:01 AM, wm4  wrote:
> On Sat, 24 Oct 2015 09:28:52 -0400
> Ganesh Ajjanagadde  wrote:
>
>> ISO C does not guarantee that functions and data live in the same
>> address space. It is thus (strictly speaking) illegal to assign to a
>
> POSIX does.

Ok. You do not think that the removal of the casts improves
readability (ignoring the ISO C part)?

>
>> void * (which is a data pointer) from a function pointer.
>>
>> Found by enabling -Wpedantic on clang 3.7.
>>
>> Signed-off-by: Ganesh Ajjanagadde 
>
> ___
> 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 2/5] all: fix incorrect usage of %p format specifier

[wm4]

On Sat, 24 Oct 2015 09:35:48 -0400
Ganesh Ajjanagadde  wrote:

> Hi all,
> 
> Apologies for the copy/pasted patch, but can't send via send-email.
> Copy pasted for review below, attached also for a non-clobbered
> version.
> 
> --
> 
> From 99cd052b614553757efa1954bf8bf4dd3caf66d0 Mon Sep 17 00:00:00 2001
> From: Ganesh Ajjanagadde 
> Date: Fri, 23 Oct 2015 11:59:40 -0400
> Subject: [PATCH 2/5] all: fix incorrect usage of %p format specifier
> 
> ISO C %p format specifier applies to void * data pointers. This casts
> relevant pointers to void * in order to be strictly correct C.
> 
> Found by -Wpedantic on clang 3.7 (in particular -Wformat-pedantic).
> 
> Signed-off-by: Ganesh Ajjanagadde 

Utterly pointless and ugly.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Can we drop OpenJPEG 1.5 in favor of 2.x?

[Nicolas George]

Le tridi 3 brumaire, an CCXXIV, Ganesh Ajjanagadde a écrit :
> I did not say it is not present, just that more packages rely on
> openjpeg instead of openjpeg2.

Ok. But having it available is enough, we do not really care how many other
programs use it, only that Michael, the maintainer for this part of FFmpeg,
likes it better, and that it is easy to install for users.

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] videodsp: don't overread edges in vfix3 emu_edge.

[Ronald S. Bultje]

Hi Andreas,

On Sat, Oct 24, 2015 at 11:58 AM, Andreas Cadhalpun <
andreas.cadhal...@googlemail.com> wrote:

> Hi Ronald,
>
> On 24.10.2015 17:55, Ronald S. Bultje wrote:
> > On Sat, Oct 24, 2015 at 11:41 AM, Andreas Cadhalpun <
> > andreas.cadhal...@googlemail.com> wrote:
> >
> >> On 24.10.2015 14:47, Ronald S. Bultje wrote:
> >>> ---
> >>>  libavcodec/x86/videodsp.asm | 15 +++
> >>>  1 file changed, 11 insertions(+), 4 deletions(-)
> >>>
> >>> diff --git a/libavcodec/x86/videodsp.asm b/libavcodec/x86/videodsp.asm
> >>> index 25d4364..48f5ac0 100644
> >>> --- a/libavcodec/x86/videodsp.asm
> >>> +++ b/libavcodec/x86/videodsp.asm
> >>> @@ -194,8 +194,12 @@ hvar_fn
> >>>  %elif (%2-%%off) == 2
> >>>  movvalw, [srcq+%2-2]
> >>>  %elifidn %1, body
> >>> -movvald, [srcq+%2-3]
> >>> -%else
> >>> +movvalb, [srcq+%2-1]
> >>> +salvald, 16
> >>> +movvalw, [srcq+%2-3]
> >>> +%elifidn %1, bottom
> >>> +movd mm %+ %%mmx_idx, [srcq+%2-4]
> >>> +%else ; top
> >>>  movd mm %+ %%mmx_idx, [srcq+%2-3]
> >>>  %endif
> >>>  %endif ; (%2-%%off) >= 1
> >>> @@ -251,12 +255,15 @@ hvar_fn
> >>>  mov [dstq+%2-2], valw
> >>>  %elifidn %1, body
> >>>  mov [dstq+%2-3], valw
> >>> -shrvald, 16
> >>> +sarvald, 16
> >>>  mov [dstq+%2-1], valb
> >>>  %else
> >>>  movd   vald, mm %+ %%mmx_idx
> >>> +%ifidn %1, bottom
> >>> +sarvald, 8
> >>> +%endif
> >>>  mov [dstq+%2-3], valw
> >>> -shrvald, 16
> >>> +sarvald, 16
> >>>  mov [dstq+%2-1], valb
> >>>  %endif
> >>>  %endif ; (%2-%%off) >= 1
> >>>
> >>
> >> This fixes the crash and passes FATE, so looks good to me.
> >> Maybe mention the bug report in the commit message, e.g.:
> >> Bug-Debian: https://bugs.debian.org/801745
> >
> >
> > Thanks for testing, so this does actually fix the bug?
>
> Yes, at least I couldn't reproduce the crash anymore with this patch
> applied.


Great, thanks for verifying that. I'll apply with your suggested addition
to the commit message.

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

Re: [FFmpeg-devel] [PATCH 4/5] avfilter: avoid zero arguments to variadic macro

[Michael Niedermayer]

On Sat, Oct 24, 2015 at 03:52:25PM +0200, Nicolas George wrote:
> Le tridi 3 brumaire, an CCXXIV, Ganesh Ajjanagadde a écrit :
> > Thanks for the super quick review. Will apply shortly. Do you (or
> > others) think adding -Wgnu-zero-variadic-macro-arguments to configure
> > is a good idea?
> 
> Considering that each additional option takes ~15 ms in configure on a
> fairly powerful box, not counting maintenance burden, I would say rather no.

about 10ms here with
time ./configure
about 1.5ms here with
time ./configure --cc='ccache gcc'  --tempprefix=/home/michael/ffconftemp

also we could speed configure up with something like this:
(or a more generic "all before each" checker)

diff --git a/configure b/configure
index a38b290..6fa3273 100755
--- a/configure
+++ b/configure
@@ -5637,6 +5637,9 @@ disabled iconv || check_func_headers iconv.h iconv || 
check_lib2 iconv.h iconv -
 enabled debug && add_cflags -g"$debuglevel" && add_asflags -g"$debuglevel"

 # add some useful compiler flags if supported
+if ! check_cflags -Wdeclaration-after-statement -Wall -Wdisabled-optimization 
-Wpointer-arith -Wredundant-decls \
+  -Wwrite-strings -Wtype-limits -Wundef -Wmissing-prototypes 
-Wno-pointer-to-int-cast -Wstrict-prototypes -Wempty-body ; then
+
 check_cflags -Wdeclaration-after-statement
 check_cflags -Wall
 check_cflags -Wdisabled-optimization
@@ -5649,6 +5652,9 @@ check_cflags -Wmissing-prototypes
 check_cflags -Wno-pointer-to-int-cast
 check_cflags -Wstrict-prototypes
 check_cflags -Wempty-body
+#Note, if you add a check_cflags here, also add it to the if above
+fi
+
 enabled extra_warnings && check_cflags -Winline

 check_disable_warning(){


-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No snowflake in an avalanche ever feels responsible. -- Voltaire


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

[FFmpeg-devel] [PATCH] videodsp: don't overread edges in vfix3 emu_edge.

[Ronald S. Bultje]

---
 libavcodec/x86/videodsp.asm | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/libavcodec/x86/videodsp.asm b/libavcodec/x86/videodsp.asm
index 25d4364..48f5ac0 100644
--- a/libavcodec/x86/videodsp.asm
+++ b/libavcodec/x86/videodsp.asm
@@ -194,8 +194,12 @@ hvar_fn
 %elif (%2-%%off) == 2
 movvalw, [srcq+%2-2]
 %elifidn %1, body
-movvald, [srcq+%2-3]
-%else
+movvalb, [srcq+%2-1]
+salvald, 16
+movvalw, [srcq+%2-3]
+%elifidn %1, bottom
+movd mm %+ %%mmx_idx, [srcq+%2-4]
+%else ; top
 movd mm %+ %%mmx_idx, [srcq+%2-3]
 %endif
 %endif ; (%2-%%off) >= 1
@@ -251,12 +255,15 @@ hvar_fn
 mov [dstq+%2-2], valw
 %elifidn %1, body
 mov [dstq+%2-3], valw
-shrvald, 16
+sarvald, 16
 mov [dstq+%2-1], valb
 %else
 movd   vald, mm %+ %%mmx_idx
+%ifidn %1, bottom
+sarvald, 8
+%endif
 mov [dstq+%2-3], valw
-shrvald, 16
+sarvald, 16
 mov [dstq+%2-1], valb
 %endif
 %endif ; (%2-%%off) >= 1
-- 
2.1.2

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

[FFmpeg-devel] [PATCH 4/5] avfilter: avoid zero arguments to variadic macro

[Ganesh Ajjanagadde]

ISO C requires at least one argument in the place of the ellipsis in a
variadic macro. In particular, under -pedantic, this triggers the
warning -Wgnu-zero-variadic-macro-arguments on clang 3.7.

Signed-off-by: Ganesh Ajjanagadde 
---
 libavfilter/af_asetrate.c |  4 ++--
 libavfilter/asrc_sine.c   | 18 +-
 2 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/libavfilter/af_asetrate.c b/libavfilter/af_asetrate.c
index 409c48f..66febd7 100644
--- a/libavfilter/af_asetrate.c
+++ b/libavfilter/af_asetrate.c
@@ -39,8 +39,8 @@ typedef struct {
 OPT_GENERIC(name, field, def, min, max, descr, INT, i64, __VA_ARGS__)
 
 static const AVOption asetrate_options[] = {
-OPT_INT("sample_rate", sample_rate, 44100, 1, INT_MAX, "set the sample 
rate"),
-OPT_INT("r",   sample_rate, 44100, 1, INT_MAX, "set the sample 
rate"),
+OPT_INT("sample_rate", sample_rate, 44100, 1, INT_MAX, "set the sample 
rate",),
+OPT_INT("r",   sample_rate, 44100, 1, INT_MAX, "set the sample 
rate",),
 {NULL},
 };
 
diff --git a/libavfilter/asrc_sine.c b/libavfilter/asrc_sine.c
index cd43ae4..f361faa 100644
--- a/libavfilter/asrc_sine.c
+++ b/libavfilter/asrc_sine.c
@@ -67,15 +67,15 @@ typedef struct {
 OPT_GENERIC(name, field, def, min, max, descr, STRING, str, __VA_ARGS__)
 
 static const AVOption sine_options[] = {
-OPT_DBL("frequency", frequency,440, 0, DBL_MAX,   "set 
the sine frequency"),
-OPT_DBL("f", frequency,440, 0, DBL_MAX,   "set 
the sine frequency"),
-OPT_DBL("beep_factor",   beep_factor,0, 0, DBL_MAX,   "set 
the beep fequency factor"),
-OPT_DBL("b", beep_factor,0, 0, DBL_MAX,   "set 
the beep fequency factor"),
-OPT_INT("sample_rate",   sample_rate,44100, 1, INT_MAX,   "set 
the sample rate"),
-OPT_INT("r", sample_rate,44100, 1, INT_MAX,   "set 
the sample rate"),
-OPT_DUR("duration",  duration,   0, 0, INT64_MAX, "set 
the audio duration"),
-OPT_DUR("d", duration,   0, 0, INT64_MAX, "set 
the audio duration"),
-OPT_STR("samples_per_frame", samples_per_frame, "1024", 0, 0, "set 
the number of samples per frame"),
+OPT_DBL("frequency", frequency,440, 0, DBL_MAX,   "set 
the sine frequency",),
+OPT_DBL("f", frequency,440, 0, DBL_MAX,   "set 
the sine frequency",),
+OPT_DBL("beep_factor",   beep_factor,0, 0, DBL_MAX,   "set 
the beep fequency factor",),
+OPT_DBL("b", beep_factor,0, 0, DBL_MAX,   "set 
the beep fequency factor",),
+OPT_INT("sample_rate",   sample_rate,44100, 1, INT_MAX,   "set 
the sample rate",),
+OPT_INT("r", sample_rate,44100, 1, INT_MAX,   "set 
the sample rate",),
+OPT_DUR("duration",  duration,   0, 0, INT64_MAX, "set 
the audio duration",),
+OPT_DUR("d", duration,   0, 0, INT64_MAX, "set 
the audio duration",),
+OPT_STR("samples_per_frame", samples_per_frame, "1024", 0, 0, "set 
the number of samples per frame",),
 {NULL}
 };
 
-- 
2.6.2

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

[FFmpeg-devel] [PATCH 5/5] 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 such errors by explicitly casting as an int, doing the
desired unsigned to signed conversion. This method works on all current
architectures. Tested with FATE.

Signed-off-by: Ganesh Ajjanagadde 
---
 libavcodec/dca_syncwords.h | 24 
 libavformat/cinedec.c  |  8 
 libavformat/mov_chan.c |  2 +-
 3 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/libavcodec/dca_syncwords.h b/libavcodec/dca_syncwords.h
index 3466b6b..a2ff313 100644
--- a/libavcodec/dca_syncwords.h
+++ b/libavcodec/dca_syncwords.h
@@ -20,18 +20,18 @@
 #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,
+DCA_SYNCWORD_CORE_BE=  0x7FFE8001U,
+DCA_SYNCWORD_CORE_LE= (int)0xFE7F0180U,
+DCA_SYNCWORD_CORE_14B_BE=  0x1FFFE800U,
+DCA_SYNCWORD_CORE_14B_LE= (int)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,
 };
 
 #endif /* AVCODEC_DCA_SYNCWORDS_H */
diff --git a/libavformat/cinedec.c b/libavformat/cinedec.c
index 632f46c..9a9023e 100644
--- a/libavformat/cinedec.c
+++ b/libavformat/cinedec.c
@@ -50,10 +50,10 @@ enum {
 CFA_BAYER = 3,  /**< GB/RG */
 CFA_BAYERFLIP = 4,  /**< RG/GB */
 
-CFA_TLGRAY= 0x8000,
-CFA_TRGRAY= 0x4000,
-CFA_BLGRAY= 0x2000,
-CFA_BRGRAY= 0x1000
+CFA_TLGRAY= (int)0x8000,
+CFA_TRGRAY=  0x4000,
+CFA_BLGRAY=  0x2000,
+CFA_BRGRAY=  0x1000
 };
 
 static int cine_read_probe(AVProbeData *p)
diff --git a/libavformat/mov_chan.c b/libavformat/mov_chan.c
index a2fa8d6..cb91a05 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,
+MOV_CH_LAYOUT_UNKNOWN   = (int)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

[FFmpeg-devel] [PATCH 3/5] all: use function pointer instead of void * data pointer

[Ganesh Ajjanagadde]

ISO C does not guarantee that functions and data live in the same
address space. It is thus (strictly speaking) illegal to assign to a
void * (which is a data pointer) from a function pointer.

Found by enabling -Wpedantic on clang 3.7.

Signed-off-by: Ganesh Ajjanagadde 
---
 ffmpeg_opt.c  | 8 
 libavcodec/hevc.c | 2 +-
 libavfilter/vf_drawtext.c | 2 +-
 libavfilter/vf_lut.c  | 6 +++---
 libavformat/async.c   | 2 +-
 5 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/ffmpeg_opt.c b/ffmpeg_opt.c
index 8f6416c..131dd89 100644
--- a/ffmpeg_opt.c
+++ b/ffmpeg_opt.c
@@ -3116,7 +3116,7 @@ const OptionDef options[] = {
 { "target", HAS_ARG | OPT_PERFILE | OPT_OUTPUT,  { 
.func_arg = opt_target },
 "specify target file type (\"vcd\", \"svcd\", \"dvd\", \"dv\" or 
\"dv50\" "
 "with optional prefixes \"pal-\", \"ntsc-\" or \"film-\")", "type" },
-{ "vsync",  HAS_ARG | OPT_EXPERT,{ 
opt_vsync },
+{ "vsync",  HAS_ARG | OPT_EXPERT,{ 
.func_arg = opt_vsync },
 "video sync method", "" },
 { "frame_drop_threshold", HAS_ARG | OPT_FLOAT | OPT_EXPERT,  { 
_drop_threshold },
 "frame drop threshold", "" },
@@ -3240,9 +3240,9 @@ const OptionDef options[] = {
 "this option is deprecated, use the yadif filter instead" },
 { "psnr", OPT_VIDEO | OPT_BOOL | OPT_EXPERT,   
  { _psnr },
 "calculate PSNR of compressed frames" },
-{ "vstats",   OPT_VIDEO | OPT_EXPERT , 
  { _vstats },
+{ "vstats",   OPT_VIDEO | OPT_EXPERT , 
  { .func_arg = opt_vstats },
 "dump video coding statistics to file" },
-{ "vstats_file",  OPT_VIDEO | HAS_ARG | OPT_EXPERT ,   
  { opt_vstats_file },
+{ "vstats_file",  OPT_VIDEO | HAS_ARG | OPT_EXPERT ,   
  { .func_arg = opt_vstats_file },
 "dump video coding statistics to file", "file" },
 { "vf",   OPT_VIDEO | HAS_ARG  | OPT_PERFILE | OPT_OUTPUT, 
  { .func_arg = opt_video_filters },
 "set video filters", "filter_graph" },
@@ -3352,7 +3352,7 @@ const OptionDef options[] = {
 "set the initial demux-decode delay", "seconds" },
 { "override_ffserver", OPT_BOOL | OPT_EXPERT | OPT_OUTPUT, { 
_ffserver },
 "override the options from ffserver", "" },
-{ "sdp_file", HAS_ARG | OPT_EXPERT | OPT_OUTPUT, { opt_sdp_file },
+{ "sdp_file", HAS_ARG | OPT_EXPERT | OPT_OUTPUT, { .func_arg = 
opt_sdp_file },
 "specify a file in which to print sdp information", "file" },
 
 { "bsf", HAS_ARG | OPT_STRING | OPT_SPEC | OPT_EXPERT | OPT_OUTPUT, { .off 
= OFFSET(bitstream_filters) },
diff --git a/libavcodec/hevc.c b/libavcodec/hevc.c
index cd49718..4b3f199 100644
--- a/libavcodec/hevc.c
+++ b/libavcodec/hevc.c
@@ -2511,7 +2511,7 @@ static int hls_slice_data_wpp(HEVCContext *s, const 
HEVCNAL *nal)
 }
 
 if (s->ps.pps->entropy_coding_sync_enabled_flag)
-s->avctx->execute2(s->avctx, (void *) hls_decode_entry_wpp, arg, ret, 
s->sh.num_entry_point_offsets + 1);
+s->avctx->execute2(s->avctx, hls_decode_entry_wpp, arg, ret, 
s->sh.num_entry_point_offsets + 1);
 
 for (i = 0; i <= s->sh.num_entry_point_offsets; i++)
 res += ret[i];
diff --git a/libavfilter/vf_drawtext.c b/libavfilter/vf_drawtext.c
index 8e21693..5c4676e 100644
--- a/libavfilter/vf_drawtext.c
+++ b/libavfilter/vf_drawtext.c
@@ -1087,7 +1087,7 @@ static int draw_glyphs(DrawTextContext *s, AVFrame *frame,
 continue;
 
 dummy.code = code;
-glyph = av_tree_find(s->glyphs, , (void *)glyph_cmp, NULL);
+glyph = av_tree_find(s->glyphs, , glyph_cmp, NULL);
 
 bitmap = borderw ? glyph->border_bitmap : glyph->bitmap;
 
diff --git a/libavfilter/vf_lut.c b/libavfilter/vf_lut.c
index 7d708f6..f0a2aba 100644
--- a/libavfilter/vf_lut.c
+++ b/libavfilter/vf_lut.c
@@ -186,9 +186,9 @@ static double compute_gammaval709(void *opaque, double 
gamma)
 }
 
 static double (* const funcs1[])(void *, double) = {
-(void *)clip,
-(void *)compute_gammaval,
-(void *)compute_gammaval709,
+clip,
+compute_gammaval,
+compute_gammaval709,
 NULL
 };
 
diff --git a/libavformat/async.c b/libavformat/async.c
index 9fac84a..f4474b8 100644
--- a/libavformat/async.c
+++ b/libavformat/async.c
@@ -224,7 +224,7 @@ static void *async_buffer_task(void *arg)
 pthread_mutex_unlock(>mutex);
 
 to_copy = FFMIN(4096, fifo_space);
-ret = ring_generic_write(ring, (void *)h, to_copy, (void 
*)wrapped_url_read);
+ret = ring_generic_write(ring, (void *)h, to_copy, wrapped_url_read);
 
 pthread_mutex_lock(>mutex);
 if (ret <= 0) {
-- 
2.6.2

___
ffmpeg-devel mailing list

Re: [FFmpeg-devel] [PATCH 2/5] all: fix incorrect usage of %p format specifier

[Ganesh Ajjanagadde]

On Sat, Oct 24, 2015 at 9:44 AM, Nicolas George  wrote:
> Le tridi 3 brumaire, an CCXXIV, Ganesh Ajjanagadde a écrit :
>> Apologies for the copy/pasted patch, but can't send via send-email.
>
> Maybe you should take some time to tackle your email troubles?
>
>> ISO C %p format specifier applies to void * data pointers. This casts
>> relevant pointers to void * in order to be strictly correct C.
>>
>> Found by -Wpedantic on clang 3.7 (in particular -Wformat-pedantic).
>
> I am rather against this change, it makes the code significantly less
> readable, and this instance I see zero chances of it fixing an actual issue
> any time.
>
> There is a reason these warnings are called "pedantic": there are often
> irrelevant.

Indeed, part of the goal of this patch series was to see which ones
people like. Consider the patch dropped unless others have something
else to say about it.

>
> Regards,
>
> --
>   Nicolas George
> ___
> 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 2/5] all: fix incorrect usage of %p format specifier

[Nicolas George]

Le tridi 3 brumaire, an CCXXIV, Ganesh Ajjanagadde a écrit :
> I have spent some time on this. Given up on gmail, as it is not in my
> control, and is inconsistent. I have tried following my university's
> mail configuration, but it does not work. Will need to speak with them
> at some point. Until then, I view this is a reasonable compromise for
> large patches.

I am rather surprised by your troubles with gmail. You are definitely not
the only person using it, but you are the only one I heard have trouble at
this kind of level.

And this is not the only issue. A decent MUA should not mangle patches, even
copy-pasted ones. We can not urge random contributors to completely change
their habits, but since you are obviously here to stay, you should certainly
make sure you use good tools as soon as possible.

Anyway, this was just advice, but I stick to it: you can probably get things
working by yourself (possibly with help, but without requiring intervention
from administrators), and I believe you would gain time overall by
addressing it as soon as possible.

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 1/7] lavfi: remove astreamsync.

[Nicolas George]

It was only useful for very specific testing purposes
and appears to be currently partially broken.

Signed-off-by: Nicolas George 
---
 MAINTAINERS  |   1 -
 doc/filters.texi |  36 ---
 libavfilter/Makefile |   1 -
 libavfilter/af_astreamsync.c | 243 ---
 libavfilter/allfilters.c |   1 -
 5 files changed, 282 deletions(-)
 delete mode 100644 libavfilter/af_astreamsync.c


I had a hard time getting the filters from libav to behave correctly,
but now I have a non-recursive version of request_frame() working.
It still needs some work, two filters still have a loop in request_frame()
that I need to remove (and no FATE test), and then some cleanup. But It is
getting there.

FATE passes after each patch in this series, and also with the non-recursive
request_frame().

The affected parts in this series are either mine or from libav, so there is
not really anyone else to approve them. If there are no objection I will
push in a few days.


diff --git a/MAINTAINERS b/MAINTAINERS
index 25cff79..a08adf7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -347,7 +347,6 @@ Filters:
   af_aphaser.c  Paul B Mahol
   af_aresample.cMichael Niedermayer
   af_astats.c   Paul B Mahol
-  af_astreamsync.c  Nicolas George
   af_atempo.c   Pavel Koshevoy
   af_biquads.c  Paul B Mahol
   af_chorus.c   Paul B Mahol
diff --git a/doc/filters.texi b/doc/filters.texi
index 5a35bde..6e8931e 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -1170,42 +1170,6 @@ Number of occasions (not the number of samples) that the 
signal attained either
 Overall bit depth of audio. Number of bits used for each sample.
 @end table
 
-@section astreamsync
-
-Forward two audio streams and control the order the buffers are forwarded.
-
-The filter accepts the following options:
-
-@table @option
-@item expr, e
-Set the expression deciding which stream should be
-forwarded next: if the result is negative, the first stream is forwarded; if
-the result is positive or zero, the second stream is forwarded. It can use
-the following variables:
-
-@table @var
-@item b1 b2
-number of buffers forwarded so far on each stream
-@item s1 s2
-number of samples forwarded so far on each stream
-@item t1 t2
-current timestamp of each stream
-@end table
-
-The default value is @code{t1-t2}, which means to always forward the stream
-that has a smaller timestamp.
-@end table
-
-@subsection Examples
-
-Stress-test @code{amerge} by randomly sending buffers on the wrong
-input, while avoiding too much of a desynchronization:
-@example
-amovie=file.ogg [a] ; amovie=file.mp3 [b] ;
-[a] [b] astreamsync=(2*random(1))-1+tanh(5*(t1-t2)) [a2] [b2] ;
-[a2] [b2] amerge
-@end example
-
 @section asyncts
 
 Synchronize audio data with timestamps by squeezing/stretching it and/or
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 8e776c1..f2f6dd1 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -50,7 +50,6 @@ OBJS-$(CONFIG_ASETTB_FILTER) += settb.o
 OBJS-$(CONFIG_ASHOWINFO_FILTER)  += af_ashowinfo.o
 OBJS-$(CONFIG_ASPLIT_FILTER) += split.o
 OBJS-$(CONFIG_ASTATS_FILTER) += af_astats.o
-OBJS-$(CONFIG_ASTREAMSYNC_FILTER)+= af_astreamsync.o
 OBJS-$(CONFIG_ASYNCTS_FILTER)+= af_asyncts.o
 OBJS-$(CONFIG_ATEMPO_FILTER) += af_atempo.o
 OBJS-$(CONFIG_ATRIM_FILTER)  += trim.o
diff --git a/libavfilter/af_astreamsync.c b/libavfilter/af_astreamsync.c
deleted file mode 100644
index d08da26..000
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 9385fdf..e7f6bec 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -72,7 +72,6 @@ void avfilter_register_all(void)
 REGISTER_FILTER(ASHOWINFO,  ashowinfo,  af);
 REGISTER_FILTER(ASPLIT, asplit, af);
 REGISTER_FILTER(ASTATS, astats, af);
-REGISTER_FILTER(ASTREAMSYNC,astreamsync,af);
 REGISTER_FILTER(ASYNCTS,asyncts,af);
 REGISTER_FILTER(ATEMPO, atempo, af);
 REGISTER_FILTER(ATRIM,  atrim,  af);
-- 
2.6.1

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

[FFmpeg-devel] [PATCH 5/7] lavfi/vf_framepack: fix scheduling.

[Nicolas George]

Signed-off-by: Nicolas George 
---
 libavfilter/vf_framepack.c | 18 +++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/libavfilter/vf_framepack.c b/libavfilter/vf_framepack.c
index be52507..621a034 100644
--- a/libavfilter/vf_framepack.c
+++ b/libavfilter/vf_framepack.c
@@ -268,25 +268,26 @@ static av_always_inline void 
spatial_frame_pack(AVFilterLink *outlink,
 }
 }
 
+static int try_push_frame(AVFilterContext *ctx);
+
 static int filter_frame_left(AVFilterLink *inlink, AVFrame *frame)
 {
 FramepackContext *s = inlink->dst->priv;
 s->input_views[LEFT] = frame;
-return 0;
+return try_push_frame(inlink->dst);
 }
 
 static int filter_frame_right(AVFilterLink *inlink, AVFrame *frame)
 {
 FramepackContext *s = inlink->dst->priv;
 s->input_views[RIGHT] = frame;
-return 0;
+return try_push_frame(inlink->dst);
 }
 
 static int request_frame(AVFilterLink *outlink)
 {
 AVFilterContext *ctx = outlink->src;
 FramepackContext *s = ctx->priv;
-AVStereo3D *stereo;
 int ret, i;
 
 /* get a frame on the either input, stop as soon as a video ends */
@@ -297,7 +298,18 @@ static int request_frame(AVFilterLink *outlink)
 return ret;
 }
 }
+return 0;
+}
+
+static int try_push_frame(AVFilterContext *ctx)
+{
+FramepackContext *s = ctx->priv;
+AVFilterLink *outlink = ctx->outputs[0];
+AVStereo3D *stereo;
+int ret, i;
 
+if (!(s->input_views[0] && s->input_views[1]))
+return 0;
 if (s->format == AV_STEREO3D_FRAMESEQUENCE) {
 if (s->double_pts == AV_NOPTS_VALUE)
 s->double_pts = s->input_views[LEFT]->pts;
-- 
2.6.1

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

[FFmpeg-devel] [PATCH 7/7] lavfi/af_asyncts: remove looping on request_frame().

[Nicolas George]

Signed-off-by: Nicolas George 
---
 libavfilter/af_asyncts.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/libavfilter/af_asyncts.c b/libavfilter/af_asyncts.c
index 214cefd..209fc4c 100644
--- a/libavfilter/af_asyncts.c
+++ b/libavfilter/af_asyncts.c
@@ -139,8 +139,7 @@ static int request_frame(AVFilterLink *link)
 int nb_samples;
 
 s->got_output = 0;
-while (ret >= 0 && !s->got_output)
-ret = ff_request_frame(ctx->inputs[0]);
+ret = ff_request_frame(ctx->inputs[0]);
 
 /* flush the fifo */
 if (ret == AVERROR_EOF) {
-- 
2.6.1

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

Re: [FFmpeg-devel] [PATCH] avutil/opt: print more meaningful default flags values

[Michael Niedermayer]

On Sat, Oct 24, 2015 at 03:14:33PM +0200, Clément Bœsch wrote:
> Example:
> % ./ffmpeg -h encoder=gif
> [...]
> GIF encoder AVOptions:
>   -gifflagsE..V set GIF flags (default 
> offsetting+transdiff)
>  offsetting   E..V enable picture offsetting
>  transdiffE..V enable transparency detection 
> between frames
> ---
>  libavutil/opt.c| 32 ++--
>  tests/ref/fate/opt |  2 +-
>  2 files changed, 31 insertions(+), 3 deletions(-)

LGTM

thanks

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

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


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

Re: [FFmpeg-devel] Can we drop OpenJPEG 1.5 in favor of 2.x?

[James Almer]

On 10/24/2015 1:03 PM, Michael Bradshaw wrote:
> tl;dr: I've got a patch that updates OpenJPEG to 2.0/2.1. Currently, I've
> opted to drop OpenJPEG 1.5. Should I proceed with preparing this patch for
> submission, or should I alter it to keep 1.5 support?
> 
> 
> 
> The OpenJPEG API went through a bit of an overhaul in the 1.x to 2.x
> transition. This means that supporting 1.5 and 2.x concurrently in ffmpeg
> would be possible, but would require some (ugly) macros.
> 
> Given that v2.0 was released ~19 months ago, I think it's been long enough
> that users should, most likely, have access to a modern 2.x OpenJPEG on
> their machine. So I don't think dropping 1.5 would be catastrophic.
> 
> But, on the other hand, it's nice to be a swiss army knife that works with
> everything, so I can understand if others think supporting 1.5 is important.
> 
> I don't want to submit my patch (as is) if I'm just going to be told to go
> back and keep 1.5 support. If ya'll still want 1.5 support, I'd rather
> include that from the get-go rather than revising the patch during the
> review.
> 
> Opinions on whether 1.5 should be dropped in favor of 2.x?

Why does configure even check for 2.x if the actual lavc wrappers don't
currently support it?

Gentoo and Debian both seem to ship it. Arch does as well but on their
Community repository (ffmpeg adopting it may be incentive enough for them
to move it to Extra).
No idea about other distros, but in any case, if there's any that doesn't
ship it then we should keep supporting it for a while, even if it means
adding some ugly macros. We could even add some deprecation warning during
configure if 1.5 is used, to urge distros to switch.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Can we drop OpenJPEG 1.5 in favor of 2.x?

[Nicolas George]

Le tridi 3 brumaire, an CCXXIV, James Almer a écrit :
> No idea about other distros, but in any case, if there's any that doesn't
> ship it then we should keep supporting it for a while, even if it means
> adding some ugly macros.

Depending on the ugliness of the macros, maybe duplicating the file as
libopenjpeg15.c and libopenjpeg2.c, and having the build system use one (or
possibly both, for testing) would be a better option. Duplicating code is of
course not a good practice, but littering the bug with conditional
compilation is horrible too, whichever is the least horrible in this
particular case should be considered.

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 5/5] all: fix enum definition for large values

[Michael Niedermayer]

On Sat, Oct 24, 2015 at 02:41:59PM -0400, Ganesh Ajjanagadde wrote:
> On Sat, Oct 24, 2015 at 2:33 PM, Michael Niedermayer
>  wrote:
> > On Sat, Oct 24, 2015 at 09:29:23AM -0400, 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 such errors by explicitly casting as an int, doing the
> >> desired unsigned to signed conversion. This method works on all current
> >> architectures. Tested with FATE.
> >>
> >> Signed-off-by: Ganesh Ajjanagadde 
> >
> > Simply changing the values to signed is not correct / not sufficient
> > the code assumes that they are unsigned
> 
> enums are ints (and hence signed).

this is not true (though thats off topic but you seemed interrested in
the C spec)
6.7.2.2 Enumeration specifiers
...
4 Each enumerated type shall be compatible with char, a signed integer type, or 
an
  unsigned integer type. The choice of type is implementation-defined,110) but 
shall be
  capable of representing the values of all the members of the enumeration. The
  enumerated type is incomplete until after the } that terminates the list of 
enumerator
  declarations.

so a enum type can be almost anything the implementation likes it to
be. 2 enums dont even need to be using the same type and this is not
just specification talk, gcc does this actually, for example it will
use (u)int64 as type when things dont fit in an (unsigned) int
also on at least some embeded platforms gcc will use shorts
for enums that fit in a short int (no i dont know which exactly but
i read about people stumbling into this so it must happen on some
platform)


> I doubt code assumed that they are
> unsigned. If code depended on these being unsigned constants, then
> there is no way of placing them in an enum. Are you fine with a macro,
> or do you prefer a static const style? Generally, it seems like FFmpeg
> prefers the macro method for defining such constants/flags.

if have no preferrance for anything beyond the code working

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

Many that live deserve death. And some that die deserve life. Can you give
it to them? Then do not be too eager to deal out death in judgement. For
even the very wise cannot see all ends. -- Gandalf


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

Re: [FFmpeg-devel] [PATCH 3/5] all: use function pointer instead of void * data pointer

[Ganesh Ajjanagadde]

On Sat, Oct 24, 2015 at 1:23 PM, Michael Niedermayer
 wrote:
> On Sat, Oct 24, 2015 at 09:28:52AM -0400, Ganesh Ajjanagadde wrote:
>> ISO C does not guarantee that functions and data live in the same
>> address space. It is thus (strictly speaking) illegal to assign to a
>> void * (which is a data pointer) from a function pointer.
>>
>> Found by enabling -Wpedantic on clang 3.7.
>>
>> Signed-off-by: Ganesh Ajjanagadde 
>> ---
>>  ffmpeg_opt.c  | 8 
>>  libavcodec/hevc.c | 2 +-
>>  libavfilter/vf_drawtext.c | 2 +-
>>  libavfilter/vf_lut.c  | 6 +++---
>>  libavformat/async.c   | 2 +-
>>  5 files changed, 10 insertions(+), 10 deletions(-)
>
> if these dont add any new warnings then LGTM
> but the commit message should rather point to code cleanup and
> not ISO C

They do not add warnings as far as I can tell (under standard warning
flags). Reworded message to reflect that it represents a cleanup, and
pushed. Thanks.

>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> The bravest are surely those who have the clearest vision
> of what is before them, glory and danger alike, and yet
> notwithstanding go out to meet it. -- Thucydides
>
> ___
> 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] [PATCH 4/5] concatdec: add metadata for file start time and duration

[Marton Balint]

Signed-off-by: Marton Balint 
---
 libavformat/concatdec.c| 6 ++
 tests/ref/fate/concat-demuxer-lavf-mxf | 2 +-
 tests/ref/fate/concat-demuxer-lavf-mxf_d10 | 2 +-
 tests/ref/fate/concat-demuxer-lavf-ts  | 2 +-
 4 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/libavformat/concatdec.c b/libavformat/concatdec.c
index f262d44..51b9703 100644
--- a/libavformat/concatdec.c
+++ b/libavformat/concatdec.c
@@ -289,6 +289,7 @@ static int open_file(AVFormatContext *avf, unsigned fileno)
 {
 ConcatContext *cat = avf->priv_data;
 ConcatFile *file = >files[fileno];
+AVDictionaryEntry *entry;
 int ret;
 
 if (cat->avf)
@@ -324,6 +325,11 @@ static int open_file(AVFormatContext *avf, unsigned fileno)
 file->duration -= cat->avf->duration - (file->outpoint - 
file->file_start_time);
 }
 
+if (!(entry = av_dict_get(file->metadata, "lavf.concatdec.start_time", 
NULL, 0)))
+av_dict_set_int(>metadata, "lavf.concatdec.start_time", 
file->start_time, 0);
+if (!(entry = av_dict_get(file->metadata, "lavf.concatdec.duration", NULL, 
0)))
+av_dict_set_int(>metadata, "lavf.concatdec.duration", 
file->duration, 0);
+
 if ((ret = match_streams(avf)) < 0)
 return ret;
 if (file->inpoint != AV_NOPTS_VALUE) {
diff --git a/tests/ref/fate/concat-demuxer-lavf-mxf 
b/tests/ref/fate/concat-demuxer-lavf-mxf
index a6fa554..d6c82d6 100644
--- a/tests/ref/fate/concat-demuxer-lavf-mxf
+++ b/tests/ref/fate/concat-demuxer-lavf-mxf
@@ -1 +1 @@
-56359998da34c3957124a8928fb58f3d 
*tests/data/fate/concat-demuxer-lavf-mxf.ffprobe
+23cd3acf3db9ee19228f381f05f1f3b9 
*tests/data/fate/concat-demuxer-lavf-mxf.ffprobe
diff --git a/tests/ref/fate/concat-demuxer-lavf-mxf_d10 
b/tests/ref/fate/concat-demuxer-lavf-mxf_d10
index 018d631..08777f7 100644
--- a/tests/ref/fate/concat-demuxer-lavf-mxf_d10
+++ b/tests/ref/fate/concat-demuxer-lavf-mxf_d10
@@ -1 +1 @@
-89c81149b4673c60aba7cf5f27cec823 
*tests/data/fate/concat-demuxer-lavf-mxf_d10.ffprobe
+bd1c6cc871fe5193186a03554ebc84c1 
*tests/data/fate/concat-demuxer-lavf-mxf_d10.ffprobe
diff --git a/tests/ref/fate/concat-demuxer-lavf-ts 
b/tests/ref/fate/concat-demuxer-lavf-ts
index 2e8ba46..a01f712 100644
--- a/tests/ref/fate/concat-demuxer-lavf-ts
+++ b/tests/ref/fate/concat-demuxer-lavf-ts
@@ -1 +1 @@
-1993b3613952fa76da8c5c260a16a96a 
*tests/data/fate/concat-demuxer-lavf-ts.ffprobe
+728e773e5009f7f652c1677573b6c8d2 
*tests/data/fate/concat-demuxer-lavf-ts.ffprobe
-- 
2.1.4

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

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

[Marton Balint]

Signed-off-by: Marton Balint 
---
 tests/Makefile |   1 +
 tests/fate-run.sh  |  14 
 tests/fate/concatdec.mak   |  12 
 tests/ref/fate/concat-demuxer-lavf-mxf |   1 +
 tests/ref/fate/concat-demuxer-lavf-mxf_d10 |   1 +
 tests/ref/fate/concat-demuxer-lavf-ts  |   1 +
 tests/test_template.ffconcat   | 112 +
 7 files changed, 142 insertions(+)
 create mode 100644 tests/fate/concatdec.mak
 create mode 100644 tests/ref/fate/concat-demuxer-lavf-mxf
 create mode 100644 tests/ref/fate/concat-demuxer-lavf-mxf_d10
 create mode 100644 tests/ref/fate/concat-demuxer-lavf-ts
 create mode 100644 tests/test_template.ffconcat

diff --git a/tests/Makefile b/tests/Makefile
index 7ee4a46..62544d0 100644
--- a/tests/Makefile
+++ b/tests/Makefile
@@ -113,6 +113,7 @@ include $(SRC_PATH)/tests/fate/audio.mak
 include $(SRC_PATH)/tests/fate/bmp.mak
 include $(SRC_PATH)/tests/fate/cdxl.mak
 include $(SRC_PATH)/tests/fate/checkasm.mak
+include $(SRC_PATH)/tests/fate/concatdec.mak
 include $(SRC_PATH)/tests/fate/cover-art.mak
 include $(SRC_PATH)/tests/fate/demux.mak
 include $(SRC_PATH)/tests/fate/dfa.mak
diff --git a/tests/fate-run.sh b/tests/fate-run.sh
index a3938dc..2056093 100755
--- a/tests/fate-run.sh
+++ b/tests/fate-run.sh
@@ -249,6 +249,20 @@ gapless(){
 do_md5sum $decfile3
 }
 
+concat(){
+template=$(target_path $1)
+sample=$(target_path $2)
+
+concatfile="${outdir}/${test}.ffconcat"
+packetfile="${outdir}/${test}.ffprobe"
+cleanfiles="$concatfile $packetfile"
+
+awk "{gsub(/%SRCFILE%/, \"$sample\"); print}" $template > $concatfile
+run ffprobe${PROGSUF} -show_streams -show_packets -v 0 -fflags keepside -f 
concat $concatfile > $packetfile
+
+do_md5sum $packetfile
+}
+
 mkdir -p "$outdir"
 
 # Disable globbing: command arguments may contain globbing characters and
diff --git a/tests/fate/concatdec.mak b/tests/fate/concatdec.mak
new file mode 100644
index 000..89d5409
--- /dev/null
+++ b/tests/fate/concatdec.mak
@@ -0,0 +1,12 @@
+FATE_CONCAT_TEMPLATE=tests/test_template.ffconcat
+
+FATE_CONCAT_DEMUXER_LAVF-$(call ENCDEC2, MPEG2VIDEO, MP2, MPEGTS)+= ts
+FATE_CONCAT_DEMUXER_LAVF-$(call ENCDEC2, MPEG2VIDEO, PCM_S16LE, MXF) += mxf
+FATE_CONCAT_DEMUXER_LAVF-$(call ENCDEC2, MPEG2VIDEO, PCM_S16LE, MXF) += mxf_d10
+
+$(foreach D,$(FATE_CONCAT_DEMUXER_LAVF-yes),$(eval 
fate-concat-demuxer-lavf-$(D): ffprobe$(PROGSSUF)$(EXESUF) fate-lavf-$(D)))
+$(foreach D,$(FATE_CONCAT_DEMUXER_LAVF-yes),$(eval 
fate-concat-demuxer-lavf-$(D): CMD = concat $(FATE_CONCAT_TEMPLATE) 
tests/data/lavf/lavf.$(D)))
+
+FATE_CONCAT_DEMUXER-$(CONFIG_CONCAT_DEMUXER) += 
$(FATE_CONCAT_DEMUXER_LAVF-yes:%=fate-concat-demuxer-lavf-%)
+
+FATE-$(CONFIG_FFPROBE) += $(FATE_CONCAT_DEMUXER-yes)
diff --git a/tests/ref/fate/concat-demuxer-lavf-mxf 
b/tests/ref/fate/concat-demuxer-lavf-mxf
new file mode 100644
index 000..a6fa554
--- /dev/null
+++ b/tests/ref/fate/concat-demuxer-lavf-mxf
@@ -0,0 +1 @@
+56359998da34c3957124a8928fb58f3d 
*tests/data/fate/concat-demuxer-lavf-mxf.ffprobe
diff --git a/tests/ref/fate/concat-demuxer-lavf-mxf_d10 
b/tests/ref/fate/concat-demuxer-lavf-mxf_d10
new file mode 100644
index 000..018d631
--- /dev/null
+++ b/tests/ref/fate/concat-demuxer-lavf-mxf_d10
@@ -0,0 +1 @@
+89c81149b4673c60aba7cf5f27cec823 
*tests/data/fate/concat-demuxer-lavf-mxf_d10.ffprobe
diff --git a/tests/ref/fate/concat-demuxer-lavf-ts 
b/tests/ref/fate/concat-demuxer-lavf-ts
new file mode 100644
index 000..2e8ba46
--- /dev/null
+++ b/tests/ref/fate/concat-demuxer-lavf-ts
@@ -0,0 +1 @@
+1993b3613952fa76da8c5c260a16a96a 
*tests/data/fate/concat-demuxer-lavf-ts.ffprobe
diff --git a/tests/test_template.ffconcat b/tests/test_template.ffconcat
new file mode 100644
index 000..e9b685d
--- /dev/null
+++ b/tests/test_template.ffconcat
@@ -0,0 +1,112 @@
+#ffconcat version 1.0
+# ^ header is commented out to avoid probing therefore enable unsafe paths
+
+file  %SRCFILE%
+
+file  %SRCFILE%
+file_packet_metadata dummy=1
+duration  1
+
+file  %SRCFILE%
+inpoint   00:00.00
+outpoint  00:00.04
+
+file  %SRCFILE%
+inpoint   00:00.04
+outpoint  00:00.08
+
+file  %SRCFILE%
+inpoint   00:00.08
+outpoint  00:00.12
+
+file  %SRCFILE%
+inpoint   00:00.12
+outpoint  00:00.16
+
+file  %SRCFILE%
+inpoint   00:00.16
+outpoint  00:00.20
+
+file  %SRCFILE%
+inpoint   00:00.20
+outpoint  00:00.24
+
+file  %SRCFILE%
+inpoint   00:00.24
+outpoint  00:00.28
+
+file  %SRCFILE%
+inpoint   00:00.28
+outpoint  00:00.32
+
+file  %SRCFILE%
+inpoint   00:00.32
+outpoint  00:00.36
+
+file  %SRCFILE%
+inpoint   00:00.36
+outpoint  00:00.40
+
+file  %SRCFILE%
+inpoint   00:00.40
+outpoint  00:00.44
+
+file  %SRCFILE%
+inpoint   00:00.44
+outpoint  00:00.48
+
+file  %SRCFILE%
+inpoint   00:00.48
+outpoint  00:00.52
+
+file  %SRCFILE%
+inpoint   00:00.52

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

[Marton Balint]

Signed-off-by: Marton Balint 
---
 libavformat/concatdec.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/libavformat/concatdec.c b/libavformat/concatdec.c
index 7686f28..f262d44 100644
--- a/libavformat/concatdec.c
+++ b/libavformat/concatdec.c
@@ -316,6 +316,14 @@ static int open_file(AVFormatContext *avf, unsigned fileno)
cat->files[fileno - 1].duration;
 file->file_start_time = (cat->avf->start_time == AV_NOPTS_VALUE) ? 0 : 
cat->avf->start_time;
 file->file_inpoint = (file->inpoint == AV_NOPTS_VALUE) ? 
file->file_start_time : file->inpoint;
+if (file->duration == AV_NOPTS_VALUE) {
+file->duration = cat->avf->duration;
+if (file->inpoint != AV_NOPTS_VALUE)
+file->duration -= (file->inpoint - file->file_start_time);
+if (file->outpoint != AV_NOPTS_VALUE)
+file->duration -= cat->avf->duration - (file->outpoint - 
file->file_start_time);
+}
+
 if ((ret = match_streams(avf)) < 0)
 return ret;
 if (file->inpoint != AV_NOPTS_VALUE) {
@@ -469,14 +477,6 @@ static int open_next_file(AVFormatContext *avf)
 ConcatContext *cat = avf->priv_data;
 unsigned fileno = cat->cur_file - cat->files;
 
-if (cat->cur_file->duration == AV_NOPTS_VALUE) {
-cat->cur_file->duration = cat->avf->duration;
-if (cat->cur_file->inpoint != AV_NOPTS_VALUE)
-cat->cur_file->duration -= (cat->cur_file->inpoint - 
cat->cur_file->file_start_time);
-if (cat->cur_file->outpoint != AV_NOPTS_VALUE)
-cat->cur_file->duration -= cat->avf->duration - 
(cat->cur_file->outpoint - cat->cur_file->file_start_time);
-}
-
 if (++fileno >= cat->nb_files) {
 cat->eof = 1;
 return AVERROR_EOF;
-- 
2.1.4

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

Re: [FFmpeg-devel] [PATCH] Don't needlessly reinitialize ff_cos_## tables.

[Michael Niedermayer]

On Sat, Oct 24, 2015 at 03:10:58PM +0200, wm4 wrote:
> On Sat, 24 Oct 2015 04:13:18 +0200
> Michael Niedermayer  wrote:
> 
> > On Thu, Oct 22, 2015 at 09:48:30PM -0700, Dale Curtis wrote:
> > > On Wed, Oct 21, 2015 at 6:52 PM, Dale Curtis 
> > > wrote:
> > >   
> > > > On Tue, Oct 20, 2015 at 11:50 PM, Michael Niedermayer <  
> > > > mich...@niedermayer.cc> wrote:
> > > >>
> > > >> the last element to be written should be checked, so that if
> > > >> initialization is done by 2 threads at the same time, neither can
> > > >> return from this function without initialization having finished
> > > >>
> > > >> also the race detectors are broken if they complain about cases where
> > > >> a variable that has value a is set to value a, that cannot be part of
> > > >> a race, not even if a is written byte per byte instead of atomically
> > > >> unless theres something iam missing
> > > >> Is this something that can be fixed or disabled on the side of the
> > > >> race detectors?
> > > >> It might reduce false positives in FFmpeg and potentially other
> > > >> tools.
> > > >>  
> > > >
> > > > We can suppress it, which I think is more reasonable then the overhead
> > > > it'd take to make this "race" go away. I notice the sin tables are
> > > > initialized within the fft context so there's no "race." Is there a 
> > > > reason
> > > > the cosine tables aren't done this way?
> > > >  
> > > 
> > > Actually it looks like sin may suffer from the same issues -- it doesn't
> > > make a copy like I was thinking it did. One of the TSAN folk detailed why
> > > suppression isn't a good idea here  
> > 
> > > https://codereview.chromium.org/1412123007/#msg7 -- which roughly says we
> > > can't rely on the compiler to do the right thing here.  
> > 
> > quite independant of the sin/cos discussion here, This statement is
> > IMHO somewhat problematic
> > It may be strictly true in a language lawyer sense but
> > 
> > Lets assume that compilers did add random writes into writable arrays
> > as long as they restore it before the next function call or return.
> > like it seems assumed in the linked discussion
> > 
> > Frame multithreading has one thread decoding a frame and the next
> > using that frame after it has been written, the individual accesses
> > are not protected by mutexes nor could they, it would defeat the
> > idea of parallel decoding ...
> > Now if the compiler could randomly add writes that exist nowhere in
> > the C code as long as the thread itself doesnt access it at that time,
> > then this would break.
> 
> All what matters is if there are memory barriers between the accesses.
> So for example if one thread is done with decoding a frame, and is
> handed off to other threads as reference frame, then the
> synchronization that takes care of this "handing off" will perform the
> required memory barrier. Or am I getting this wrong?

in practice i belive its all fine, this is theoretical but
I think there are multiple issues
one would be simply that thread 1 which writes frame 1 might never
access it again before deallocation thus the compiler could optimize
the whole decode out, free the frame earlier or use the memory for
something else, i dont think this is a real problem but iam not aware
of anything in the C spec that would disallow it.
This is similar to the linked text where tab[] was used by a compiler
to hold a intermediate value which in no way or form was written
into the array by the C code
That is the compiler in that example added a write with a value
where there was no write with such value in the C code once the
compiler proofed that the function itself in its current context
doesnt need the arrays value at that point
in the frame multithreading, the frames too can be similarly
unused by the thread itself so by the same chain of reasoning the
compiler too could add writes as it likes.
I doubt this is a real issue in either case but i dont know

The "proper solution" would be to make the frame volatile but that
cannot be done as it would de-optimize the code

and iam quite sure as this is a complex subject there are also details
that iam missing

memory barries are needed too, and should be done internally by the
pthread calls used to synchronize the progress state

either way, this subject is rather uninterresting ill try to do
something more usefull for FFmpeg than arguing about these 
hypothetical cases ...

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

I am the wisest man alive, for I know one thing, and that is that I know
nothing. -- Socrates


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

Re: [FFmpeg-devel] [PATCH] x86/intmath: allow the source operand for icc/icl ff_ctzll to be a memory location

[Ganesh Ajjanagadde]

On Sat, Oct 24, 2015 at 6:08 PM, James Almer  wrote:
> This gives the compiler some flexibility
>
> Signed-off-by: James Almer 
> ---
>  libavutil/x86/intmath.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavutil/x86/intmath.h b/libavutil/x86/intmath.h
> index 7881e3c..10d3e7f 100644
> --- a/libavutil/x86/intmath.h
> +++ b/libavutil/x86/intmath.h
> @@ -36,7 +36,7 @@ static av_always_inline av_const int ff_ctzll_x86(long long 
> v)
>  {
>  #   if ARCH_X86_64
>  uint64_t c;
> -__asm__("bsfq %1,%0" : "=r" (c) : "r" (v));
> +__asm__ ("bsfq %1,%0" : "=r" (c) : "rm" (v));
>  return c;
>  #   else
>  return ((uint32_t)v == 0) ? _bit_scan_forward((uint32_t)(v >> 32)) + 32 
> : _bit_scan_forward((uint32_t)v);
> --
> 2.6.2

This question may be silly, but can you clarify when this asm code is
used instead of __builtin_ctzll? For instance, I think on GNU/Linux,
x86-64, sufficiently modern GCC (even with asm enabled), we should
always use the builtin: the compiler knows best what to do with its
builtin.

>
> ___
> 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 1/3] avfilter/vf_deshake: use a void * comparator for consistency

[Ganesh Ajjanagadde]

On Sat, Oct 24, 2015 at 7:07 PM, Henrik Gramner  wrote:
> On Sun, Oct 25, 2015 at 12:02 AM, Ganesh Ajjanagadde
>  wrote:
>> -static int cmp(const double *a, const double *b)
>> +static int cmp(const void *a, const void *b)
>>  {
>> -return *a < *b ? -1 : ( *a > *b ? 1 : 0 );
>> +double va = *(double *)a, vb = *(double *)b;
>> +return va < vb ? -1 : ( va > vb ? 1 : 0 );
>>  }
>
> This cast discards the const qualifier and may cause warnings
> depending on which compiler and compiler flags you use.

no warnings unfortunately; fixed. See also new patch.

> ___
> 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 1/3] avfilter/vf_deshake: use a void * comparator for consistency

[Ganesh Ajjanagadde]

On Sat, Oct 24, 2015 at 7:04 PM, wm4  wrote:
> On Sat, 24 Oct 2015 18:02:36 -0400
> Ganesh Ajjanagadde  wrote:
>
>> For generality, qsort uses a comparator whose elements are void *. This
>> makes the comparator have such a form, and thus makes the void * cast of
>> the comparator pointer useless. Furthermore, this makes the code more
>> consistent with other usages of qsort across the codebase.
>>
>> Signed-off-by: Ganesh Ajjanagadde 
>> ---
>
> Entire patchset (1-3) LGTM, if it really does not cause new warnings.
>
> Maybe instead of "libc" it would be good to write "Standard C", but it
> probably doesn't matter at all.

Since you pointed it out, changed while pushing. Thanks.

> ___
> 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 1/5] all: fix -Wextra-semi reported on clang

[Ganesh Ajjanagadde]

On Sat, Oct 24, 2015 at 4:12 PM, Michael Niedermayer
 wrote:
> On Sat, Oct 24, 2015 at 09:33:22AM -0400, Ganesh Ajjanagadde wrote:
>> Hi all,
>>
>> Apologies for the copy/pasted patch, but can't send via send-email.
>> Copy pasted for review below, attached also for a non-clobbered
>> version.
>>
>> --
>>
>> From 82b889a359925d1f9f7496c916cf24146b44e648 Mon Sep 17 00:00:00 2001
>> From: Ganesh Ajjanagadde 
>> Date: Fri, 23 Oct 2015 11:23:42 -0400
>> Subject: [PATCH 1/5] all: fix -Wextra-semi reported on clang
>>
>> This fixes extra semicolons that clang 3.7 on GNU/Linux warns about.
>> These were trigggered when built under -Wpedantic, which essentially
>> checks for strict ISO compliance in numerous ways.
>>
>> Signed-off-by: Ganesh Ajjanagadde 
>> ---
>>  ffprobe.c   |  20 +-
>>  libavcodec/x86/hevcdsp_init.c   | 637 
>> ++--
>>  libavcodec/x86/rv40dsp_init.c   |   2 +-
>>  libavcodec/x86/vp9dsp_init.c|  14 +-
>>  libavcodec/x86/vp9dsp_init.h|   6 +-
>>  libavcodec/x86/vp9dsp_init_16bpp_template.c |  36 +-
>>  libavdevice/alsa.c  |   6 +-
>>  7 files changed, 358 insertions(+), 363 deletions(-)
>
> removing one of duplicate or unneeded ; should be ok

sorry, did not follow: are you suggesting a commit message rewording?

>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Many that live deserve death. And some that die deserve life. Can you give
> it to them? Then do not be too eager to deal out death in judgement. For
> even the very wise cannot see all ends. -- Gandalf
>
> ___
> 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 1/5] all: fix -Wextra-semi reported on clang

[Michael Niedermayer]

On Sat, Oct 24, 2015 at 04:16:56PM -0400, Ganesh Ajjanagadde wrote:
> On Sat, Oct 24, 2015 at 4:12 PM, Michael Niedermayer
>  wrote:
> > On Sat, Oct 24, 2015 at 09:33:22AM -0400, Ganesh Ajjanagadde wrote:
> >> Hi all,
> >>
> >> Apologies for the copy/pasted patch, but can't send via send-email.
> >> Copy pasted for review below, attached also for a non-clobbered
> >> version.
> >>
> >> --
> >>
> >> From 82b889a359925d1f9f7496c916cf24146b44e648 Mon Sep 17 00:00:00 2001
> >> From: Ganesh Ajjanagadde 
> >> Date: Fri, 23 Oct 2015 11:23:42 -0400
> >> Subject: [PATCH 1/5] all: fix -Wextra-semi reported on clang
> >>
> >> This fixes extra semicolons that clang 3.7 on GNU/Linux warns about.
> >> These were trigggered when built under -Wpedantic, which essentially
> >> checks for strict ISO compliance in numerous ways.
> >>
> >> Signed-off-by: Ganesh Ajjanagadde 
> >> ---
> >>  ffprobe.c   |  20 +-
> >>  libavcodec/x86/hevcdsp_init.c   | 637 
> >> ++--
> >>  libavcodec/x86/rv40dsp_init.c   |   2 +-
> >>  libavcodec/x86/vp9dsp_init.c|  14 +-
> >>  libavcodec/x86/vp9dsp_init.h|   6 +-
> >>  libavcodec/x86/vp9dsp_init_16bpp_template.c |  36 +-
> >>  libavdevice/alsa.c  |   6 +-
> >>  7 files changed, 358 insertions(+), 363 deletions(-)
> >
> > removing one of duplicate or unneeded ; should be ok
> 
> sorry, did not follow: are you suggesting a commit message rewording?

no, ill restart in verbose mode
the patch seems to remove duplicate or unneeded ;
in case of any duplicate ; there would be 2, either of which could be
removed, i have no oppinion on which if there are any cases that have
alternative resolutions
except that the patch should be fine

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

I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- Socrates


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

[FFmpeg-devel] [PATCH 1/5] ffprobe: add support for printing packet strings metadata as packet tags

[Marton Balint]

ffprobe.xsd already contains the tag element.

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

diff --git a/ffprobe.c b/ffprobe.c
index ac03689..f5930ae 100644
--- a/ffprobe.c
+++ b/ffprobe.c
@@ -77,6 +77,7 @@ static int do_show_format_tags = 0;
 static int do_show_frame_tags = 0;
 static int do_show_program_tags = 0;
 static int do_show_stream_tags = 0;
+static int do_show_packet_tags = 0;
 
 static int show_value_unit  = 0;
 static int use_value_prefix = 0;
@@ -135,6 +136,7 @@ typedef enum {
 SECTION_ID_LIBRARY_VERSION,
 SECTION_ID_LIBRARY_VERSIONS,
 SECTION_ID_PACKET,
+SECTION_ID_PACKET_TAGS,
 SECTION_ID_PACKETS,
 SECTION_ID_PACKETS_AND_FRAMES,
 SECTION_ID_PACKET_SIDE_DATA_LIST,
@@ -178,7 +180,8 @@ static struct section sections[] = {
 [SECTION_ID_LIBRARY_VERSION] ={ SECTION_ID_LIBRARY_VERSION, 
"library_version", 0, { -1 } },
 [SECTION_ID_PACKETS] ={ SECTION_ID_PACKETS, "packets", 
SECTION_FLAG_IS_ARRAY, { SECTION_ID_PACKET, -1} },
 [SECTION_ID_PACKETS_AND_FRAMES] = { SECTION_ID_PACKETS_AND_FRAMES, 
"packets_and_frames", SECTION_FLAG_IS_ARRAY, { SECTION_ID_PACKET, -1} },
-[SECTION_ID_PACKET] = { SECTION_ID_PACKET, "packet", 0, { 
SECTION_ID_PACKET_SIDE_DATA_LIST, -1 } },
+[SECTION_ID_PACKET] = { SECTION_ID_PACKET, "packet", 0, { 
SECTION_ID_PACKET_TAGS, SECTION_ID_PACKET_SIDE_DATA_LIST, -1 } },
+[SECTION_ID_PACKET_TAGS] ={ SECTION_ID_PACKET_TAGS, "tags", 
SECTION_FLAG_HAS_VARIABLE_FIELDS, { -1 }, .element_name = "tag", .unique_name = 
"packet_tags" },
 [SECTION_ID_PACKET_SIDE_DATA_LIST] ={ SECTION_ID_PACKET_SIDE_DATA_LIST, 
"side_data_list", SECTION_FLAG_IS_ARRAY, { SECTION_ID_PACKET_SIDE_DATA, -1 } },
 [SECTION_ID_PACKET_SIDE_DATA] = { SECTION_ID_PACKET_SIDE_DATA, 
"side_data", 0, { -1 } },
 [SECTION_ID_PIXEL_FORMATS] =  { SECTION_ID_PIXEL_FORMATS, 
"pixel_formats", SECTION_FLAG_IS_ARRAY, { SECTION_ID_PIXEL_FORMAT, -1 } },
@@ -1762,6 +1765,16 @@ static void show_packet(WriterContext *w, 
AVFormatContext *fmt_ctx, AVPacket *pk
 
 if (pkt->side_data_elems) {
 int i;
+int size;
+const uint8_t *side_metadata;
+
+side_metadata = av_packet_get_side_data(pkt, 
AV_PKT_DATA_STRINGS_METADATA, );
+if (side_metadata && size && do_show_packet_tags) {
+AVDictionary *dict = NULL;
+if (av_packet_unpack_dictionary(side_metadata, size, ) >= 0)
+show_tags(w, dict, SECTION_ID_PACKET_TAGS);
+av_dict_free();
+}
 writer_print_section_header(w, SECTION_ID_PACKET_SIDE_DATA_LIST);
 for (i = 0; i < pkt->side_data_elems; i++) {
 AVPacketSideData *sd = >side_data[i];
@@ -3178,6 +3191,7 @@ int main(int argc, char **argv)
 SET_DO_SHOW(FRAME_TAGS, frame_tags);
 SET_DO_SHOW(PROGRAM_TAGS, program_tags);
 SET_DO_SHOW(STREAM_TAGS, stream_tags);
+SET_DO_SHOW(PACKET_TAGS, packet_tags);
 
 if (do_bitexact && (do_show_program_version || do_show_library_versions)) {
 av_log(NULL, AV_LOG_ERROR,
-- 
2.1.4

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

Re: [FFmpeg-devel] Can we drop OpenJPEG 1.5 in favor of 2.x?

[Michael Bradshaw]

On Sat, Oct 24, 2015 at 11:28 AM, Timothy Gu  wrote:

> On Sat, Oct 24, 2015 at 11:03 AM James Almer  wrote:
>
> > Gentoo and Debian both seem to ship it. Arch does as well but on their
> > Community repository (ffmpeg adopting it may be incentive enough for them
> > to move it to Extra).
> >
> In fact, at least two of the reverse dependencies (out of 8, not counting
> duplicates) of the Arch openjpeg package already support openjpeg2 (poppler
> and gst-plugins-bad).
>
> I would prefer if we keep compat for both since Ubuntu 14.04 LTS doesn't
> have openjpeg2 yet, and that's unfortunately not going away any time soon.


Crap, you're right. Before I started this I checked if Ubuntu had openjpeg2
and they do[1] but it turns out it's really just openjpeg 1.3 (if anyone
knows why they made a separate package named libopenjpeg2 when it's really
openjpeg 1.3, I'd be curious to learn why).

Well that settles it for me, then. I'll keep compatibility with 1.5.

[1]: http://packages.ubuntu.com/trusty/libopenjpeg2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/5] all: fix -Wextra-semi reported on clang

[Ganesh Ajjanagadde]

On Sat, Oct 24, 2015 at 4:28 PM, Michael Niedermayer
 wrote:
> On Sat, Oct 24, 2015 at 04:16:56PM -0400, Ganesh Ajjanagadde wrote:
>> On Sat, Oct 24, 2015 at 4:12 PM, Michael Niedermayer
>>  wrote:
>> > On Sat, Oct 24, 2015 at 09:33:22AM -0400, Ganesh Ajjanagadde wrote:
>> >> Hi all,
>> >>
>> >> Apologies for the copy/pasted patch, but can't send via send-email.
>> >> Copy pasted for review below, attached also for a non-clobbered
>> >> version.
>> >>
>> >> --
>> >>
>> >> From 82b889a359925d1f9f7496c916cf24146b44e648 Mon Sep 17 00:00:00 2001
>> >> From: Ganesh Ajjanagadde 
>> >> Date: Fri, 23 Oct 2015 11:23:42 -0400
>> >> Subject: [PATCH 1/5] all: fix -Wextra-semi reported on clang
>> >>
>> >> This fixes extra semicolons that clang 3.7 on GNU/Linux warns about.
>> >> These were trigggered when built under -Wpedantic, which essentially
>> >> checks for strict ISO compliance in numerous ways.
>> >>
>> >> Signed-off-by: Ganesh Ajjanagadde 
>> >> ---
>> >>  ffprobe.c   |  20 +-
>> >>  libavcodec/x86/hevcdsp_init.c   | 637 
>> >> ++--
>> >>  libavcodec/x86/rv40dsp_init.c   |   2 +-
>> >>  libavcodec/x86/vp9dsp_init.c|  14 +-
>> >>  libavcodec/x86/vp9dsp_init.h|   6 +-
>> >>  libavcodec/x86/vp9dsp_init_16bpp_template.c |  36 +-
>> >>  libavdevice/alsa.c  |   6 +-
>> >>  7 files changed, 358 insertions(+), 363 deletions(-)
>> >
>> > removing one of duplicate or unneeded ; should be ok
>>
>> sorry, did not follow: are you suggesting a commit message rewording?
>
> no, ill restart in verbose mode
> the patch seems to remove duplicate or unneeded ;
> in case of any duplicate ; there would be 2, either of which could be
> removed, i have no oppinion on which if there are any cases that have
> alternative resolutions
> except that the patch should be fine

ok, pushed.

>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> I know you won't believe me, but the highest form of Human Excellence is
> to question oneself and others. -- Socrates
>
> ___
> 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 1/7] lavfi: remove astreamsync.

[Paul B Mahol]

Dana 24. 10. 2015. 19:06 osoba "Nicolas George"  napisala
je:
>
> It was only useful for very specific testing purposes
> and appears to be currently partially broken.

What's broken?

>
> Signed-off-by: Nicolas George 
> ---
>  MAINTAINERS  |   1 -
>  doc/filters.texi |  36 ---
>  libavfilter/Makefile |   1 -
>  libavfilter/af_astreamsync.c | 243
---
>  libavfilter/allfilters.c |   1 -
>  5 files changed, 282 deletions(-)
>  delete mode 100644 libavfilter/af_astreamsync.c
>
>
> I had a hard time getting the filters from libav to behave correctly,
> but now I have a non-recursive version of request_frame() working.
> It still needs some work, two filters still have a loop in request_frame()
> that I need to remove (and no FATE test), and then some cleanup. But It is
> getting there.
>
> FATE passes after each patch in this series, and also with the
non-recursive
> request_frame().
>
> The affected parts in this series are either mine or from libav, so there
is
> not really anyone else to approve them. If there are no objection I will
> push in a few days.
>
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 25cff79..a08adf7 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -347,7 +347,6 @@ Filters:
>af_aphaser.c  Paul B Mahol
>af_aresample.cMichael Niedermayer
>af_astats.c   Paul B Mahol
> -  af_astreamsync.c  Nicolas George
>af_atempo.c   Pavel Koshevoy
>af_biquads.c  Paul B Mahol
>af_chorus.c   Paul B Mahol
> diff --git a/doc/filters.texi b/doc/filters.texi
> index 5a35bde..6e8931e 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -1170,42 +1170,6 @@ Number of occasions (not the number of samples)
that the signal attained either
>  Overall bit depth of audio. Number of bits used for each sample.
>  @end table
>
> -@section astreamsync
> -
> -Forward two audio streams and control the order the buffers are
forwarded.
> -
> -The filter accepts the following options:
> -
> -@table @option
> -@item expr, e
> -Set the expression deciding which stream should be
> -forwarded next: if the result is negative, the first stream is
forwarded; if
> -the result is positive or zero, the second stream is forwarded. It can
use
> -the following variables:
> -
> -@table @var
> -@item b1 b2
> -number of buffers forwarded so far on each stream
> -@item s1 s2
> -number of samples forwarded so far on each stream
> -@item t1 t2
> -current timestamp of each stream
> -@end table
> -
> -The default value is @code{t1-t2}, which means to always forward the
stream
> -that has a smaller timestamp.
> -@end table
> -
> -@subsection Examples
> -
> -Stress-test @code{amerge} by randomly sending buffers on the wrong
> -input, while avoiding too much of a desynchronization:
> -@example
> -amovie=file.ogg [a] ; amovie=file.mp3 [b] ;
> -[a] [b] astreamsync=(2*random(1))-1+tanh(5*(t1-t2)) [a2] [b2] ;
> -[a2] [b2] amerge
> -@end example
> -
>  @section asyncts
>
>  Synchronize audio data with timestamps by squeezing/stretching it and/or
> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> index 8e776c1..f2f6dd1 100644
> --- a/libavfilter/Makefile
> +++ b/libavfilter/Makefile
> @@ -50,7 +50,6 @@ OBJS-$(CONFIG_ASETTB_FILTER) += settb.o
>  OBJS-$(CONFIG_ASHOWINFO_FILTER)  += af_ashowinfo.o
>  OBJS-$(CONFIG_ASPLIT_FILTER) += split.o
>  OBJS-$(CONFIG_ASTATS_FILTER) += af_astats.o
> -OBJS-$(CONFIG_ASTREAMSYNC_FILTER)+= af_astreamsync.o
>  OBJS-$(CONFIG_ASYNCTS_FILTER)+= af_asyncts.o
>  OBJS-$(CONFIG_ATEMPO_FILTER) += af_atempo.o
>  OBJS-$(CONFIG_ATRIM_FILTER)  += trim.o
> diff --git a/libavfilter/af_astreamsync.c b/libavfilter/af_astreamsync.c
> deleted file mode 100644
> index d08da26..000
> diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
> index 9385fdf..e7f6bec 100644
> --- a/libavfilter/allfilters.c
> +++ b/libavfilter/allfilters.c
> @@ -72,7 +72,6 @@ void avfilter_register_all(void)
>  REGISTER_FILTER(ASHOWINFO,  ashowinfo,  af);
>  REGISTER_FILTER(ASPLIT, asplit, af);
>  REGISTER_FILTER(ASTATS, astats, af);
> -REGISTER_FILTER(ASTREAMSYNC,astreamsync,af);
>  REGISTER_FILTER(ASYNCTS,asyncts,af);
>  REGISTER_FILTER(ATEMPO, atempo, af);
>  REGISTER_FILTER(ATRIM,  atrim,  af);
> --
> 2.6.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org

Re: [FFmpeg-devel] [PATCH] Don't needlessly reinitialize ff_cos_## tables.

[Ronald S. Bultje]

On Sat, Oct 24, 2015 at 6:45 PM, Michael Niedermayer  wrote:

> either way, this subject is rather uninterresting ill try to do
> something more usefull for FFmpeg than arguing about these
> hypothetical cases ...


+100.

Many of these tools are like -Wpedantic. Reminds me of my rants about
helgrind.

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

Re: [FFmpeg-devel] [PATCH] videodsp: don't overread edges in vfix3 emu_edge.

[Ronald S. Bultje]

Hi,

On Sat, Oct 24, 2015 at 2:13 PM, Carl Eugen Hoyos  wrote:

> Ronald S. Bultje  gmail.com> writes:
>
> > Great, thanks for verifying that. I'll apply with
> > your suggested addition to the commit message.
>
> Please do, you could also mention ticket #3226: I
> was never able to reproduce (I can reproduce the
> Debian bug) but it has a very similar description
> iirc.
> (And you could mention Andreas' analysis.)


Yes, sounds like it's the same, added that + a thank-you to Andreas.

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

Re: [FFmpeg-devel] [PATCH 5/5] all: fix enum definition for large values

[Michael Niedermayer]

On Sat, Oct 24, 2015 at 09:29:23AM -0400, 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 such errors by explicitly casting as an int, doing the
> desired unsigned to signed conversion. This method works on all current
> architectures. Tested with FATE.
> 
> Signed-off-by: Ganesh Ajjanagadde 

Simply changing the values to signed is not correct / not sufficient
the code assumes that they are unsigned

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

[FFmpeg-devel] [PATCH] x86/intmath: allow the source operand for icc/icl ff_ctzll to be a memory location

[James Almer]

This gives the compiler some flexibility

Signed-off-by: James Almer 
---
 libavutil/x86/intmath.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavutil/x86/intmath.h b/libavutil/x86/intmath.h
index 7881e3c..10d3e7f 100644
--- a/libavutil/x86/intmath.h
+++ b/libavutil/x86/intmath.h
@@ -36,7 +36,7 @@ static av_always_inline av_const int ff_ctzll_x86(long long v)
 {
 #   if ARCH_X86_64
 uint64_t c;
-__asm__("bsfq %1,%0" : "=r" (c) : "r" (v));
+__asm__ ("bsfq %1,%0" : "=r" (c) : "rm" (v));
 return c;
 #   else
 return ((uint32_t)v == 0) ? _bit_scan_forward((uint32_t)(v >> 32)) + 32 : 
_bit_scan_forward((uint32_t)v);
-- 
2.6.2

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

Re: [FFmpeg-devel] [PATCH] x86/intmath: allow the source operand for icc/icl ff_ctzll to be a memory location

[James Almer]

On 10/24/2015 7:48 PM, Ganesh Ajjanagadde wrote:
> On Sat, Oct 24, 2015 at 6:08 PM, James Almer  wrote:
>> This gives the compiler some flexibility
>>
>> Signed-off-by: James Almer 
>> ---
>>  libavutil/x86/intmath.h | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavutil/x86/intmath.h b/libavutil/x86/intmath.h
>> index 7881e3c..10d3e7f 100644
>> --- a/libavutil/x86/intmath.h
>> +++ b/libavutil/x86/intmath.h
>> @@ -36,7 +36,7 @@ static av_always_inline av_const int ff_ctzll_x86(long 
>> long v)
>>  {
>>  #   if ARCH_X86_64
>>  uint64_t c;
>> -__asm__("bsfq %1,%0" : "=r" (c) : "r" (v));
>> +__asm__ ("bsfq %1,%0" : "=r" (c) : "rm" (v));
>>  return c;
>>  #   else
>>  return ((uint32_t)v == 0) ? _bit_scan_forward((uint32_t)(v >> 32)) + 32 
>> : _bit_scan_forward((uint32_t)v);
>> --
>> 2.6.2
> 
> This question may be silly, but can you clarify when this asm code is
> used instead of __builtin_ctzll? For instance, I think on GNU/Linux,
> x86-64, sufficiently modern GCC (even with asm enabled), we should
> always use the builtin: the compiler knows best what to do with its
> builtin.

This is ICC/ICL, not GCC.


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

Re: [FFmpeg-devel] [PATCH 5/5] all: fix enum definition for large values

[Nicolas George]

Le tridi 3 brumaire, an CCXXIV, Ganesh Ajjanagadde a écrit :
> or do you prefer a static const style?

static const is not build-time constant, and therefore unusable for this:
impossible to use it as case label or constant initializer.

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] Wanted to contribute

[rishi shah]

Hi wm4,
I went through that link but its all about just coding convention and patch
submission methodology. Nothing about dev setup or nothing about list of
projects, modules and bugs.

Thanks,
Rishi




On Sat, Oct 24, 2015 at 6:48 PM, wm4  wrote:

> On Sat, 24 Oct 2015 18:21:45 +0530
> rishi shah  wrote:
>
> > Hi !
> >  I wanted to contribute in FFMpeg organization. What can be the good
> > starting point? I have Mac OS.
>
> Here's an overview: http://ffmpeg.org/developer.html#Contributing
> ___
> 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] Can we drop OpenJPEG 1.5 in favor of 2.x?

[Ben Boeckel]

On Sat, 24 Oct, 2015 at 21:37:57 GMT, Michael Bradshaw wrote:
> Crap, you're right. Before I started this I checked if Ubuntu had openjpeg2
> and they do[1] but it turns out it's really just openjpeg 1.3 (if anyone
> knows why they made a separate package named libopenjpeg2 when it's really
> openjpeg 1.3, I'd be curious to learn why).

Number suffixes on library packages on Debian (and subsequently Ubuntu)
indicate the soversion of the library. For example, KDE4 has soversion
5, so its package is kdelibs5.

Not obvious or helpful to anywone really, IMO.

-- Ben

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

[FFmpeg-devel] [PATCH 5/5] lavfi/select: add support for concatdec_select option

[Marton Balint]

This option can be used to select useful frames from an ffconcat file which is
using inpoints and outpoints but where the source files are not intra frame
only.

Signed-off-by: Marton Balint 
---
 doc/filters.texi   | 17 +
 libavfilter/f_select.c | 20 
 2 files changed, 37 insertions(+)

diff --git a/doc/filters.texi b/doc/filters.texi
index 5a35bde..093eec5 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -13160,6 +13160,16 @@ value between 0 and 1 to indicate a new scene; a low 
value reflects a low
 probability for the current frame to introduce a new scene, while a higher
 value means the current frame is more likely to be one (see the example below)
 
+@item concatdec_select
+The concat demuxer sets the @var{lavf.concat.start_time} and the
+@var{lavf.concat.duration} packet metadata values which are also present in the
+decoded frames. These metadata entries contain the start_time and the duration
+of the respective file segments in the concatenated output.
+
+The @var{concatdec_select} variable is -1 if the frame pts is at least
+start_time but less than start_time + duration, 0 otherwise, and NaN if the
+mentioned metadata entires are not present.
+
 @end table
 
 The default value of the select expression is "1".
@@ -13234,6 +13244,13 @@ Send even and odd frames to separate outputs, and 
compose them:
 @example
 select=n=2:e='mod(n, 2)+1' [odd][even]; [odd] pad=h=2*ih [tmp]; [tmp][even] 
overlay=y=h
 @end example
+
+@item
+Select useful frames from an ffconcat file which is using inpoints and
+outpoints but where the source files are not intra frame only.
+@example
+ffmpeg -copyts -vsync 0 -i input.ffconcat -vf select=concatdec_select -af 
aselect=concatdec_select output.avi
+@end example
 @end itemize
 
 @section selectivecolor
diff --git a/libavfilter/f_select.c b/libavfilter/f_select.c
index 2b926e1..d5f1470 100644
--- a/libavfilter/f_select.c
+++ b/libavfilter/f_select.c
@@ -82,6 +82,8 @@ static const char *const var_names[] = {
 
 "scene",
 
+"concatdec_select",  ///< frame usefulness based on pts and frame metadata 
originating from the concat demuxer
+
 NULL
 };
 
@@ -132,6 +134,8 @@ enum var_name {
 
 VAR_SCENE,
 
+VAR_CONCATDEC_SELECT,
+
 VAR_VARS_NB
 };
 
@@ -278,6 +282,21 @@ static double get_scene_score(AVFilterContext *ctx, 
AVFrame *frame)
 return ret;
 }
 
+static double get_concatdec_select(AVFrame *frame, int64_t pts)
+{
+AVDictionary *metadata = av_frame_get_metadata(frame);
+AVDictionaryEntry *e1 = av_dict_get(metadata, "lavf.concatdec.start_time", 
NULL, 0);
+AVDictionaryEntry *e2 = av_dict_get(metadata, "lavf.concatdec.duration", 
NULL, 0);
+if (e1 && e1->value && e2 && e2->value) {
+int64_t start_time = strtoll(e1->value, NULL, 10);
+int64_t duration = strtoll(e2->value, NULL, 10);
+if (pts >= start_time && pts < start_time + duration)
+return -1;
+return 0;
+}
+return NAN;
+}
+
 #define D2TS(d)  (isnan(d) ? AV_NOPTS_VALUE : (int64_t)(d))
 #define TS2D(ts) ((ts) == AV_NOPTS_VALUE ? NAN : (double)(ts))
 
@@ -297,6 +316,7 @@ static void select_frame(AVFilterContext *ctx, AVFrame 
*frame)
 select->var_values[VAR_T  ] = TS2D(frame->pts) * av_q2d(inlink->time_base);
 select->var_values[VAR_POS] = av_frame_get_pkt_pos(frame) == -1 ? NAN : 
av_frame_get_pkt_pos(frame);
 select->var_values[VAR_KEY] = frame->key_frame;
+select->var_values[VAR_CONCATDEC_SELECT] = get_concatdec_select(frame, 
av_rescale_q(frame->pts, inlink->time_base, AV_TIME_BASE_Q));
 
 switch (inlink->type) {
 case AVMEDIA_TYPE_AUDIO:
-- 
2.1.4

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

[FFmpeg-devel] [PATCH 2/3] avutil/tree: improve documentation for av_tree_find, av_tree_insert

[Ganesh Ajjanagadde]

This documents the additional constness, and provides a useful libc
reference for the API specification of the comparator.

Signed-off-by: Ganesh Ajjanagadde 
---
 libavutil/tree.h | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/libavutil/tree.h b/libavutil/tree.h
index a14fa91..16dd8de 100644
--- a/libavutil/tree.h
+++ b/libavutil/tree.h
@@ -56,6 +56,8 @@ struct AVTreeNode *av_tree_node_alloc(void);
  * @param next If next is not NULL, then next[0] will contain the previous
  * element and next[1] the next element. If either does not exist,
  * then the corresponding entry in next is unchanged.
+ * @param cmp compare function used to compare elements in the tree,
+ *API identical to that of libc's qsort
  * @return An element with cmp(key, elem) == 0 or NULL if no such element
  * exists in the tree.
  */
@@ -99,7 +101,8 @@ void *av_tree_find(const struct AVTreeNode *root, void *key,
  * return av_tree_insert(rootp, key, cmp, next);
  * }
  * @endcode
- * @param cmp compare function used to compare elements in the tree
+ * @param cmp compare function used to compare elements in the tree, API 
identical
+ *to that of libc's qsort
  * @return If no insertion happened, the found element; if an insertion or
  * removal happened, then either key or NULL will be returned.
  * Which one it is depends on the tree state and the implementation. 
You
-- 
2.6.2

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

[FFmpeg-devel] [PATCH 1/3] avfilter/vf_deshake: use a void * comparator for consistency

[Ganesh Ajjanagadde]

For generality, qsort uses a comparator whose elements are void *. This
makes the comparator have such a form, and thus makes the void * cast of
the comparator pointer useless. Furthermore, this makes the code more
consistent with other usages of qsort across the codebase.

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

diff --git a/libavfilter/vf_deshake.c b/libavfilter/vf_deshake.c
index ac13ecd..3f96f7d 100644
--- a/libavfilter/vf_deshake.c
+++ b/libavfilter/vf_deshake.c
@@ -91,9 +91,10 @@ static const AVOption deshake_options[] = {
 
 AVFILTER_DEFINE_CLASS(deshake);
 
-static int cmp(const double *a, const double *b)
+static int cmp(const void *a, const void *b)
 {
-return *a < *b ? -1 : ( *a > *b ? 1 : 0 );
+double va = *(double *)a, vb = *(double *)b;
+return va < vb ? -1 : ( va > vb ? 1 : 0 );
 }
 
 /**
@@ -105,7 +106,7 @@ static double clean_mean(double *values, int count)
 int cut = count / 5;
 int x;
 
-qsort(values, count, sizeof(double), (void*)cmp);
+qsort(values, count, sizeof(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 1/7] lavfi: remove astreamsync.

[Nicolas George]

Le tridi 3 brumaire, an CCXXIV, Paul B Mahol a écrit :
> What's broken?

EOF handling. I am not sure it did ever 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] Can we drop OpenJPEG 1.5 in favor of 2.x?

[Dominik 'Rathann' Mierzejewski]

On Saturday, 24 October 2015 at 18:59, Carl Eugen Hoyos wrote:
> Michael Bradshaw  gmail.com> writes:
> 
> > tl;dr: I've got a patch that updates OpenJPEG to 2.0/2.1. 
> > Currently, I've opted to drop OpenJPEG 1.5. Should I 
> > proceed with preparing this patch for submission, or 
> > should I alter it to keep 1.5 support?
> 
> Do distributions support (contain) 2.x?

FWIW Fedora has both openjpeg-1.5.1 and openjpeg2-2.1.0.

Regards,
Dominik
-- 
MPlayer http://mplayerhq.hu | RPMFusion http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] all: simplify qsort comparators, and add const-correctness

[Ganesh Ajjanagadde]

All the comparator API needs is > 0, < 0, or = 0 signalling: it does not
need +1, -1, 0. This avoids some useless branching.

This also adds const-correctness when needed for the comparators.

Signed-off-by: Ganesh Ajjanagadde 
---
 cmdutils_opencl.c   | 2 +-
 ffmpeg.c| 3 +--
 libavfilter/f_sendcmd.c | 2 +-
 libavfilter/vf_removegrain.c| 5 +
 libavformat/subtitles.c | 9 +++--
 libswresample/swresample-test.c | 6 +++---
 6 files changed, 10 insertions(+), 17 deletions(-)

diff --git a/cmdutils_opencl.c b/cmdutils_opencl.c
index 61478e2..d9095b6 100644
--- a/cmdutils_opencl.c
+++ b/cmdutils_opencl.c
@@ -206,7 +206,7 @@ end:
 
 static int compare_ocl_device_desc(const void *a, const void *b)
 {
-return ((OpenCLDeviceBenchmark*)a)->runtime - 
((OpenCLDeviceBenchmark*)b)->runtime;
+return ((const OpenCLDeviceBenchmark*)a)->runtime - ((const 
OpenCLDeviceBenchmark*)b)->runtime;
 }
 
 int opt_opencl_bench(void *optctx, const char *opt, const char *arg)
diff --git a/ffmpeg.c b/ffmpeg.c
index a19c816..26c5ae9 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -2578,8 +2578,7 @@ static InputStream *get_input_stream(OutputStream *ost)
 
 static int compare_int64(const void *a, const void *b)
 {
-int64_t va = *(int64_t *)a, vb = *(int64_t *)b;
-return va < vb ? -1 : va > vb ? +1 : 0;
+return *(const int64_t *)a - *(const int64_t *)b;
 }
 
 static int init_output_stream(OutputStream *ost, char *error, int error_len)
diff --git a/libavfilter/f_sendcmd.c b/libavfilter/f_sendcmd.c
index 37aedc5..539be9c 100644
--- a/libavfilter/f_sendcmd.c
+++ b/libavfilter/f_sendcmd.c
@@ -367,7 +367,7 @@ static int cmp_intervals(const void *a, const void *b)
 int64_t ts_diff = i1->start_ts - i2->start_ts;
 int ret;
 
-ret = ts_diff > 0 ? 1 : ts_diff < 0 ? -1 : 0;
+ret = ts_diff;
 return ret == 0 ? i1->index - i2->index : ret;
 }
 
diff --git a/libavfilter/vf_removegrain.c b/libavfilter/vf_removegrain.c
index da17f6a..f675edd 100644
--- a/libavfilter/vf_removegrain.c
+++ b/libavfilter/vf_removegrain.c
@@ -82,10 +82,7 @@ static int mode01(int c, int a1, int a2, int a3, int a4, int 
a5, int a6, int a7,
 
 static int cmp_int(const void *p1, const void *p2)
 {
-int left = *(const int *)p1;
-int right = *(const int *)p2;
-
-return ((left > right) - (left < right));
+return *(const int *)p1 - *(const int *)p2;
 }
 
 static int mode02(int c, int a1, int a2, int a3, int a4, int a5, int a6, int 
a7, int a8)
diff --git a/libavformat/subtitles.c b/libavformat/subtitles.c
index bb89766..1c1928b 100644
--- a/libavformat/subtitles.c
+++ b/libavformat/subtitles.c
@@ -146,12 +146,9 @@ static int cmp_pkt_sub_ts_pos(const void *a, const void *b)
 {
 const AVPacket *s1 = a;
 const AVPacket *s2 = b;
-if (s1->pts == s2->pts) {
-if (s1->pos == s2->pos)
-return 0;
-return s1->pos > s2->pos ? 1 : -1;
-}
-return s1->pts > s2->pts ? 1 : -1;
+if (s1->pts == s2->pts)
+return s1->pos - s2->pos;
+return s1->pts - s2->pts;
 }
 
 static int cmp_pkt_sub_pos_ts(const void *a, const void *b)
diff --git a/libswresample/swresample-test.c b/libswresample/swresample-test.c
index 9caa750..0aa47c8 100644
--- a/libswresample/swresample-test.c
+++ b/libswresample/swresample-test.c
@@ -138,8 +138,8 @@ static void setup_array(uint8_t *out[SWR_CH_MAX], uint8_t 
*in, enum AVSampleForm
 }
 }
 
-static int cmp(const int *a, const int *b){
-return *a - *b;
+static int cmp(const void *a, const void *b){
+return *(const int *)a - *(const int *)b;
 }
 
 static void audiogen(void *data, enum AVSampleFormat sample_fmt,
@@ -271,7 +271,7 @@ int main(int argc, char **argv){
 r = (seed * (uint64_t)(max_tests - test)) >>32;
 FFSWAP(int, remaining_tests[r], remaining_tests[max_tests - test - 1]);
 }
-qsort(remaining_tests + max_tests - num_tests, num_tests, 
sizeof(remaining_tests[0]), (void*)cmp);
+qsort(remaining_tests + max_tests - num_tests, num_tests, 
sizeof(remaining_tests[0]), cmp);
 in_sample_rate=16000;
 for(test=0; test

Re: [FFmpeg-devel] [PATCH 3/3] avutil/tree: add additional const qualifier to the comparator

[Ganesh Ajjanagadde]

On Sat, Oct 24, 2015 at 7:17 PM, Henrik Gramner  wrote:
> On Sun, Oct 25, 2015 at 12:02 AM, Ganesh Ajjanagadde
>  wrote:
>> -static int cmp(void *key, const void *node)
>> +static int cmp(const void *key, const void *node)
>>  {
>>  return (*(int64_t *) key) - ((const CacheEntry *) node)->logical_pos;
>>  }
>
>> -int ff_nut_sp_pos_cmp(const Syncpoint *a, const Syncpoint *b)
>> +int ff_nut_sp_pos_cmp(const void *a, const void *b)
>>  {
>> -return ((a->pos - b->pos) >> 32) - ((b->pos - a->pos) >> 32);
>> +Syncpoint va = *(Syncpoint *)a, vb = *(Syncpoint *)b;
>> +return ((va.pos - vb.pos) >> 32) - ((vb.pos - va.pos) >> 32);
>>  }
>
>> -int ff_nut_sp_pts_cmp(const Syncpoint *a, const Syncpoint *b)
>> +int ff_nut_sp_pts_cmp(const void *a, const void *b)
>>  {
>> -return ((a->ts - b->ts) >> 32) - ((b->ts - a->ts) >> 32);
>> +Syncpoint va = *(Syncpoint *)a, vb = *(Syncpoint *)b;
>> +return ((va.ts - vb.ts) >> 32) - ((vb.ts - va.ts) >> 32);
>>  }
>
> Casts discards const qualifiers.

Good catch, changed. There is some more such constness being discarded
in comparators, and some needlessly complex comparator logic in some
places. Submitted a patch.

>
> Furthermore, why are you changing the two last functions to copy the
> entire struct to a temporary local copy?

Sorry, forgot they were structs.
Fixed all, pushed. Thanks.

> ___
> 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 5/5] all: fix enum definition for large values

[Ganesh Ajjanagadde]

On Sat, Oct 24, 2015 at 2:33 PM, Michael Niedermayer
 wrote:
> On Sat, Oct 24, 2015 at 09:29:23AM -0400, 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 such errors by explicitly casting as an int, doing the
>> desired unsigned to signed conversion. This method works on all current
>> architectures. Tested with FATE.
>>
>> Signed-off-by: Ganesh Ajjanagadde 
>
> Simply changing the values to signed is not correct / not sufficient
> the code assumes that they are unsigned

enums are ints (and hence signed). I doubt code assumed that they are
unsigned. If code depended on these being unsigned constants, then
there is no way of placing them in an enum. Are you fine with a macro,
or do you prefer a static const style? Generally, it seems like FFmpeg
prefers the macro method for defining such constants/flags.

>
> [...]
> --
> 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 4/5] avfilter: avoid zero arguments to variadic macro

[Michael Niedermayer]

On Sat, Oct 24, 2015 at 02:01:07PM -0400, Ganesh Ajjanagadde wrote:
> On Sat, Oct 24, 2015 at 1:48 PM, Michael Niedermayer
>  wrote:
> > On Sat, Oct 24, 2015 at 03:52:25PM +0200, Nicolas George wrote:
> >> Le tridi 3 brumaire, an CCXXIV, Ganesh Ajjanagadde a écrit :
> >> > Thanks for the super quick review. Will apply shortly. Do you (or
> >> > others) think adding -Wgnu-zero-variadic-macro-arguments to configure
> >> > is a good idea?
> >>
> >> Considering that each additional option takes ~15 ms in configure on a
> >> fairly powerful box, not counting maintenance burden, I would say rather 
> >> no.
> >
> > about 10ms here with
> > time ./configure
> > about 1.5ms here with
> > time ./configure --cc='ccache gcc'  
> > --tempprefix=/home/michael/ffconftemp
> >
> > also we could speed configure up with something like this:
> > (or a more generic "all before each" checker)
> >
> > diff --git a/configure b/configure
> > index a38b290..6fa3273 100755
> > --- a/configure
> > +++ b/configure
> > @@ -5637,6 +5637,9 @@ disabled iconv || check_func_headers iconv.h iconv || 
> > check_lib2 iconv.h iconv -
> >  enabled debug && add_cflags -g"$debuglevel" && add_asflags -g"$debuglevel"
> >
> >  # add some useful compiler flags if supported
> > +if ! check_cflags -Wdeclaration-after-statement -Wall 
> > -Wdisabled-optimization -Wpointer-arith -Wredundant-decls \
> > +  -Wwrite-strings -Wtype-limits -Wundef 
> > -Wmissing-prototypes -Wno-pointer-to-int-cast -Wstrict-prototypes 
> > -Wempty-body ; then
> > +
> >  check_cflags -Wdeclaration-after-statement
> >  check_cflags -Wall
> >  check_cflags -Wdisabled-optimization
> > @@ -5649,6 +5652,9 @@ check_cflags -Wmissing-prototypes
> >  check_cflags -Wno-pointer-to-int-cast
> >  check_cflags -Wstrict-prototypes
> >  check_cflags -Wempty-body
> > +#Note, if you add a check_cflags here, also add it to the if above
> > +fi
> > +
> >  enabled extra_warnings && check_cflags -Winline
> >
> >  check_disable_warning(){
> 
> Will leave it to you (or others) for such patches (to speed up
> configure and/or add warnings), I am fine either way.

i can apply above code if wanted, beyond that ill leave it to
others as well, like for writing a nice generic
"all before each" checker
as in
check_each check_cflags -Wdeclaration-after-statement -Wall 
-Wdisabled-optimization -Wpointer-arith -Wredundant-decls

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

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


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

Re: [FFmpeg-devel] [PATCH 5/5] all: fix enum definition for large values

[Michael Niedermayer]

On Sat, Oct 24, 2015 at 02:41:59PM -0400, Ganesh Ajjanagadde wrote:
> On Sat, Oct 24, 2015 at 2:33 PM, Michael Niedermayer
>  wrote:
> > On Sat, Oct 24, 2015 at 09:29:23AM -0400, 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 such errors by explicitly casting as an int, doing the
> >> desired unsigned to signed conversion. This method works on all current
> >> architectures. Tested with FATE.
> >>
> >> Signed-off-by: Ganesh Ajjanagadde 
> >
> > Simply changing the values to signed is not correct / not sufficient
> > the code assumes that they are unsigned
> 
> enums are ints (and hence signed).

> I doubt code assumed that they are
> unsigned.

it did
for example (uint64_t)DCA_SYNCWORD_CORE_LE will change its value
with this patch, if thats the only one of if there are dozends more
i dont know

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

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus


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

Re: [FFmpeg-devel] [PATCH 5/5] all: fix enum definition for large values

[Hendrik Leppkes]

On Sat, Oct 24, 2015 at 8:58 PM, Michael Niedermayer
 wrote:
> On Sat, Oct 24, 2015 at 02:41:59PM -0400, Ganesh Ajjanagadde wrote:
>> On Sat, Oct 24, 2015 at 2:33 PM, Michael Niedermayer
>>  wrote:
>> > On Sat, Oct 24, 2015 at 09:29:23AM -0400, 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 such errors by explicitly casting as an int, doing the
>> >> desired unsigned to signed conversion. This method works on all current
>> >> architectures. Tested with FATE.
>> >>
>> >> Signed-off-by: Ganesh Ajjanagadde 
>> >
>> > Simply changing the values to signed is not correct / not sufficient
>> > the code assumes that they are unsigned
>>
>> enums are ints (and hence signed).
>
> this is not true (though thats off topic but you seemed interrested in
> the C spec)
> 6.7.2.2 Enumeration specifiers
> ...
> 4 Each enumerated type shall be compatible with char, a signed integer type, 
> or an
>   unsigned integer type. The choice of type is implementation-defined,110) 
> but shall be
>   capable of representing the values of all the members of the enumeration. 
> The
>   enumerated type is incomplete until after the } that terminates the list of 
> enumerator
>   declarations.
>
> so a enum type can be almost anything the implementation likes it to
> be. 2 enums dont even need to be using the same type and this is not
> just specification talk, gcc does this actually, for example it will
> use (u)int64 as type when things dont fit in an (unsigned) int
> also on at least some embeded platforms gcc will use shorts
> for enums that fit in a short int (no i dont know which exactly but
> i read about people stumbling into this so it must happen on some
> platform)
>
>
>> I doubt code assumed that they are
>> unsigned. If code depended on these being unsigned constants, then
>> there is no way of placing them in an enum. Are you fine with a macro,
>> or do you prefer a static const style? Generally, it seems like FFmpeg
>> prefers the macro method for defining such constants/flags.
>
> if have no preferrance for anything beyond the code working
>

If the current code is correct according to the spec (ie. the enum
gets represented as unsigned or int64), then it should just remain as
it is.

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