[FFmpeg-devel] [PATCH] avdevice/libdc1394: silence -Wdiscarded-qualifiers

[Ganesh Ajjanagadde]

fmt, fps are non-const as they are needed to loop over a static const array.
Thus the patch explicitly casts them to be non-const. This suppresses
-Wdiscarded-qualifiers seen in e.g
http://fate.ffmpeg.org/log.cgi?time=20150919100330=compile=x86_64-archlinux-gcc-enableshared.

Signed-off-by: Ganesh Ajjanagadde 
---
 libavdevice/libdc1394.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavdevice/libdc1394.c b/libavdevice/libdc1394.c
index 6868e9c..250f5e9 100644
--- a/libavdevice/libdc1394.c
+++ b/libavdevice/libdc1394.c
@@ -148,11 +148,11 @@ static inline int dc1394_read_common(AVFormatContext *c,
 }
 dc1394->frame_rate = av_rescale(1000, framerate.num, framerate.den);
 
-for (fmt = dc1394_frame_formats; fmt->width; fmt++)
+for (fmt = (struct dc1394_frame_format *) dc1394_frame_formats; 
fmt->width; fmt++)
  if (fmt->pix_fmt == pix_fmt && fmt->width == width && fmt->height == 
height)
  break;
 
-for (fps = dc1394_frame_rates; fps->frame_rate; fps++)
+for (fps = (struct dc1394_frame_rate *) dc1394_frame_rates; 
fps->frame_rate; fps++)
  if (fps->frame_rate == dc1394->frame_rate)
  break;
 
-- 
2.5.2

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

Re: [FFmpeg-devel] [PATCHv3] avfilter/vf_chromakey: Add chromakey video filter

[Lou Logan]

Hi,

I know the docs is similar to colorkey, but I have a few short
suggestions.

On Fri, 18 Sep 2015 16:27:54 +0200, Timo Rothenpieler wrote:

[...]
> diff --git a/doc/filters.texi b/doc/filters.texi
> index 4a55e59..0446204 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -3556,6 +3556,51 @@ 
> boxblur=luma_radius=min(h\,w)/10:luma_power=1:chroma_radius=min(cw\,ch)/10:chrom
>  @end example
>  @end itemize
>  
> +@section chromakey
> +YUV colorspace color/chroma keying.
> +
> +The filter accepts the following options:
> +
> +@table @option
> +@item color
> +The color which will be replaced with transparency.

For the general syntax of this option, check the "Color" section in the
ffmpeg-utils manual. Default is @code{black}.

> +@item similarity
> +Similarity percentage with the key color.
> +
> +0.01 matches only the exact key color, while 1.0 matches everything.

Default is 0.01.

> +@item blend
> +Blend percentage.
> +
> +0.0 makes pixels either fully transparent, or not transparent at all.

Range is 0.0 to 1.0. Default is 0.0.

> +Higher values result in semi-transparent pixels, with a higher transparency
> +the more similar the pixels color is to the key color.
> +
> +@item yuv
> +Signals that the color passed is already in YUV instead of RGB.

Default is disabled.

> +
> +Litteral colors like "green" or "red" don't make sense with this enabled 
> anymore.

s/Litteral/Literal

The "anymore" can be removed.

What happens if a literal color is used when the yuv option is enabled?

[...]

> +static const AVOption chromakey_options[] = {
> +{ "color", "set the chromakey key color", OFFSET(chromakey_rgba), 
> AV_OPT_TYPE_COLOR, { .str = "black" }, CHAR_MIN, CHAR_MAX, FLAGS },
> +{ "similarity", "set the chromakey similarity value", 
> OFFSET(similarity), AV_OPT_TYPE_FLOAT, { .dbl = 0.01 }, 0.01, 1.0, FLAGS },
> +{ "blend", "set the chromakey key blend value", OFFSET(blend), 
> AV_OPT_TYPE_FLOAT, { .dbl = 0.0 }, 0.0, 1.0, FLAGS },
> +{ "yuv", "color parameter is in yuv instead of rgb", OFFSET(is_yuv), 
> AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, FLAGS },

"indicate that the color parameter is in yuv instead of rgb"
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avcodec/snowenc: fix discarded const warning

[Ganesh Ajjanagadde]

This fixes a -Wdiscarded-qualifiers in e.g
http://fate.ffmpeg.org/log.cgi?time=20150919093218=compile=x86_64-archlinux-gcc-ddebug.
It is quite clear from the code that the discard of constness was deliberate,
so the cast should be fine.

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

diff --git a/libavcodec/snowenc.c b/libavcodec/snowenc.c
index 5e5dc35..86ecc4f 100644
--- a/libavcodec/snowenc.c
+++ b/libavcodec/snowenc.c
@@ -1557,7 +1557,7 @@ static int encode_frame(AVCodecContext *avctx, AVPacket 
*pkt,
 {
 SnowContext *s = avctx->priv_data;
 RangeCoder * const c= >c;
-AVFrame *pic = pict;
+AVFrame *pic = (AVFrame *) pict;
 const int width= s->avctx->width;
 const int height= s->avctx->height;
 int level, orientation, plane_index, i, y, ret;
-- 
2.5.2

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

Re: [FFmpeg-devel] [PATCH] avformat/format: silence -Wdiscarded-qualifiers

[Ganesh Ajjanagadde]

On Wed, Sep 16, 2015 at 9:08 PM, Michael Niedermayer  wrote:
> On Wed, Sep 16, 2015 at 06:50:54PM -0400, Ganesh Ajjanagadde wrote:
>> lpd.buf is non-const and discards the const qualifier of zerobuffer.
>> This fixes -Wdiscarded-qualifiers observed with GCC 5.2.
>>
>> Signed-off-by: Ganesh Ajjanagadde 
>> ---
>>  libavformat/format.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavformat/format.c b/libavformat/format.c
>> index fd81d7a..9c40512 100644
>> --- a/libavformat/format.c
>> +++ b/libavformat/format.c
>> @@ -172,7 +172,7 @@ AVInputFormat *av_probe_input_format3(AVProbeData *pd, 
>> int is_opened,
>>  AVProbeData lpd = *pd;
>>  AVInputFormat *fmt1 = NULL, *fmt;
>>  int score, nodat = 0, score_max = 0;
>> -const static uint8_t zerobuffer[AVPROBE_PADDING_SIZE];
>> +static uint8_t zerobuffer[AVPROBE_PADDING_SIZE];
>
> this is wrong, the buffer is constant
> if the content of the buffer would change that would be a serious
> bug.
> Before this change the compiler would detect direct changes done to
> the buffer

see patchv2, this avoids the issue.

>
> [...]
> --
> 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] checkasm: add VP9 loopfilter tests.

[Ronald S. Bultje]

Hi,

On Thu, Sep 17, 2015 at 5:58 PM, Ronald S. Bultje 
wrote:

> The randomize_buffer() implementation assures that "most of the time",
> we'll do a good mix of wide16/wide8/hev/regular/no filters for complete
> code coverage. However, this is not mathematically assured because that
> would make the code either much more complex, or much less random.
> ---
>  tests/checkasm/vp9dsp.c | 147
> 
>  1 file changed, 147 insertions(+)


Poke.

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

[FFmpeg-devel] [PATCH 2/2] doc/developer: s/ffmpeg-cvslog/ffmpeg-devel

[Ganesh Ajjanagadde]

ffmpeg has not been using cvs for a long time.

Signed-off-by: Ganesh Ajjanagadde 
---
 doc/developer.texi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/developer.texi b/doc/developer.texi
index 7324629..923ee69 100644
--- a/doc/developer.texi
+++ b/doc/developer.texi
@@ -349,7 +349,7 @@ timeframe (12h for build failures and security fixes, 3 
days small changes,
 Also note, the maintainer can simply ask for more time to review!
 
 @item
-Subscribe to the ffmpeg-cvslog mailing list. The diffs of all commits
+Subscribe to the ffmpeg-devel mailing list. The diffs of all commits
 are sent there and reviewed by all the other developers. Bugs and possible
 improvements or general questions regarding commits are discussed there. We
 expect you to react if problems with your code are uncovered.
-- 
2.5.2

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

[FFmpeg-devel] [PATCH 1/2] doc/developer: add note on patches that fix warnings

[Ganesh Ajjanagadde]

This adds some recommendations while submitting patches that fix warnings.

Signed-off-by: Ganesh Ajjanagadde 
---
 doc/developer.texi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/doc/developer.texi b/doc/developer.texi
index b8259e7..7324629 100644
--- a/doc/developer.texi
+++ b/doc/developer.texi
@@ -391,6 +391,12 @@ be changed to not generate a warning unless that causes a 
slowdown
 or obfuscates the code.
 
 @item
+While fixing compiler warnings, please add some information to the commit
+message body indicating the compiler/environment version or configuration.
+This is very helpful for future maintainers since it eases possible
+modifications when the toolchain gets updated.
+
+@item
 Make sure that no parts of the codebase that you maintain are missing from the
 @file{MAINTAINERS} file. If something that you want to maintain is missing add 
it with
 your name after it.
-- 
2.5.2

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

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/x86/hpeldsp_rnd_template: silence -Wunused-function on --disable-mmx

[Michael Niedermayer]

On Sat, Sep 19, 2015 at 11:38:59AM -0400, Ganesh Ajjanagadde wrote:
> This silences some of the -Wunused-function warnings when compiled with 
> --disable-mmx, e.g
> http://fate.ffmpeg.org/log.cgi?time=20150919094617=compile=x86_64-archlinux-gcc-disable-mmx.
> Header guards are too brittle and ugly for this case.
> 
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavcodec/x86/hpeldsp_rnd_template.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)

applied

thanks

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

The real ebay dictionary, page 1
"Used only once"- "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."


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

Re: [FFmpeg-devel] [PATCH 2/2] doc/developer: s/ffmpeg-cvslog/ffmpeg-devel

[James Almer]

On 9/19/2015 8:36 PM, Ganesh Ajjanagadde wrote:
> ffmpeg has not been using cvs for a long time.
> 
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  doc/developer.texi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/doc/developer.texi b/doc/developer.texi
> index 7324629..923ee69 100644
> --- a/doc/developer.texi
> +++ b/doc/developer.texi
> @@ -349,7 +349,7 @@ timeframe (12h for build failures and security fixes, 3 
> days small changes,
>  Also note, the maintainer can simply ask for more time to review!
>  
>  @item
> -Subscribe to the ffmpeg-cvslog mailing list. The diffs of all commits
> +Subscribe to the ffmpeg-devel mailing list. The diffs of all commits
>  are sent there and reviewed by all the other developers. Bugs and possible
>  improvements or general questions regarding commits are discussed there. We
>  expect you to react if problems with your code are uncovered.

https://ffmpeg.org/pipermail/ffmpeg-cvslog/

ffmpeg-cvslog has a different purpose than ffmpeg-devel.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] doc/developer: s/ffmpeg-cvslog/ffmpeg-devel

[James Almer]

On 9/19/2015 8:54 PM, Ganesh Ajjanagadde wrote:
> On Sat, Sep 19, 2015 at 7:48 PM, James Almer  wrote:
>> On 9/19/2015 8:36 PM, Ganesh Ajjanagadde wrote:
>>> ffmpeg has not been using cvs for a long time.
>>>
>>> Signed-off-by: Ganesh Ajjanagadde 
>>> ---
>>>  doc/developer.texi | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/doc/developer.texi b/doc/developer.texi
>>> index 7324629..923ee69 100644
>>> --- a/doc/developer.texi
>>> +++ b/doc/developer.texi
>>> @@ -349,7 +349,7 @@ timeframe (12h for build failures and security fixes, 3 
>>> days small changes,
>>>  Also note, the maintainer can simply ask for more time to review!
>>>
>>>  @item
>>> -Subscribe to the ffmpeg-cvslog mailing list. The diffs of all commits
>>> +Subscribe to the ffmpeg-devel mailing list. The diffs of all commits
>>>  are sent there and reviewed by all the other developers. Bugs and possible
>>>  improvements or general questions regarding commits are discussed there. We
>>>  expect you to react if problems with your code are uncovered.
>>
>> https://ffmpeg.org/pipermail/ffmpeg-cvslog/
>>
>> ffmpeg-cvslog has a different purpose than ffmpeg-devel.
> 
> Isn't the same information available at
> https://ffmpeg.org/pipermail/ffmpeg-devel/?
> Can you tell me what the difference between the two is?

If you check and compare the emails between the two list, you'll notice that one
is a list where automated emails are sent every time something is committed to
the git repo, and the other is a list where patches are sent for review.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC] avformat/mxfenc: stop encoding if unfilled video packet

[Tomas Härdin]

On Wed, 2015-09-16 at 14:33 +0200, Tobias Rapp wrote:
> Hi,
> 
> attached patch fixes ticket #4759 but I guess it is a bit too hasty to 
> always abort transcoding if a single frame cannot be written. I guess it 
> would be better to check for some "exit_on_error" like flag set but 
> couldn't find out how to achieve that.
> 
> Any comments would be appreciated.
> 
> Regards,
> Tobias


> From 7d6f8de2a411817c970a19d8766e69b6eb604132 Mon Sep 17 00:00:00 2001
> From: Tobias Rapp 
> Date: Mon, 14 Sep 2015 12:06:22 +0200
> Subject: [PATCH] avformat/mxfenc: stop encoding if unfilled video packet
>  occurs
> 
> Fixes ticket #4759.
> ---
>  libavformat/mxfenc.c | 14 +-
>  1 file changed, 9 insertions(+), 5 deletions(-)
> 
> diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
> index 84ce979..4eac812 100644
> --- a/libavformat/mxfenc.c
> +++ b/libavformat/mxfenc.c
> @@ -2262,7 +2262,7 @@ static void mxf_write_system_item(AVFormatContext *s)
>  mxf_write_umid(s, 1);
>  }
>  
> -static void mxf_write_d10_video_packet(AVFormatContext *s, AVStream *st, 
> AVPacket *pkt)
> +static int mxf_write_d10_video_packet(AVFormatContext *s, AVStream *st, 
> AVPacket *pkt)
>  {
>  MXFContext *mxf = s->priv_data;
>  AVIOContext *pb = s->pb;
> @@ -2286,9 +2286,12 @@ static void mxf_write_d10_video_packet(AVFormatContext 
> *s, AVStream *st, AVPacke
>  ffio_fill(s->pb, 0, pad);
>  av_assert1(!(avio_tell(s->pb) & (KAG_SIZE-1)));
>  } else {
> -av_log(s, AV_LOG_WARNING, "cannot fill d-10 video packet\n");
> +av_log(s, AV_LOG_ERROR, "cannot fill d-10 video packet\n");
>  ffio_fill(s->pb, 0, pad);
> +return AVERROR(EIO);
>  }
> +
> +return 0;
>  }

Is this really better than not writing anything?

/Tomas

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

Re: [FFmpeg-devel] [PATCH] avcodec/x86/mpegvideoenc: silence -Wunused-function on --disable-mmx

[Michael Niedermayer]

On Sat, Sep 19, 2015 at 11:00:50AM -0400, Ganesh Ajjanagadde wrote:
> This silences -Wunused-function when compiled with --disable-mmx, e.g
> http://fate.ffmpeg.org/log.cgi?time=20150919094617=compile=x86_64-archlinux-gcc-disable-mmx.
> 
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavcodec/x86/mpegvideoenc.c | 4 
>  1 file changed, 4 insertions(+)

applied

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


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

Re: [FFmpeg-devel] [PATCH] avresample/resample: remove unused variable

[Michael Niedermayer]

On Sat, Sep 19, 2015 at 01:26:35PM -0400, Ganesh Ajjanagadde wrote:
> This fixes a -Wunused-variable, see e.g
> http://fate.ffmpeg.org/log.cgi?time=20150919162338=compile=x86_64-archlinux-gcc-threads.
> 
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavresample/resample.c | 1 -
>  1 file changed, 1 deletion(-)

applied

thx

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

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


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

[FFmpeg-devel] [PATCH] avcodec/hevc_mp4toannexb_bsf: silence -Wdiscarded-qualifiers

[Ganesh Ajjanagadde]

*poutbuf is non-const, so this casts it explicitly.
This suppresses -Wdiscarded-qualifiers seen in e.g
http://fate.ffmpeg.org/log.cgi?time=20150919100330=compile=x86_64-archlinux-gcc-enableshared.

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

diff --git a/libavcodec/hevc_mp4toannexb_bsf.c 
b/libavcodec/hevc_mp4toannexb_bsf.c
index 54d6d79..1545e4a 100644
--- a/libavcodec/hevc_mp4toannexb_bsf.c
+++ b/libavcodec/hevc_mp4toannexb_bsf.c
@@ -134,7 +134,7 @@ static int hevc_mp4toannexb_filter(AVBitStreamFilterContext 
*bsfc,
"The input looks like it is Annex B already\n");
 ctx->logged_nonmp4_warning = 1;
 }
-*poutbuf  = buf;
+*poutbuf  = (uint8_t *) buf;
 *poutbuf_size = buf_size;
 return 0;
 }
