Re: [FFmpeg-devel] [PATCH] x86/vp9: add avx2 subpel MC SIMD for 10/12bpp
Hi,
On Sep 18, 2015 3:55 AM, "James Almer" wrote:
>
> Signed-off-by: James Almer
> ---
> Unbenched as i lack the hardware to do so.
>
> libavcodec/x86/vp9dsp_init_16bpp_template.c | 22 ++
> libavcodec/x86/vp9mc_16bpp.asm | 6 ++
> 2 files changed, 28 insertions(+)
>
> diff --git a/libavcodec/x86/vp9dsp_init_16bpp_template.c
b/libavcodec/x86/vp9dsp_init_16bpp_template.c
> index 3e2737b..a1ce212 100644
> --- a/libavcodec/x86/vp9dsp_init_16bpp_template.c
> +++ b/libavcodec/x86/vp9dsp_init_16bpp_template.c
> @@ -33,16 +33,31 @@ extern const int16_t ff_filters_16bpp[3][15][4][16];
>
> decl_mc_funcs(4, sse2, int16_t, 16, BPC);
> decl_mc_funcs(8, sse2, int16_t, 16, BPC);
> +decl_mc_funcs(16, avx2, int16_t, 16, BPC);
>
> mc_rep_funcs(16, 8, 16, sse2, int16_t, 16, BPC);
> mc_rep_funcs(32, 16, 32, sse2, int16_t, 16, BPC);
> mc_rep_funcs(64, 32, 64, sse2, int16_t, 16, BPC);
> +mc_rep_funcs(32, 16, 32, avx2, int16_t, 16, BPC);
> +mc_rep_funcs(64, 32, 64, avx2, int16_t, 16, BPC);
>
> filters_8tap_2d_fn2(put, 16, BPC, 2, sse2, sse2, 16bpp)
> filters_8tap_2d_fn2(avg, 16, BPC, 2, sse2, sse2, 16bpp)
> +filters_8tap_2d_fn(put, 64, 32, BPC, 2, avx2, 16bpp)
> +filters_8tap_2d_fn(avg, 64, 32, BPC, 2, avx2, 16bpp)
> +filters_8tap_2d_fn(put, 32, 32, BPC, 2, avx2, 16bpp)
> +filters_8tap_2d_fn(avg, 32, 32, BPC, 2, avx2, 16bpp)
> +filters_8tap_2d_fn(put, 16, 32, BPC, 2, avx2, 16bpp)
> +filters_8tap_2d_fn(avg, 16, 32, BPC, 2, avx2, 16bpp)
>
> filters_8tap_1d_fn3(put, BPC, sse2, sse2, 16bpp)
> filters_8tap_1d_fn3(avg, BPC, sse2, sse2, 16bpp)
> +filters_8tap_1d_fn2(put, 64, BPC, avx2, 16bpp)
> +filters_8tap_1d_fn2(avg, 64, BPC, avx2, 16bpp)
> +filters_8tap_1d_fn2(put, 32, BPC, avx2, 16bpp)
> +filters_8tap_1d_fn2(avg, 32, BPC, avx2, 16bpp)
> +filters_8tap_1d_fn2(put, 16, BPC, avx2, 16bpp)
> +filters_8tap_1d_fn2(avg, 16, BPC, avx2, 16bpp)
>
> #endif /* HAVE_YASM */
>
> @@ -56,6 +71,13 @@ av_cold void INIT_FUNC(VP9DSPContext *dsp)
> init_subpel3(1, avg, BPC, sse2);
> }
>
> +if (EXTERNAL_AVX2(cpu_flags)) {
> +init_subpel3_32_64(0, put, BPC, avx2);
> +init_subpel3_32_64(1, avg, BPC, avx2);
> +init_subpel2(2, 0, 16, put, BPC, avx2);
> +init_subpel2(2, 1, 16, avg, BPC, avx2);
> +}
> +
> #endif /* HAVE_YASM */
>
> ff_vp9dsp_init_16bpp_x86(dsp);
> diff --git a/libavcodec/x86/vp9mc_16bpp.asm
b/libavcodec/x86/vp9mc_16bpp.asm
> index 52fc5ee..d66da55 100644
> --- a/libavcodec/x86/vp9mc_16bpp.asm
> +++ b/libavcodec/x86/vp9mc_16bpp.asm
> @@ -201,6 +201,9 @@ cglobal vp9_%1_8tap_1d_h_ %+ %%px %+ _12, 6, 6, %2,
dst, dstride, src, sstride,
> INIT_XMM sse2
> filter_h_fn put
> filter_h_fn avg
> +INIT_YMM avx2
> +filter_h_fn put
> +filter_h_fn avg
>
> %macro filter_v4_fn 1-2 12
> %if ARCH_X86_64
> @@ -419,3 +422,6 @@ cglobal vp9_%1_8tap_1d_v_ %+ %%px %+ _12, 4, 7, %2,
dst, dstride, src, sstride,
> INIT_XMM sse2
> filter_v_fn put
> filter_v_fn avg
> +INIT_YMM avx2
> +filter_v_fn put
> +filter_v_fn avg
> --
> 2.5.2
Cool, I was hoping that would work but don't have Intel's emulator; thanks
for testing && lgtm.
Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv2] avcodec: use HAVE_THREADS header guards to silence -Wunused-function
On 17.09.2015 15:07, Ganesh Ajjanagadde wrote:
When compiled with --disable-pthreads, e.g
http://fate.ffmpeg.org/report.cgi?time=20150917015044&slot=alpha-debian-qemu-gcc-4.7,
a bunch of -Wunused-functions are reported.
This patch should silence such warnings.
Signed-off-by: Ganesh Ajjanagadde
---
libavcodec/alac.c | 2 +-
libavcodec/exr.c | 2 +-
libavcodec/ffv1dec.c | 4 ++--
libavcodec/flacdec.c | 2 +-
libavcodec/h264.c | 2 +-
libavcodec/huffyuvdec.c| 2 +-
libavcodec/mdec.c | 2 +-
libavcodec/mimic.c | 4 ++--
libavcodec/mpeg12dec.c | 2 +-
libavcodec/mpeg4videodec.c | 2 +-
libavcodec/pngdec.c| 2 +-
libavcodec/takdec.c| 4 ++--
libavcodec/tta.c | 4 ++--
libavcodec/vp3.c | 4 ++--
libavcodec/vp8.c | 4 ++--
libavcodec/vp9.c | 2 +-
libavcodec/wavpack.c | 2 +-
17 files changed, 23 insertions(+), 23 deletions(-)
diff --git a/libavcodec/alac.c b/libavcodec/alac.c
index 827c0db..f2e5907 100644
--- a/libavcodec/alac.c
+++ b/libavcodec/alac.c
@@ -609,7 +609,7 @@ static av_cold int alac_decode_init(AVCodecContext * avctx)
return 0;
}
-static int init_thread_copy(AVCodecContext *avctx)
+av_unused static int init_thread_copy(AVCodecContext *avctx)
{
ALACContext *alac = avctx->priv_data;
alac->avctx = avctx;
diff --git a/libavcodec/exr.c b/libavcodec/exr.c
index 3b6b245..778088e 100644
--- a/libavcodec/exr.c
+++ b/libavcodec/exr.c
@@ -1426,7 +1426,7 @@ static av_cold int decode_init(AVCodecContext *avctx)
return 0;
}
-static int decode_init_thread_copy(AVCodecContext *avctx)
+av_unused static int decode_init_thread_copy(AVCodecContext *avctx)
{EXRContext *s = avctx->priv_data;
// allocate thread data, used for non EXR_RAW compreesion types
diff --git a/libavcodec/ffv1dec.c b/libavcodec/ffv1dec.c
index 557b1a0..70ae37d 100644
--- a/libavcodec/ffv1dec.c
+++ b/libavcodec/ffv1dec.c
@@ -1008,7 +1008,7 @@ static int decode_frame(AVCodecContext *avctx, void
*data, int *got_frame, AVPac
return buf_size;
}
-static int init_thread_copy(AVCodecContext *avctx)
+av_unused static int init_thread_copy(AVCodecContext *avctx)
{
FFV1Context *f = avctx->priv_data;
int i, ret;
@@ -1061,7 +1061,7 @@ static void copy_fields(FFV1Context *fsdst, FFV1Context
*fssrc, FFV1Context *fsr
}
}
-static int update_thread_context(AVCodecContext *dst, const AVCodecContext
*src)
+av_unused static int update_thread_context(AVCodecContext *dst, const
AVCodecContext *src)
{
FFV1Context *fsrc = src->priv_data;
FFV1Context *fdst = dst->priv_data;
diff --git a/libavcodec/flacdec.c b/libavcodec/flacdec.c
index 8653da7..00744da 100644
--- a/libavcodec/flacdec.c
+++ b/libavcodec/flacdec.c
@@ -623,7 +623,7 @@ static int flac_decode_frame(AVCodecContext *avctx, void
*data,
return bytes_read;
}
-static int init_thread_copy(AVCodecContext *avctx)
+av_unused static int init_thread_copy(AVCodecContext *avctx)
{
FLACContext *s = avctx->priv_data;
s->decoded_buffer = NULL;
diff --git a/libavcodec/h264.c b/libavcodec/h264.c
index b797893..fa66b53 100644
--- a/libavcodec/h264.c
+++ b/libavcodec/h264.c
@@ -701,7 +701,7 @@ av_cold int ff_h264_decode_init(AVCodecContext *avctx)
return 0;
}
-static int decode_init_thread_copy(AVCodecContext *avctx)
+av_unused static int decode_init_thread_copy(AVCodecContext *avctx)
{
H264Context *h = avctx->priv_data;
int ret;
diff --git a/libavcodec/huffyuvdec.c b/libavcodec/huffyuvdec.c
index a700abb..eda11ee 100644
--- a/libavcodec/huffyuvdec.c
+++ b/libavcodec/huffyuvdec.c
@@ -571,7 +571,7 @@ static av_cold int decode_init(AVCodecContext *avctx)
return ret;
}
-static av_cold int decode_init_thread_copy(AVCodecContext *avctx)
+av_unused static av_cold int decode_init_thread_copy(AVCodecContext *avctx)
{
HYuvContext *s = avctx->priv_data;
int i, ret;
diff --git a/libavcodec/mdec.c b/libavcodec/mdec.c
index a9b7e82..b169ac6 100644
--- a/libavcodec/mdec.c
+++ b/libavcodec/mdec.c
@@ -233,7 +233,7 @@ static av_cold int decode_init(AVCodecContext *avctx)
return 0;
}
-static av_cold int decode_init_thread_copy(AVCodecContext *avctx)
+av_unused static av_cold int decode_init_thread_copy(AVCodecContext *avctx)
{
MDECContext * const a = avctx->priv_data;
diff --git a/libavcodec/mimic.c b/libavcodec/mimic.c
index f5853b5..2d861b6 100644
--- a/libavcodec/mimic.c
+++ b/libavcodec/mimic.c
@@ -167,7 +167,7 @@ static av_cold int mimic_decode_init(AVCodecContext *avctx)
return 0;
}
-static int mimic_decode_update_thread_context(AVCodecContext *avctx, const
AVCodecContext *avctx_from)
+av_unused static int mimic_decode_update_thread_context(AVCodecContext *avctx,
const AVCodecContext *avctx_from)
{
MimicContext *dst = avctx->priv_data, *src = avctx_from->priv_data;
int i, ret;
@@ -454,7 +454,7
Re: [FFmpeg-devel] [PATCH] avfilter/avf_showcqt: use frequency domain windowing
On Thu, Sep 17, 2015 at 1:58 AM, Ganesh Ajjanagadde wrote: > Have not checked what the filter is doing, but have a minor comment: > int sign computation - please use FFSIGN. > > the code doesn't extract sign of number, but decide for even index use positive sign and for odd index use negative sign thanks ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Voting committee
On 16.09.2015 07:32, Yayoi Ukai wrote: I also thought that it was wrong that how some of the FFmpeg developer treated/regarded this Outreachy organization. For example, it seemed that Outreachy was regarded more like a source of cheap talented labor to accomplish FFmpeg agenda further rather than an instrument for FFmpeg to be more inclusive organization. It is not respectable to Outreachy which helped to raise funds for interns and look for the talent to work for the FFmpeg and put a lot of work on these activities while they were only hoping to the betterment of the us. I don't get this mindset. FFmpeg is an open source software project, and of course the main focus is on developing software. Further, everyone is free to work on it for free (without _any_ compensation). Outreachy candidates were even paid for their work. So whatever you expected for Outreachy, why can't you simply make the best of it? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add ocr filter
On 09.09.2015 18:23, Paul B Mahol wrote: On 9/9/15, Carl Eugen Hoyos wrote: Paul B Mahol gmail.com> writes: +av_log(ctx, AV_LOG_INFO, "%s\n", result); Can't this output a subtitle stream as it is currently done for Closed Captions? Imo, this would be helpful even without any formatting whatsoever. There are no subtitles in AVFrame nor in lavfi. But you could still do what was done for Closed Captions, or is that not possible? Where, which commit? He means the really terrible hack for the movie src filter, which shouldn't have been done at all. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add ocr filter
Le jour du Génie, an CCXXIII, wm4 a écrit : > He means the really terrible hack for the movie src filter, which shouldn't > have been done at all. We have verified users who use the feature. If you are not prepared to propose another solution for the same use, then either keep that kind of remark for yourself or go work on a project that favours code cleanliness over user satisfaction. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avutil/attributes: add AV_GCC_VERSION_AT_MOST
On Fri, Sep 18, 2015 at 01:04:52AM -0300, James Almer wrote: > Signed-off-by: James Almer > --- > doc/Doxyfile | 1 + > libavutil/arm/bswap.h| 4 ++-- > libavutil/arm/intreadwrite.h | 4 ++-- > libavutil/attributes.h | 2 ++ > libavutil/x86/bswap.h| 8 > 5 files changed, 11 insertions(+), 8 deletions(-) LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Breaking DRM is a little like attempting to break through a door even though the window is wide open and the only thing in the house is a bunch of things you dont want and which you would get tomorrow for free anyway signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avfilter/vf_chromakey: Add chromakey video filter
--- Changelog | 1 + MAINTAINERS| 1 + doc/filters.texi | 45 ++ libavfilter/Makefile | 1 + libavfilter/allfilters.c | 1 + libavfilter/version.h | 2 +- libavfilter/vf_chromakey.c | 211 + 7 files changed, 261 insertions(+), 1 deletion(-) create mode 100644 libavfilter/vf_chromakey.c diff --git a/Changelog b/Changelog index 653317f..db9064d 100644 --- a/Changelog +++ b/Changelog @@ -7,6 +7,7 @@ version : - ocr filter - alimiter filter - stereowiden filter +- chromakey filter version 2.8: diff --git a/MAINTAINERS b/MAINTAINERS index 4a50430..12da0cd 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -359,6 +359,7 @@ Filters: avf_avectorscope.cPaul B Mahol avf_showcqt.c Muhammad Faiz vf_blend.cPaul B Mahol + vf_chromakey.cTimo Rothenpieler vf_colorchannelmixer.cPaul B Mahol vf_colorbalance.c Paul B Mahol vf_colorkey.c Timo Rothenpieler 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. + +@item similarity +Similarity percentage with the key color. + +0.01 matches only the exact key color, while 1.0 matches everything. + +@item blend +Blend percentage. + +0.0 makes pixels either fully transparent, or not transparent at all. + +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. + +Litteral colors like "green" or "red" don't make sense with this enabled anymore. +This can be used to pass exact YUV values as hexadecimal numbers. +@end table + +@subsection Examples + +@itemize +@item +Make every green pixel in the input image transparent: +@example +ffmpeg -i input.png -vf chromakey=green out.png +@end example + +@item +Overlay a greenscreen-video on top of a static black background. +@example +ffmpeg -f lavfi -i color=c=black:s=1280x720 -i video.mp4 -shortest -filter_complex "[1:v]chromakey=0x70de77:0.1:0.2[ckout];[0:v][ckout]overlay[out]" -map "[out]" output.mkv +@end example +@end itemize + @section codecview Visualize information exported by some codecs. diff --git a/libavfilter/Makefile b/libavfilter/Makefile index 05effd6..2aa8603 100644 --- a/libavfilter/Makefile +++ b/libavfilter/Makefile @@ -102,6 +102,7 @@ OBJS-$(CONFIG_BLACKDETECT_FILTER)+= vf_blackdetect.o OBJS-$(CONFIG_BLACKFRAME_FILTER) += vf_blackframe.o OBJS-$(CONFIG_BLEND_FILTER) += vf_blend.o dualinput.o framesync.o OBJS-$(CONFIG_BOXBLUR_FILTER)+= vf_boxblur.o +OBJS-$(CONFIG_CHROMAKEY_FILTER) += vf_chromakey.o OBJS-$(CONFIG_CODECVIEW_FILTER) += vf_codecview.o OBJS-$(CONFIG_COLORBALANCE_FILTER) += vf_colorbalance.o OBJS-$(CONFIG_COLORCHANNELMIXER_FILTER) += vf_colorchannelmixer.o diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c index cab4564..5075fca 100644 --- a/libavfilter/allfilters.c +++ b/libavfilter/allfilters.c @@ -124,6 +124,7 @@ void avfilter_register_all(void) REGISTER_FILTER(BLACKFRAME, blackframe, vf); REGISTER_FILTER(BLEND, blend, vf); REGISTER_FILTER(BOXBLUR,boxblur,vf); +REGISTER_FILTER(CHROMAKEY, chromakey, vf); REGISTER_FILTER(CODECVIEW, codecview, vf); REGISTER_FILTER(COLORBALANCE, colorbalance, vf); REGISTER_FILTER(COLORCHANNELMIXER, colorchannelmixer, vf); diff --git a/libavfilter/version.h b/libavfilter/version.h index e918184..9d44fd0 100644 --- a/libavfilter/version.h +++ b/libavfilter/version.h @@ -30,7 +30,7 @@ #include "libavutil/version.h" #define LIBAVFILTER_VERSION_MAJOR 6 -#define LIBAVFILTER_VERSION_MINOR 5 +#define LIBAVFILTER_VERSION_MINOR 6 #define LIBAVFILTER_VERSION_MICRO 100 #define LIBAVFILTER_VERSION_INT AV_VERSION_INT(LIBAVFILTER_VERSION_MAJOR, \ diff --git a/libavfilter/vf_chromakey.c b/libavfilter/vf_chromakey.c new file mode 100644 index 000..4809e39 --- /dev/null +++ b/libavfilter/vf_chromakey.c @@ -0,0 +1,211 @@ +/* + * Copyright (c) 2015 Timo Rothenpieler + * + * 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
Re: [FFmpeg-devel] [PATCH] avfilter/vf_chromakey: Add chromakey video filter
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 | 211 > + > 7 files changed, 261 insertions(+), 1 deletion(-) > create mode 100644 libavfilter/vf_chromakey.c > > diff --git a/Changelog b/Changelog > index 653317f..db9064d 100644 > --- a/Changelog > +++ b/Changelog > @@ -7,6 +7,7 @@ version : > - ocr filter > - alimiter filter > - stereowiden filter > +- chromakey filter > > > version 2.8: > diff --git a/MAINTAINERS b/MAINTAINERS > index 4a50430..12da0cd 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -359,6 +359,7 @@ Filters: >avf_avectorscope.cPaul B Mahol >avf_showcqt.c Muhammad Faiz >vf_blend.cPaul B Mahol > + vf_chromakey.cTimo Rothenpieler >vf_colorchannelmixer.cPaul B Mahol >vf_colorbalance.c Paul B Mahol >vf_colorkey.c Timo Rothenpieler > 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. > + > +@item similarity > +Similarity percentage with the key color. > + > +0.01 matches only the exact key color, while 1.0 matches everything. > + > +@item blend > +Blend percentage. > + > +0.0 makes pixels either fully transparent, or not transparent at all. > + > +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. > + > +Litteral colors like "green" or "red" don't make sense with this enabled > anymore. > +This can be used to pass exact YUV values as hexadecimal numbers. > +@end table > + > +@subsection Examples > + > +@itemize > +@item > +Make every green pixel in the input image transparent: > +@example > +ffmpeg -i input.png -vf chromakey=green out.png > +@end example > + > +@item > +Overlay a greenscreen-video on top of a static black background. > +@example > +ffmpeg -f lavfi -i color=c=black:s=1280x720 -i video.mp4 -shortest > -filter_complex > "[1:v]chromakey=0x70de77:0.1:0.2[ckout];[0:v][ckout]overlay[out]" -map > "[out]" output.mkv > +@end example > +@end itemize > + > @section codecview > > Visualize information exported by some codecs. > diff --git a/libavfilter/Makefile b/libavfilter/Makefile > index 05effd6..2aa8603 100644 > --- a/libavfilter/Makefile > +++ b/libavfilter/Makefile > @@ -102,6 +102,7 @@ OBJS-$(CONFIG_BLACKDETECT_FILTER)+= > vf_blackdetect.o > OBJS-$(CONFIG_BLACKFRAME_FILTER) += vf_blackframe.o > OBJS-$(CONFIG_BLEND_FILTER) += vf_blend.o dualinput.o > framesync.o > OBJS-$(CONFIG_BOXBLUR_FILTER)+= vf_boxblur.o > +OBJS-$(CONFIG_CHROMAKEY_FILTER) += vf_chromakey.o > OBJS-$(CONFIG_CODECVIEW_FILTER) += vf_codecview.o > OBJS-$(CONFIG_COLORBALANCE_FILTER) += vf_colorbalance.o > OBJS-$(CONFIG_COLORCHANNELMIXER_FILTER) += vf_colorchannelmixer.o > diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c > index cab4564..5075fca 100644 > --- a/libavfilter/allfilters.c > +++ b/libavfilter/allfilters.c > @@ -124,6 +124,7 @@ void avfilter_register_all(void) > REGISTER_FILTER(BLACKFRAME, blackframe, vf); > REGISTER_FILTER(BLEND, blend, vf); > REGISTER_FILTER(BOXBLUR,boxblur,vf); > +REGISTER_FILTER(CHROMAKEY, chromakey, vf); > REGISTER_FILTER(CODECVIEW, codecview, vf); > REGISTER_FILTER(COLORBALANCE, colorbalance, vf); > REGISTER_FILTER(COLORCHANNELMIXER, colorchannelmixer, vf); > diff --git a/libavfilter/version.h b/libavfilter/version.h > index e918184..9d44fd0 100644 > --- a/libavfilter/version.h > +++ b/libavfilter/version.h > @@ -30,7 +30,7 @@ > #include "libavutil/version.h" > > #define LIBAVFILTER_VERSION_MAJOR 6 > -#define LIBAVFILTER_VERSION_MINOR 5 > +#define LIBAVFILTER_VERSION_MINOR 6 > #define LIBAVFILTER_VERSION_MICRO 100 > > #define LIBAVFILTER_VERSION_INT AV_VERSION_INT(LIBAVFILTER_VERSION_MAJOR, \ > diff --git a/libavfilter/vf_chromakey.c b/libavfilter/vf_chromakey.c > new file mode 100644 > index 000..4809e39 > --- /dev/null > +++ b/libavfilter/vf_chromakey.c > @@ -0,0 +1,211 @@ > +/* > + *
Re: [FFmpeg-devel] [PATCH] avfilter/avf_showcqt: use frequency domain windowing
On Fri, Sep 18, 2015 at 4:43 AM, Muhammad Faiz wrote: > On Thu, Sep 17, 2015 at 1:58 AM, Ganesh Ajjanagadde > wrote: > >> Have not checked what the filter is doing, but have a minor comment: >> int sign computation - please use FFSIGN. >> >> > the code doesn't extract sign of number, but decide for even index use > positive sign and for odd index use negative sign ah, ok - sorry about that. > > thanks > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/vf_chromakey: Add chromakey video filter
On 9/18/15, Paul B Mahol wrote: > 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 | 211 >> + >> 7 files changed, 261 insertions(+), 1 deletion(-) >> create mode 100644 libavfilter/vf_chromakey.c >> > Otherwise looks good, gonna test it. > Have you explored way how to handle borders? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCHv2] avfilter/vf_chromakey: Add chromakey video filter
--- Changelog | 1 + MAINTAINERS| 1 + doc/filters.texi | 45 ++ libavfilter/Makefile | 1 + libavfilter/allfilters.c | 1 + libavfilter/version.h | 2 +- libavfilter/vf_chromakey.c | 199 + 7 files changed, 249 insertions(+), 1 deletion(-) create mode 100644 libavfilter/vf_chromakey.c diff --git a/Changelog b/Changelog index 62d3a7a..461d0d6 100644 --- a/Changelog +++ b/Changelog @@ -8,6 +8,7 @@ version : - alimiter filter - stereowiden filter - stereotools filter +- chromakey filter version 2.8: diff --git a/MAINTAINERS b/MAINTAINERS index 4a50430..12da0cd 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -359,6 +359,7 @@ Filters: avf_avectorscope.cPaul B Mahol avf_showcqt.c Muhammad Faiz vf_blend.cPaul B Mahol + vf_chromakey.cTimo Rothenpieler vf_colorchannelmixer.cPaul B Mahol vf_colorbalance.c Paul B Mahol vf_colorkey.c Timo Rothenpieler 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. + +@item similarity +Similarity percentage with the key color. + +0.01 matches only the exact key color, while 1.0 matches everything. + +@item blend +Blend percentage. + +0.0 makes pixels either fully transparent, or not transparent at all. + +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. + +Litteral colors like "green" or "red" don't make sense with this enabled anymore. +This can be used to pass exact YUV values as hexadecimal numbers. +@end table + +@subsection Examples + +@itemize +@item +Make every green pixel in the input image transparent: +@example +ffmpeg -i input.png -vf chromakey=green out.png +@end example + +@item +Overlay a greenscreen-video on top of a static black background. +@example +ffmpeg -f lavfi -i color=c=black:s=1280x720 -i video.mp4 -shortest -filter_complex "[1:v]chromakey=0x70de77:0.1:0.2[ckout];[0:v][ckout]overlay[out]" -map "[out]" output.mkv +@end example +@end itemize + @section codecview Visualize information exported by some codecs. diff --git a/libavfilter/Makefile b/libavfilter/Makefile index 05effd6..2aa8603 100644 --- a/libavfilter/Makefile +++ b/libavfilter/Makefile @@ -102,6 +102,7 @@ OBJS-$(CONFIG_BLACKDETECT_FILTER)+= vf_blackdetect.o OBJS-$(CONFIG_BLACKFRAME_FILTER) += vf_blackframe.o OBJS-$(CONFIG_BLEND_FILTER) += vf_blend.o dualinput.o framesync.o OBJS-$(CONFIG_BOXBLUR_FILTER)+= vf_boxblur.o +OBJS-$(CONFIG_CHROMAKEY_FILTER) += vf_chromakey.o OBJS-$(CONFIG_CODECVIEW_FILTER) += vf_codecview.o OBJS-$(CONFIG_COLORBALANCE_FILTER) += vf_colorbalance.o OBJS-$(CONFIG_COLORCHANNELMIXER_FILTER) += vf_colorchannelmixer.o diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c index cab4564..5075fca 100644 --- a/libavfilter/allfilters.c +++ b/libavfilter/allfilters.c @@ -124,6 +124,7 @@ void avfilter_register_all(void) REGISTER_FILTER(BLACKFRAME, blackframe, vf); REGISTER_FILTER(BLEND, blend, vf); REGISTER_FILTER(BOXBLUR,boxblur,vf); +REGISTER_FILTER(CHROMAKEY, chromakey, vf); REGISTER_FILTER(CODECVIEW, codecview, vf); REGISTER_FILTER(COLORBALANCE, colorbalance, vf); REGISTER_FILTER(COLORCHANNELMIXER, colorchannelmixer, vf); diff --git a/libavfilter/version.h b/libavfilter/version.h index e918184..9d44fd0 100644 --- a/libavfilter/version.h +++ b/libavfilter/version.h @@ -30,7 +30,7 @@ #include "libavutil/version.h" #define LIBAVFILTER_VERSION_MAJOR 6 -#define LIBAVFILTER_VERSION_MINOR 5 +#define LIBAVFILTER_VERSION_MINOR 6 #define LIBAVFILTER_VERSION_MICRO 100 #define LIBAVFILTER_VERSION_INT AV_VERSION_INT(LIBAVFILTER_VERSION_MAJOR, \ diff --git a/libavfilter/vf_chromakey.c b/libavfilter/vf_chromakey.c new file mode 100644 index 000..3828ca9 --- /dev/null +++ b/libavfilter/vf_chromakey.c @@ -0,0 +1,199 @@ +/* + * Copyright (c) 2015 Timo Rothenpieler + * + * 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
Re: [FFmpeg-devel] [PATCHv2] avcodec: use HAVE_THREADS header guards to silence -Wunused-function
On Fri, Sep 18, 2015 at 4:40 AM, wm4 wrote:
> On 17.09.2015 15:07, Ganesh Ajjanagadde wrote:
>>
>> When compiled with --disable-pthreads, e.g
>>
>> http://fate.ffmpeg.org/report.cgi?time=20150917015044&slot=alpha-debian-qemu-gcc-4.7,
>> a bunch of -Wunused-functions are reported.
>> This patch should silence such warnings.
>>
>> Signed-off-by: Ganesh Ajjanagadde
>> ---
>> libavcodec/alac.c | 2 +-
>> libavcodec/exr.c | 2 +-
>> libavcodec/ffv1dec.c | 4 ++--
>> libavcodec/flacdec.c | 2 +-
>> libavcodec/h264.c | 2 +-
>> libavcodec/huffyuvdec.c| 2 +-
>> libavcodec/mdec.c | 2 +-
>> libavcodec/mimic.c | 4 ++--
>> libavcodec/mpeg12dec.c | 2 +-
>> libavcodec/mpeg4videodec.c | 2 +-
>> libavcodec/pngdec.c| 2 +-
>> libavcodec/takdec.c| 4 ++--
>> libavcodec/tta.c | 4 ++--
>> libavcodec/vp3.c | 4 ++--
>> libavcodec/vp8.c | 4 ++--
>> libavcodec/vp9.c | 2 +-
>> libavcodec/wavpack.c | 2 +-
>> 17 files changed, 23 insertions(+), 23 deletions(-)
>>
>> diff --git a/libavcodec/alac.c b/libavcodec/alac.c
>> index 827c0db..f2e5907 100644
>> --- a/libavcodec/alac.c
>> +++ b/libavcodec/alac.c
>> @@ -609,7 +609,7 @@ static av_cold int alac_decode_init(AVCodecContext *
>> avctx)
>> return 0;
>> }
>>
>> -static int init_thread_copy(AVCodecContext *avctx)
>> +av_unused static int init_thread_copy(AVCodecContext *avctx)
>> {
>> ALACContext *alac = avctx->priv_data;
>> alac->avctx = avctx;
>> diff --git a/libavcodec/exr.c b/libavcodec/exr.c
>> index 3b6b245..778088e 100644
>> --- a/libavcodec/exr.c
>> +++ b/libavcodec/exr.c
>> @@ -1426,7 +1426,7 @@ static av_cold int decode_init(AVCodecContext
>> *avctx)
>> return 0;
>> }
>>
>> -static int decode_init_thread_copy(AVCodecContext *avctx)
>> +av_unused static int decode_init_thread_copy(AVCodecContext *avctx)
>> {EXRContext *s = avctx->priv_data;
>>
>> // allocate thread data, used for non EXR_RAW compreesion types
>> diff --git a/libavcodec/ffv1dec.c b/libavcodec/ffv1dec.c
>> index 557b1a0..70ae37d 100644
>> --- a/libavcodec/ffv1dec.c
>> +++ b/libavcodec/ffv1dec.c
>> @@ -1008,7 +1008,7 @@ static int decode_frame(AVCodecContext *avctx, void
>> *data, int *got_frame, AVPac
>> return buf_size;
>> }
>>
>> -static int init_thread_copy(AVCodecContext *avctx)
>> +av_unused static int init_thread_copy(AVCodecContext *avctx)
>> {
>> FFV1Context *f = avctx->priv_data;
>> int i, ret;
>> @@ -1061,7 +1061,7 @@ static void copy_fields(FFV1Context *fsdst,
>> FFV1Context *fssrc, FFV1Context *fsr
>> }
>> }
>>
>> -static int update_thread_context(AVCodecContext *dst, const
>> AVCodecContext *src)
>> +av_unused static int update_thread_context(AVCodecContext *dst, const
>> AVCodecContext *src)
>> {
>> FFV1Context *fsrc = src->priv_data;
>> FFV1Context *fdst = dst->priv_data;
>> diff --git a/libavcodec/flacdec.c b/libavcodec/flacdec.c
>> index 8653da7..00744da 100644
>> --- a/libavcodec/flacdec.c
>> +++ b/libavcodec/flacdec.c
>> @@ -623,7 +623,7 @@ static int flac_decode_frame(AVCodecContext *avctx,
>> void *data,
>> return bytes_read;
>> }
>>
>> -static int init_thread_copy(AVCodecContext *avctx)
>> +av_unused static int init_thread_copy(AVCodecContext *avctx)
>> {
>> FLACContext *s = avctx->priv_data;
>> s->decoded_buffer = NULL;
>> diff --git a/libavcodec/h264.c b/libavcodec/h264.c
>> index b797893..fa66b53 100644
>> --- a/libavcodec/h264.c
>> +++ b/libavcodec/h264.c
>> @@ -701,7 +701,7 @@ av_cold int ff_h264_decode_init(AVCodecContext *avctx)
>> return 0;
>> }
>>
>> -static int decode_init_thread_copy(AVCodecContext *avctx)
>> +av_unused static int decode_init_thread_copy(AVCodecContext *avctx)
>> {
>> H264Context *h = avctx->priv_data;
>> int ret;
>> diff --git a/libavcodec/huffyuvdec.c b/libavcodec/huffyuvdec.c
>> index a700abb..eda11ee 100644
>> --- a/libavcodec/huffyuvdec.c
>> +++ b/libavcodec/huffyuvdec.c
>> @@ -571,7 +571,7 @@ static av_cold int decode_init(AVCodecContext *avctx)
>> return ret;
>> }
>>
>> -static av_cold int decode_init_thread_copy(AVCodecContext *avctx)
>> +av_unused static av_cold int decode_init_thread_copy(AVCodecContext
>> *avctx)
>> {
>> HYuvContext *s = avctx->priv_data;
>> int i, ret;
>> diff --git a/libavcodec/mdec.c b/libavcodec/mdec.c
>> index a9b7e82..b169ac6 100644
>> --- a/libavcodec/mdec.c
>> +++ b/libavcodec/mdec.c
>> @@ -233,7 +233,7 @@ static av_cold int decode_init(AVCodecContext *avctx)
>> return 0;
>> }
>>
>> -static av_cold int decode_init_thread_copy(AVCodecContext *avctx)
>> +av_unused static av_cold int decode_init_thread_copy(AVCodecContext
>> *avctx)
>> {
>> MDECContext * const a = avctx->priv_data;
>>
>> diff --git a/libavcodec/mimic.c b/libavcodec/mimic.c
>> index f5853b5..2d861b6 100644
>> --- a/libavcodec/mimic.c
>> +++ b/li
Re: [FFmpeg-devel] [PATCH] avfilter/vf_chromakey: Add chromakey video filter
Have you explored way how to handle borders? You mean the outmost pixels, where the calculation is slightly inaccurate? Or the greenscreen spilling into the object because of light reflections? The first could be addressed by adjusting the value for the out-of-bounds pixels. The later is harder to fix, and maybe even needs another filter for spill reduction which filters out the greenscreen color. You can already get quite good results by playing with the similarity and blend values, eliminating most of the spill. signature.asc Description: OpenPGP digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/hls: remove unused function
On Wed, Sep 16, 2015 at 8:26 PM, Ganesh Ajjanagadde
wrote:
> Fixes -Wunused-function from
> http://fate.ffmpeg.org/report.cgi?time=20150820031140&slot=arm64-darwin-clang-apple-5.1
>
> Signed-off-by: Ganesh Ajjanagadde
> ---
> libavformat/hls.c | 13 -
> 1 file changed, 13 deletions(-)
>
> diff --git a/libavformat/hls.c b/libavformat/hls.c
> index c16c770..2ea3a22 100644
> --- a/libavformat/hls.c
> +++ b/libavformat/hls.c
> @@ -495,19 +495,6 @@ static int ensure_playlist(HLSContext *c, struct
> playlist **pls, const char *url
> return 0;
> }
>
> -static int open_in(HLSContext *c, AVIOContext **in, const char *url)
> -{
> -AVDictionary *tmp = NULL;
> -int ret;
> -
> -av_dict_copy(&tmp, c->avio_opts, 0);
> -
> -ret = avio_open2(in, url, AVIO_FLAG_READ, c->interrupt_callback, &tmp);
> -
> -av_dict_free(&tmp);
> -return ret;
> -}
> -
> static int url_connect(struct playlist *pls, AVDictionary *opts,
> AVDictionary *opts2)
> {
> AVDictionary *tmp = NULL;
> --
> 2.5.2
>
ping; wm4 basically did not like my old patch: see
https://ffmpeg.org/pipermail/ffmpeg-devel/2015-August/177769.html for
his thoughts and my response. Here, I delete as opposed to comment out
the lines. I personally do not care about deleting vs commenting out;
but one of the two should be used.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv2] all: do standards compliant absdiff computation
On Wed, Sep 16, 2015 at 2:48 PM, Ganesh Ajjanagadde
wrote:
> This resolves implementation defined behavior, and also silences
> -Wabsolute-value in clang 3.5+.
> Moreover, the generated asm is identical to before modulo nop padding.
>
> Signed-off-by: Ganesh Ajjanagadde
> ---
> libavcodec/flashsv2enc.c | 8 +---
> libavfilter/vf_hqx.c | 8 +---
> libavfilter/vf_xbr.c | 7 ---
> 3 files changed, 14 insertions(+), 9 deletions(-)
>
> diff --git a/libavcodec/flashsv2enc.c b/libavcodec/flashsv2enc.c
> index c2c00f4..65db112 100644
> --- a/libavcodec/flashsv2enc.c
> +++ b/libavcodec/flashsv2enc.c
> @@ -412,12 +412,14 @@ static inline unsigned pixel_color15(const uint8_t *
> src)
>
> static inline unsigned int chroma_diff(unsigned int c1, unsigned int c2)
> {
> +#define ABSDIFF(a,b) (abs((int)(a)-(int)(b)))
> +
> unsigned int t1 = (c1 & 0x00ff) + ((c1 & 0xff00) >> 8) + ((c1 &
> 0x00ff) >> 16);
> unsigned int t2 = (c2 & 0x00ff) + ((c2 & 0xff00) >> 8) + ((c2 &
> 0x00ff) >> 16);
>
> -return abs(t1 - t2) + abs((c1 & 0x00ff) - (c2 & 0x00ff)) +
> -abs(((c1 & 0xff00) >> 8) - ((c2 & 0xff00) >> 8)) +
> -abs(((c1 & 0x00ff) >> 16) - ((c2 & 0x00ff) >> 16));
> +return ABSDIFF(t1, t2) + ABSDIFF(c1 & 0x00ff, c2 & 0x00ff) +
> +ABSDIFF((c1 & 0xff00) >> 8 , (c2 & 0xff00) >> 8) +
> +ABSDIFF((c1 & 0x00ff) >> 16, (c2 & 0x00ff) >> 16);
> }
>
> static inline int pixel_color7_fast(Palette * palette, unsigned c15)
> diff --git a/libavfilter/vf_hqx.c b/libavfilter/vf_hqx.c
> index fa15d9c..d1e360f 100644
> --- a/libavfilter/vf_hqx.c
> +++ b/libavfilter/vf_hqx.c
> @@ -65,9 +65,11 @@ static av_always_inline int yuv_diff(uint32_t yuv1,
> uint32_t yuv2)
> #define YMASK 0xff
> #define UMASK 0x00ff00
> #define VMASK 0xff
> -return abs((yuv1 & YMASK) - (yuv2 & YMASK)) > (48 << 16) ||
> - abs((yuv1 & UMASK) - (yuv2 & UMASK)) > ( 7 << 8) ||
> - abs((yuv1 & VMASK) - (yuv2 & VMASK)) > ( 6 << 0);
> +#define ABSDIFF(a,b) (abs((int)(a)-(int)(b)))
> +
> +return ABSDIFF(yuv1 & YMASK, yuv2 & YMASK) > (48 << 16) ||
> + ABSDIFF(yuv1 & UMASK, yuv2 & UMASK) > ( 7 << 8) ||
> + ABSDIFF(yuv1 & VMASK, yuv2 & VMASK) > ( 6 << 0);
> }
>
> /* (c1*w1 + c2*w2) >> s */
> diff --git a/libavfilter/vf_xbr.c b/libavfilter/vf_xbr.c
> index 8586608..c92e9a8 100644
> --- a/libavfilter/vf_xbr.c
> +++ b/libavfilter/vf_xbr.c
> @@ -65,13 +65,14 @@ static uint32_t pixel_diff(uint32_t x, uint32_t y, const
> uint32_t *r2y)
> #define YMASK 0xff
> #define UMASK 0x00ff00
> #define VMASK 0xff
> +#define ABSDIFF(a,b) (abs((int)(a)-(int)(b)))
>
> uint32_t yuv1 = r2y[x & 0xff];
> uint32_t yuv2 = r2y[y & 0xff];
>
> -return (abs((yuv1 & YMASK) - (yuv2 & YMASK)) >> 16) +
> - (abs((yuv1 & UMASK) - (yuv2 & UMASK)) >> 8) +
> - abs((yuv1 & VMASK) - (yuv2 & VMASK));
> +return (ABSDIFF(yuv1 & YMASK, yuv2 & YMASK) >> 16) +
> + (ABSDIFF(yuv1 & UMASK, yuv2 & UMASK) >> 8) +
> +ABSDIFF(yuv1 & VMASK, yuv2 & VMASK);
> }
>
> #define ALPHA_BLEND_128_W(a, b) a) & LB_MASK) >> 1) + (((b) & LB_MASK)
> >> 1))
> --
> 2.5.2
>
ping; the macro has now been localized.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/vf_chromakey: Add chromakey video filter
On 9/18/15, Timo Rothenpieler wrote: >> >> Have you explored way how to handle borders? > > You mean the outmost pixels, where the calculation is slightly inaccurate? > Or the greenscreen spilling into the object because of light reflections? Yes, the first one. > > The first could be addressed by adjusting the value for the > out-of-bounds pixels. This one is quite more obvious. Gonna write patch? > > The later is harder to fix, and maybe even needs another filter for > spill reduction which filters out the greenscreen color. > > You can already get quite good results by playing with the similarity > and blend values, eliminating most of the spill. > > > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] undefined left shift of negative number (clang 3.7+ warnings)
Hi all, Would like to bring to attention the undefined left shift of negative numbers that are found by latest clang 3.7.0 (-Wshift-negative-value). I send this because I have no idea important they are, but clearly they are of the type that interests static analyzers/fuzzers: e5aa6f702130f1afd53c61d058c2ebc48e61e9ea Anyway, I am not submitting a patch for one of them myself (libavcodec/apedec) as I do not even know whether current code is correct, e.g does it actually implicitly assume res (of type int) is 32 bits, and the shift by 30/31 is for high order bit stuff? In that case, additional change to int32_t is needed. More can be found e.g http://fate.ffmpeg.org/log.cgi?time=20150917122742&log=compile&slot=x86_64-darwin-clang-3.7-O3 Regards, Ganesh ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCHv3] avfilter/vf_chromakey: Add chromakey video filter
--- 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 diff --git a/Changelog b/Changelog index 62d3a7a..461d0d6 100644 --- a/Changelog +++ b/Changelog @@ -8,6 +8,7 @@ version : - alimiter filter - stereowiden filter - stereotools filter +- chromakey filter version 2.8: diff --git a/MAINTAINERS b/MAINTAINERS index 4a50430..12da0cd 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -359,6 +359,7 @@ Filters: avf_avectorscope.cPaul B Mahol avf_showcqt.c Muhammad Faiz vf_blend.cPaul B Mahol + vf_chromakey.cTimo Rothenpieler vf_colorchannelmixer.cPaul B Mahol vf_colorbalance.c Paul B Mahol vf_colorkey.c Timo Rothenpieler 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. + +@item similarity +Similarity percentage with the key color. + +0.01 matches only the exact key color, while 1.0 matches everything. + +@item blend +Blend percentage. + +0.0 makes pixels either fully transparent, or not transparent at all. + +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. + +Litteral colors like "green" or "red" don't make sense with this enabled anymore. +This can be used to pass exact YUV values as hexadecimal numbers. +@end table + +@subsection Examples + +@itemize +@item +Make every green pixel in the input image transparent: +@example +ffmpeg -i input.png -vf chromakey=green out.png +@end example + +@item +Overlay a greenscreen-video on top of a static black background. +@example +ffmpeg -f lavfi -i color=c=black:s=1280x720 -i video.mp4 -shortest -filter_complex "[1:v]chromakey=0x70de77:0.1:0.2[ckout];[0:v][ckout]overlay[out]" -map "[out]" output.mkv +@end example +@end itemize + @section codecview Visualize information exported by some codecs. diff --git a/libavfilter/Makefile b/libavfilter/Makefile index 05effd6..2aa8603 100644 --- a/libavfilter/Makefile +++ b/libavfilter/Makefile @@ -102,6 +102,7 @@ OBJS-$(CONFIG_BLACKDETECT_FILTER)+= vf_blackdetect.o OBJS-$(CONFIG_BLACKFRAME_FILTER) += vf_blackframe.o OBJS-$(CONFIG_BLEND_FILTER) += vf_blend.o dualinput.o framesync.o OBJS-$(CONFIG_BOXBLUR_FILTER)+= vf_boxblur.o +OBJS-$(CONFIG_CHROMAKEY_FILTER) += vf_chromakey.o OBJS-$(CONFIG_CODECVIEW_FILTER) += vf_codecview.o OBJS-$(CONFIG_COLORBALANCE_FILTER) += vf_colorbalance.o OBJS-$(CONFIG_COLORCHANNELMIXER_FILTER) += vf_colorchannelmixer.o diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c index cab4564..5075fca 100644 --- a/libavfilter/allfilters.c +++ b/libavfilter/allfilters.c @@ -124,6 +124,7 @@ void avfilter_register_all(void) REGISTER_FILTER(BLACKFRAME, blackframe, vf); REGISTER_FILTER(BLEND, blend, vf); REGISTER_FILTER(BOXBLUR,boxblur,vf); +REGISTER_FILTER(CHROMAKEY, chromakey, vf); REGISTER_FILTER(CODECVIEW, codecview, vf); REGISTER_FILTER(COLORBALANCE, colorbalance, vf); REGISTER_FILTER(COLORCHANNELMIXER, colorchannelmixer, vf); diff --git a/libavfilter/version.h b/libavfilter/version.h index e918184..9d44fd0 100644 --- a/libavfilter/version.h +++ b/libavfilter/version.h @@ -30,7 +30,7 @@ #include "libavutil/version.h" #define LIBAVFILTER_VERSION_MAJOR 6 -#define LIBAVFILTER_VERSION_MINOR 5 +#define LIBAVFILTER_VERSION_MINOR 6 #define LIBAVFILTER_VERSION_MICRO 100 #define LIBAVFILTER_VERSION_INT AV_VERSION_INT(LIBAVFILTER_VERSION_MAJOR, \ diff --git a/libavfilter/vf_chromakey.c b/libavfilter/vf_chromakey.c new file mode 100644 index 000..5e6280f --- /dev/null +++ b/libavfilter/vf_chromakey.c @@ -0,0 +1,198 @@ +/* + * Copyright (c) 2015 Timo Rothenpieler + * + * 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 Licens
[FFmpeg-devel] [PATCH] avcodec/imgconvert: Support non-planar colorspaces while padding
---
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));
+}
+}
+} else {
+if (src)
+return -1;
+
+av_image_fill_max_pixsteps(max_step, NULL, desc);
+
+if (padtop || padleft) {
+memset(dst->data[0], color[0],
+dst->linesize[0] * padtop + (padleft * max_step[0]));
}
-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;
+if (padleft || padright) {
+optr = dst->data[0] + dst->linesize[0] * padtop +
+(dst->linesize[0] - (padright * max_step[0]));
+yheight = height - 1 - (padtop + padbottom);
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];
+memset(optr, color[0], (padleft + padright) * max_step[0]);
+optr += dst->linesize[0];
}
}
Re: [FFmpeg-devel] [PATCH] avfilter: add ocr filter
On 18.09.2015 13:03, Nicolas George wrote: Le jour du Génie, an CCXXIII, wm4 a écrit : He means the really terrible hack for the movie src filter, which shouldn't have been done at all. We have verified users who use the feature. If you are not prepared to propose another solution for the same use, then either keep that kind of remark for yourself or go work on a project that favours code cleanliness over user satisfaction. Nice snarky, content-free remark. But you know that just because a hack got "blessed" because it has "verified users", this is not a reason to implement things in the right way, so that they are also maintainable and orthogonal. (Or what do you tell to a user who wants to add hardsubbing captions to his existing transcode commandline? Have fun.) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/mp3dec: Silence a warning if it makes no sense
On 16.09.2015 12:16, Carl Eugen Hoyos wrote: Hi! Attached patch silences the following warning: Skipping 0 bytes of junk at 5772990. NACK. It logs the byte position, and also you can know if the ffmpeg version includes this code. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/hls: remove unused function
On 18.09.2015 15:09, Ganesh Ajjanagadde wrote:
On Wed, Sep 16, 2015 at 8:26 PM, Ganesh Ajjanagadde
wrote:
Fixes -Wunused-function from
http://fate.ffmpeg.org/report.cgi?time=20150820031140&slot=arm64-darwin-clang-apple-5.1
Signed-off-by: Ganesh Ajjanagadde
---
libavformat/hls.c | 13 -
1 file changed, 13 deletions(-)
diff --git a/libavformat/hls.c b/libavformat/hls.c
index c16c770..2ea3a22 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -495,19 +495,6 @@ static int ensure_playlist(HLSContext *c, struct playlist
**pls, const char *url
return 0;
}
-static int open_in(HLSContext *c, AVIOContext **in, const char *url)
-{
-AVDictionary *tmp = NULL;
-int ret;
-
-av_dict_copy(&tmp, c->avio_opts, 0);
-
-ret = avio_open2(in, url, AVIO_FLAG_READ, c->interrupt_callback, &tmp);
-
-av_dict_free(&tmp);
-return ret;
-}
-
static int url_connect(struct playlist *pls, AVDictionary *opts, AVDictionary
*opts2)
{
AVDictionary *tmp = NULL;
--
2.5.2
ping; wm4 basically did not like my old patch: see
https://ffmpeg.org/pipermail/ffmpeg-devel/2015-August/177769.html for
his thoughts and my response. Here, I delete as opposed to comment out
the lines. I personally do not care about deleting vs commenting out;
but one of the two should be used.
If you think the inactive code is worth keeping, put it into a git
branch or tag the commit removing the code.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avfilter: slightly improve filters descriptions
Signed-off-by: Paul B Mahol
---
libavfilter/f_reverse.c | 2 +-
libavfilter/src_movie.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavfilter/f_reverse.c b/libavfilter/f_reverse.c
index 37c25e9..890be54 100644
--- a/libavfilter/f_reverse.c
+++ b/libavfilter/f_reverse.c
@@ -136,7 +136,7 @@ static const AVFilterPad reverse_outputs[] = {
AVFilter ff_vf_reverse = {
.name= "reverse",
-.description = NULL_IF_CONFIG_SMALL("Reverse a clip."),
+.description = NULL_IF_CONFIG_SMALL("Reverse a video clip."),
.priv_size = sizeof(ReverseContext),
.init= init,
.uninit = uninit,
diff --git a/libavfilter/src_movie.c b/libavfilter/src_movie.c
index bbdcbc8..4de0ab2 100644
--- a/libavfilter/src_movie.c
+++ b/libavfilter/src_movie.c
@@ -575,7 +575,7 @@ AVFILTER_DEFINE_CLASS(movie);
AVFilter ff_avsrc_movie = {
.name = "movie",
-.description = NULL_IF_CONFIG_SMALL("Read from a movie source."),
+.description = NULL_IF_CONFIG_SMALL("Read video from a movie source."),
.priv_size = sizeof(MovieContext),
.priv_class= &movie_class,
.init = movie_common_init,
--
1.7.11.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/hls: remove unused function
On Fri, Sep 18, 2015 at 11:08 AM, wm4 wrote:
> On 18.09.2015 15:09, Ganesh Ajjanagadde wrote:
>>
>> On Wed, Sep 16, 2015 at 8:26 PM, Ganesh Ajjanagadde
>> wrote:
>>>
>>> Fixes -Wunused-function from
>>>
>>> http://fate.ffmpeg.org/report.cgi?time=20150820031140&slot=arm64-darwin-clang-apple-5.1
>>>
>>> Signed-off-by: Ganesh Ajjanagadde
>>> ---
>>> libavformat/hls.c | 13 -
>>> 1 file changed, 13 deletions(-)
>>>
>>> diff --git a/libavformat/hls.c b/libavformat/hls.c
>>> index c16c770..2ea3a22 100644
>>> --- a/libavformat/hls.c
>>> +++ b/libavformat/hls.c
>>> @@ -495,19 +495,6 @@ static int ensure_playlist(HLSContext *c, struct
>>> playlist **pls, const char *url
>>> return 0;
>>> }
>>>
>>> -static int open_in(HLSContext *c, AVIOContext **in, const char *url)
>>> -{
>>> -AVDictionary *tmp = NULL;
>>> -int ret;
>>> -
>>> -av_dict_copy(&tmp, c->avio_opts, 0);
>>> -
>>> -ret = avio_open2(in, url, AVIO_FLAG_READ, c->interrupt_callback,
>>> &tmp);
>>> -
>>> -av_dict_free(&tmp);
>>> -return ret;
>>> -}
>>> -
>>> static int url_connect(struct playlist *pls, AVDictionary *opts,
>>> AVDictionary *opts2)
>>> {
>>> AVDictionary *tmp = NULL;
>>> --
>>> 2.5.2
>>>
>>
>> ping; wm4 basically did not like my old patch: see
>> https://ffmpeg.org/pipermail/ffmpeg-devel/2015-August/177769.html for
>> his thoughts and my response. Here, I delete as opposed to comment out
>> the lines. I personally do not care about deleting vs commenting out;
>> but one of the two should be used.
>
>
> If you think the inactive code is worth keeping, put it into a git branch or
> tag the commit removing the code.t
I do not have write access, so I will leave it up to you (or anyone
else pushing) to either apply the old patch or this one (and possibly
tag it if desired).
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add ocr filter
wm4: > Nice snarky, content-free remark. But you know that just because a hack got > "blessed" because it has "verified users", this is not a reason to implement > things in the right way, so that they are also maintainable and orthogonal. Do you intend to propose a patch that implements things "the right way", "orthogonal", in less than, let's say, two years? If not, do not criticize people who propose something that works. > (Or what do you tell to a user who wants to add hardsubbing captions to his > existing transcode commandline? Have fun.) Maybe I tell them to wait until the genius wm4 has condescended to implement it. My patches, either for sub2video or for subcc in movie, are indeed ugly hacks, I never denied it. But they work, right now, and they are of service to users. Furthermore, they are isolated features, without tendrils all over the place, without causing unrelated problems and ready to be removed when a proper implementation is committed. By disparaging them, you are insulting both me and every user who uses the features. There are very few people whose contributions are so invaluable that the community has to bear with their rudeness. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: slightly improve filters descriptions
Le jour du Génie, an CCXXIII, Paul B Mahol a écrit :
> .name = "movie",
> -.description = NULL_IF_CONFIG_SMALL("Read from a movie source."),
> +.description = NULL_IF_CONFIG_SMALL("Read video from a movie source."),
movie can read audio too.
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] x86/vp9: add avx2 subpel MC SIMD for 10/12bpp
On 9/18/2015 5:10 AM, Ronald S. Bultje wrote: > Cool, I was hoping that would work but don't have Intel's emulator; thanks > for testing && lgtm. > > Ronald Pushed. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: slightly improve filters descriptions
On 9/18/15, Nicolas George wrote:
> Le jour du Genie, an CCXXIII, Paul B Mahol a ecrit :
>> .name = "movie",
>> -.description = NULL_IF_CONFIG_SMALL("Read from a movie source."),
>> +.description = NULL_IF_CONFIG_SMALL("Read video from a movie
>> source."),
>
> movie can read audio too.
Yes, but that filter is called amovie, this one is called movie.
I failed to use movie filter with audio only file, please enlight me.
>
> Regards,
>
> --
> Nicolas George
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: slightly improve filters descriptions
Le jour du Génie, an CCXXIII, Paul B Mahol a écrit :
> Yes, but that filter is called amovie, this one is called movie.
>
> I failed to use movie filter with audio only file, please enlight me.
movie=${file}:s=v+a
The difference between movie and amovie lies only in the default value for
the s option: v or a.
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add ocr filter
I'm not interested in this inflammatory conversation, to be hones it should never started. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avutil/attributes: add AV_GCC_VERSION_AT_MOST
On 9/18/2015 8:46 AM, Michael Niedermayer wrote: > On Fri, Sep 18, 2015 at 01:04:52AM -0300, James Almer wrote: >> Signed-off-by: James Almer >> --- >> doc/Doxyfile | 1 + >> libavutil/arm/bswap.h| 4 ++-- >> libavutil/arm/intreadwrite.h | 4 ++-- >> libavutil/attributes.h | 2 ++ >> libavutil/x86/bswap.h| 8 >> 5 files changed, 11 insertions(+), 8 deletions(-) > > LGTM > > thx Pushed. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add ocr filter
On 18.09.2015 17:19, Nicolas George wrote: wm4: Nice snarky, content-free remark. But you know that just because a hack got "blessed" because it has "verified users", this is not a reason to implement things in the right way, so that they are also maintainable and orthogonal. Do you intend to propose a patch that implements things "the right way", "orthogonal", in less than, let's say, two years? If not, do not criticize people who propose something that works. I have no interest in ffmpeg.c, so of course I won't. But I had a pretty simple way to implement it in mpv without having to go through ridiculous things like a libavfilter movie source filter. It was probably 10 lines in total. (Or what do you tell to a user who wants to add hardsubbing captions to his existing transcode commandline? Have fun.) Maybe I tell them to wait until the genius wm4 has condescended to implement it. My patches, either for sub2video or for subcc in movie, are indeed ugly hacks, I never denied it. But they work, right now, and they are of service to users. Furthermore, they are isolated features, without tendrils all over the place, without causing unrelated problems and ready to be removed when a proper implementation is committed. By disparaging them, you are insulting both me and every user who uses the features. There are very few people whose contributions are so invaluable that the community has to bear with their rudeness. Honestly, I find most of your passively aggressive replies at least annoying and often enough definitely sound like they're intended to insult. You just did it again - read your mail. Maybe you could turn it down a little? And just for the protocol, yes, I called it a terrible hack, but you agree that it's an "ugly hack", so I'm not sure what I did wrong here. By implementing something as a hack, you put the burden on future generations of developers who somehow have to clean it up (instead of only having to implement it the right way), and of course without causing any "regressions". (Which means pretty please duplicate all the fucked corner-casey up stuff that happened to work because of a specific implementation etc.) You know, I don't do this to argue with you to death or because I enjoy fighting (surprisingly I don't) - I just want sane technical solutions, because just committing mistakes causes a magnitude of more work at a later point. Either because somehow has to clean it up, or because it'll be so hard to fix bugs/add features. Anyway, the bottom line is, no you can't output a subtitle stream, if you want to, add subtitles to lavfi. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: slightly improve filters descriptions
On 9/18/15, Nicolas George wrote:
> Le jour du Genie, an CCXXIII, Paul B Mahol a ecrit :
>> Yes, but that filter is called amovie, this one is called movie.
>>
>> I failed to use movie filter with audio only file, please enlight me.
>
> movie=${file}:s=v+a
>
> The difference between movie and amovie lies only in the default value for
> the s option: v or a.
Heh, why than amovie have 'audio' in its description
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add ocr filter
Le jour du Génie, an CCXXIII, wm4 a écrit : > And just for the protocol, yes, I called it a terrible hack, but you agree > that it's an "ugly hack", so I'm not sure what I did wrong here. Read Cyrano: Je me les sers à moi-même avec assez de verve Mais je ne permets pas qu'un autre me les serve. (Get a translation if you do not know it already.) And the insulting part was not just calling them hack but affirming that "shouldn't have been done at all", i.e. calling my work useless. > By implementing something as a hack, you put the burden on future > generations of developers who somehow have to clean it up (instead of only > having to implement it the right way), This is a lie. As I have just explained, and therefore you just read, I have made very sure that it was not the case: the hacks can be very easily removed, I have made sure of that. >and of course without causing any > "regressions". (Which means pretty please duplicate all the fucked > corner-casey up stuff that happened to work because of a specific > implementation etc.) > > You know, I don't do this to argue with you to death or because I enjoy > fighting Yes, you do. Otherwise, you would avoid inflammatory language like in the previous paragraph. So please stop. Stop disparaging other people's work, stop spitting in the soup, strop being altogether rude. EOT for me, sorry Paul. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/avf_showcqt: use frequency domain windowing
On Fri, Sep 18, 2015 at 08:55:51AM -0400, Ganesh Ajjanagadde wrote: > On Fri, Sep 18, 2015 at 4:43 AM, Muhammad Faiz wrote: > > On Thu, Sep 17, 2015 at 1:58 AM, Ganesh Ajjanagadde > > wrote: > > > >> Have not checked what the filter is doing, but have a minor comment: > >> int sign computation - please use FFSIGN. > >> > >> > > the code doesn't extract sign of number, but decide for even index use > > positive sign and for odd index use negative sign > > ah, ok - sorry about that. patch applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have never wished to cater to the crowd; for what I know they do not approve, and what they approve I do not know. -- Epicurus signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] AAC encoder: refactor to resynchronize MIPS port
On 9/15/2015 4:24 AM, Claudio Freire wrote: > This patch refactors the AAC coders to reuse code > between the MIPS port and the regular, portable C code. > There were two main functions that had to use > hand-optimized versions of quantization code: > - search_for_quantizers_twoloop > - codebook_trellis_rate > > Those two were split into their own template header > files so they can be inlined inside both the MIPS port > and the generic code. In each context, they'll link > to their specialized implementations, and thus be > optimized by the compiler. > > This approach I believe is better than maintaining > several copies of each function. As past experience has > proven, having to keep those in sync was error prone. > In this way, they will remain in sync by default. > > Also, an implementation of the reconstructed output > argument for the optimized quantize_and_encode > functions is included in the patch. While the current > implementation of search_for_pred still isn't using > it, future iterations of main prediction probably will. > It should not imply any measurable performance hit while > not being used. > > > Patch attached. This broke make checkheaders, since the new headers are purposely missing functions like abs_pow34_v() when compiled standalone. http://fate.ffmpeg.org/log.cgi?time=20150918161151&log=compile&slot=x86_64-archlinux-gcc-checkheaders ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH][RFC] configure: silence preprocessor noise from dependency generation
Currently, errors are thrown for various macros while building that are completely bogus. They occur during the dependency (.d) generation phase, and have no bearing on the compiled output, since only the stdout is piped into the sed command to generate the .d files. They basically occur as the relevant -I paths are not (and cannot be passed) during the dependancy generation phase. As such, this patch silences them. Signed-off-by: Ganesh Ajjanagadde --- configure | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure b/configure index e5d7b12..6f9be48 100755 --- a/configure +++ b/configure @@ -2975,7 +2975,7 @@ target_path='$(CURDIR)' # since the object filename is not given with the -MM flag, the compiler # is only able to print the basename, and we must add the path ourselves -DEPCMD='$(DEP$(1)) $(DEP$(1)FLAGS) $($(1)DEP_FLAGS) $< | sed -e "/^\#.*/d" -e "s,^[[:space:]]*$(*F)\\.o,$(@D)/$(*F).o," > $(@:.o=.d)' +DEPCMD='$(DEP$(1)) $(DEP$(1)FLAGS) $($(1)DEP_FLAGS) $< 2>/dev/null | sed -e "/^\#.*/d" -e "s,^[[:space:]]*$(*F)\\.o,$(@D)/$(*F).o," > $(@:.o=.d)' DEPFLAGS='-MM' # find source path -- 2.5.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv2] all: do standards compliant absdiff computation
On Fri, Sep 18, 2015 at 09:10:49AM -0400, Ganesh Ajjanagadde wrote:
> On Wed, Sep 16, 2015 at 2:48 PM, Ganesh Ajjanagadde
> wrote:
> > This resolves implementation defined behavior, and also silences
> > -Wabsolute-value in clang 3.5+.
> > Moreover, the generated asm is identical to before modulo nop padding.
> >
> > Signed-off-by: Ganesh Ajjanagadde
> > ---
> > libavcodec/flashsv2enc.c | 8 +---
> > libavfilter/vf_hqx.c | 8 +---
> > libavfilter/vf_xbr.c | 7 ---
> > 3 files changed, 14 insertions(+), 9 deletions(-)
> >
> > diff --git a/libavcodec/flashsv2enc.c b/libavcodec/flashsv2enc.c
> > index c2c00f4..65db112 100644
> > --- a/libavcodec/flashsv2enc.c
> > +++ b/libavcodec/flashsv2enc.c
> > @@ -412,12 +412,14 @@ static inline unsigned pixel_color15(const uint8_t *
> > src)
> >
> > static inline unsigned int chroma_diff(unsigned int c1, unsigned int c2)
> > {
> > +#define ABSDIFF(a,b) (abs((int)(a)-(int)(b)))
> > +
> > unsigned int t1 = (c1 & 0x00ff) + ((c1 & 0xff00) >> 8) + ((c1
> > & 0x00ff) >> 16);
> > unsigned int t2 = (c2 & 0x00ff) + ((c2 & 0xff00) >> 8) + ((c2
> > & 0x00ff) >> 16);
> >
> > -return abs(t1 - t2) + abs((c1 & 0x00ff) - (c2 & 0x00ff)) +
> > -abs(((c1 & 0xff00) >> 8) - ((c2 & 0xff00) >> 8)) +
> > -abs(((c1 & 0x00ff) >> 16) - ((c2 & 0x00ff) >> 16));
> > +return ABSDIFF(t1, t2) + ABSDIFF(c1 & 0x00ff, c2 & 0x00ff) +
> > +ABSDIFF((c1 & 0xff00) >> 8 , (c2 & 0xff00) >> 8) +
> > +ABSDIFF((c1 & 0x00ff) >> 16, (c2 & 0x00ff) >> 16);
> > }
> >
> > static inline int pixel_color7_fast(Palette * palette, unsigned c15)
> > diff --git a/libavfilter/vf_hqx.c b/libavfilter/vf_hqx.c
> > index fa15d9c..d1e360f 100644
> > --- a/libavfilter/vf_hqx.c
> > +++ b/libavfilter/vf_hqx.c
> > @@ -65,9 +65,11 @@ static av_always_inline int yuv_diff(uint32_t yuv1,
> > uint32_t yuv2)
> > #define YMASK 0xff
> > #define UMASK 0x00ff00
> > #define VMASK 0xff
> > -return abs((yuv1 & YMASK) - (yuv2 & YMASK)) > (48 << 16) ||
> > - abs((yuv1 & UMASK) - (yuv2 & UMASK)) > ( 7 << 8) ||
> > - abs((yuv1 & VMASK) - (yuv2 & VMASK)) > ( 6 << 0);
> > +#define ABSDIFF(a,b) (abs((int)(a)-(int)(b)))
> > +
> > +return ABSDIFF(yuv1 & YMASK, yuv2 & YMASK) > (48 << 16) ||
> > + ABSDIFF(yuv1 & UMASK, yuv2 & UMASK) > ( 7 << 8) ||
> > + ABSDIFF(yuv1 & VMASK, yuv2 & VMASK) > ( 6 << 0);
> > }
> >
> > /* (c1*w1 + c2*w2) >> s */
> > diff --git a/libavfilter/vf_xbr.c b/libavfilter/vf_xbr.c
> > index 8586608..c92e9a8 100644
> > --- a/libavfilter/vf_xbr.c
> > +++ b/libavfilter/vf_xbr.c
> > @@ -65,13 +65,14 @@ static uint32_t pixel_diff(uint32_t x, uint32_t y,
> > const uint32_t *r2y)
> > #define YMASK 0xff
> > #define UMASK 0x00ff00
> > #define VMASK 0xff
> > +#define ABSDIFF(a,b) (abs((int)(a)-(int)(b)))
> >
> > uint32_t yuv1 = r2y[x & 0xff];
> > uint32_t yuv2 = r2y[y & 0xff];
> >
> > -return (abs((yuv1 & YMASK) - (yuv2 & YMASK)) >> 16) +
> > - (abs((yuv1 & UMASK) - (yuv2 & UMASK)) >> 8) +
> > - abs((yuv1 & VMASK) - (yuv2 & VMASK));
> > +return (ABSDIFF(yuv1 & YMASK, yuv2 & YMASK) >> 16) +
> > + (ABSDIFF(yuv1 & UMASK, yuv2 & UMASK) >> 8) +
> > +ABSDIFF(yuv1 & VMASK, yuv2 & VMASK);
> > }
> >
> > #define ALPHA_BLEND_128_W(a, b) a) & LB_MASK) >> 1) + (((b) & LB_MASK)
> > >> 1))
> > --
> > 2.5.2
> >
>
> ping; the macro has now been localized.
applied
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
No human being will ever know the Truth, for even if they happen to say it
by chance, they would not even known they had done so. -- Xenophanes
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/rtmpcrypt: fix discarded const warning
This patch silences a -Wdiscarded-qualifiers observed with GCC 5.2.
Signed-off-by: Ganesh Ajjanagadde
---
libavformat/rtmpcrypt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/rtmpcrypt.c b/libavformat/rtmpcrypt.c
index 2065ec6..447dbc2 100644
--- a/libavformat/rtmpcrypt.c
+++ b/libavformat/rtmpcrypt.c
@@ -300,7 +300,7 @@ static int rtmpe_write(URLContext *h, const uint8_t *buf,
int size)
if (rt->handshaked) {
/* encrypt data to send to the server */
-av_rc4_crypt(&rt->key_out, buf, buf, size, NULL, 1);
+av_rc4_crypt(&rt->key_out, (uint8_t *)buf, buf, size, NULL, 1);
}
if ((ret = ffurl_write(rt->stream, buf, size)) < 0)
--
2.5.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/rtmpcrypt: fix discarded const warning
Le jour du Génie, an CCXXIII, Ganesh Ajjanagadde a écrit : > This patch silences a -Wdiscarded-qualifiers observed with GCC 5.2. > > Signed-off-by: Ganesh Ajjanagadde > --- > libavformat/rtmpcrypt.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) I am not sure this is correct: the buffer is const for a reason, the warning is right. An application would be completely allowed to give a buffer in read-only memory, or to reuse the contents of the buffer afterwards. Actually, I suspect this muxer, if used as first output in the tee muxer, would cause the next outputs to be corrupt. The correct fix would probably be to allocate a new buffer, probably keeping it in the context for performances reasons instead of allocating each time. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/rtmpcrypt: fix discarded const warning
On Fri, Sep 18, 2015 at 3:50 PM, Nicolas George wrote: > Le jour du Génie, an CCXXIII, Ganesh Ajjanagadde a écrit : >> This patch silences a -Wdiscarded-qualifiers observed with GCC 5.2. >> >> Signed-off-by: Ganesh Ajjanagadde >> --- >> libavformat/rtmpcrypt.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) > > I am not sure this is correct: the buffer is const for a reason, the warning > is right. An application would be completely allowed to give a buffer in > read-only memory, or to reuse the contents of the buffer afterwards. > > Actually, I suspect this muxer, if used as first output in the tee muxer, > would cause the next outputs to be corrupt. It is indeed fishy, since making it non-const essentially violates the url_write const'ness. > > The correct fix would probably be to allocate a new buffer, probably keeping > it in the context for performances reasons instead of allocating each time. This sounds better. I did not think that creation of a separate buffer would be necessary and wanted to avoid it unless absolutely essential; will change based on this. Thanks. > > Regards, > > -- > Nicolas George > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avfilter: add rubberband wrapper
Signed-off-by: Paul B Mahol
---
configure | 5 +
libavfilter/Makefile| 1 +
libavfilter/af_rubberband.c | 225
libavfilter/allfilters.c| 1 +
4 files changed, 232 insertions(+)
create mode 100644 libavfilter/af_rubberband.c
diff --git a/configure b/configure
index 839c85d..d2a25bb 100755
--- a/configure
+++ b/configure
@@ -236,6 +236,7 @@ External library support:
--enable-libopenjpeg enable JPEG 2000 de/encoding via OpenJPEG [no]
--enable-libopus enable Opus de/encoding via libopus [no]
--enable-libpulseenable Pulseaudio input via libpulse [no]
+ --enable-librubberband enable rubberband needed for rubberband filter [no]
--enable-libquvi enable quvi input via libquvi [no]
--enable-librtmp enable RTMP[E] support via librtmp [no]
--enable-libschroedinger enable Dirac de/encoding via libschroedinger [no]
@@ -1405,6 +1406,7 @@ EXTERNAL_LIBRARY_LIST="
libpulse
libquvi
librtmp
+librubberband
libschroedinger
libshine
libsmbclient
@@ -2789,6 +2791,7 @@ pullup_filter_deps="gpl"
removelogo_filter_deps="avcodec avformat swscale"
repeatfields_filter_deps="gpl"
resample_filter_deps="avresample"
+rubberband_filter_deps="librubberband"
sab_filter_deps="gpl swscale"
scale_filter_deps="swscale"
scale2ref_filter_deps="swscale"
@@ -4661,6 +4664,7 @@ die_license_disabled_gpl() {
die_license_disabled gpl frei0r
die_license_disabled gpl libcdio
+die_license_disabled gpl librubberband
die_license_disabled gpl libsmbclient
die_license_disabled gpl libutvideo
die_license_disabled gpl libvidstab
@@ -5271,6 +5275,7 @@ enabled libopus && require_pkg_config opus
opus_multistream.h opus_mul
enabled libpulse && require_pkg_config libpulse pulse/pulseaudio.h
pa_context_new
enabled libquvi && require_pkg_config libquvi quvi/quvi.h quvi_init
enabled librtmp && require_pkg_config librtmp librtmp/rtmp.h
RTMP_Socket
+enabled librubberband && require_pkg_config rubberband
rubberband/rubberband-c.h rubberband_new
enabled libschroedinger && require_pkg_config schroedinger-1.0
schroedinger/schro.h schro_init
enabled libshine && require_pkg_config shine shine/layer3.h
shine_encode_buffer
enabled libsmbclient && { use_pkg_config smbclient libsmbclient.h
smbc_init ||
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 05effd6..4bbe972 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -77,6 +77,7 @@ OBJS-$(CONFIG_LOWPASS_FILTER)+= af_biquads.o
OBJS-$(CONFIG_PAN_FILTER)+= af_pan.o
OBJS-$(CONFIG_REPLAYGAIN_FILTER) += af_replaygain.o
OBJS-$(CONFIG_RESAMPLE_FILTER) += af_resample.o
+OBJS-$(CONFIG_RUBBERBAND_FILTER) += af_rubberband.o
OBJS-$(CONFIG_SIDECHAINCOMPRESS_FILTER) += af_sidechaincompress.o
OBJS-$(CONFIG_SILENCEDETECT_FILTER) += af_silencedetect.o
OBJS-$(CONFIG_SILENCEREMOVE_FILTER) += af_silenceremove.o
diff --git a/libavfilter/af_rubberband.c b/libavfilter/af_rubberband.c
new file mode 100644
index 000..a2cca2c
--- /dev/null
+++ b/libavfilter/af_rubberband.c
@@ -0,0 +1,225 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include
+
+#include "libavutil/channel_layout.h"
+#include "libavutil/common.h"
+#include "libavutil/opt.h"
+
+#include "audio.h"
+#include "avfilter.h"
+#include "formats.h"
+#include "internal.h"
+
+typedef struct RubberBandContext {
+const AVClass *class;
+RubberBandState rbs;
+
+double tempo, pitch;
+int transients, detector, phase, window,
+smoothing, formant, pitch, channels;
+int64_t nb_samples_out;
+int flushed;
+} RubberBandContext;
+
+#define OFFSET(x) offsetof(RubberBandContext, x)
+#define A AV_OPT_FLAG_AUDIO_PARAM|AV_OPT_FLAG_FILTERING_PARAM
+
+static const AVOption rubberband_options[] = {
+{ "tempo", "set tempo scale factor", OFFSET(tempo),
AV_OPT_TYPE_DOUBLE, {.dbl=1}, 0.01, 100, A },
+{ "pitch", "set pitch scale factor", OFFSET(pitch),
AV_OPT_TYPE_DOUBLE, {.dbl=1}, 0.01, 100, A },
+{ "transients", "set transients", OFFSET(transients), AV_OPT_TYPE
[FFmpeg-devel] [PATCH] libswscale/swscale: fix -Wunused-function
hyscale, hcscale are only used in old filter code, hence place header guard to silence -Wunused-function. Signed-off-by: Ganesh Ajjanagadde --- libswscale/swscale.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/libswscale/swscale.c b/libswscale/swscale.c index 120bba1..f4aa41b 100644 --- a/libswscale/swscale.c +++ b/libswscale/swscale.c @@ -240,6 +240,7 @@ static void lumRangeFromJpeg16_c(int16_t *_dst, int width) dst[i] = (dst[i]*(14071/4) + (33561947<<4)/4)>>12; } +#ifndef NEW_FILTER // *** horizontal scale Y line to temp buffer static av_always_inline void hyscale(SwsContext *c, int16_t *dst, int dstWidth, const uint8_t *src_in[4], @@ -311,6 +312,7 @@ static av_always_inline void hcscale(SwsContext *c, int16_t *dst1, if (c->chrConvertRange) c->chrConvertRange(dst1, dst2, dstWidth); } +#endif /* NEW_FILTER */ #define DEBUG_SWSCALE_BUFFERS 0 #define DEBUG_BUFFERS(...) \ -- 2.5.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add rubberband wrapper
On 9/18/2015 5:22 PM, Paul B Mahol wrote: > Signed-off-by: Paul B Mahol > --- > configure | 5 + > libavfilter/Makefile| 1 + > libavfilter/af_rubberband.c | 225 > > libavfilter/allfilters.c| 1 + > 4 files changed, 232 insertions(+) > create mode 100644 libavfilter/af_rubberband.c This needs a line in the "compatible libraries" section of LICENSE.md mentioning librubberband is gpl. That section is outdated for that matter. It's missing other libraries. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] FFMPEG build
Hi, How to build a single module or file in ffmpeg? currently I am using "make" and it trigger a full build. Thanks, Rajesh.M ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add ocr filter
On September 18, 2015 9:12:46 PM IST, wm4 wrote: >On 18.09.2015 17:19, Nicolas George wrote: >> wm4: >>> Nice snarky, content-free remark. But you know that just because a >hack got >>> "blessed" because it has "verified users", this is not a reason to >implement >>> things in the right way, so that they are also maintainable and >orthogonal. >> >> Do you intend to propose a patch that implements things "the right >way", >> "orthogonal", in less than, let's say, two years? If not, do not >criticize >> people who propose something that works. > >I have no interest in ffmpeg.c, so of course I won't. But I had a >pretty >simple way to implement it in mpv without having to go through >ridiculous things like a libavfilter movie source filter. It was >probably 10 lines in total. > >>> (Or what do you tell to a user who wants to add hardsubbing captions >to his >>> existing transcode commandline? Have fun.) >> >> Maybe I tell them to wait until the genius wm4 has condescended to >implement >> it. >> >> My patches, either for sub2video or for subcc in movie, are indeed >ugly >> hacks, I never denied it. But they work, right now, and they are of >service >> to users. Furthermore, they are isolated features, without tendrils >all over >> the place, without causing unrelated problems and ready to be removed >when a >> proper implementation is committed. >> >> By disparaging them, you are insulting both me and every user who >uses the >> features. There are very few people whose contributions are so >invaluable >> that the community has to bear with their rudeness. > >Honestly, I find most of your passively aggressive replies at least >annoying and often enough definitely sound like they're intended to >insult. You just did it again - read your mail. Maybe you could turn it > >down a little? > >And just for the protocol, yes, I called it a terrible hack, but you >agree that it's an "ugly hack", so I'm not sure what I did wrong here. > >By implementing something as a hack, you put the burden on future >generations of developers who somehow have to clean it up (instead of >only having to implement it the right way), and of course without >causing any "regressions". (Which means pretty please duplicate all the > >fucked corner-casey up stuff that happened to work because of a >specific >implementation etc.) > >You know, I don't do this to argue with you to death or because I enjoy > >fighting (surprisingly I don't) - I just want sane technical solutions, > >because just committing mistakes causes a magnitude of more work at a >later point. Either because somehow has to clean it up, or because >it'll >be so hard to fix bugs/add features. > >Anyway, the bottom line is, no you can't output a subtitle stream, if >you want to, add subtitles to lavfi. > >___ Hey guys, Dont want to add salt in this fight, But on end note can anyone define what is "hack" ? Because I get this answer to most of my approch. Mine Analysed defination of hack in this community is that when other developers dont understand the code or when it is out of the general aproch, developers here call it hack. I might be wrong with my notion but I am asking to confirm. this question was also creeping in my brain because none of Google defination match here: Hack: verb cut with rough or heavy blows. gain unauthorized access to data in a system or computer. cough persistently. manage; cope. noun a rough cut, blow, or stroke. an act of computer hacking. Note: I dont want to hijack original thread, so please explain with refrence to this thread that which way of implentation wont be consider hack, which ways for ocr would be consider hack. I am not speaking to make fun or insult, but it was far easy to implement ocr of dvbsub to get srt from dvbdub in ccextractor then here in FFmpeg because of unclear definition of hack. So I beg to make it clear today. I really dont want answers in gurbish, like: 1) hack is that it would make difficult to developer or maintainer( until how do you scale difficult and easy, as per human brain is concerned difficult is what we dont understand which is non comparative ) The worst answer of hack is that: this is not the way I do in ffmpeg, Since that is the reason you could not do it and new approch is needed. Thanks Anshul -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/rtmpcrypt: fix discarded const warning
On Fri, Sep 18, 2015 at 09:50:29PM +0200, Nicolas George wrote: > Le jour du Génie, an CCXXIII, Ganesh Ajjanagadde a écrit : > > This patch silences a -Wdiscarded-qualifiers observed with GCC 5.2. > > > > Signed-off-by: Ganesh Ajjanagadde > > --- > > libavformat/rtmpcrypt.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > I am not sure this is correct: the buffer is const for a reason, the warning > is right. An application would be completely allowed to give a buffer in > read-only memory, or to reuse the contents of the buffer afterwards. > > Actually, I suspect this muxer, if used as first output in the tee muxer, > would cause the next outputs to be corrupt. IIRC the code is safe, just ugly the writing only occurs if handshaked is set, which is only set by ff_rtmpe_update_keystream() which is not part of the public interface and only called from libavformat/rtmpproto.c i assume but did not double check that libavformat/rtmpproto.c calls the functions so that writable buffers are used > > The correct fix would probably be to allocate a new buffer, probably keeping > it in the context for performances reasons instead of allocating each time. id need to double check but i think the calling code possibly uses the written buffer with the expectation that it has been updated if that is so then such fix would break it. [...] -- 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
[FFmpeg-devel] [PATCH] avformat/movenc: suppress -Wstrict-overflow warnings
This patch results in identical behavior of movenc, and suppresses
-Wstrict-overflow
warnings observed in GCC 5.2.
I have manually checked that all usages are safe, and overflow possibility does
not exist with this expression rewrite.
Signed-off-by: Ganesh Ajjanagadde
---
libavformat/movenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index af03d1e..6e4a1a6 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -854,7 +854,7 @@ static int get_cluster_duration(MOVTrack *track, int
cluster_idx)
{
int64_t next_dts;
-if (cluster_idx >= track->entry)
+if (cluster_idx - track->entry >= 0)
return 0;
if (cluster_idx + 1 == track->entry)
--
2.5.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] AAC encoder: refactor to resynchronize MIPS port
On Fri, Sep 18, 2015 at 3:10 PM, James Almer wrote: > On 9/15/2015 4:24 AM, Claudio Freire wrote: >> This patch refactors the AAC coders to reuse code >> between the MIPS port and the regular, portable C code. >> There were two main functions that had to use >> hand-optimized versions of quantization code: >> - search_for_quantizers_twoloop >> - codebook_trellis_rate >> >> Those two were split into their own template header >> files so they can be inlined inside both the MIPS port >> and the generic code. In each context, they'll link >> to their specialized implementations, and thus be >> optimized by the compiler. >> >> This approach I believe is better than maintaining >> several copies of each function. As past experience has >> proven, having to keep those in sync was error prone. >> In this way, they will remain in sync by default. >> >> Also, an implementation of the reconstructed output >> argument for the optimized quantize_and_encode >> functions is included in the patch. While the current >> implementation of search_for_pred still isn't using >> it, future iterations of main prediction probably will. >> It should not imply any measurable performance hit while >> not being used. >> >> >> Patch attached. > > This broke make checkheaders, since the new headers are purposely > missing functions like abs_pow34_v() when compiled standalone. > http://fate.ffmpeg.org/log.cgi?time=20150918161151&log=compile&slot=x86_64-archlinux-gcc-checkheaders I wasn't aware of checkheaders. I'll add it to skipheaders. ___ 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
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&log=compile&slot=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. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/xface: suppress -Wstrict-overflow warnings
This patch results in identical behavior of xface, and suppresses
-Wstrict-overflow
warnings observed in GCC 5.2.
I have manually checked that this usage is safe, and overflow possibility does
not exist with this expression rewrite.
Signed-off-by: Ganesh Ajjanagadde
---
libavcodec/xface.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/xface.c b/libavcodec/xface.c
index 8c0cbfd..78b6def 100644
--- a/libavcodec/xface.c
+++ b/libavcodec/xface.c
@@ -315,7 +315,7 @@ void ff_xface_generate_face(uint8_t *dst, uint8_t * const
src)
for (l = i - 2; l <= i + 2; l++) {
for (m = j - 2; m <= j; m++) {
-if (l >= i && m == j)
+if ((l - i >= 0) && m == j)
continue;
if (l > 0 && l <= XFACE_WIDTH && m > 0)
k = 2*k + src[l + m * XFACE_WIDTH];
--
2.5.2
___
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
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&log=compile&slot=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. > ___ > 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] libswscale/swscale: fix -Wunused-function
On Fri, Sep 18, 2015 at 04:35:33PM -0400, Ganesh Ajjanagadde wrote: > hyscale, hcscale are only used in old filter code, hence place > header guard to silence -Wunused-function. > > Signed-off-by: Ganesh Ajjanagadde > --- > libswscale/swscale.c | 2 ++ > 1 file changed, 2 insertions(+) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No snowflake in an avalanche ever feels responsible. -- Voltaire signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/ac3enc: use long long after switch to 64 bit bitrate
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&log=compile&slot=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. 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] [PATCH 1/2] avcodec/vda_h264: use multichar literal portably
Multichar literals are implementation defined, and thus trigger -Wmultichar: http://fate.ffmpeg.org/log.cgi?time=20150918202532&log=compile&slot=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'); +int32_t pix_fmt = vda_ctx->cv_pix_fmt_type; // kCVPixelFormatType_420YpCbCr8Planar; -- 2.5.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] avcodec/vda_h264_dec: use multichar literal portably
Multichar literals are implementation defined, and thus trigger -Wmultichar:
http://fate.ffmpeg.org/log.cgi?time=20150918202532&log=compile&slot=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_dec.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/libavcodec/vda_h264_dec.c b/libavcodec/vda_h264_dec.c
index a092693..c3899d8 100644
--- a/libavcodec/vda_h264_dec.c
+++ b/libavcodec/vda_h264_dec.c
@@ -186,22 +186,23 @@ static av_cold int vdadec_init(AVCodecContext *avctx)
memset(vda_ctx, 0, sizeof(struct vda_context));
vda_ctx->width = avctx->width;
vda_ctx->height = avctx->height;
-vda_ctx->format = 'avc1';
+#define LE_CHR(a,b,c,d) ( ((a)<<24) | ((b)<<16) | ((c)<<8) | (d) )
+vda_ctx->format = LE_CHR( 'a', 'v', 'c', '1');
vda_ctx->use_sync_decoding = 1;
vda_ctx->use_ref_buffer = 1;
ctx->pix_fmt = avctx->get_format(avctx, avctx->codec->pix_fmts);
switch (ctx->pix_fmt) {
case AV_PIX_FMT_UYVY422:
-vda_ctx->cv_pix_fmt_type = '2vuy';
+vda_ctx->cv_pix_fmt_type = LE_CHR( '2', 'v', 'u', 'y');
break;
case AV_PIX_FMT_YUYV422:
-vda_ctx->cv_pix_fmt_type = 'yuvs';
+vda_ctx->cv_pix_fmt_type = LE_CHR( 'y', 'u', 'v', 's');
break;
case AV_PIX_FMT_NV12:
-vda_ctx->cv_pix_fmt_type = '420v';
+vda_ctx->cv_pix_fmt_type = LE_CHR( '4', '2', '0', 'v');
break;
case AV_PIX_FMT_YUV420P:
-vda_ctx->cv_pix_fmt_type = 'y420';
+vda_ctx->cv_pix_fmt_type = LE_CHR( 'y', '4', '2', '0');
break;
default:
av_log(avctx, AV_LOG_ERROR, "Unsupported pixel format: %d\n",
avctx->pix_fmt);
--
2.5.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avdevice/xcbgrab: fix -Wunused-variable
This patch fixes a -Wunused-variable reported in e.g
http://fate.ffmpeg.org/log.cgi?time=20150918194649&log=compile&slot=x86_64-debian-asan-144800.
av_unused is used as opposed to a header guard for readability.
Signed-off-by: Ganesh Ajjanagadde
---
libavdevice/xcbgrab.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavdevice/xcbgrab.c b/libavdevice/xcbgrab.c
index f169f93..2da7ec7 100644
--- a/libavdevice/xcbgrab.c
+++ b/libavdevice/xcbgrab.c
@@ -591,7 +591,7 @@ static void setup_window(AVFormatContext *s)
uint32_t values[] = { 1,
XCB_EVENT_MASK_EXPOSURE |
XCB_EVENT_MASK_STRUCTURE_NOTIFY };
-xcb_rectangle_t rect = { 0, 0, c->width, c->height };
+av_unused xcb_rectangle_t rect = { 0, 0, c->width, c->height };
c->window = xcb_generate_id(c->conn);
--
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/vda_h264: use multichar literal portably
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&log=compile&slot=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
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCHv2 1/2] avcodec/vda_h264: use multichar literal portably
Multichar literals are implementation defined, and thus trigger -Wmultichar:
http://fate.ffmpeg.org/log.cgi?time=20150918202532&log=compile&slot=x86_64-darwin-gcc-5.
This patch replaces them with AV_RB32.
Signed-off-by: Ganesh Ajjanagadde
---
libavcodec/vda_h264.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/vda_h264.c b/libavcodec/vda_h264.c
index 8c526c0..bd411cc 100644
--- a/libavcodec/vda_h264.c
+++ b/libavcodec/vda_h264.c
@@ -339,7 +339,7 @@ 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;
+int32_t fmt = AV_RB32("avc1"), pix_fmt = vda_ctx->cv_pix_fmt_type;
// kCVPixelFormatType_420YpCbCr8Planar;
--
2.5.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCHv2 2/2] avcodec/vda_h264_dec: use multichar literal portably
Multichar literals are implementation defined, and thus trigger -Wmultichar:
http://fate.ffmpeg.org/log.cgi?time=20150918202532&log=compile&slot=x86_64-darwin-gcc-5.
This patch uses AV_RB32 to silence such warnings.
Signed-off-by: Ganesh Ajjanagadde
---
libavcodec/vda_h264_dec.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavcodec/vda_h264_dec.c b/libavcodec/vda_h264_dec.c
index a092693..0a54747 100644
--- a/libavcodec/vda_h264_dec.c
+++ b/libavcodec/vda_h264_dec.c
@@ -186,22 +186,22 @@ static av_cold int vdadec_init(AVCodecContext *avctx)
memset(vda_ctx, 0, sizeof(struct vda_context));
vda_ctx->width = avctx->width;
vda_ctx->height = avctx->height;
-vda_ctx->format = 'avc1';
+vda_ctx->format = AV_RB32("avc1");
vda_ctx->use_sync_decoding = 1;
vda_ctx->use_ref_buffer = 1;
ctx->pix_fmt = avctx->get_format(avctx, avctx->codec->pix_fmts);
switch (ctx->pix_fmt) {
case AV_PIX_FMT_UYVY422:
-vda_ctx->cv_pix_fmt_type = '2vuy';
+vda_ctx->cv_pix_fmt_type = AV_RB32("2vuy");
break;
case AV_PIX_FMT_YUYV422:
-vda_ctx->cv_pix_fmt_type = 'yuvs';
+vda_ctx->cv_pix_fmt_type = AV_RB32("yuvs");
break;
case AV_PIX_FMT_NV12:
-vda_ctx->cv_pix_fmt_type = '420v';
+vda_ctx->cv_pix_fmt_type = AV_RB32("420v");
break;
case AV_PIX_FMT_YUV420P:
-vda_ctx->cv_pix_fmt_type = 'y420';
+vda_ctx->cv_pix_fmt_type = AV_RB32("y420");
break;
default:
av_log(avctx, AV_LOG_ERROR, "Unsupported pixel format: %d\n",
avctx->pix_fmt);
--
2.5.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv2 2/2] avcodec/vda_h264_dec: use multichar literal portably
On Fri, Sep 18, 2015 at 7:28 PM, Ganesh Ajjanagadde
wrote:
> Multichar literals are implementation defined, and thus trigger -Wmultichar:
> http://fate.ffmpeg.org/log.cgi?time=20150918202532&log=compile&slot=x86_64-darwin-gcc-5.
> This patch uses AV_RB32 to silence such warnings.
>
> Signed-off-by: Ganesh Ajjanagadde
> ---
> libavcodec/vda_h264_dec.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/libavcodec/vda_h264_dec.c b/libavcodec/vda_h264_dec.c
> index a092693..0a54747 100644
> --- a/libavcodec/vda_h264_dec.c
> +++ b/libavcodec/vda_h264_dec.c
> @@ -186,22 +186,22 @@ static av_cold int vdadec_init(AVCodecContext *avctx)
> memset(vda_ctx, 0, sizeof(struct vda_context));
> vda_ctx->width = avctx->width;
> vda_ctx->height = avctx->height;
> -vda_ctx->format = 'avc1';
> +vda_ctx->format = AV_RB32("avc1");
> vda_ctx->use_sync_decoding = 1;
> vda_ctx->use_ref_buffer = 1;
> ctx->pix_fmt = avctx->get_format(avctx, avctx->codec->pix_fmts);
> switch (ctx->pix_fmt) {
> case AV_PIX_FMT_UYVY422:
> -vda_ctx->cv_pix_fmt_type = '2vuy';
> +vda_ctx->cv_pix_fmt_type = AV_RB32("2vuy");
> break;
> case AV_PIX_FMT_YUYV422:
> -vda_ctx->cv_pix_fmt_type = 'yuvs';
> +vda_ctx->cv_pix_fmt_type = AV_RB32("yuvs");
> break;
> case AV_PIX_FMT_NV12:
> -vda_ctx->cv_pix_fmt_type = '420v';
> +vda_ctx->cv_pix_fmt_type = AV_RB32("420v");
> break;
> case AV_PIX_FMT_YUV420P:
> -vda_ctx->cv_pix_fmt_type = 'y420';
> +vda_ctx->cv_pix_fmt_type = AV_RB32("y420");
> break;
> default:
> av_log(avctx, AV_LOG_ERROR, "Unsupported pixel format: %d\n",
> avctx->pix_fmt);
> --
> 2.5.2
>
Apologies; forgot to put the v2.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avdevice/xcbgrab: fix -Wunused-variable
On Fri, Sep 18, 2015 at 06:17:42PM -0400, Ganesh Ajjanagadde wrote: > This patch fixes a -Wunused-variable reported in e.g > http://fate.ffmpeg.org/log.cgi?time=20150918194649&log=compile&slot=x86_64-debian-asan-144800. > av_unused is used as opposed to a header guard for readability. applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB You can kill me, but you cannot change the truth. 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/imgconvert: Support non-planar colorspaces while padding
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
> +} else {
> +if (src)
> +return -1;
why ?
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/indeo3data: fix undefined left shift of negative number
This fixes a whole sea of -Wshift-negative-value reported with clang 3.7+, e.g
http://fate.ffmpeg.org/log.cgi?time=20150918181527&log=compile&slot=x86_64-darwin-clang-polly-vectorize-stripmine-3.7.
Any half decent compiler should anyway optimize away the multiplication.
Signed-off-by: Ganesh Ajjanagadde
---
libavcodec/indeo3data.h | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/libavcodec/indeo3data.h b/libavcodec/indeo3data.h
index e7e28a3..7a2df12 100644
--- a/libavcodec/indeo3data.h
+++ b/libavcodec/indeo3data.h
@@ -237,10 +237,11 @@
* Pack two delta values (a,b) into one 16bit word
* according with endianness of the host machine.
*/
+#define POW_2(n) (1 << (n))
#if HAVE_BIGENDIAN
-#define PD(a,b) (((a) << 8) + (b))
+#define PD(a,b) (((a) * POW_2(8)) + (b))
#else
-#define PD(a,b) (((b) << 8) + (a))
+#define PD(a,b) (((b) * POW_2(8)) + (a))
#endif
/**
@@ -285,9 +286,9 @@ static const int16_t delta_tab_3_5[79] = { TAB_3_5 };
* according with endianness of the host machine.
*/
#if HAVE_BIGENDIAN
-#define PD(a,b) (((a) << 24) + ((a) << 16) + ((b) << 8) + (b))
+#define PD(a,b) (((a) * POW_2(24)) + ((a) * POW_2(16)) + ((b) * POW_2(8)) +
(b))
#else
-#define PD(a,b) (((b) << 24) + ((b) << 16) + ((a) << 8) + (a))
+#define PD(a,b) (((b) * POW_2(24)) + ((b) * POW_2(16)) + ((a) * POW_2(8)) +
(a))
#endif
/*
--
2.5.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/internal: silence -Wempty-body on clang
This silences a -Wempty-body warning on clang 3.7+, e.g
http://fate.ffmpeg.org/log.cgi?time=20150918181527&log=compile&slot=x86_64-darwin-clang-polly-vectorize-stripmine-3.7.
Signed-off-by: Ganesh Ajjanagadde
---
libavcodec/internal.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/internal.h b/libavcodec/internal.h
index 89f5aa2..fbee411 100644
--- a/libavcodec/internal.h
+++ b/libavcodec/internal.h
@@ -57,7 +57,7 @@
#ifdef TRACE
# define ff_tlog(ctx, ...) av_log(ctx, AV_LOG_TRACE, __VA_ARGS__)
#else
-# define ff_tlog(ctx, ...) while(0)
+# define ff_tlog(ctx, ...) while(0) {}
#endif
--
2.5.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/g723_1: fix a undefined left shift of negative number
This fixes a -Wshift-negative-value reported with clang 3.7+, e.g
http://fate.ffmpeg.org/log.cgi?time=20150918181527&log=compile&slot=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(-)
diff --git a/libavcodec/g723_1.c b/libavcodec/g723_1.c
index 4a73c3c..68a6d91 100644
--- a/libavcodec/g723_1.c
+++ b/libavcodec/g723_1.c
@@ -2142,7 +2142,7 @@ static void get_fcb_param(FCBParam *optim, int16_t
*impulse_resp,
temp_corr[param.pulse_pos[0]] = 1;
for (k = 1; k < pulse_cnt; k++) {
-max = -1 << 30;
+max = INT_MIN;
for (l = i; l < SUBFRAME_LEN; l += GRID_SIZE) {
if (temp_corr[l])
continue;
--
2.5.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] avutil/attributes: extend av_uninit to clang
Commit 6dac8c8327 disabled av_uninit for clang, due to some useless warnings.
The concept of av_uninit is inherently useful though. This patch silences a
bunch of warnings on clang e.g
http://fate.ffmpeg.org/log.cgi?time=20150918181527&log=compile&slot=x86_64-darwin-clang-polly-vectorize-stripmine-3.7.
Furthermore, it should be useful for general usage of av_uninit in future.
Signed-off-by: Ganesh Ajjanagadde
---
libavutil/attributes.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libavutil/attributes.h b/libavutil/attributes.h
index 50e8eb3..b4b5f13 100644
--- a/libavutil/attributes.h
+++ b/libavutil/attributes.h
@@ -141,6 +141,12 @@
#if defined(__GNUC__) && !defined(__INTEL_COMPILER) && !defined(__clang__)
#define av_uninit(x) x=x
+#elif defined(__clang__)
+#define av_uninit(x) \
+_Pragma("clang diagnostic push") \
+_Pragma("clang diagnostic ignored \"-Wuninitialized\"") \
+x=x \
+_Pragma("clang diagnostic pop")
#else
#define av_uninit(x) x
#endif
--
2.5.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] avcodec/dcadec: fix a -Wsometimes-unitialized on clang
This fixes a genuine -Wsometimes-unitialized reported on clang, e.g
http://fate.ffmpeg.org/log.cgi?time=20150918181527&log=compile&slot=x86_64-darwin-clang-polly-vectorize-stripmine-3.7.
Signed-off-by: Ganesh Ajjanagadde
---
libavcodec/dcadec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/dcadec.c b/libavcodec/dcadec.c
index bc1222b..10efdda 100644
--- a/libavcodec/dcadec.c
+++ b/libavcodec/dcadec.c
@@ -1456,7 +1456,7 @@ static float dca_dmix_code(unsigned code)
static int scan_for_extensions(AVCodecContext *avctx)
{
DCAContext *s = avctx->priv_data;
-int core_ss_end, ret;
+int core_ss_end, ret = 0;
core_ss_end = FFMIN(s->frame_size, s->dca_buffer_size) * 8;
--
2.5.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/indeo3data: fix undefined left shift of negative number
On 9/19/2015 1:53 AM, Ganesh Ajjanagadde wrote:
> This fixes a whole sea of -Wshift-negative-value reported with clang 3.7+, e.g
> http://fate.ffmpeg.org/log.cgi?time=20150918181527&log=compile&slot=x86_64-darwin-clang-polly-vectorize-stripmine-3.7.
> Any half decent compiler should anyway optimize away the multiplication.
>
> Signed-off-by: Ganesh Ajjanagadde
> ---
> libavcodec/indeo3data.h | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/libavcodec/indeo3data.h b/libavcodec/indeo3data.h
> index e7e28a3..7a2df12 100644
> --- a/libavcodec/indeo3data.h
> +++ b/libavcodec/indeo3data.h
> @@ -237,10 +237,11 @@
> * Pack two delta values (a,b) into one 16bit word
> * according with endianness of the host machine.
> */
> +#define POW_2(n) (1 << (n))
> #if HAVE_BIGENDIAN
> -#define PD(a,b) (((a) << 8) + (b))
> +#define PD(a,b) (((a) * POW_2(8)) + (b))
#define PD(a,b) (((a) * (1 << 8)) + (b))
Is more in line with previous similar changes. See for example commits 4eee685a,
e50ae60d and many others.
Same for the lines below.
> #else
> -#define PD(a,b) (((b) << 8) + (a))
> +#define PD(a,b) (((b) * POW_2(8)) + (a))
> #endif
>
> /**
> @@ -285,9 +286,9 @@ static const int16_t delta_tab_3_5[79] = { TAB_3_5 };
> * according with endianness of the host machine.
> */
> #if HAVE_BIGENDIAN
> -#define PD(a,b) (((a) << 24) + ((a) << 16) + ((b) << 8) + (b))
> +#define PD(a,b) (((a) * POW_2(24)) + ((a) * POW_2(16)) + ((b) * POW_2(8)) +
> (b))
> #else
> -#define PD(a,b) (((b) << 24) + ((b) << 16) + ((a) << 8) + (a))
> +#define PD(a,b) (((b) * POW_2(24)) + ((b) * POW_2(16)) + ((a) * POW_2(8)) +
> (a))
> #endif
>
> /*
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/mlpdec: fix a undefined left shift of negative number
This fixes a -Wshift-negative-value reported with clang 3.7+, e.g http://fate.ffmpeg.org/log.cgi?time=20150918181527&log=compile&slot=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(-) diff --git a/libavcodec/mlpdec.c b/libavcodec/mlpdec.c index b2d1e2f..c93b058 100644 --- a/libavcodec/mlpdec.c +++ b/libavcodec/mlpdec.c @@ -602,7 +602,7 @@ static int read_restart_header(MLPDecodeContext *m, GetBitContext *gbp, /* Default audio coding is 24-bit raw PCM. */ cp->huff_offset = 0; -cp->sign_huff_offset = (-1) << 23; +cp->sign_huff_offset = -(1 << 23); cp->codebook = 0; cp->huff_lsbs= 24; } -- 2.5.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCHv2] avcodec/indeo3data: fix undefined left shift of negative number
This fixes a whole sea of -Wshift-negative-value reported with clang 3.7+, e.g
http://fate.ffmpeg.org/log.cgi?time=20150918181527&log=compile&slot=x86_64-darwin-clang-polly-vectorize-stripmine-3.7.
Any half decent compiler should anyway optimize away the multiplication.
Signed-off-by: Ganesh Ajjanagadde
---
libavcodec/indeo3data.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavcodec/indeo3data.h b/libavcodec/indeo3data.h
index e7e28a3..fe8f0ba 100644
--- a/libavcodec/indeo3data.h
+++ b/libavcodec/indeo3data.h
@@ -238,9 +238,9 @@
* according with endianness of the host machine.
*/
#if HAVE_BIGENDIAN
-#define PD(a,b) (((a) << 8) + (b))
+#define PD(a,b) (((a) * (1 << 8)) + (b))
#else
-#define PD(a,b) (((b) << 8) + (a))
+#define PD(a,b) (((b) * (1 << 8)) + (a))
#endif
/**
@@ -285,9 +285,9 @@ static const int16_t delta_tab_3_5[79] = { TAB_3_5 };
* according with endianness of the host machine.
*/
#if HAVE_BIGENDIAN
-#define PD(a,b) (((a) << 24) + ((a) << 16) + ((b) << 8) + (b))
+#define PD(a,b) (((a) * (1 << 24)) + ((a) * (1 << 16)) + ((b) * (1 << 8)) +
(b))
#else
-#define PD(a,b) (((b) << 24) + ((b) << 16) + ((a) << 8) + (a))
+#define PD(a,b) (((b) * (1 << 24)) + ((b) * (1 << 16)) + ((a) * (1 << 8)) +
(a))
#endif
/*
--
2.5.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/indeo3data: fix undefined left shift of negative number
On Sat, Sep 19, 2015 at 1:02 AM, James Almer wrote:
> On 9/19/2015 1:53 AM, Ganesh Ajjanagadde wrote:
>> This fixes a whole sea of -Wshift-negative-value reported with clang 3.7+,
>> e.g
>> http://fate.ffmpeg.org/log.cgi?time=20150918181527&log=compile&slot=x86_64-darwin-clang-polly-vectorize-stripmine-3.7.
>> Any half decent compiler should anyway optimize away the multiplication.
>>
>> Signed-off-by: Ganesh Ajjanagadde
>> ---
>> libavcodec/indeo3data.h | 9 +
>> 1 file changed, 5 insertions(+), 4 deletions(-)
>>
>> diff --git a/libavcodec/indeo3data.h b/libavcodec/indeo3data.h
>> index e7e28a3..7a2df12 100644
>> --- a/libavcodec/indeo3data.h
>> +++ b/libavcodec/indeo3data.h
>> @@ -237,10 +237,11 @@
>> * Pack two delta values (a,b) into one 16bit word
>> * according with endianness of the host machine.
>> */
>> +#define POW_2(n) (1 << (n))
>> #if HAVE_BIGENDIAN
>> -#define PD(a,b) (((a) << 8) + (b))
>> +#define PD(a,b) (((a) * POW_2(8)) + (b))
>
> #define PD(a,b) (((a) * (1 << 8)) + (b))
>
> Is more in line with previous similar changes. See for example commits
> 4eee685a,
> e50ae60d and many others.
I have patchv2 on these lines; apply and push whichever you/others wish.
>
> Same for the lines below.
>
>> #else
>> -#define PD(a,b) (((b) << 8) + (a))
>> +#define PD(a,b) (((b) * POW_2(8)) + (a))
>> #endif
>>
>> /**
>> @@ -285,9 +286,9 @@ static const int16_t delta_tab_3_5[79] = { TAB_3_5 };
>> * according with endianness of the host machine.
>> */
>> #if HAVE_BIGENDIAN
>> -#define PD(a,b) (((a) << 24) + ((a) << 16) + ((b) << 8) + (b))
>> +#define PD(a,b) (((a) * POW_2(24)) + ((a) * POW_2(16)) + ((b) * POW_2(8)) +
>> (b))
>> #else
>> -#define PD(a,b) (((b) << 24) + ((b) << 16) + ((a) << 8) + (a))
>> +#define PD(a,b) (((b) * POW_2(24)) + ((b) * POW_2(16)) + ((a) * POW_2(8)) +
>> (a))
>> #endif
>>
>> /*
>>
>
> ___
> 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] [PATCHv2] avcodec/indeo3data: fix undefined left shift of negative number
On 9/19/2015 2:21 AM, Ganesh Ajjanagadde wrote:
> This fixes a whole sea of -Wshift-negative-value reported with clang 3.7+, e.g
> http://fate.ffmpeg.org/log.cgi?time=20150918181527&log=compile&slot=x86_64-darwin-clang-polly-vectorize-stripmine-3.7.
> Any half decent compiler should anyway optimize away the multiplication.
>
> Signed-off-by: Ganesh Ajjanagadde
> ---
> libavcodec/indeo3data.h | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/libavcodec/indeo3data.h b/libavcodec/indeo3data.h
> index e7e28a3..fe8f0ba 100644
> --- a/libavcodec/indeo3data.h
> +++ b/libavcodec/indeo3data.h
> @@ -238,9 +238,9 @@
> * according with endianness of the host machine.
> */
> #if HAVE_BIGENDIAN
> -#define PD(a,b) (((a) << 8) + (b))
> +#define PD(a,b) (((a) * (1 << 8)) + (b))
> #else
> -#define PD(a,b) (((b) << 8) + (a))
> +#define PD(a,b) (((b) * (1 << 8)) + (a))
> #endif
>
> /**
> @@ -285,9 +285,9 @@ static const int16_t delta_tab_3_5[79] = { TAB_3_5 };
> * according with endianness of the host machine.
> */
> #if HAVE_BIGENDIAN
> -#define PD(a,b) (((a) << 24) + ((a) << 16) + ((b) << 8) + (b))
> +#define PD(a,b) (((a) * (1 << 24)) + ((a) * (1 << 16)) + ((b) * (1 << 8)) +
> (b))
> #else
> -#define PD(a,b) (((b) << 24) + ((b) << 16) + ((a) << 8) + (a))
> +#define PD(a,b) (((b) * (1 << 24)) + ((b) * (1 << 16)) + ((a) * (1 << 8)) +
> (a))
> #endif
>
> /*
>
Applied.
___
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
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&log=compile&slot=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