-- 
2.5.2

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

Re: [FFmpeg-devel] [PATCH] avcodec/mlpdec: fix a undefined left shift of negative number

[Michael Niedermayer]

On Sat, Sep 19, 2015 at 01:06:46AM -0400, Ganesh Ajjanagadde wrote:
> This fixes a -Wshift-negative-value reported with clang 3.7+, e.g
> http://fate.ffmpeg.org/log.cgi?time=20150918181527=compile=x86_64-darwin-clang-polly-vectorize-stripmine-3.7.
> 
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavcodec/mlpdec.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

applied

thanks

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

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


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

Re: [FFmpeg-devel] [PATCHv2] configure: add -D_DEFAULT_SOURCE to silence -Wcpp

[Ganesh Ajjanagadde]

On Sat, Sep 19, 2015 at 2:13 PM, Hendrik Leppkes  wrote:
> On Sat, Sep 19, 2015 at 6:07 PM, Ganesh Ajjanagadde  wrote:
>> On Thu, Sep 17, 2015 at 6:45 AM, Ganesh Ajjanagadde  wrote:
>>> On Thu, Sep 17, 2015 at 4:54 AM, Clément Bœsch  wrote:
 On Wed, Sep 16, 2015 at 06:55:39PM -0400, Ganesh Ajjanagadde wrote:
> Glibc 2.20 onwards generates a deprecation warning for usage of 
> _BSD_SOURCE and _SVID_SOURCE.
> The solution from man feature_test_macros is to define both 
> _DEFAULT_SOURCE and the old macros.
> This change is done in configure while testing for Glibc. Doing it in 
> source code
> would require __UCLIBC__ checks, etc since uclibc also defines __GLIBC__ 
> and __GLIBC_MINOR__,
> so placing it in configure avoids the repeated checks.
>
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  configure| 6 ++
>  libavformat/os_support.c | 1 -
>  2 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/configure b/configure
> index cd6f629..0cd0a6c 100755
> --- a/configure
> +++ b/configure
> @@ -4520,6 +4520,12 @@ probe_libc(){
>  elif check_${pfx}cpp_condition features.h "defined __GLIBC__"; then
>  eval ${pfx}libc_type=glibc
>  add_${pfx}cppflags -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600
> +# define _DEFAULT_SOURCE for glibc 2.20 onwards to silence 
> deprecation
> +# warnings for _BSD_SOURCE and _SVID_SOURCE.
> +if check_${pfx}cpp_condition features.h "(__GLIBC__ == 2 && 
> __GLIBC_MINOR__ >= 20) \
> +|| (__GLIBC__ > 2)"; then
> +add_${pfx}cppflags -D_DEFAULT_SOURCE
> +fi

 Is this adding _DEFAULT_SOURCE to every compiled file while it was scope
 to a standalone source file before?
>>>
>>> Don't know exactly what you mean, but try e.g strings on any of these
>>> objects. There is no "DEFAULT_SOURCE", "BSD_SOURCE", or any such thing
>>> suggesting they are optimized out. Furthermore, a du on the libav*
>>> does not reveal any increase in size.
>>
>> ping
>
> I agree with Clément, adding a global define to every single file
> while it was contained to a handful of select files before seems less
> than ideal.

Like I said, it causes no visible change in the result. One could add
it to the specific files. However, think about the future: it is very
easy to miss adding this, and warnings may be triggered in the future
at any point if a dev uses the BSD, SVID, etc forgetting the DEFAULT.
Who knows what glibc would do 3 releases down, when the deprecation
becomes an actual error. I think FFmpeg devs should have better things
to do in future than agonizing over some ugly glibc thing that is
introduced for god knows what reason. In light of that I wanted to
create a "fire and forget" solution which is global in character. This
achieves this at no performance penalty and practically speaking no
symbol problems. We already have a bunch of global things, see e.g the
-DZLIB, etc - they are certainly not needed everywhere and your
argument would apply to them as well.

If this was required in just a single file, I would agree with you.
However, it shows up in multiple places (IIRC at least 3).

Anyway, if you (or others) still feel that way about it, I will change
the patch.

>
> - Hendrik
> ___
> 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/2] avcodec/x86/hpeldsp_rnd_template: silence -Wunused-function on --disable-mmx

[Ganesh Ajjanagadde]

On Sat, Sep 19, 2015 at 11:38 AM, Ganesh Ajjanagadde
 wrote:
> This silences some of the -Wunused-function warnings when compiled with 
> --disable-mmx, e.g
> http://fate.ffmpeg.org/log.cgi?time=20150919094617=compile=x86_64-archlinux-gcc-disable-mmx.
> Header guards are too brittle and ugly for this case.
>
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavcodec/x86/hpeldsp_rnd_template.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/x86/hpeldsp_rnd_template.c 
> b/libavcodec/x86/hpeldsp_rnd_template.c
> index 8cbc412..abe3bb1 100644
> --- a/libavcodec/x86/hpeldsp_rnd_template.c
> +++ b/libavcodec/x86/hpeldsp_rnd_template.c
> @@ -28,7 +28,7 @@
>  #include 
>
>  // put_pixels
> -static void DEF(put, pixels8_x2)(uint8_t *block, const uint8_t *pixels, 
> ptrdiff_t line_size, int h)
> +av_unused static void DEF(put, pixels8_x2)(uint8_t *block, const uint8_t 
> *pixels, ptrdiff_t line_size, int h)
>  {
>  MOVQ_BFE(mm6);
>  __asm__ volatile(
> @@ -60,7 +60,7 @@ static void DEF(put, pixels8_x2)(uint8_t *block, const 
> uint8_t *pixels, ptrdiff_
>  :REG_a, "memory");
>  }
>
> -static void DEF(put, pixels16_x2)(uint8_t *block, const uint8_t *pixels, 
> ptrdiff_t line_size, int h)
> +av_unused static void DEF(put, pixels16_x2)(uint8_t *block, const uint8_t 
> *pixels, ptrdiff_t line_size, int h)
>  {
>  MOVQ_BFE(mm6);
>  __asm__ volatile(
> @@ -135,7 +135,7 @@ static void DEF(put, pixels8_y2)(uint8_t *block, const 
> uint8_t *pixels, ptrdiff_
>  :REG_a, "memory");
>  }
>
> -static void DEF(avg, pixels16_x2)(uint8_t *block, const uint8_t *pixels, 
> ptrdiff_t line_size, int h)
> +av_unused static void DEF(avg, pixels16_x2)(uint8_t *block, const uint8_t 
> *pixels, ptrdiff_t line_size, int h)
>  {
>  MOVQ_BFE(mm6);
>  __asm__ volatile(
> --
> 2.5.2
>

apologies; [PATCH 1/2] -> [PATCH 1/3].
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/videotoolbox: fix -Wunused-but-set-variable

[Hendrik Leppkes]

On Sat, Sep 19, 2015 at 9:58 PM, Ganesh Ajjanagadde
 wrote:
> pix_fmt was declared presumably to shorten the argument passed to the 
> function.
> However, it is currently not being used for such a purpose.
> This patch makes it used for that purpose.
> This fixes -Wunused-but-set-variable reported at e.g:
> http://fate.ffmpeg.org/log.cgi?time=20150919194249=compile=x86_64-darwin-gcc-4.9.
>
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavcodec/videotoolbox.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
> index b78238a..e35eb2d 100644
> --- a/libavcodec/videotoolbox.c
> +++ b/libavcodec/videotoolbox.c
> @@ -546,7 +546,7 @@ static int videotoolbox_default_init(AVCodecContext 
> *avctx)
>
>  buf_attr = videotoolbox_buffer_attributes_create(avctx->width,
>   avctx->height,
> - 
> videotoolbox->cv_pix_fmt_type);
> + pix_fmt);
>
>  decoder_cb.decompressionOutputCallback = videotoolbox_decoder_callback;
>  decoder_cb.decompressionOutputRefCon   = avctx;

If the variable is entirely unused right now, then it should just be
removed instead of finding some  use for it that'll just get optimized
away anyway.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] doc/developer: s/ffmpeg-cvslog/ffmpeg-devel

[Ganesh Ajjanagadde]

On Sat, Sep 19, 2015 at 8:30 PM, James Almer  wrote:
> On 9/19/2015 8:54 PM, Ganesh Ajjanagadde wrote:
>> On Sat, Sep 19, 2015 at 7:48 PM, James Almer  wrote:
>>> On 9/19/2015 8:36 PM, Ganesh Ajjanagadde wrote:
 ffmpeg has not been using cvs for a long time.

 Signed-off-by: Ganesh Ajjanagadde 
 ---
  doc/developer.texi | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/doc/developer.texi b/doc/developer.texi
 index 7324629..923ee69 100644
 --- a/doc/developer.texi
 +++ b/doc/developer.texi
 @@ -349,7 +349,7 @@ timeframe (12h for build failures and security fixes, 
 3 days small changes,
  Also note, the maintainer can simply ask for more time to review!

  @item
 -Subscribe to the ffmpeg-cvslog mailing list. The diffs of all commits
 +Subscribe to the ffmpeg-devel mailing list. The diffs of all commits
  are sent there and reviewed by all the other developers. Bugs and possible
  improvements or general questions regarding commits are discussed there. 
 We
  expect you to react if problems with your code are uncovered.
>>>
>>> https://ffmpeg.org/pipermail/ffmpeg-cvslog/
>>>
>>> ffmpeg-cvslog has a different purpose than ffmpeg-devel.
>>
>> Isn't the same information available at
>> https://ffmpeg.org/pipermail/ffmpeg-devel/?
>> Can you tell me what the difference between the two is?
>
> If you check and compare the emails between the two list, you'll notice that 
> one
> is a list where automated emails are sent every time something is committed to
> the git repo, and the other is a list where patches are sent for review.

Well, in that case the doc is broken in a worse way. "Bugs and
possilbe improvements or general questions regarding commits are
discussed there" does not even apply to ffmpeg-cvslog, it really
applies to ffmpeg-devel. In that case this patch is still an
improvement over the current situation. ffmpeg-cvslog is pretty much
useless for a dev on daily basis, since he/she can't see the
discussion. If a dev is subscribing to something, ffmpeg-devel gives
far more useful information and IMHO is the preferred mailing list.

However, perhaps the commit message needs rewording due to my misunderstanding.

> ___
> 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/2] doc/developer: s/ffmpeg-cvslog/ffmpeg-devel

[Ganesh Ajjanagadde]

On Sat, Sep 19, 2015 at 7:48 PM, James Almer  wrote:
> On 9/19/2015 8:36 PM, Ganesh Ajjanagadde wrote:
>> ffmpeg has not been using cvs for a long time.
>>
>> Signed-off-by: Ganesh Ajjanagadde 
>> ---
>>  doc/developer.texi | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/doc/developer.texi b/doc/developer.texi
>> index 7324629..923ee69 100644
>> --- a/doc/developer.texi
>> +++ b/doc/developer.texi
>> @@ -349,7 +349,7 @@ timeframe (12h for build failures and security fixes, 3 
>> days small changes,
>>  Also note, the maintainer can simply ask for more time to review!
>>
>>  @item
>> -Subscribe to the ffmpeg-cvslog mailing list. The diffs of all commits
>> +Subscribe to the ffmpeg-devel mailing list. The diffs of all commits
>>  are sent there and reviewed by all the other developers. Bugs and possible
>>  improvements or general questions regarding commits are discussed there. We
>>  expect you to react if problems with your code are uncovered.
>
> https://ffmpeg.org/pipermail/ffmpeg-cvslog/
>
> ffmpeg-cvslog has a different purpose than ffmpeg-devel.

Isn't the same information available at
https://ffmpeg.org/pipermail/ffmpeg-devel/?
Can you tell me what the difference between the two is?

> ___
> 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] [PATCHv2] avcodec/videotoolbox: fix -Wunused-but-set-variable

[Ganesh Ajjanagadde]

pix_fmt was declared presumably to shorten the argument passed to the function.
However, it is currently not being used for such a purpose.
This patch simply removes it instead.
This fixes -Wunused-but-set-variable reported at e.g:
http://fate.ffmpeg.org/log.cgi?time=20150919194249=compile=x86_64-darwin-gcc-4.9.

Signed-off-by: Ganesh Ajjanagadde 
---
 libavcodec/videotoolbox.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
index b78238a..ca44491 100644
--- a/libavcodec/videotoolbox.c
+++ b/libavcodec/videotoolbox.c
@@ -501,7 +501,6 @@ static int videotoolbox_default_init(AVCodecContext *avctx)
 VTDecompressionOutputCallbackRecord decoder_cb;
 CFDictionaryRef decoder_spec;
 CFDictionaryRef buf_attr;
-int32_t pix_fmt;
 
 if (!videotoolbox) {
 av_log(avctx, AV_LOG_ERROR, "hwaccel context is not set\n");
@@ -528,8 +527,6 @@ static int videotoolbox_default_init(AVCodecContext *avctx)
 break;
 }
 
-pix_fmt = videotoolbox->cv_pix_fmt_type;
-
 decoder_spec = 
videotoolbox_decoder_config_create(videotoolbox->cm_codec_type, avctx);
 
 videotoolbox->cm_fmt_desc = 
videotoolbox_format_desc_create(videotoolbox->cm_codec_type,
-- 
2.5.2

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

Re: [FFmpeg-devel] [PATCH] avcodec/videotoolbox: fix -Wunused-but-set-variable

[Ganesh Ajjanagadde]

On Sat, Sep 19, 2015 at 5:33 PM, Hendrik Leppkes  wrote:
> On Sat, Sep 19, 2015 at 9:58 PM, Ganesh Ajjanagadde
>  wrote:
>> pix_fmt was declared presumably to shorten the argument passed to the 
>> function.
>> However, it is currently not being used for such a purpose.
>> This patch makes it used for that purpose.
>> This fixes -Wunused-but-set-variable reported at e.g:
>> http://fate.ffmpeg.org/log.cgi?time=20150919194249=compile=x86_64-darwin-gcc-4.9.
>>
>> Signed-off-by: Ganesh Ajjanagadde 
>> ---
>>  libavcodec/videotoolbox.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
>> index b78238a..e35eb2d 100644
>> --- a/libavcodec/videotoolbox.c
>> +++ b/libavcodec/videotoolbox.c
>> @@ -546,7 +546,7 @@ static int videotoolbox_default_init(AVCodecContext 
>> *avctx)
>>
>>  buf_attr = videotoolbox_buffer_attributes_create(avctx->width,
>>   avctx->height,
>> - 
>> videotoolbox->cv_pix_fmt_type);
>> + pix_fmt);
>>
>>  decoder_cb.decompressionOutputCallback = videotoolbox_decoder_callback;
>>  decoder_cb.decompressionOutputRefCon   = avctx;
>
> If the variable is entirely unused right now, then it should just be
> removed instead of finding some  use for it that'll just get optimized
> away anyway.

ok; patchv2 created.

> ___
> 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] checkasm: add jpeg2000dsp rct_int tests

[Henrik Gramner]

On Fri, Sep 18, 2015 at 4:55 AM, James Almer  wrote:
> Signed-off-by: James Almer 
> ---
>  tests/checkasm/Makefile  |  1 +
>  tests/checkasm/checkasm.c|  3 ++
>  tests/checkasm/checkasm.h|  1 +
>  tests/checkasm/jpeg2000dsp.c | 71 
> 
>  4 files changed, 76 insertions(+)
>  create mode 100644 tests/checkasm/jpeg2000dsp.c

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

[FFmpeg-devel] [PATCH] avcodec/dvenc: silence -Wdiscarded-qualifiers

[Ganesh Ajjanagadde]

s->frame is non-const, so this casts them explicitly.
This suppresses -Wdiscarded-qualifiers seen in e.g
http://fate.ffmpeg.org/log.cgi?time=20150919100330=compile=x86_64-archlinux-gcc-enableshared.

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

diff --git a/libavcodec/dvenc.c b/libavcodec/dvenc.c
index 5de12cc..0f4daa1 100644
--- a/libavcodec/dvenc.c
+++ b/libavcodec/dvenc.c
@@ -721,7 +721,7 @@ static int dvvideo_encode_frame(AVCodecContext *c, AVPacket 
*pkt,
 return ret;
 
 c->pix_fmt= s->sys->pix_fmt;
-s->frame  = frame;
+s->frame  = (AVFrame *) frame;
 #if FF_API_CODED_FRAME
 FF_DISABLE_DEPRECATION_WARNINGS
 c->coded_frame->key_frame = 1;
-- 
2.5.2

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

Re: [FFmpeg-devel] [PATCH 2/2] doc/developer: s/ffmpeg-cvslog/ffmpeg-devel

[Ganesh Ajjanagadde]

On Sat, Sep 19, 2015 at 9:09 PM, James Almer  wrote:
> On 9/19/2015 10:03 PM, Ganesh Ajjanagadde wrote:
>> On Sat, Sep 19, 2015 at 8:30 PM, James Almer  wrote:
>>> On 9/19/2015 8:54 PM, Ganesh Ajjanagadde wrote:
 On Sat, Sep 19, 2015 at 7:48 PM, James Almer  wrote:
> On 9/19/2015 8:36 PM, Ganesh Ajjanagadde wrote:
>> ffmpeg has not been using cvs for a long time.
>>
>> Signed-off-by: Ganesh Ajjanagadde 
>> ---
>>  doc/developer.texi | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/doc/developer.texi b/doc/developer.texi
>> index 7324629..923ee69 100644
>> --- a/doc/developer.texi
>> +++ b/doc/developer.texi
>> @@ -349,7 +349,7 @@ timeframe (12h for build failures and security 
>> fixes, 3 days small changes,
>>  Also note, the maintainer can simply ask for more time to review!
>>
>>  @item
>> -Subscribe to the ffmpeg-cvslog mailing list. The diffs of all commits
>> +Subscribe to the ffmpeg-devel mailing list. The diffs of all commits
>>  are sent there and reviewed by all the other developers. Bugs and 
>> possible
>>  improvements or general questions regarding commits are discussed 
>> there. We
>>  expect you to react if problems with your code are uncovered.
>
> https://ffmpeg.org/pipermail/ffmpeg-cvslog/
>
> ffmpeg-cvslog has a different purpose than ffmpeg-devel.

 Isn't the same information available at
 https://ffmpeg.org/pipermail/ffmpeg-devel/?
 Can you tell me what the difference between the two is?
>>>
>>> If you check and compare the emails between the two list, you'll notice 
>>> that one
>>> is a list where automated emails are sent every time something is committed 
>>> to
>>> the git repo, and the other is a list where patches are sent for review.
>>
>> Well, in that case the doc is broken in a worse way. "Bugs and
>> possilbe improvements or general questions regarding commits are
>> discussed there" does not even apply to ffmpeg-cvslog, it really
>
> Discussion about commits (not patches) can and does happen there, even though 
> in
> general it's always CCd to ffmpeg-devel where people are more likely to see 
> it.
> ffmpeg-devel has its own section on this file, mentioning it's meant for 
> patches
> and discussions about development.

Thanks for clarifying. I still think it is terribly confusing; the
very fact that we are discussing this right now suggests that it needs
rework. I will let this sink in and may come up with an improvement
sometime. At the moment, consider the patch dropped.

>
>> applies to ffmpeg-devel. In that case this patch is still an
>> improvement over the current situation. ffmpeg-cvslog is pretty much
>> useless for a dev on daily basis, since he/she can't see the
>> discussion. If a dev is subscribing to something, ffmpeg-devel gives
>> far more useful information and IMHO is the preferred mailing list.
>>
>> However, perhaps the commit message needs rewording due to my 
>> misunderstanding.
>
>
>
> ___
> 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] avcodec/videotoolbox: fix -Wunused-but-set-variable

[Ganesh Ajjanagadde]

pix_fmt was declared presumably to shorten the argument passed to the function.
However, it is currently not being used for such a purpose.
This patch makes it used for that purpose.
This fixes -Wunused-but-set-variable reported at e.g:
http://fate.ffmpeg.org/log.cgi?time=20150919194249=compile=x86_64-darwin-gcc-4.9.

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

diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
index b78238a..e35eb2d 100644
--- a/libavcodec/videotoolbox.c
+++ b/libavcodec/videotoolbox.c
@@ -546,7 +546,7 @@ static int videotoolbox_default_init(AVCodecContext *avctx)
 
 buf_attr = videotoolbox_buffer_attributes_create(avctx->width,
  avctx->height,
- 
videotoolbox->cv_pix_fmt_type);
+ pix_fmt);
 
 decoder_cb.decompressionOutputCallback = videotoolbox_decoder_callback;
 decoder_cb.decompressionOutputRefCon   = avctx;
-- 
2.5.2

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

Re: [FFmpeg-devel] [PATCHv2] avformat/format: silence -Wdiscarded-qualifiers

[Michael Niedermayer]

On Sat, Sep 19, 2015 at 05:37:14PM -0400, Ganesh Ajjanagadde wrote:
> lpd.buf is non-const and discards the const qualifier of zerobuffer.
> This fixes -Wdiscarded-qualifiers observed with a variety of compilers, 
> including GCC 5.2.
> Note that this does not change the type of zerobuffer, and merely makes the 
> intent explicit.
> 
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavformat/format.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

applied

thanks

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

I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire


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

[FFmpeg-devel] [PATCH] avcodec/apedec: fix undefined left shifts of negative numbers

[Ganesh Ajjanagadde]

This fixes -Wshift-negative-value reported with clang 3.7+, e.g
http://fate.ffmpeg.org/log.cgi?time=20150919172459=compile=x86_64-darwin-clang-polly-notiling-3.7.
Note that the patch crucially depends on int >= 32 bits,
an assumption made in many places in the codebase.

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

diff --git a/libavcodec/apedec.c b/libavcodec/apedec.c
index 5536e0f..7b34d26 100644
--- a/libavcodec/apedec.c
+++ b/libavcodec/apedec.c
@@ -1281,7 +1281,7 @@ static void do_apply_filter(APEContext *ctx, int version, 
APEFilter *f,
 /* Update the adaption coefficients */
 absres = FFABS(res);
 if (absres)
-*f->adaptcoeffs = ((res & (-1<<31)) ^ (-1<<30)) >>
+*f->adaptcoeffs = ((res & (-(1<<31))) ^ (-(1<<30))) >>
   (25 + (absres <= f->avg*3) + (absres <= 
f->avg*4/3));
 else
 *f->adaptcoeffs = 0;
-- 
2.5.2

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

[FFmpeg-devel] [PATCH] avfilter: add tremolo filter

[Kyle Swanson]

Signed-off-by: Kyle Swanson 
---
 doc/filters.texi |  19 ++
 libavfilter/Makefile |   1 +
 libavfilter/af_tremolo.c | 173 +++
 libavfilter/allfilters.c |   1 +
 libavfilter/version.h|   2 +-
 5 files changed, 195 insertions(+), 1 deletion(-)
 create mode 100644 libavfilter/af_tremolo.c

diff --git a/doc/filters.texi b/doc/filters.texi
index 88cb3ce..5bbbaf0 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -2568,6 +2568,25 @@ slope
 Determine how steep is the filter's shelf transition.
 @end table
 
+@section tremolo
+
+Sinusoidal amplitude modulation.
+
+The filter accepts the following options:
+
+@table @option
+@item f
+Modulation frequency in Hertz. Modulation frequencies in the subharmonic range
+(20 Hz or lower) will result in a tremolo effect.
+This filter may also be used as a ring modulator by specifying
+a modulation frequency higher than 20 Hz.
+Range is 0.1 - 2.0. Default value is 5.0 Hz.
+
+@item d
+Depth of modulation as a percentage. Range is 0.0 - 1.0.
+Default value is 0.5.
+@end table
+
 @section volume
 
 Adjust the input audio volume.
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 05effd6..45fca3b 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -82,6 +82,7 @@ OBJS-$(CONFIG_SILENCEDETECT_FILTER)  += 
af_silencedetect.o
 OBJS-$(CONFIG_SILENCEREMOVE_FILTER)  += af_silenceremove.o
 OBJS-$(CONFIG_STEREOTOOLS_FILTER)+= af_stereotools.o
 OBJS-$(CONFIG_STEREOWIDEN_FILTER)+= af_stereowiden.o
+OBJS-$(CONFIG_TREMOLO_FILTER)+= af_tremolo.o 
generate_wave_table.o
 OBJS-$(CONFIG_TREBLE_FILTER) += af_biquads.o
 OBJS-$(CONFIG_VOLUME_FILTER) += af_volume.o
 OBJS-$(CONFIG_VOLUMEDETECT_FILTER)   += af_volumedetect.o
diff --git a/libavfilter/af_tremolo.c b/libavfilter/af_tremolo.c
new file mode 100644
index 000..7896127
--- /dev/null
+++ b/libavfilter/af_tremolo.c
@@ -0,0 +1,173 @@
+/*
+ * Tremolo
+ * Copyright (c) 2015 Kyle Swanson . Some rights reserved.
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+/**
+ * @file
+ * Tremolo
+ */
+
+#include "libavutil/opt.h"
+#include "avfilter.h"
+#include "internal.h"
+#include "audio.h"
+#include "generate_wave_table.h"
+
+typedef struct TremoloContext {
+const AVClass *class;
+double freq;
+double depth;
+double *wave_table;
+int wave_table_index;
+int sample_rate;
+} TremoloContext;
+
+#define OFFSET(x) offsetof(TremoloContext, x)
+#define FLAGS AV_OPT_FLAG_AUDIO_PARAM|AV_OPT_FLAG_FILTERING_PARAM
+
+static const AVOption tremolo_options[] = {
+{ "f", "set frequency in hertz",OFFSET(freq),AV_OPT_TYPE_DOUBLE,   
{.dbl = 5.0},   0.1,   2.0, FLAGS },
+{ "d", "set depth as percentage",   OFFSET(depth),   AV_OPT_TYPE_DOUBLE,   
{.dbl = 0.5},   0.0,   1.0, FLAGS },
+{ NULL }
+};
+
+AVFILTER_DEFINE_CLASS(tremolo);
+
+static float trem_env(AVFilterContext *ctx)
+{
+TremoloContext *s = ctx->priv;
+float env = s->wave_table[s->wave_table_index];
+s->wave_table_index++;
+if (s->wave_table_index >= s->sample_rate / s->freq)
+s->wave_table_index = 0;
+return 1.0 - (s->depth * env);
+}
+
+static int filter_frame(AVFilterLink *inlink, AVFrame *in)
+{
+AVFilterContext *ctx = inlink->dst;
+AVFilterLink *outlink = ctx->outputs[0];
+AVFrame *out;
+
+if (av_frame_is_writable(in)) {
+out = in;
+} else {
+out = ff_get_audio_buffer(inlink, in->nb_samples);
+if (!out) {
+av_frame_free();
+return AVERROR(ENOMEM);
+}
+av_frame_copy_props(out, in);
+}
+
+int channels = inlink->channels;
+int nb_samples = in->nb_samples;
+double *dst = (double *)out->data[0];
+int n, c;
+
+for (n = 0; n < nb_samples; n++) {
+float env = trem_env(ctx);
+for (c = 0; c < channels; c++) {
+dst[c] *= env;
+}
+dst += channels;
+}
+
+if (in != out)
+av_frame_free();
+
+return ff_filter_frame(outlink, out);
+}
+
+static int query_formats(AVFilterContext *ctx)
+{
+AVFilterFormats *formats;
+

Re: [FFmpeg-devel] [PATCHv2] configure: add -D_DEFAULT_SOURCE to silence -Wcpp

[Hendrik Leppkes]

On Sat, Sep 19, 2015 at 6:07 PM, Ganesh Ajjanagadde  wrote:
> On Thu, Sep 17, 2015 at 6:45 AM, Ganesh Ajjanagadde  wrote:
>> On Thu, Sep 17, 2015 at 4:54 AM, Clément Bœsch  wrote:
>>> On Wed, Sep 16, 2015 at 06:55:39PM -0400, Ganesh Ajjanagadde wrote:
 Glibc 2.20 onwards generates a deprecation warning for usage of 
 _BSD_SOURCE and _SVID_SOURCE.
 The solution from man feature_test_macros is to define both 
 _DEFAULT_SOURCE and the old macros.
 This change is done in configure while testing for Glibc. Doing it in 
 source code
 would require __UCLIBC__ checks, etc since uclibc also defines __GLIBC__ 
 and __GLIBC_MINOR__,
 so placing it in configure avoids the repeated checks.

 Signed-off-by: Ganesh Ajjanagadde 
 ---
  configure| 6 ++
  libavformat/os_support.c | 1 -
  2 files changed, 6 insertions(+), 1 deletion(-)

 diff --git a/configure b/configure
 index cd6f629..0cd0a6c 100755
 --- a/configure
 +++ b/configure
 @@ -4520,6 +4520,12 @@ probe_libc(){
  elif check_${pfx}cpp_condition features.h "defined __GLIBC__"; then
  eval ${pfx}libc_type=glibc
  add_${pfx}cppflags -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600
 +# define _DEFAULT_SOURCE for glibc 2.20 onwards to silence 
 deprecation
 +# warnings for _BSD_SOURCE and _SVID_SOURCE.
 +if check_${pfx}cpp_condition features.h "(__GLIBC__ == 2 && 
 __GLIBC_MINOR__ >= 20) \
 +|| (__GLIBC__ > 2)"; then
 +add_${pfx}cppflags -D_DEFAULT_SOURCE
 +fi
>>>
>>> Is this adding _DEFAULT_SOURCE to every compiled file while it was scope
>>> to a standalone source file before?
>>
>> Don't know exactly what you mean, but try e.g strings on any of these
>> objects. There is no "DEFAULT_SOURCE", "BSD_SOURCE", or any such thing
>> suggesting they are optimized out. Furthermore, a du on the libav*
>> does not reveal any increase in size.
>
> ping

I agree with Clément, adding a global define to every single file
while it was contained to a handful of select files before seems less
than ideal.

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

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/vda_h264: use multichar literal portably

[Hendrik Leppkes]

On Sat, Sep 19, 2015 at 12:35 AM, Michael Niedermayer  wrote:
> On Fri, Sep 18, 2015 at 06:16:18PM -0400, Ganesh Ajjanagadde wrote:
>> Multichar literals are implementation defined, and thus trigger -Wmultichar:
>> http://fate.ffmpeg.org/log.cgi?time=20150918202532=compile=x86_64-darwin-gcc-5.
>> http://www.zipcon.net/~swhite/docs/computers/languages/c_multi-char_const.html
>> gives a good summary of how to deal with them; in particular this patch
>> results in behavior identical to that generated by GCC (which I assume is 
>> correct this case).
>>
>> Signed-off-by: Ganesh Ajjanagadde 
>> ---
>>  libavcodec/vda_h264.c | 4 +++-
>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/libavcodec/vda_h264.c b/libavcodec/vda_h264.c
>> index 8c526c0..3279afa 100644
>> --- a/libavcodec/vda_h264.c
>> +++ b/libavcodec/vda_h264.c
>> @@ -339,7 +339,9 @@ int ff_vda_default_init(AVCodecContext *avctx)
>>  CFMutableDictionaryRef buffer_attributes;
>>  CFMutableDictionaryRef io_surface_properties;
>>  CFNumberRef cv_pix_fmt;
>> -int32_t fmt = 'avc1', pix_fmt = vda_ctx->cv_pix_fmt_type;
>> +#define LE_CHR(a,b,c,d) ( ((a)<<24) | ((b)<<16) | ((c)<<8) | (d) )
>> +int32_t fmt = LE_CHR( 'a', 'v', 'c', '1');
>
> please use AV_RB32("avc1")
> its simpler and used elsewhere
>

IMHO even better is MKBETAG( 'a', 'v', 'c', '1')
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] hevc: properly handle no_rasl_output_flag when removing pictures from the DPB

[Hendrik Leppkes]

Fixes ticket #4185.

Reviewed-By: Mickael Raulet 
---
 libavcodec/hevc.c  | 5 +
 libavcodec/hevc.h  | 1 +
 libavcodec/hevc_refs.c | 2 +-
 3 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/libavcodec/hevc.c b/libavcodec/hevc.c
index 8d4db22..e45f4a4 100644
--- a/libavcodec/hevc.c
+++ b/libavcodec/hevc.c
@@ -809,6 +809,8 @@ static int hls_slice_header(HEVCContext *s)
 s->HEVClc->tu.cu_qp_offset_cb = 0;
 s->HEVClc->tu.cu_qp_offset_cr = 0;
 
+s->no_rasl_output_flag = IS_IDR(s) || IS_BLA(s) || (s->nal_unit_type == 
NAL_CRA_NUT && s->last_eos);
+
 return 0;
 }
 
@@ -3135,6 +3137,7 @@ static int hevc_update_thread_context(AVCodecContext *dst,
 s->pocTid0= s0->pocTid0;
 s->max_ra = s0->max_ra;
 s->eos= s0->eos;
+s->no_rasl_output_flag = s0->no_rasl_output_flag;
 
 s->is_nalff= s0->is_nalff;
 s->nal_length_size = s0->nal_length_size;
@@ -3239,6 +3242,7 @@ static av_cold int hevc_decode_init(AVCodecContext *avctx)
 
 s->enable_parallel_tiles = 0;
 s->picture_struct = 0;
+s->eos = 1;
 
 if(avctx->active_thread_type & FF_THREAD_SLICE)
 s->threads_number = avctx->thread_count;
@@ -3280,6 +3284,7 @@ static void hevc_decode_flush(AVCodecContext *avctx)
 HEVCContext *s = avctx->priv_data;
 ff_hevc_flush_dpb(s);
 s->max_ra = INT_MAX;
+s->eos = 1;
 }
 
 #define OFFSET(x) offsetof(HEVCContext, x)
diff --git a/libavcodec/hevc.h b/libavcodec/hevc.h
index 32d6da9..66b9a2f 100644
--- a/libavcodec/hevc.h
+++ b/libavcodec/hevc.h
@@ -866,6 +866,7 @@ typedef struct HEVCContext {
 int bs_height;
 
 int is_decoded;
+int no_rasl_output_flag;
 
 HEVCPredContext hpc;
 HEVCDSPContext hevcdsp;
diff --git a/libavcodec/hevc_refs.c b/libavcodec/hevc_refs.c
index e85ce89..611ad45 100644
--- a/libavcodec/hevc_refs.c
+++ b/libavcodec/hevc_refs.c
@@ -174,7 +174,7 @@ int ff_hevc_output_frame(HEVCContext *s, AVFrame *out, int 
flush)
 int min_poc   = INT_MAX;
 int i, min_idx, ret;
 
-if (s->sh.no_output_of_prior_pics_flag == 1) {
+if (s->sh.no_output_of_prior_pics_flag == 1 && s->no_rasl_output_flag 
== 1) {
 for (i = 0; i < FF_ARRAY_ELEMS(s->DPB); i++) {
 HEVCFrame *frame = >DPB[i];
 if (!(frame->flags & HEVC_FRAME_FLAG_BUMPING) && frame->poc != 
s->poc &&
-- 
2.5.1.windows.1

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

Re: [FFmpeg-devel] [PATCH] avcodec/internal: silence -Wempty-body on clang

[Michael Niedermayer]

On Sat, Sep 19, 2015 at 12:55:18AM -0400, Ganesh Ajjanagadde wrote:
> This silences a -Wempty-body warning on clang 3.7+, e.g
> http://fate.ffmpeg.org/log.cgi?time=20150918181527=compile=x86_64-darwin-clang-polly-vectorize-stripmine-3.7.
> 
> Signed-off-by: Ganesh Ajjanagadde 

applied

thanks

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

There will always be a question for which you do not know the correct answer.


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

Re: [FFmpeg-devel] [PATCH] hevc: properly handle no_rasl_output_flag when removing pictures from the DPB

[Carl Eugen Hoyos]

Hendrik Leppkes  gmail.com> writes:

> Fixes ticket #4185.
> 
> Reviewed-By: Mickael Raulet  insa-rennes.fr>

If he reviewed it (that's also how I remember it) 
please push!

Thank you for looking into this issue, Carl Eugen

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

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/vda_h264: use multichar literal portably

[Ganesh Ajjanagadde]

On Sat, Sep 19, 2015 at 2:27 AM, Hendrik Leppkes  wrote:
> On Sat, Sep 19, 2015 at 12:35 AM, Michael Niedermayer  
> wrote:
>> On Fri, Sep 18, 2015 at 06:16:18PM -0400, Ganesh Ajjanagadde wrote:
>>> Multichar literals are implementation defined, and thus trigger -Wmultichar:
>>> http://fate.ffmpeg.org/log.cgi?time=20150918202532=compile=x86_64-darwin-gcc-5.
>>> http://www.zipcon.net/~swhite/docs/computers/languages/c_multi-char_const.html
>>> gives a good summary of how to deal with them; in particular this patch
>>> results in behavior identical to that generated by GCC (which I assume is 
>>> correct this case).
>>>
>>> Signed-off-by: Ganesh Ajjanagadde 
>>> ---
>>>  libavcodec/vda_h264.c | 4 +++-
>>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/libavcodec/vda_h264.c b/libavcodec/vda_h264.c
>>> index 8c526c0..3279afa 100644
>>> --- a/libavcodec/vda_h264.c
>>> +++ b/libavcodec/vda_h264.c
>>> @@ -339,7 +339,9 @@ int ff_vda_default_init(AVCodecContext *avctx)
>>>  CFMutableDictionaryRef buffer_attributes;
>>>  CFMutableDictionaryRef io_surface_properties;
>>>  CFNumberRef cv_pix_fmt;
>>> -int32_t fmt = 'avc1', pix_fmt = vda_ctx->cv_pix_fmt_type;
>>> +#define LE_CHR(a,b,c,d) ( ((a)<<24) | ((b)<<16) | ((c)<<8) | (d) )
>>> +int32_t fmt = LE_CHR( 'a', 'v', 'c', '1');
>>
>> please use AV_RB32("avc1")
>> its simpler and used elsewhere
>>
>
> IMHO even better is MKBETAG( 'a', 'v', 'c', '1')

I do not know about the technical merits of this, but there is
certainly one drawback of MKBETAG as compared to AV_RB32: MKBETAG
can't be grepped as easily for (one can't just grep avc1).

> ___
> 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/imgconvert: Support non-planar colorspaces while padding

[Przemysław Sobala]

W dniu 19.09.2015 o 04:14, Michael Niedermayer pisze:

On Fri, Sep 18, 2015 at 04:31:16PM +0200, Przemysław Sobala wrote:

---
  libavcodec/imgconvert.c | 99 -
  1 file changed, 65 insertions(+), 34 deletions(-)

diff --git a/libavcodec/imgconvert.c b/libavcodec/imgconvert.c
index dc67560..a523bd5 100644
--- a/libavcodec/imgconvert.c
+++ b/libavcodec/imgconvert.c
@@ -236,54 +236,85 @@ int av_picture_pad(AVPicture *dst, const AVPicture *src, 
int height, int width,
  int x_shift;
  int yheight;
  int i, y;
+int max_step[4];

-if (pix_fmt < 0 || pix_fmt >= AV_PIX_FMT_NB ||
-!is_yuv_planar(desc)) return -1;
+if (pix_fmt < 0 || pix_fmt >= AV_PIX_FMT_NB)
+return -1;

-for (i = 0; i < 3; i++) {
-x_shift = i ? desc->log2_chroma_w : 0;
-y_shift = i ? desc->log2_chroma_h : 0;
+if (is_yuv_planar(desc)) {
+for (i = 0; i < 3; i++) {
+x_shift = i ? desc->log2_chroma_w : 0;
+y_shift = i ? desc->log2_chroma_h : 0;

-if (padtop || padleft) {
-memset(dst->data[i], color[i],
-dst->linesize[i] * (padtop >> y_shift) + (padleft >> x_shift));
-}
+if (padtop || padleft) {
+memset(dst->data[i], color[i],
+dst->linesize[i] * (padtop >> y_shift) + (padleft >> 
x_shift));
+}

-if (padleft || padright) {
-optr = dst->data[i] + dst->linesize[i] * (padtop >> y_shift) +
-(dst->linesize[i] - (padright >> x_shift));
-yheight = (height - 1 - (padtop + padbottom)) >> y_shift;
-for (y = 0; y < yheight; y++) {
-memset(optr, color[i], (padleft + padright) >> x_shift);
-optr += dst->linesize[i];
+if (padleft || padright) {
+optr = dst->data[i] + dst->linesize[i] * (padtop >> y_shift) +
+(dst->linesize[i] - (padright >> x_shift));
+yheight = (height - 1 - (padtop + padbottom)) >> y_shift;
+for (y = 0; y < yheight; y++) {
+memset(optr, color[i], (padleft + padright) >> x_shift);
+optr += dst->linesize[i];
+}
  }
+
+if (src) { /* first line */
+uint8_t *iptr = src->data[i];
+optr = dst->data[i] + dst->linesize[i] * (padtop >> y_shift) +
+(padleft >> x_shift);
+memcpy(optr, iptr, (width - padleft - padright) >> x_shift);
+iptr += src->linesize[i];
+optr = dst->data[i] + dst->linesize[i] * (padtop >> y_shift) +
+(dst->linesize[i] - (padright >> x_shift));
+yheight = (height - 1 - (padtop + padbottom)) >> y_shift;
+for (y = 0; y < yheight; y++) {
+memset(optr, color[i], (padleft + padright) >> x_shift);
+memcpy(optr + ((padleft + padright) >> x_shift), iptr,
+   (width - padleft - padright) >> x_shift);
+iptr += src->linesize[i];
+optr += dst->linesize[i];
+}
+}
+
+if (padbottom || padright) {
+optr = dst->data[i] + dst->linesize[i] *
+((height - padbottom) >> y_shift) - (padright >> x_shift);
+memset(optr, color[i],dst->linesize[i] *
+(padbottom >> y_shift) + (padright >> x_shift));
+}
+}


this only reindents the code, moving the reindention to a seperate
patch would make it more readable


I've rearranged the code a bit.


+} else {



+if (src)
+return -1;


why ?



Because it's not yet implemented.
I've added a comment.
New patch attached.

--
Regards
Przemysław Sobala


Główne Spółki Grupy Wirtualna Polska:

Wirtualna Polska Holding Spółka Akcyjna z siedzibą w Warszawie, ul. Jutrzenki 
137A, 02-231 Warszawa, wpisana do Krajowego Rejestru Sądowego - Rejestru 
Przedsiębiorców prowadzonego przez Sąd Rejonowy dla m.st. Warszawy w Warszawie 
pod nr KRS: 407130, kapitał zakładowy: 1 245 651,90 zł (w całości 
wpłacony), Numer Identyfikacji Podatkowej (NIP): 521-31-11-513

Grupa Wirtualna Polska Spółka z ograniczoną odpowiedzialnością z siedzibą w 
Warszawie, ul. Jutrzenki 137A, 02-231 Warszawa, wpisana do Krajowego Rejestru 
Sądowego - Rejestru Przedsiębiorców prowadzonego przez Sąd Rejonowy dla m.st. 
Warszawy w Warszawie pod nr KRS: 373814, kapitał zakładowy: 317 957 800,00 
zł, Numer Identyfikacji Podatkowej (NIP): 527-26-45-593

WP Shopping Spółka z ograniczoną odpowiedzialnością z siedzibą w Gdańsku, ul. 
Romualda Traugutta 115 C, 80-226 Gdańsk, wpisana do Krajowego Rejestru Sądowego 
- Rejestru Przedsiębiorców prowadzonego przez Sąd Rejonowy Gdańsk - Północ w 
Gdańsku pod nr KRS: 546914, kapitał zakładowy: 170.000,00 złotych (w 

Re: [FFmpeg-devel] [PATCH] hevc: properly handle no_rasl_output_flag when removing pictures from the DPB

[Michael Niedermayer]

On Sat, Sep 19, 2015 at 11:46:09AM +0200, Hendrik Leppkes wrote:
> Fixes ticket #4185.
> 
> Reviewed-By: Mickael Raulet 
> ---
>  libavcodec/hevc.c  | 5 +
>  libavcodec/hevc.h  | 1 +
>  libavcodec/hevc_refs.c | 2 +-
>  3 files changed, 7 insertions(+), 1 deletion(-)

LGTM

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

Democracy is the form of government in which you can choose your dictator


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

Re: [FFmpeg-devel] [PATCH] avcodec/g723_1: fix a undefined left shift of negative number

[Michael Niedermayer]

On Sat, Sep 19, 2015 at 12:57:24AM -0400, Ganesh Ajjanagadde wrote:
> This fixes a -Wshift-negative-value reported with clang 3.7+, e.g
> http://fate.ffmpeg.org/log.cgi?time=20150918181527=compile=x86_64-darwin-clang-polly-vectorize-stripmine-3.7.
> 
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavcodec/g723_1.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

applied

thanks

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

The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates


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

[FFmpeg-devel] [PATCH] avcodec/x86/cavsdsp: silence -Wunuse-variable on --disable-mmx

[Ganesh Ajjanagadde]

This silences -Wunused-variable when compiled with --disable-mmx, e.g
http://fate.ffmpeg.org/log.cgi?time=20150919094617=compile=x86_64-archlinux-gcc-disable-mmx.
The alternative of header guards will make it far too ugly.

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

diff --git a/libavcodec/x86/cavsdsp.c b/libavcodec/x86/cavsdsp.c
index b571163..4b20e65 100644
--- a/libavcodec/x86/cavsdsp.c
+++ b/libavcodec/x86/cavsdsp.c
@@ -563,7 +563,7 @@ static av_cold void cavsdsp_init_3dnow(CAVSDSPContext *c,
 
 av_cold void ff_cavsdsp_init_x86(CAVSDSPContext *c, AVCodecContext *avctx)
 {
-int cpu_flags = av_get_cpu_flags();
+av_unused int cpu_flags = av_get_cpu_flags();
 
 cavsdsp_init_mmx(c, avctx);
 #if HAVE_AMD3DNOW_INLINE
-- 
2.5.2

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

Re: [FFmpeg-devel] [PATCH] avcodec/x86/cavsdsp: silence -Wunuse-variable on --disable-mmx

[Ganesh Ajjanagadde]

On Sat, Sep 19, 2015 at 10:34 AM, Ganesh Ajjanagadde
 wrote:
> This silences -Wunused-variable when compiled with --disable-mmx, e.g
> http://fate.ffmpeg.org/log.cgi?time=20150919094617=compile=x86_64-archlinux-gcc-disable-mmx.
> The alternative of header guards will make it far too ugly.
>
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavcodec/x86/cavsdsp.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/x86/cavsdsp.c b/libavcodec/x86/cavsdsp.c
> index b571163..4b20e65 100644
> --- a/libavcodec/x86/cavsdsp.c
> +++ b/libavcodec/x86/cavsdsp.c
> @@ -563,7 +563,7 @@ static av_cold void cavsdsp_init_3dnow(CAVSDSPContext *c,
>
>  av_cold void ff_cavsdsp_init_x86(CAVSDSPContext *c, AVCodecContext *avctx)
>  {
> -int cpu_flags = av_get_cpu_flags();
> +av_unused int cpu_flags = av_get_cpu_flags();
>
>  cavsdsp_init_mmx(c, avctx);
>  #if HAVE_AMD3DNOW_INLINE
> --
> 2.5.2
>

commit message typo: -Wunuse-> -Wunused.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCHv2] avcodec/ac3enc: use long long after switch to 64 bit bitrate

[Ganesh Ajjanagadde]

Commit 7404f3bdb switched bitrate to 64 bits.
This triggers -Wabsolute-value on clang, e.g
http://fate.ffmpeg.org/log.cgi?time=20150917122742=compile=x86_64-darwin-clang-3.7-O3.
Therefore, usage of abs is changed to llabs, which is available on all of the 
platforms.
Unfortunately, LLONG_MAX is not always available, so INT64_MAX is used instead.

Signed-off-by: Ganesh Ajjanagadde 
---
 libavcodec/ac3enc.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/libavcodec/ac3enc.c b/libavcodec/ac3enc.c
index 0d8a678..35e721a 100644
--- a/libavcodec/ac3enc.c
+++ b/libavcodec/ac3enc.c
@@ -2153,8 +2153,9 @@ static av_cold int validate_options(AC3EncodeContext *s)
 
 /* validate bit rate */
 if (s->eac3) {
-int max_br, min_br, wpf, min_br_dist, min_br_code;
+int max_br, min_br, wpf, min_br_code;
 int num_blks_code, num_blocks, frame_samples;
+long long min_br_dist;
 
 /* calculate min/max bitrate */
 /* TODO: More testing with 3 and 2 blocks. All E-AC-3 samples I've
@@ -2184,9 +2185,9 @@ static av_cold int validate_options(AC3EncodeContext *s)
this is needed for lookup tables for bandwidth and coupling
parameter selection */
 min_br_code = -1;
-min_br_dist = INT_MAX;
+min_br_dist = INT64_MAX;
 for (i = 0; i < 19; i++) {
-int br_dist = abs(ff_ac3_bitrate_tab[i] * 1000 - avctx->bit_rate);
+long long br_dist = llabs(ff_ac3_bitrate_tab[i] * 1000 - 
avctx->bit_rate);
 if (br_dist < min_br_dist) {
 min_br_dist = br_dist;
 min_br_code = i;
@@ -2199,10 +2200,11 @@ static av_cold int validate_options(AC3EncodeContext *s)
 wpf--;
 s->frame_size_min = 2 * wpf;
 } else {
-int best_br = 0, best_code = 0, best_diff = INT_MAX;
+int best_br = 0, best_code = 0;
+long long best_diff = INT64_MAX;
 for (i = 0; i < 19; i++) {
 int br   = (ff_ac3_bitrate_tab[i] >> s->bit_alloc.sr_shift) * 1000;
-int diff = abs(br - avctx->bit_rate);
+long long diff = llabs(br - avctx->bit_rate);
 if (diff < best_diff) {
 best_br   = br;
 best_code = i;
-- 
2.5.2

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

[FFmpeg-devel] [PATCH] cmdutils: silence unused warnings under --disable-swscale, --disable-swresample

[Ganesh Ajjanagadde]

This patch silences such warnings by placing initializations under a header 
guard,
see e.g
http://fate.ffmpeg.org/log.cgi?time=20150919095430=compile=x86_64-archlinux-gcc-disableswscale,
http://fate.ffmpeg.org/log.cgi?time=20150919095048=compile=x86_64-archlinux-gcc-disableswresample
for examples of such warnings.
It also has the benefit of placing library specific #defines next to each other.

Signed-off-by: Ganesh Ajjanagadde 
---
 cmdutils.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/cmdutils.c b/cmdutils.c
index b696008..38d6334 100644
--- a/cmdutils.c
+++ b/cmdutils.c
@@ -533,7 +533,12 @@ int opt_default(void *optctx, const char *opt, const char 
*arg)
 #if CONFIG_AVRESAMPLE
 const AVClass *rc = avresample_get_class();
 #endif
-const AVClass *sc, *swr_class;
+#if CONFIG_SWSCALE
+const AVClass *sc = sws_get_class();
+#endif
+#if CONFIG_SWRESAMPLE
+const AVClass *swr_class = swr_get_class();
+#endif
 
 if (!strcmp(opt, "debug") || !strcmp(opt, "fdebug"))
 av_log_set_level(AV_LOG_DEBUG);
@@ -557,7 +562,6 @@ int opt_default(void *optctx, const char *opt, const char 
*arg)
 consumed = 1;
 }
 #if CONFIG_SWSCALE
-sc = sws_get_class();
 if (!consumed && (o = opt_find(, opt, NULL, 0,
  AV_OPT_SEARCH_CHILDREN | AV_OPT_SEARCH_FAKE_OBJ))) {
 struct SwsContext *sws = sws_alloc_context();
@@ -579,7 +583,6 @@ int opt_default(void *optctx, const char *opt, const char 
*arg)
 }
 #endif
 #if CONFIG_SWRESAMPLE
-swr_class = swr_get_class();
 if (!consumed && (o=opt_find(_class, opt, NULL, 0,
 AV_OPT_SEARCH_CHILDREN | 
AV_OPT_SEARCH_FAKE_OBJ))) {
 struct SwrContext *swr = swr_alloc();
-- 
2.5.2

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

[FFmpeg-devel] [PATCH] avcodec/x86/mpegaudiodsp: silence -Wunused-variable on --disable-mmx

[Ganesh Ajjanagadde]

This silences -Wunused-variable when compiled with --disable-mmx, e.g
http://fate.ffmpeg.org/log.cgi?time=20150919094617=compile=x86_64-archlinux-gcc-disable-mmx.
The alternative of header guards will make it far too ugly.

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

diff --git a/libavcodec/x86/mpegaudiodsp.c b/libavcodec/x86/mpegaudiodsp.c
index 298dc2d..d969f1d 100644
--- a/libavcodec/x86/mpegaudiodsp.c
+++ b/libavcodec/x86/mpegaudiodsp.c
@@ -241,7 +241,7 @@ DECL_IMDCT_BLOCKS(avx,avx)
 
 av_cold void ff_mpadsp_init_x86(MPADSPContext *s)
 {
-int cpu_flags = av_get_cpu_flags();
+av_unused int cpu_flags = av_get_cpu_flags();
 
 int i, j;
 for (j = 0; j < 4; j++) {
-- 
2.5.2

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

Re: [FFmpeg-devel] policy on "necro-bumping" patches

[Ganesh Ajjanagadde]

On Wed, Sep 16, 2015 at 8:29 PM, Michael Niedermayer  wrote:
> On Tue, Sep 15, 2015 at 04:54:19PM +0200, Michael Niedermayer wrote:
>> On Tue, Sep 15, 2015 at 08:48:33AM -0400, Ganesh Ajjanagadde wrote:
>> > On Tue, Sep 15, 2015 at 6:54 AM, Ronald S. Bultje  
>> > wrote:
>> > > Hi Ganesh,
>> > >
>> > > On Mon, Sep 14, 2015 at 10:27 PM, Ganesh Ajjanagadde 
>> > > wrote:
>> > >
>> > >> Hi all,
>> > >>
>> > >> What is ffmpeg's policy on "necro-bumping" old patches? Or more
>> > >> precisely, what is the policy of requesting a patch to be merged where
>> > >> all objections raised have been addressed via discussion/updated
>> > >> patches, and which have not been merged in over 2 weeks due to unknown
>> > >> reasons?
>> > >>
>> > >> In particular, there are 2 patchsets I would like to get merged:
>> > >> 1. This I consider an important patch, simply because it solves a trac
>> > >> ticket labelled as "important": https://trac.ffmpeg.org/ticket/2964,
>> > >> which also contains links to the patches. A lot of discussion went on
>> > >> around it on the mailing lists, and it is supported strongly by
>> > >> Nicolas and me. Michael seemed initially hesitant but later became
>> > >> convinced of (at least one of the set's) utility, and one of the
>> > >> patches was applied. The only objection I recall was from Hendrik,
>> > >> which was addressed by Nicolas in a follow-up.
>> > >>
>> > >> 2. This I consider much more trivial, but in this case there are no
>> > >> remaining objections. However, I still consider it important enough
>> > >> for a request to re-examine, as I am doing here. The patchset is more
>> > >> recent, 
>> > >> https://ffmpeg.org/pipermail/ffmpeg-devel/2015-August/177794.html
>> > >> and 
>> > >> https://ffmpeg.org/pipermail/ffmpeg-devel/2015-September/178700.html.
>> > >
>> > >
>> > > Trivial patches can be merged after 24-48 hours if there's no objections
>> > > outstanding. For more elaborate patches, poke anyone for review if you 
>> > > feel
>> > > it would be helpful.
>> > >
>> > > In both cases, having push access yourself will hurry this along (i.e. 
>> > > you
>> > > really should get push access), but in this case I will push later today.
>> > > If you don't want push access, poke one of us on IRC to do the push for
>> > > you, or bump the original email with a "poke" or "ping".
>> >
>> > Thanks. Patches for 2) needs work, and I will be posting it soon.
>>
>>
>> > Patch for 1) should be ok (it was reviewed by Nicolas, and Michael
>> > seems ok with it like I mentioned).
>>
>> there where a few patches, iam not exactly sure which are left and
>> what effects they have
>
>> What i objected to and still object to is to cause the terminal to
>
> i withdraw my objection, ill leave it to others to decide which way is
> better. Some arguments in this thread have sort of changed my oppinion
> from prefering the heuristic to being undecided on what is better

Ping, any other opinions?

>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> I have often repented speaking, but never of holding my tongue.
> -- Xenocrates
>
> ___
> 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/ac3enc: use long long after switch to 64 bit bitrate

[Ganesh Ajjanagadde]

On Fri, Sep 18, 2015 at 5:52 PM, James Almer  wrote:
> On 9/18/2015 6:35 PM, Ganesh Ajjanagadde wrote:
>> On Fri, Sep 18, 2015 at 5:30 PM, James Almer  wrote:
>>> On 9/17/2015 9:46 AM, Ganesh Ajjanagadde wrote:
 Commit 7404f3bdb switched bitrate to 64 bits.
 This triggers -Wabsolute-value on clang, e.g
 http://fate.ffmpeg.org/log.cgi?time=20150917122742=compile=x86_64-darwin-clang-3.7-O3.
 Therefore, usage of abs is changed to llabs, which is available on all of 
 the platforms.
 Have not tested whether LLONG_MAX (C99 feature) is available on Microsoft 
 or not.
>>>
>>> Use int64_t and INT64_MAX instead.
>>
>> I can definitely do that, but am curious about this. The codebase
>> already uses long long (see e.g ffprobe), and morally llabs returns
>> long long; hence I use it. As for the INT64_MAX, I do not have a
>> current example to know whether it is safe on all platforms, but
>> again, the "clean" solution is LLONG_MAX due to the type of llabs.
>
> grepping INT64_MAX shows a lot of hits in the codebase, so it's safe to
> use. Also, int64_t is used in hundreds of files whereas long long is
> used in about seven.

So Microsoft, even in 2015 after countless opportunities to do c99
stuff correctly, and thousands of engineers on its payroll, can't add
the few lines of #defines etc to define LLONG_MAX:
https://msdn.microsoft.com/en-us/library/296az74e.aspx

I checked out msinttypes; it seems like it does not handle LLONG_MAX
either. I guess if and when someone patches msinttypes we can finally
have our desired "clean" code.

As for long long, it has been in use for over a month (at least) in
the codebase and has caused no breakage on fate. Since it is the
correct/clean way of doing thing, I will update patch replacing the
LLONG_MAX by INT64_MAX but keeping the long long unless there are
objections.

>
> C guarantees that long long is at least 64bits so int64_t should be ok
> for this patch, but in any case wait for someone else to comment before
> sending a 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

[FFmpeg-devel] [PATCH] avcodec/x86/rv40dsp_init: silence -Wunused-variable on --disable-mmx

[Ganesh Ajjanagadde]

This silences -Wunused-variable when compiled with --disable-mmx, e.g
http://fate.ffmpeg.org/log.cgi?time=20150919094617=compile=x86_64-archlinux-gcc-disable-mmx.
The alternative of header guards will make it far too ugly.

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

diff --git a/libavcodec/x86/rv40dsp_init.c b/libavcodec/x86/rv40dsp_init.c
index bbf9c78..12b85c9 100644
--- a/libavcodec/x86/rv40dsp_init.c
+++ b/libavcodec/x86/rv40dsp_init.c
@@ -214,7 +214,7 @@ DEFINE_FN(avg, 16, mmx)
 
 av_cold void ff_rv40dsp_init_x86(RV34DSPContext *c)
 {
-int cpu_flags = av_get_cpu_flags();
+av_unused int cpu_flags = av_get_cpu_flags();
 
 #if HAVE_MMX_INLINE
 if (INLINE_MMX(cpu_flags)) {
-- 
2.5.2

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

[FFmpeg-devel] [PATCH] avcodec/x86/mpegvideoenc: silence -Wunused-function on --disable-mmx

[Ganesh Ajjanagadde]

This silences -Wunused-function when compiled with --disable-mmx, e.g
http://fate.ffmpeg.org/log.cgi?time=20150919094617=compile=x86_64-archlinux-gcc-disable-mmx.

Signed-off-by: Ganesh Ajjanagadde 
---
 libavcodec/x86/mpegvideoenc.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/libavcodec/x86/mpegvideoenc.c b/libavcodec/x86/mpegvideoenc.c
index b410511..67b2617 100644
--- a/libavcodec/x86/mpegvideoenc.c
+++ b/libavcodec/x86/mpegvideoenc.c
@@ -86,6 +86,7 @@ DECLARE_ALIGNED(16, static uint16_t, inv_zigzag_direct16)[64];
 #endif /* HAVE_6REGS */
 
 #if HAVE_INLINE_ASM
+#if HAVE_MMX_INLINE
 static void  denoise_dct_mmx(MpegEncContext *s, int16_t *block){
 const int intra= s->mb_intra;
 int *sum= s->dct_error_sum[intra];
@@ -139,7 +140,9 @@ static void  denoise_dct_mmx(MpegEncContext *s, int16_t 
*block){
 : "r"(block+64)
 );
 }
+#endif /* HAVE_MMX_INLINE */
 
+#if HAVE_SSE2_INLINE
 static void  denoise_dct_sse2(MpegEncContext *s, int16_t *block){
 const int intra= s->mb_intra;
 int *sum= s->dct_error_sum[intra];
@@ -195,6 +198,7 @@ static void  denoise_dct_sse2(MpegEncContext *s, int16_t 
*block){
 "%xmm4", "%xmm5", "%xmm6", "%xmm7")
 );
 }
+#endif /* HAVE_SSE2_INLINE */
 #endif /* HAVE_INLINE_ASM */
 
 av_cold void ff_dct_encode_init_x86(MpegEncContext *s)
-- 
2.5.2

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

[FFmpeg-devel] [PATCH 1/2] avcodec/x86/hpeldsp_rnd_template: silence -Wunused-function on --disable-mmx

[Ganesh Ajjanagadde]

This silences some of the -Wunused-function warnings when compiled with 
--disable-mmx, e.g
http://fate.ffmpeg.org/log.cgi?time=20150919094617=compile=x86_64-archlinux-gcc-disable-mmx.
Header guards are too brittle and ugly for this case.

Signed-off-by: Ganesh Ajjanagadde 
---
 libavcodec/x86/hpeldsp_rnd_template.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/libavcodec/x86/hpeldsp_rnd_template.c 
b/libavcodec/x86/hpeldsp_rnd_template.c
index 8cbc412..abe3bb1 100644
--- a/libavcodec/x86/hpeldsp_rnd_template.c
+++ b/libavcodec/x86/hpeldsp_rnd_template.c
@@ -28,7 +28,7 @@
 #include 
 
 // put_pixels
-static void DEF(put, pixels8_x2)(uint8_t *block, const uint8_t *pixels, 
ptrdiff_t line_size, int h)
+av_unused static void DEF(put, pixels8_x2)(uint8_t *block, const uint8_t 
*pixels, ptrdiff_t line_size, int h)
 {
 MOVQ_BFE(mm6);
 __asm__ volatile(
@@ -60,7 +60,7 @@ static void DEF(put, pixels8_x2)(uint8_t *block, const 
uint8_t *pixels, ptrdiff_
 :REG_a, "memory");
 }
 
-static void DEF(put, pixels16_x2)(uint8_t *block, const uint8_t *pixels, 
ptrdiff_t line_size, int h)
+av_unused static void DEF(put, pixels16_x2)(uint8_t *block, const uint8_t 
*pixels, ptrdiff_t line_size, int h)
 {
 MOVQ_BFE(mm6);
 __asm__ volatile(
@@ -135,7 +135,7 @@ static void DEF(put, pixels8_y2)(uint8_t *block, const 
uint8_t *pixels, ptrdiff_
 :REG_a, "memory");
 }
 
-static void DEF(avg, pixels16_x2)(uint8_t *block, const uint8_t *pixels, 
ptrdiff_t line_size, int h)
+av_unused static void DEF(avg, pixels16_x2)(uint8_t *block, const uint8_t 
*pixels, ptrdiff_t line_size, int h)
 {
 MOVQ_BFE(mm6);
 __asm__ volatile(
-- 
2.5.2

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

[FFmpeg-devel] [PATCH] avcodec/motion_est_template: fix undefined left shift of negative number

[Ganesh Ajjanagadde]

This fixes -Wshift-negative-value reported with clang 3.7+, e.g
http://fate.ffmpeg.org/log.cgi?time=20150918181527=compile=x86_64-darwin-clang-polly-vectorize-stripmine-3.7.

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

diff --git a/libavcodec/motion_est_template.c b/libavcodec/motion_est_template.c
index 25bab9d..2141771 100644
--- a/libavcodec/motion_est_template.c
+++ b/libavcodec/motion_est_template.c
@@ -702,7 +702,7 @@ static int sab_diamond_search(MpegEncContext * s, int 
*best, int dmin,
 
 key += (1<<(ME_MAP_MV_BITS-1)) + (1<<(2*ME_MAP_MV_BITS-1));
 
-if((key&((-1)<<(2*ME_MAP_MV_BITS))) != map_generation) continue;
+if((key&(-(1<<(2*ME_MAP_MV_BITS != map_generation) continue;
 
 minima[j].height= score_map[i];
 minima[j].x= key & ((1<>=ME_MAP_MV_BITS;
-- 
2.5.2

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

[FFmpeg-devel] [PATCH] avresample/resample: remove unused variable

[Ganesh Ajjanagadde]

This fixes a -Wunused-variable, see e.g
http://fate.ffmpeg.org/log.cgi?time=20150919162338=compile=x86_64-archlinux-gcc-threads.

Signed-off-by: Ganesh Ajjanagadde 
---
 libavresample/resample.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/libavresample/resample.c b/libavresample/resample.c
index 8f920fa..651670d 100644
--- a/libavresample/resample.c
+++ b/libavresample/resample.c
@@ -234,7 +234,6 @@ int avresample_set_compensation(AVAudioResampleContext 
*avr, int sample_delta,
 int compensation_distance)
 {
 ResampleContext *c;
-AudioData *fifo_buf = NULL;
 
 if (compensation_distance < 0)
 return AVERROR(EINVAL);
-- 
2.5.2

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

Re: [FFmpeg-devel] [PATCH] avresample/resample: remove unused variable

[Ganesh Ajjanagadde]

On Sat, Sep 19, 2015 at 1:26 PM, Ganesh Ajjanagadde
 wrote:
> This fixes a -Wunused-variable, see e.g
> http://fate.ffmpeg.org/log.cgi?time=20150919162338=compile=x86_64-archlinux-gcc-threads.
>
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavresample/resample.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/libavresample/resample.c b/libavresample/resample.c
> index 8f920fa..651670d 100644
> --- a/libavresample/resample.c
> +++ b/libavresample/resample.c
> @@ -234,7 +234,6 @@ int avresample_set_compensation(AVAudioResampleContext 
> *avr, int sample_delta,
>  int compensation_distance)
>  {
>  ResampleContext *c;
> -AudioData *fifo_buf = NULL;
>
>  if (compensation_distance < 0)
>  return AVERROR(EINVAL);
> --
> 2.5.2
>

I recall something like swresample is what FFmpeg cares about,
avresample is for libav compatibility. I personally do not care what
libav does with this stuff; but at the moment it is a warning that
affects FFmpeg, hence I am sending it here.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCHv3] avfilter/vf_chromakey: Add chromakey video filter

[Paul B Mahol]

On 9/18/15, Timo Rothenpieler  wrote:
> ---
>  Changelog  |   1 +
>  MAINTAINERS|   1 +
>  doc/filters.texi   |  45 +++
>  libavfilter/Makefile   |   1 +
>  libavfilter/allfilters.c   |   1 +
>  libavfilter/version.h  |   2 +-
>  libavfilter/vf_chromakey.c | 198
> +
>  7 files changed, 248 insertions(+), 1 deletion(-)
>  create mode 100644 libavfilter/vf_chromakey.c
>


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

[FFmpeg-devel] [PATCHv2] avformat/format: silence -Wdiscarded-qualifiers

[Ganesh Ajjanagadde]

lpd.buf is non-const and discards the const qualifier of zerobuffer.
This fixes -Wdiscarded-qualifiers observed with a variety of compilers, 
including GCC 5.2.
Note that this does not change the type of zerobuffer, and merely makes the 
intent explicit.

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

diff --git a/libavformat/format.c b/libavformat/format.c
index fd81d7a..ffddb13 100644
--- a/libavformat/format.c
+++ b/libavformat/format.c
@@ -175,7 +175,7 @@ AVInputFormat *av_probe_input_format3(AVProbeData *pd, int 
is_opened,
 const static uint8_t zerobuffer[AVPROBE_PADDING_SIZE];
 
 if (!lpd.buf)
-lpd.buf = zerobuffer;
+lpd.buf = (unsigned char *) zerobuffer;
 
 if (lpd.buf_size > 10 && ff_id3v2_match(lpd.buf, ID3v2_DEFAULT_MAGIC)) {
 int id3len = ff_id3v2_tag_len(lpd.buf);
-- 
2.5.2

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

Re: [FFmpeg-devel] [PATCH] checkasm: add VP9 loopfilter tests.

[Henrik Gramner]

On Thu, Sep 17, 2015 at 5:58 PM, Ronald S. Bultje  wrote:
> The randomize_buffer() implementation assures that "most of the time",
> we'll do a good mix of wide16/wide8/hev/regular/no filters for complete
> code coverage. However, this is not mathematically assured because that
> would make the code either much more complex, or much less random.

http://fate.ffmpeg.org/ runs the tests often enough that any issue
should be caught (with the prng seed to reproduce it), so that's
probably fine.

> +static void check_loopfilter()

(void)

> +int E[2] = { 20, 28 }, I[2] = { 10, 16 }, H[2] = { 7, 11 }, F[2] = { 1, 
> 1 };

const

+uint8_t *buf0, *buf1;
[..]
+buf0 = base0 + midoff_aligned;
+buf1 = base1 + midoff_aligned;

Could be declared and initialized at the same time.

I unfortunately don't know enough about VP9 to comment on most of the
logic or numerical values chosen, but I'd say go ahead and push if
nobody objects.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] x86/vp9mc: fix string concatenation of fullpel function names

[James Almer]

Fixes compilation with NASM

Signed-off-by: James Almer 
---
See 
http://fate.ffmpeg.org/log.cgi?time=20150919155527=compile=x86_64-archlinux-gcc-nasm

 libavcodec/x86/vp9mc.asm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/x86/vp9mc.asm b/libavcodec/x86/vp9mc.asm
index d828312..9152ba5 100644
--- a/libavcodec/x86/vp9mc.asm
+++ b/libavcodec/x86/vp9mc.asm
@@ -583,11 +583,11 @@ filter_vx2_fn avg
 %endif
 
 %if %2 <= mmsize
-cglobal vp9_%1%2%%szsuf, 5, 7, 4, dst, dstride, src, sstride, h, dstride3, 
sstride3
+cglobal vp9_%1%2 %+ %%szsuf, 5, 7, 4, dst, dstride, src, sstride, h, dstride3, 
sstride3
 lea  sstride3q, [sstrideq*3]
 lea  dstride3q, [dstrideq*3]
 %else
-cglobal vp9_%1%2%%szsuf, 5, 5, %8, dst, dstride, src, sstride, h
+cglobal vp9_%1%2 %+ %%szsuf, 5, 5, %8, dst, dstride, src, sstride, h
 %endif
 .loop:
 %%srcfn m0, [srcq]
-- 
2.5.2

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

Re: [FFmpeg-devel] [PATCH] swscale/output: fix undefined left shifts of negative numbers

[Michael Niedermayer]

On Sat, Sep 19, 2015 at 01:10:44PM -0400, Ganesh Ajjanagadde wrote:
> This fixes -Wshift-negative-value reported with clang 3.7+, e.g
> http://fate.ffmpeg.org/log.cgi?time=20150918181527=compile=x86_64-darwin-clang-polly-vectorize-stripmine-3.7.
> 
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libswscale/output.c | 32 
>  1 file changed, 16 insertions(+), 16 deletions(-)

applied

thanks

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

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


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

Re: [FFmpeg-devel] [PATCH 2/2] doc/developer: s/ffmpeg-cvslog/ffmpeg-devel

[James Almer]

On 9/19/2015 10:03 PM, Ganesh Ajjanagadde wrote:
> On Sat, Sep 19, 2015 at 8:30 PM, James Almer  wrote:
>> On 9/19/2015 8:54 PM, Ganesh Ajjanagadde wrote:
>>> On Sat, Sep 19, 2015 at 7:48 PM, James Almer  wrote:
 On 9/19/2015 8:36 PM, Ganesh Ajjanagadde wrote:
> ffmpeg has not been using cvs for a long time.
>
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  doc/developer.texi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/doc/developer.texi b/doc/developer.texi
> index 7324629..923ee69 100644
> --- a/doc/developer.texi
> +++ b/doc/developer.texi
> @@ -349,7 +349,7 @@ timeframe (12h for build failures and security fixes, 
> 3 days small changes,
>  Also note, the maintainer can simply ask for more time to review!
>
>  @item
> -Subscribe to the ffmpeg-cvslog mailing list. The diffs of all commits
> +Subscribe to the ffmpeg-devel mailing list. The diffs of all commits
>  are sent there and reviewed by all the other developers. Bugs and 
> possible
>  improvements or general questions regarding commits are discussed there. 
> We
>  expect you to react if problems with your code are uncovered.

 https://ffmpeg.org/pipermail/ffmpeg-cvslog/

 ffmpeg-cvslog has a different purpose than ffmpeg-devel.
>>>
>>> Isn't the same information available at
>>> https://ffmpeg.org/pipermail/ffmpeg-devel/?
>>> Can you tell me what the difference between the two is?
>>
>> If you check and compare the emails between the two list, you'll notice that 
>> one
>> is a list where automated emails are sent every time something is committed 
>> to
>> the git repo, and the other is a list where patches are sent for review.
> 
> Well, in that case the doc is broken in a worse way. "Bugs and
> possilbe improvements or general questions regarding commits are
> discussed there" does not even apply to ffmpeg-cvslog, it really

Discussion about commits (not patches) can and does happen there, even though in
general it's always CCd to ffmpeg-devel where people are more likely to see it.
ffmpeg-devel has its own section on this file, mentioning it's meant for patches
and discussions about development.

> applies to ffmpeg-devel. In that case this patch is still an
> improvement over the current situation. ffmpeg-cvslog is pretty much
> useless for a dev on daily basis, since he/she can't see the
> discussion. If a dev is subscribing to something, ffmpeg-devel gives
> far more useful information and IMHO is the preferred mailing list.
> 
> However, perhaps the commit message needs rewording due to my 
> misunderstanding.



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

[FFmpeg-devel] some thoughts on the website and warnings

[Ganesh Ajjanagadde]

Hi all,

I have a suggestion for improving the FFmpeg website. I really like
the way the current "About FFmpeg" webpage presents FFmpeg - the very
first sentence is amazingly true. A few months back I thought this was
just a PR push, but the proof of this lies in the variety of ways
FFmpeg is used and its flexibility compared to anything else I know
of.

Furthermore, it is honest and balanced - security issues are always
there and it gives an accurate description of why.

Anyway, I feel it can be improved by adding a sentence or two
somewhere regarding portability. Just have a look at fate.ffmpeg.org -
it compiles, runs, and passes fate on Linux, Mac OS, Windows, Solaris,
FreeBSD, OpenBSD, etc under a wide array of compilers, libraries, etc.
It is definitely a lot of work writing portable code across such
platforms, and I have appreciated this first hand with some recent
work that I have done. How many projects out there are this good in
terms of portability? I estimate that a significant fraction of e.g
GitHub projects are Linux/Mac OS X specific - many will fail even on a
POSIX platform, let alone Windows. This is part of the general trap I
have noticed of the incorrect "POSIX == Linux". Then you have cases
like systemd, which don't even bother - Linux is their only platform,
and even there they have quite restrictive kernel/libc dependencies.
Thus, FFmpeg can rightfully be proud of this accomplishment, and IMHO
should mention it publicly on the page. I can help/submit patches
regarding wording if others agree with this.

Regarding the large array of platforms, as can be seen from the
patches I have submitted over the past few weeks, one long term goal I
have is getting to a "nearly -Werror" state at least on the most
recent clang/gcc. Already notice that most warnings are from older
compilers, non clang/gcc, windows, etc, which in many cases give us
nothing (since newer ones anyway warn for the good ones).
Nevertheless, these are occasionally useful.

Latest clang/gcc are on the order of 100 warnings, and I think with
some more work, this can be brought down to 10 (for the most annoying
ones). If this happens, it should help us in treating warnings on
latest clang/gcc more seriously than before. Among these two, I have
been far more impressed with clang than gcc.

This might stir the flames, but who knows: maybe in a year we can
seriously consider -Werror for a certain set of "core platforms"
(which can be voted upon; recall the leadership committee etc). By a
"platform" I mean a complete environment: set of configure flags,
compiler flags, compiler versions, etc.

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

Re: [FFmpeg-devel] [PATCH] avcodec/imgconvert: Support non-planar colorspaces while padding

[Michael Niedermayer]

On Sat, Sep 19, 2015 at 12:33:55PM +0200, Przemysław Sobala wrote:
> W dniu 19.09.2015 o 04:14, Michael Niedermayer pisze:
> >On Fri, Sep 18, 2015 at 04:31:16PM +0200, Przemysław Sobala wrote:
> >>---
> >>  libavcodec/imgconvert.c | 99 
> >> -
> >>  1 file changed, 65 insertions(+), 34 deletions(-)
> >>
> >>diff --git a/libavcodec/imgconvert.c b/libavcodec/imgconvert.c
> >>index dc67560..a523bd5 100644
> >>--- a/libavcodec/imgconvert.c
> >>+++ b/libavcodec/imgconvert.c
> >>@@ -236,54 +236,85 @@ int av_picture_pad(AVPicture *dst, const AVPicture 
> >>*src, int height, int width,
> >>  int x_shift;
> >>  int yheight;
> >>  int i, y;
> >>+int max_step[4];
> >>
> >>-if (pix_fmt < 0 || pix_fmt >= AV_PIX_FMT_NB ||
> >>-!is_yuv_planar(desc)) return -1;
> >>+if (pix_fmt < 0 || pix_fmt >= AV_PIX_FMT_NB)
> >>+return -1;
> >>
> >>-for (i = 0; i < 3; i++) {
> >>-x_shift = i ? desc->log2_chroma_w : 0;
> >>-y_shift = i ? desc->log2_chroma_h : 0;
> >>+if (is_yuv_planar(desc)) {
> >>+for (i = 0; i < 3; i++) {
> >>+x_shift = i ? desc->log2_chroma_w : 0;
> >>+y_shift = i ? desc->log2_chroma_h : 0;
> >>
> >>-if (padtop || padleft) {
> >>-memset(dst->data[i], color[i],
> >>-dst->linesize[i] * (padtop >> y_shift) + (padleft >> 
> >>x_shift));
> >>-}
> >>+if (padtop || padleft) {
> >>+memset(dst->data[i], color[i],
> >>+dst->linesize[i] * (padtop >> y_shift) + (padleft >> 
> >>x_shift));
> >>+}
> >>
> >>-if (padleft || padright) {
> >>-optr = dst->data[i] + dst->linesize[i] * (padtop >> y_shift) +
> >>-(dst->linesize[i] - (padright >> x_shift));
> >>-yheight = (height - 1 - (padtop + padbottom)) >> y_shift;
> >>-for (y = 0; y < yheight; y++) {
> >>-memset(optr, color[i], (padleft + padright) >> x_shift);
> >>-optr += dst->linesize[i];
> >>+if (padleft || padright) {
> >>+optr = dst->data[i] + dst->linesize[i] * (padtop >> 
> >>y_shift) +
> >>+(dst->linesize[i] - (padright >> x_shift));
> >>+yheight = (height - 1 - (padtop + padbottom)) >> y_shift;
> >>+for (y = 0; y < yheight; y++) {
> >>+memset(optr, color[i], (padleft + padright) >> 
> >>x_shift);
> >>+optr += dst->linesize[i];
> >>+}
> >>  }
> >>+
> >>+if (src) { /* first line */
> >>+uint8_t *iptr = src->data[i];
> >>+optr = dst->data[i] + dst->linesize[i] * (padtop >> 
> >>y_shift) +
> >>+(padleft >> x_shift);
> >>+memcpy(optr, iptr, (width - padleft - padright) >> 
> >>x_shift);
> >>+iptr += src->linesize[i];
> >>+optr = dst->data[i] + dst->linesize[i] * (padtop >> 
> >>y_shift) +
> >>+(dst->linesize[i] - (padright >> x_shift));
> >>+yheight = (height - 1 - (padtop + padbottom)) >> y_shift;
> >>+for (y = 0; y < yheight; y++) {
> >>+memset(optr, color[i], (padleft + padright) >> 
> >>x_shift);
> >>+memcpy(optr + ((padleft + padright) >> x_shift), iptr,
> >>+   (width - padleft - padright) >> x_shift);
> >>+iptr += src->linesize[i];
> >>+optr += dst->linesize[i];
> >>+}
> >>+}
> >>+
> >>+if (padbottom || padright) {
> >>+optr = dst->data[i] + dst->linesize[i] *
> >>+((height - padbottom) >> y_shift) - (padright >> 
> >>x_shift);
> >>+memset(optr, color[i],dst->linesize[i] *
> >>+(padbottom >> y_shift) + (padright >> x_shift));
> >>+}
> >>+}
> >
> >this only reindents the code, moving the reindention to a seperate
> >patch would make it more readable
> 
> I've rearranged the code a bit.
> 
> >>+} else {
> >
> >>+if (src)
> >>+return -1;
> >
> >why ?
> >
> 
> Because it's not yet implemented.
> I've added a comment.
> New patch attached.
> 
> --
> Regards
> Przemysław Sobala
> 
> 
> Główne Spółki Grupy Wirtualna Polska:
> 
> Wirtualna Polska Holding Spółka Akcyjna z siedzibą w Warszawie, ul. Jutrzenki 
> 137A, 02-231 Warszawa, wpisana do Krajowego Rejestru Sądowego - Rejestru 
> Przedsiębiorców prowadzonego przez Sąd Rejonowy dla m.st. Warszawy w 
> Warszawie pod nr KRS: 407130, kapitał zakładowy: 1 245 651,90 zł (w 
> całości wpłacony), Numer Identyfikacji Podatkowej (NIP): 521-31-11-513
> 
> Grupa Wirtualna Polska Spółka z ograniczoną odpowiedzialnością z siedzibą w 
> Warszawie, ul. Jutrzenki 137A, 02-231 Warszawa, wpisana do Krajowego Rejestru 
> Sądowego - Rejestru 

[FFmpeg-devel] [PATCH] swscale/output: fix undefined left shifts of negative numbers

[Ganesh Ajjanagadde]

This fixes -Wshift-negative-value reported with clang 3.7+, e.g
http://fate.ffmpeg.org/log.cgi?time=20150918181527=compile=x86_64-darwin-clang-polly-vectorize-stripmine-3.7.

Signed-off-by: Ganesh Ajjanagadde 
---
 libswscale/output.c | 32 
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/libswscale/output.c b/libswscale/output.c
index 3188baa..4b70626 100644
--- a/libswscale/output.c
+++ b/libswscale/output.c
@@ -693,8 +693,8 @@ yuv2rgba64_X_c_template(SwsContext *c, const int16_t 
*lumFilter,
 int j;
 int Y1 = -0x4000;
 int Y2 = -0x4000;
-int U  = -128 << 23; // 19
-int V  = -128 << 23;
+int U  = -(128 << 23); // 19
+int V  = -(128 << 23);
 int R, G, B;
 
 for (j = 0; j < lumFilterSize; j++) {
@@ -780,8 +780,8 @@ yuv2rgba64_2_c_template(SwsContext *c, const int32_t 
*buf[2],
 for (i = 0; i < ((dstW + 1) >> 1); i++) {
 int Y1 = (buf0[i * 2] * yalpha1  + buf1[i * 2] * yalpha) >> 14;
 int Y2 = (buf0[i * 2 + 1] * yalpha1  + buf1[i * 2 + 1] * yalpha) >> 14;
-int U  = (ubuf0[i]* uvalpha1 + ubuf1[i]* uvalpha + 
(-128 << 23)) >> 14;
-int V  = (vbuf0[i]* uvalpha1 + vbuf1[i]* uvalpha + 
(-128 << 23)) >> 14;
+int U  = (ubuf0[i]* uvalpha1 + ubuf1[i]* uvalpha - 
(128 << 23)) >> 14;
+int V  = (vbuf0[i]* uvalpha1 + vbuf1[i]* uvalpha - 
(128 << 23)) >> 14;
 int R, G, B;
 
 Y1 -= c->yuv2rgb_y_offset;
@@ -836,8 +836,8 @@ yuv2rgba64_1_c_template(SwsContext *c, const int32_t *buf0,
 for (i = 0; i < ((dstW + 1) >> 1); i++) {
 int Y1 = (buf0[i * 2]) >> 2;
 int Y2 = (buf0[i * 2 + 1]) >> 2;
-int U  = (ubuf0[i] + (-128 << 11)) >> 2;
-int V  = (vbuf0[i] + (-128 << 11)) >> 2;
+int U  = (ubuf0[i] - (128 << 11)) >> 2;
+int V  = (vbuf0[i] - (128 << 11)) >> 2;
 int R, G, B;
 
 Y1 -= c->yuv2rgb_y_offset;
@@ -882,8 +882,8 @@ yuv2rgba64_1_c_template(SwsContext *c, const int32_t *buf0,
 for (i = 0; i < ((dstW + 1) >> 1); i++) {
 int Y1 = (buf0[i * 2]) >> 2;
 int Y2 = (buf0[i * 2 + 1]) >> 2;
-int U  = (ubuf0[i] + ubuf1[i] + (-128 << 12)) >> 3;
-int V  = (vbuf0[i] + vbuf1[i] + (-128 << 12)) >> 3;
+int U  = (ubuf0[i] + ubuf1[i] - (128 << 12)) >> 3;
+int V  = (vbuf0[i] + vbuf1[i] - (128 << 12)) >> 3;
 int R, G, B;
 
 Y1 -= c->yuv2rgb_y_offset;
@@ -939,8 +939,8 @@ yuv2rgba64_full_X_c_template(SwsContext *c, const int16_t 
*lumFilter,
 for (i = 0; i < dstW; i++) {
 int j;
 int Y  = -0x4000;
-int U  = -128 << 23; // 19
-int V  = -128 << 23;
+int U  = -(128 << 23); // 19
+int V  = -(128 << 23);
 int R, G, B;
 
 for (j = 0; j < lumFilterSize; j++) {
@@ -1008,8 +1008,8 @@ yuv2rgba64_full_2_c_template(SwsContext *c, const int32_t 
*buf[2],
 
 for (i = 0; i < dstW; i++) {
 int Y  = (buf0[i] * yalpha1  + buf1[i] * yalpha) >> 14;
-int U  = (ubuf0[i]   * uvalpha1 + ubuf1[i] * uvalpha + (-128 << 
23)) >> 14;
-int V  = (vbuf0[i]   * uvalpha1 + vbuf1[i] * uvalpha + (-128 << 
23)) >> 14;
+int U  = (ubuf0[i]   * uvalpha1 + ubuf1[i] * uvalpha - (128 << 
23)) >> 14;
+int V  = (vbuf0[i]   * uvalpha1 + vbuf1[i] * uvalpha - (128 << 
23)) >> 14;
 int R, G, B;
 
 Y -= c->yuv2rgb_y_offset;
@@ -1051,8 +1051,8 @@ yuv2rgba64_full_1_c_template(SwsContext *c, const int32_t 
*buf0,
 if (uvalpha < 2048) {
 for (i = 0; i < dstW; i++) {
 int Y  = (buf0[i]) >> 2;
-int U  = (ubuf0[i] + (-128 << 11)) >> 2;
-int V  = (vbuf0[i] + (-128 << 11)) >> 2;
+int U  = (ubuf0[i] - (128 << 11)) >> 2;
+int V  = (vbuf0[i] - (128 << 11)) >> 2;
 int R, G, B;
 
 Y -= c->yuv2rgb_y_offset;
@@ -1084,8 +1084,8 @@ yuv2rgba64_full_1_c_template(SwsContext *c, const int32_t 
*buf0,
 int A = 0x<<14;
 for (i = 0; i < dstW; i++) {
 int Y  = (buf0[i]) >> 2;
-int U  = (ubuf0[i] + ubuf1[i] + (-128 << 12)) >> 3;
-int V  = (vbuf0[i] + vbuf1[i] + (-128 << 12)) >> 3;
+int U  = (ubuf0[i] + ubuf1[i] - (128 << 12)) >> 3;
+int V  = (vbuf0[i] + vbuf1[i] - (128 << 12)) >> 3;
 int R, G, B;
 
 Y -= c->yuv2rgb_y_offset;
-- 
2.5.2

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

[FFmpeg-devel] [PATCH 2/3] avcodec/x86/hpeldsp_init: silence -Wunused-function on --disable-mmx

[Ganesh Ajjanagadde]

This silences some of the -Wunused-function warnings when compiled with 
--disable-mmx, e.g
http://fate.ffmpeg.org/log.cgi?time=20150919094617=compile=x86_64-archlinux-gcc-disable-mmx.

Signed-off-by: Ganesh Ajjanagadde 
---
 libavcodec/x86/hpeldsp_init.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/libavcodec/x86/hpeldsp_init.c b/libavcodec/x86/hpeldsp_init.c
index 1479992..5c5da28 100644
--- a/libavcodec/x86/hpeldsp_init.c
+++ b/libavcodec/x86/hpeldsp_init.c
@@ -121,11 +121,13 @@ void ff_avg_approx_pixels8_xy2_3dnow(uint8_t *block, 
const uint8_t *pixels,
 #undef PAVGB
 #undef STATIC
 
+#if HAVE_MMX
 CALL_2X_PIXELS(avg_no_rnd_pixels16_y2_mmx, avg_no_rnd_pixels8_y2_mmx, 8)
 CALL_2X_PIXELS(put_no_rnd_pixels16_y2_mmx, put_no_rnd_pixels8_y2_mmx, 8)
 
 CALL_2X_PIXELS(avg_no_rnd_pixels16_xy2_mmx, avg_no_rnd_pixels8_xy2_mmx, 8)
 CALL_2X_PIXELS(put_no_rnd_pixels16_xy2_mmx, put_no_rnd_pixels8_xy2_mmx, 8)
+#endif
 
 /***/
 /* MMX rounding */
@@ -148,11 +150,13 @@ CALL_2X_PIXELS(put_no_rnd_pixels16_xy2_mmx, 
put_no_rnd_pixels8_xy2_mmx, 8)
 #undef PAVGBP
 #undef PAVGB
 
+#if HAVE_MMX
 CALL_2X_PIXELS(avg_pixels16_y2_mmx, avg_pixels8_y2_mmx, 8)
 CALL_2X_PIXELS(put_pixels16_y2_mmx, put_pixels8_y2_mmx, 8)
 
 CALL_2X_PIXELS_EXPORT(ff_avg_pixels16_xy2_mmx, ff_avg_pixels8_xy2_mmx, 8)
 CALL_2X_PIXELS_EXPORT(ff_put_pixels16_xy2_mmx, ff_put_pixels8_xy2_mmx, 8)
+#endif
 
 #endif /* HAVE_INLINE_ASM */
 
-- 
2.5.2

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

Re: [FFmpeg-devel] some thoughts on the website and warnings

[Lou Logan]

On Sat, Sep 19, 2015, at 08:36 AM, Ganesh Ajjanagadde wrote:

> Thus, FFmpeg can rightfully be proud of this accomplishment, and IMHO
> should mention it publicly on the page. I can help/submit patches
> regarding wording if others agree with this.

The index page mentions "cross-platform", but if you would like to put
few sentences or short paragraph regarding this in the about page that
would be fine with me. Patch welcome.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel