Re: [FFmpeg-devel] [PATCH] avformat: Add simple ACLR atom reading to set the color range
So reading through the comments in this thread, it looks to me like some of the problems come from the use of the mov_read_extradata() function, which has more logic than the name implies, in particular it will successfully return even if it did not read the atom into the extradata, so if i just directly read the atom, what will break? I could do the ugly thing of reading it and then filling the extradata (or modify the reading function to better communicate to the callers if the data was read correctly). The atom could also not be in the extradata but does it have to be? The movenc.c writer of the atom doesn't always use the extradata - for DNxHD relies on the colour_range of the track's encoder directly and doesn't appear to write the extradata (calls mov_write_avid_tag()), for other codecs it uses mov_write_extradata_tag() (for AV_CODEC_ID_AVU and AV_CODEC_ID_SVQ3). This suggests that for DNxHD I don't need it in the extradata to preserve behaviour, or am I missing something in the code (something in the use as a library for instance)? Thanks Kevin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] x86/doc/Makefile: DBG=1 to preprocess external asm
Hi, 2015-02-17 20:06 GMT+01:00 James Almer : > $ make libavcodec/x86/dcadsp.o DBG=0 OK, it's mainly a matter of documentation then here, as just having DBG defined is fine. I'm not sure of the makefile syntax if DBG=1 is what is really wanted. > YASMlibavcodec/x86/dcadsp.dbg.asm > YASMlibavcodec/x86/dcadsp.o > STRIP libavcodec/x86/dcadsp.o > rm libavcodec/x86/dcadsp.dbg.asm Huh, a rm command isn't issued in the rule... On the other hand, running make with debugging states: Successfully remade target file `libavcodec/x86/dcadsp.o'. Removing intermediate files... rm libavcodec/x86/dcadsp.dbg.asm So, in a way, the above is quite ok: no need to keep libavcodec/x86/dcadsp.dbg.asm around if compilation was ok. But if you run the command a 2nd time, it does keep it around :( And it shouldn't even attempt this because compilation is succesful. I think this a dependency rule issue for the .dbg.asm file But even with the attached file, it still rebuilds it an additional time. But third time is the charm, as it stops rebuilding it... > $ rm libavcodec/x86/dcadsp.o > > $ make libavcodec/x86/dcadsp.o > YASMlibavcodec/x86/dcadsp.dbg.asm This seems fixed with the attached patch. But I wonder if a dependency rule is really needed, as I can see it causing issues... (does it depend on .asm or .dbg.asm etc) So I don't think we there yet. -- Christophe From f3365ec79b096dad0ccd7246b78ea9b7074f3b49 Mon Sep 17 00:00:00 2001 From: Christophe Gisquet Date: Wed, 18 Feb 2015 10:51:17 +0100 Subject: [PATCH] Makefile: improve DBG option for asm This improves the cleanup, dependency generation and DBG command issuing. --- common.mak | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/common.mak b/common.mak index a6fabb3..20b7fa3 100644 --- a/common.mak +++ b/common.mak @@ -7,10 +7,10 @@ all: all-yes DEFAULT_YASMD=.dbg -ifndef DBG -YASMD= -else +ifeq (1, DBG) YASMD=$(DEFAULT_YASMD) +else +YASMD= endif ifndef SUBDIR @@ -152,11 +152,11 @@ LIBSUFFIXES = *.a *.lib *.so *.so.* *.dylib *.dll *.def *.dll.a define RULES clean:: - $(RM) $(OBJS) $(OBJS:.o=.d) + $(RM) $(OBJS) $(OBJS:.o=.d) $(OBJS:.o=$(DEFAULT_YASMD).d) $(RM) $(HOSTPROGS) $(RM) $(TOOLS) endef $(eval $(RULES)) --include $(wildcard $(OBJS:.o=.d) $(HOSTOBJS:.o=.d) $(TESTOBJS:.o=.d) $(HOBJS:.o=.d) $(SLIBOBJS:.o=.d)) +-include $(wildcard $(OBJS:.o=.d) $(HOSTOBJS:.o=.d) $(TESTOBJS:.o=.d) $(HOBJS:.o=.d) $(SLIBOBJS:.o=.d)) $(OBJS:.o=$(DEFAULT_YASMD).d) -- 1.9.2.msysgit.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] tests: fate: adding fate-test for twofish
Hello, I have attached a patch to add fate-test for twofish. Thanks, Supraja From 577cb83254a0474ef303ec6531304705587f2a94 Mon Sep 17 00:00:00 2001 From: Supraja Meedinti Date: Wed, 18 Feb 2015 18:43:03 +0530 Subject: [PATCH] tests: fate: adding fate-test for twofish Signed-off-by: Supraja Meedinti --- tests/fate/libavutil.mak | 5 + 1 file changed, 5 insertions(+) diff --git a/tests/fate/libavutil.mak b/tests/fate/libavutil.mak index 92a7f05..58307ae 100644 --- a/tests/fate/libavutil.mak +++ b/tests/fate/libavutil.mak @@ -108,6 +108,11 @@ fate-tree: libavutil/tree-test$(EXESUF) fate-tree: CMD = run libavutil/tree-test fate-tree: REF = /dev/null +FATE_LIBAVUTIL += fate-twofish +fate-twofish: libavutil/twofish-test$(EXESUF) +fate-twofish: CMD = run libavutil/twofish-test +fate-twofish: REF = /dev/null + FATE_LIBAVUTIL += fate-xtea fate-xtea: libavutil/xtea-test$(EXESUF) fate-xtea: CMD = run libavutil/xtea-test -- 1.8.3.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] avfilter/paletteuse: fix error dithering accuracy
From: Clément Bœsch
---
libavfilter/vf_paletteuse.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavfilter/vf_paletteuse.c b/libavfilter/vf_paletteuse.c
index a8defc7..87a90d0 100644
--- a/libavfilter/vf_paletteuse.c
+++ b/libavfilter/vf_paletteuse.c
@@ -133,9 +133,9 @@ static int query_formats(AVFilterContext *ctx)
static av_always_inline int dither_color(uint32_t px, int er, int eg, int eb,
int scale, int shift)
{
-return av_clip_uint8((px >> 16 & 0xff) + ((er * scale) >> shift)) << 16
- | av_clip_uint8((px >> 8 & 0xff) + ((eg * scale) >> shift)) << 8
- | av_clip_uint8((px & 0xff) + ((eb * scale) >> shift));
+return av_clip_uint8((px >> 16 & 0xff) + ((er * scale) / (1<> 8 & 0xff) + ((eg * scale) / (1
[FFmpeg-devel] [PATCH 2/2] avfilter/paletteuse: add diff_mode
From: Clément Bœsch
TODO: bump minor
---
doc/filters.texi| 15 +
libavfilter/vf_paletteuse.c | 151
2 files changed, 153 insertions(+), 13 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index 191b52f..d75e39a 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -6991,6 +6991,21 @@ visible pattern for less banding, and higher value means
less visible pattern
at the cost of more banding.
The option must be an integer value in the range [0,5]. Default is @var{2}.
+
+@item diff_mode
+If set, define the zone to process
+
+@table @samp
+@item rectangle
+Only the changing rectangle will be reprocessed. This is similar to GIF
+cropping/offsetting compression mechanism. This option can be useful for speed
+if only a part of the image is changing, and has use cases such as limiting the
+scope of the error diffusal @option{dither} to the rectangle that bound the
+moving scene (it leads to more deterministic output if the scene doesn't change
+much, and as a result less moving noise and better GIF compression).
+@end table
+
+Default is @var{none}.
@end table
@subsection Examples
diff --git a/libavfilter/vf_paletteuse.c b/libavfilter/vf_paletteuse.c
index 87a90d0..12b4a1e 100644
--- a/libavfilter/vf_paletteuse.c
+++ b/libavfilter/vf_paletteuse.c
@@ -43,6 +43,12 @@ enum color_search_method {
NB_COLOR_SEARCHES
};
+enum diff_mode {
+DIFF_MODE_NONE,
+DIFF_MODE_RECTANGLE,
+NB_DIFF_MODE
+};
+
struct color_node {
uint8_t val[3];
uint8_t palette_id;
@@ -65,7 +71,8 @@ struct cache_node {
struct PaletteUseContext;
-typedef int (*set_frame_func)(struct PaletteUseContext *s, AVFrame *out,
AVFrame *in);
+typedef int (*set_frame_func)(struct PaletteUseContext *s, AVFrame *out,
AVFrame *in,
+ int x_start, int y_start, int width, int height);
typedef struct PaletteUseContext {
const AVClass *class;
@@ -78,6 +85,9 @@ typedef struct PaletteUseContext {
set_frame_func set_frame;
int bayer_scale;
int ordered_dither[8*8];
+int diff_mode;
+AVFrame *last_in;
+AVFrame *last_out;
/* debug options */
char *dot_filename;
@@ -97,6 +107,8 @@ static const AVOption paletteuse_options[] = {
{ "sierra2", "Frankie Sierra dithering v2 (error diffusion)",
0, AV_OPT_TYPE_CONST, {.i64=DITHERING_SIERRA2},
INT_MIN, INT_MAX, FLAGS, "dithering_mode" },
{ "sierra2_4a", "Frankie Sierra dithering v2 \"Lite\" (error
diffusion)", 0, AV_OPT_TYPE_CONST, {.i64=DITHERING_SIERRA2_4A},
INT_MIN, INT_MAX, FLAGS, "dithering_mode" },
{ "bayer_scale", "set scale for bayer dithering", OFFSET(bayer_scale),
AV_OPT_TYPE_INT, {.i64=2}, 0, 5, FLAGS },
+{ "diff_mode", "set frame difference mode", OFFSET(diff_mode),
AV_OPT_TYPE_INT, {.i64=DIFF_MODE_NONE}, 0, NB_DIFF_MODE-1, FLAGS, "diff_mode" },
+{ "rectangle", "process smallest different rectangle", 0,
AV_OPT_TYPE_CONST, {.i64=DIFF_MODE_RECTANGLE}, INT_MIN, INT_MAX, FLAGS,
"diff_mode" },
/* following are the debug options, not part of the official API */
{ "debug_kdtree", "save Graphviz graph of the kdtree in specified file",
OFFSET(dot_filename), AV_OPT_TYPE_STRING, {.str=NULL}, CHAR_MIN, CHAR_MAX,
FLAGS },
@@ -349,6 +361,7 @@ static av_always_inline uint8_t get_dst_color_err(struct
cache_node *cache,
}
static av_always_inline int set_frame(PaletteUseContext *s, AVFrame *out,
AVFrame *in,
+ int x_start, int y_start, int w, int h,
enum dithering_mode dither,
const enum color_search_method
search_method)
{
@@ -356,13 +369,16 @@ static av_always_inline int set_frame(PaletteUseContext
*s, AVFrame *out, AVFram
const struct color_node *map = s->map;
struct cache_node *cache = s->cache;
const uint32_t *palette = s->palette;
-uint32_t *src = (uint32_t *)in ->data[0];
-uint8_t *dst = out->data[0];
const int src_linesize = in ->linesize[0] >> 2;
const int dst_linesize = out->linesize[0];
+uint32_t *src = ((uint32_t *)in ->data[0]) + y_start*src_linesize;
+uint8_t *dst = out->data[0] + y_start*dst_linesize;
-for (y = 0; y < in->height; y++) {
-for (x = 0; x < in->width; x++) {
+w += x_start;
+h += y_start;
+
+for (y = y_start; y < h; y++) {
+for (x = x_start; x < w; x++) {
int er, eg, eb;
if (dither == DITHERING_BAYER) {
@@ -381,7 +397,7 @@ static av_always_inline int set_frame(PaletteUseContext *s,
AVFrame *out, AVFram
dst[x] = color;
} else if (dither == DITHERING_HECKBERT) {
-const int right = x < in->width - 1, down = y < in->height - 1;
+const int right = x < w - 1, down = y < h - 1;
Re: [FFmpeg-devel] tools: crypto_bench: Added support for Twofish
Hi,
2015-02-14 11:12 GMT+01:00 Giorgio Vazzana :
> Hi,
>
> 2015-02-14 9:33 GMT+01:00 supraja reddy :
>> Hello,
>>
>> I have added the necessary functions for twofish in crypto_bench.
>> A note, there is no twofish implementation in openssl library but since the
>> code demands that all the libraries have the impl, i have introduced a
>> dummy function.
>
> I know this was initially my suggestion, but looking now at the code I
> see that maybe we could use the IMPL() macro instead of the IMPL_ALL()
> macro in order to exclude 'crypto'. This should simplify the patch.
>
> I'll give it a look tomorrow hopefully, but of course let's see if
> others have comments.
what about something like the following code? You won't need to add a
dummy function or insert a check inside run_implementation():
@@ -398,6 +398,9 @@ struct hash_impl implementations[] = {
IMPL_ALL("AES-128",aes128,"crc:ff6bc888")
IMPL_ALL("CAMELLIA", camellia, "crc:7abb59a7")
IMPL_ALL("CAST-128", cast128, "crc:456aa584")
+IMPL(lavu, "TWOFISH", twofish, "crc:9edbd5c1")
+IMPL(gcrypt, "TWOFISH", twofish, "crc:9edbd5c1")
+IMPL(tomcrypt, "TWOFISH", twofish, "crc:9edbd5c1")
};
Giorgio Vazzana
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] tests: fate: adding fate-test for twofish
On Wed, Feb 18, 2015 at 06:46:21PM +0530, supraja reddy wrote: > Hello, > > I have attached a patch to add fate-test for twofish. > > Thanks, > Supraja > libavutil.mak |5 + > 1 file changed, 5 insertions(+) > 487a837eebc4f0d2a29bcb6f0bf87f1a198023cf > 0001-tests-fate-adding-fate-test-for-twofish.patch > From 577cb83254a0474ef303ec6531304705587f2a94 Mon Sep 17 00:00:00 2001 > From: Supraja Meedinti > Date: Wed, 18 Feb 2015 18:43:03 +0530 > Subject: [PATCH] tests: fate: adding fate-test for twofish > > Signed-off-by: Supraja Meedinti applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are too smart to engage in politics are punished by being governed by those who are dumber. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/5] avcodec/vc1: optimize block functions
On Sat, Feb 14, 2015 at 10:56:28PM +0800, zhaoxiu.zeng wrote: > From 960eca51e6e65e6969f7d829e29ddc2387420733 Mon Sep 17 00:00:00 2001 > From: Zeng Zhaoxiu > Date: Sat, 14 Feb 2015 19:46:51 +0800 > Subject: [PATCH 2/5] avcodec/vc1: optimize block functions This patch breaks make fate: also please include benchmark values --- ./tests/ref/fate/mss2-wmv 2015-02-12 16:53:42.138771890 +0100 +++ tests/data/fate/mss2-wmv2015-02-18 19:10:41.449866314 +0100 @@ -27,11 +27,11 @@ 0, 31, 31,1, 230400, 0x18a2f97a 0, 32, 32,1, 230400, 0xf9e82961 0, 33, 33,1, 230400, 0x57a8e9e8 -0, 34, 34,1, 230400, 0xdef6fd66 -0, 35, 35,1, 230400, 0xc7d923a9 -0, 36, 36,1, 230400, 0x08bb41ee -0, 37, 37,1, 230400, 0x43ccbd29 -0, 38, 38,1, 230400, 0x4ee3 +0, 34, 34,1, 230400, 0xbd60fd5a +0, 35, 35,1, 230400, 0x289b2391 +0, 36, 36,1, 230400, 0x8d5a4205 +0, 37, 37,1, 230400, 0xbed1bcb6 +0, 38, 38,1, 230400, 0x24086ea2 0, 39, 39,1, 230400, 0xbfd2ef29 0, 40, 40,1, 230400, 0x6504545f 0, 41, 41,1, 230400, 0x8fb86901 @@ -40,25 +40,25 @@ 0, 44, 44,1, 230400, 0xf808106b 0, 45, 45,1, 230400, 0x34150020 0, 46, 46,1, 230400, 0x50fdfe89 -0, 47, 47,1, 230400, 0x920b7708 +0, 47, 47,1, 230400, 0xe8287631 0, 48, 48,1, 230400, 0xed64fcc4 0, 49, 49,1, 230400, 0x6291a170 0, 50, 50,1, 230400, 0x20524643 -0, 51, 51,1, 230400, 0x92aafecd +0, 51, 51,1, 230400, 0x5e9efe62 0, 52, 52,1, 230400, 0xf00ee14d 0, 53, 53,1, 230400, 0xfa3113ea 0, 54, 54,1, 230400, 0x99c06df1 0, 55, 55,1, 230400, 0x625c6918 -0, 56, 56,1, 230400, 0xb277b25e +0, 56, 56,1, 230400, 0xeb34b22e 0, 57, 57,1, 230400, 0x2e913006 0, 58, 58,1, 230400, 0x3f6f1d99 0, 59, 59,1, 230400, 0x100ab60f -0, 60, 60,1, 230400, 0x9b73d0bf +0, 60, 60,1, 230400, 0xe21acfc4 0, 61, 61,1, 230400, 0xda0df2ce 0, 62, 62,1, 230400, 0x67f7ca24 0, 63, 63,1, 230400, 0xbde9b3d0 0, 64, 64,1, 230400, 0x92e14d07 -0, 65, 65,1, 230400, 0x9426c3d9 +0, 65, 65,1, 230400, 0xa584c3c4 0, 66, 66,1, 230400, 0x6104be70 0, 67, 67,1, 230400, 0xc4d1078a 0, 68, 68,1, 230400, 0x89426a42 @@ -67,35 +67,35 @@ 0, 71, 71,1, 230400, 0x4249b8c6 0, 72, 72,1, 230400, 0x4b88cad3 0, 73, 73,1, 230400, 0x76af545d -0, 74, 74,1, 230400, 0xfe47e3c4 +0, 74, 74,1, 230400, 0xb165e37d 0, 75, 75,1, 230400, 0xa2e0e721 0, 76, 76,1, 230400, 0xde974a42 -0, 77, 77,1, 230400, 0x87bf38ba +0, 77, 77,1, 230400, 0x3dad37cc 0, 78, 78,1, 230400, 0xd52318fd 0, 79, 79,1, 230400, 0x0bbb1526 -0, 80, 80,1, 230400, 0xa22c5e5e +0, 80, 80,1, 230400, 0xe85b5e88 0, 81, 81,1, 230400, 0x4532c5d2 0, 82, 82,1, 230400, 0x88b560ec -0, 83, 83,1, 230400, 0xcee9d9c9 +0, 83, 83,1, 230400, 0xeddad96d 0, 84, 84,1, 230400, 0x0429358f -0, 85, 85,1, 230400, 0xf18a9b98 -0, 86, 86,1, 230400, 0x63f7a12c -0, 87, 87,1, 230400, 0x98635515 +0, 85, 85,1, 230400, 0xaee09b6d +0, 86, 86,1, 230400, 0xce98a02b +0, 87, 87,1, 230400, 0x127654f4 0, 88, 88,1, 230400, 0x36affebc 0, 89, 89,1, 230400, 0xd8c19629 -0, 90, 90,1, 230400, 0x9ef5344d -0, 91, 91,1, 230400, 0x545668dc -0, 92, 92,1, 230400, 0x50e65e74 -0, 93, 93,1, 230400, 0xe3
Re: [FFmpeg-devel] [PATCH] avformat: Add simple ACLR atom reading to set the color range
On Wed, Feb 18, 2015 at 09:40:24AM +, Kevin Wheatley wrote: > So reading through the comments in this thread, it looks to me like > some of the problems come from the use of the mov_read_extradata() > function, which has more logic than the name implies, in particular it > will successfully return even if it did not read the atom into the > extradata, so if i just directly read the atom, what will break? I > could do the ugly thing of reading it and then filling the extradata > (or modify the reading function to better communicate to the callers > if the data was read correctly). > > The atom could also not be in the extradata but does it have to be? its probably best to leave it in extradata for codecs which expect/use it. Otherwise i think its best if the demuxer extracts the data and sets the fields like color_range based on it and the muxer creates the atom again from that. That is if no information is lost that way. This should also allow some interoperability between mov and other containers which would not produce for example mjpeg with such atom > > The movenc.c writer of the atom doesn't always use the extradata - for > DNxHD relies on the colour_range of the track's encoder directly and > doesn't appear to write the extradata (calls mov_write_avid_tag()), > for other codecs it uses mov_write_extradata_tag() (for > AV_CODEC_ID_AVU and AV_CODEC_ID_SVQ3). > > This suggests that for DNxHD I don't need it in the extradata to > preserve behaviour, or am I missing something in the code (something > in the use as a library for instance)? > > Thanks > > Kevin > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB While the State exists there can be no freedom; when there is freedom there will be no State. -- Vladimir Lenin signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/5] avcodec/vc1: optimize block functions
Michael Niedermayer gmx.at> writes: > 0, 31, 31,1, 230400, 0x18a2f97a > 0, 32, 32,1, 230400, 0xf9e82961 > 0, 33, 33,1, 230400, 0x57a8e9e8 > -0, 34, 34,1, 230400, 0xdef6fd66 > -0, 35, 35,1, 230400, 0xc7d923a9 > -0, 36, 36,1, 230400, 0x08bb41ee > -0, 37, 37,1, 230400, 0x43ccbd29 > -0, 38, 38,1, 230400, 0x4ee3 These four are currently bit-identical with the binary decoder. (Some later frames are not.) Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavfi: Add support to process_command in vf_eq.c
On Sat, Jan 31, 2015 at 3:55 PM, Stefano Sabatini
wrote:
> On date Friday 2015-01-30 23:17:33 +0530, Arwa Arif encoded:
> > I have tried to add process_command in vf_eq.c. I have attached the
> patch.
>
> > From 1d65e493a8eb247d86b0db324cb740579662706d Mon Sep 17 00:00:00 2001
> > From: Arwa Arif
> > Date: Fri, 30 Jan 2015 23:06:50 +0530
> > Subject: [PATCH] Add support to process_command in vf_eq.c
> >
> > ---
> > libavfilter/vf_eq.c | 53
> ++-
> > 1 file changed, 40 insertions(+), 13 deletions(-)
>
> Missing doc updates.
>
> >
> > diff --git a/libavfilter/vf_eq.c b/libavfilter/vf_eq.c
> > index ad2a37e..5899abb 100644
> > --- a/libavfilter/vf_eq.c
> > +++ b/libavfilter/vf_eq.c
> > @@ -27,11 +27,6 @@
> > * very simple video equalizer
> > */
> >
> > -/**
> > - * TODO:
> > - * - Add support to process_command
> > - */
> > -
> > #include "libavfilter/internal.h"
> > #include "libavutil/common.h"
> > #include "libavutil/imgutils.h"
> > @@ -217,6 +212,37 @@ static int filter_frame(AVFilterLink *inlink,
> AVFrame *in)
> > av_frame_free(&in);
> > return ff_filter_frame(outlink, out);
> > }
> > +
> > +static int process_command(AVFilterContext *ctx, const char *cmd, const
> char *args,
> > + char *res, int res_len, int flags)
> > +{
> > +EQContext *eq = ctx->priv;
> > +
> > +if (!strcmp(cmd, "contrast"))
>
> > +eq->contrast = av_clipf(strtod(args, NULL), -2.0, 2.0);
>
> All this parameters are set through the av_opt_ interface. Try to use
> it, since otherwise range checks and parsing is inconsistent. In
> particular, the parsing performed by av_opt_ may be different from
> strtod(). Also you want to want the user in case of out-of-range values.
>
> > +if (!strcmp(cmd, "brightness"))
> > +eq->brightness = av_clipf(strtod(args, NULL), -1.0, 1.0);
> > +if (!strcmp(cmd, "saturation"))
> > +eq->saturation = av_clipf(strtod(args, NULL), 0.0, 3.0);
> > +if (!strcmp(cmd, "gamma"))
> > +eq->gamma= av_clipf(strtod(args, NULL), 0.1, 10.0);
> > +if (!strcmp(cmd, "gamma_r"))
> > +eq->gamma_r = av_clipf(strtod(args, NULL), 0.1, 10.0);
> > +if (!strcmp(cmd, "gamma_g"))
> > +eq->gamma_g = av_clipf(strtod(args, NULL), 0.1, 10.0);
> > +if (!strcmp(cmd, "gamma_b"))
> > +eq->gamma_b = av_clipf(strtod(args, NULL), 0.1, 10.0);
> > +if (!strcmp(cmd, "gamma_weight"))
> > +eq->gamma_weight = av_clipf(strtod(args, NULL), 0.0, 1.0);
> > +
> > +set_gamma(eq);
> > +set_contrast(eq);
> > +set_brightness(eq);
> > +set_saturation(eq);
> > +
> > +return 0;
> > +}
>
> if (!strcmp(cmd, "contrast) {
>set contrast
>set_contrast(eq);
> } else if (...)
>
> } else...
>
> This wauy you don't need to set the other parameters if they are not
> changed.
>
>
> Also it should return AVERROR(ENOSYS) in case of unrecognized command.
>
> > +
> > static const AVFilterPad eq_inputs[] = {
> > {
> > .name = "default",
> > @@ -260,12 +286,13 @@ static const AVOption eq_options[] = {
> > AVFILTER_DEFINE_CLASS(eq);
> >
> > AVFilter ff_vf_eq = {
> > -.name = "eq",
> > -.description = NULL_IF_CONFIG_SMALL("Adjust brightness, contrast,
> gamma, and saturation."),
> > -.priv_size = sizeof(EQContext),
> > -.priv_class= &eq_class,
> > -.inputs= eq_inputs,
> > -.outputs = eq_outputs,
> > -.query_formats = query_formats,
> > -.init = initialize,
>
> > +.name= "eq",
> > +.description = NULL_IF_CONFIG_SMALL("Adjust brightness,
> contrast, gamma, and saturation."),
> > +.priv_size = sizeof(EQContext),
> > +.priv_class = &eq_class,
> > +.inputs = eq_inputs,
> > +.outputs = eq_outputs,
> > +.process_command = process_command,
> > +.query_formats = query_formats,
> > +.init= initialize,
>
> avoid cosmetic changes, you can vertically realign in a separate
> (cosmetical) commit.
> --
> FFmpeg = Fostering Faithless Mournful Puristic Ecletic Generator
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
I have looked at various codes which use process_command and tried to
update the patch accordingly.
From 656071669ed14f8b273cd288526702406c6b22f9 Mon Sep 17 00:00:00 2001
From: Arwa Arif
Date: Thu, 19 Feb 2015 01:26:44 +0530
Subject: [PATCH] Add process_command to eq.
---
doc/filters.texi| 35 +++
libavfilter/vf_eq.c | 160 ---
libavfilter/vf_eq.h | 56 --
3 files changed, 199 insertions(+), 52 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index 191b52f..e5bf3a2 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -4402,6 +4402,41 @@ De
[FFmpeg-devel] [PATCH] libavfilter:vf_thumbnail.c: Fix bug in buffer handling for RGB width
This is a pretty obvious bug we caught in the thumbnail filter that is very
subtle and hardly ever shows issues except for certain videos. Yet it can
be seen how it is blatantly going out of bounds by basing the width
increment off of i*3 that resulted in odd crashes in rare cases.
Thanks,
Chris
--
---
Chris Kennedy
Video Engineer
CrunchyRoll - http://www.crunchyroll.com
diff --git a/libavfilter/vf_thumbnail.c b/libavfilter/vf_thumbnail.c
index 1883154..a1272a0 100644
--- a/libavfilter/vf_thumbnail.c
+++ b/libavfilter/vf_thumbnail.c
@@ -142,7 +142,8 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
*frame)
// update current frame RGB histogram
for (j = 0; j < inlink->h; j++) {
-for (i = 0; i < inlink->w; i++) {
+// last third of image, walk every 3 bytes/pixels reading RGB
+for (i = 0; i < inlink->w/3; i++) {
hist[0*256 + p[i*3]]++;
hist[1*256 + p[i*3 + 1]]++;
hist[2*256 + p[i*3 + 2]]++;
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavfilter:vf_thumbnail.c: Fix bug in buffer handling for RGB width
On Wed, Feb 18, 2015 at 02:22:53PM -0800, Chris Kennedy wrote:
> This is a pretty obvious bug we caught in the thumbnail filter that is very
> subtle and hardly ever shows issues except for certain videos. Yet it can
> be seen how it is blatantly going out of bounds by basing the width
> increment off of i*3 that resulted in odd crashes in rare cases.
>
>
> Thanks,
> Chris
> --
> ---
> Chris Kennedy
> Video Engineer
> CrunchyRoll - http://www.crunchyroll.com
> diff --git a/libavfilter/vf_thumbnail.c b/libavfilter/vf_thumbnail.c
> index 1883154..a1272a0 100644
> --- a/libavfilter/vf_thumbnail.c
> +++ b/libavfilter/vf_thumbnail.c
> @@ -142,7 +142,8 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
> *frame)
>
> // update current frame RGB histogram
> for (j = 0; j < inlink->h; j++) {
> -for (i = 0; i < inlink->w; i++) {
> +// last third of image, walk every 3 bytes/pixels reading RGB
> +for (i = 0; i < inlink->w/3; i++) {
width is expressed in pixels, not bytes.
How to reproduce the issue or crash?
> hist[0*256 + p[i*3]]++;
> hist[1*256 + p[i*3 + 1]]++;
> hist[2*256 + p[i*3 + 2]]++;
>
--
Clément B.
pgpUGn1jJaURH.pgp
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavfi: Add support to process_command in vf_eq.c
On Thu, Feb 19, 2015 at 02:33:43AM +0530, arwa arif wrote:
> On Sat, Jan 31, 2015 at 3:55 PM, Stefano Sabatini
> wrote:
>
> > On date Friday 2015-01-30 23:17:33 +0530, Arwa Arif encoded:
> > > I have tried to add process_command in vf_eq.c. I have attached the
> > patch.
> >
> > > From 1d65e493a8eb247d86b0db324cb740579662706d Mon Sep 17 00:00:00 2001
> > > From: Arwa Arif
> > > Date: Fri, 30 Jan 2015 23:06:50 +0530
> > > Subject: [PATCH] Add support to process_command in vf_eq.c
> > >
> > > ---
> > > libavfilter/vf_eq.c | 53
> > ++-
> > > 1 file changed, 40 insertions(+), 13 deletions(-)
> >
> > Missing doc updates.
> >
> > >
> > > diff --git a/libavfilter/vf_eq.c b/libavfilter/vf_eq.c
> > > index ad2a37e..5899abb 100644
> > > --- a/libavfilter/vf_eq.c
> > > +++ b/libavfilter/vf_eq.c
> > > @@ -27,11 +27,6 @@
> > > * very simple video equalizer
> > > */
> > >
> > > -/**
> > > - * TODO:
> > > - * - Add support to process_command
> > > - */
> > > -
> > > #include "libavfilter/internal.h"
> > > #include "libavutil/common.h"
> > > #include "libavutil/imgutils.h"
> > > @@ -217,6 +212,37 @@ static int filter_frame(AVFilterLink *inlink,
> > AVFrame *in)
> > > av_frame_free(&in);
> > > return ff_filter_frame(outlink, out);
> > > }
> > > +
> > > +static int process_command(AVFilterContext *ctx, const char *cmd, const
> > char *args,
> > > + char *res, int res_len, int flags)
> > > +{
> > > +EQContext *eq = ctx->priv;
> > > +
> > > +if (!strcmp(cmd, "contrast"))
> >
> > > +eq->contrast = av_clipf(strtod(args, NULL), -2.0, 2.0);
> >
> > All this parameters are set through the av_opt_ interface. Try to use
> > it, since otherwise range checks and parsing is inconsistent. In
> > particular, the parsing performed by av_opt_ may be different from
> > strtod(). Also you want to want the user in case of out-of-range values.
> >
> > > +if (!strcmp(cmd, "brightness"))
> > > +eq->brightness = av_clipf(strtod(args, NULL), -1.0, 1.0);
> > > +if (!strcmp(cmd, "saturation"))
> > > +eq->saturation = av_clipf(strtod(args, NULL), 0.0, 3.0);
> > > +if (!strcmp(cmd, "gamma"))
> > > +eq->gamma= av_clipf(strtod(args, NULL), 0.1, 10.0);
> > > +if (!strcmp(cmd, "gamma_r"))
> > > +eq->gamma_r = av_clipf(strtod(args, NULL), 0.1, 10.0);
> > > +if (!strcmp(cmd, "gamma_g"))
> > > +eq->gamma_g = av_clipf(strtod(args, NULL), 0.1, 10.0);
> > > +if (!strcmp(cmd, "gamma_b"))
> > > +eq->gamma_b = av_clipf(strtod(args, NULL), 0.1, 10.0);
> > > +if (!strcmp(cmd, "gamma_weight"))
> > > +eq->gamma_weight = av_clipf(strtod(args, NULL), 0.0, 1.0);
> > > +
> > > +set_gamma(eq);
> > > +set_contrast(eq);
> > > +set_brightness(eq);
> > > +set_saturation(eq);
> > > +
> > > +return 0;
> > > +}
> >
> > if (!strcmp(cmd, "contrast) {
> >set contrast
> >set_contrast(eq);
> > } else if (...)
> >
> > } else...
> >
> > This wauy you don't need to set the other parameters if they are not
> > changed.
> >
> >
> > Also it should return AVERROR(ENOSYS) in case of unrecognized command.
> >
> > > +
> > > static const AVFilterPad eq_inputs[] = {
> > > {
> > > .name = "default",
> > > @@ -260,12 +286,13 @@ static const AVOption eq_options[] = {
> > > AVFILTER_DEFINE_CLASS(eq);
> > >
> > > AVFilter ff_vf_eq = {
> > > -.name = "eq",
> > > -.description = NULL_IF_CONFIG_SMALL("Adjust brightness, contrast,
> > gamma, and saturation."),
> > > -.priv_size = sizeof(EQContext),
> > > -.priv_class= &eq_class,
> > > -.inputs= eq_inputs,
> > > -.outputs = eq_outputs,
> > > -.query_formats = query_formats,
> > > -.init = initialize,
> >
> > > +.name= "eq",
> > > +.description = NULL_IF_CONFIG_SMALL("Adjust brightness,
> > contrast, gamma, and saturation."),
> > > +.priv_size = sizeof(EQContext),
> > > +.priv_class = &eq_class,
> > > +.inputs = eq_inputs,
> > > +.outputs = eq_outputs,
> > > +.process_command = process_command,
> > > +.query_formats = query_formats,
> > > +.init= initialize,
> >
> > avoid cosmetic changes, you can vertically realign in a separate
> > (cosmetical) commit.
> > --
> > FFmpeg = Fostering Faithless Mournful Puristic Ecletic Generator
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
>
>
> I have looked at various codes which use process_command and tried to
> update the patch accordingly.
[...]
> Extract color channel components from input video stream into
> diff --git a/libavfilter/vf_eq.c b/libavfilter/vf_eq.c
> index 5899abb..2b957d3 100644
> --- a/libavfilter/vf_eq.c
> +++ b/libavfilter/vf_eq.c
Re: [FFmpeg-devel] [PATCH] libavfilter:vf_thumbnail.c: Fix bug in buffer handling for RGB width
On Wed, Feb 18, 2015 at 2:34 PM, Clément Bœsch wrote:
> On Wed, Feb 18, 2015 at 02:22:53PM -0800, Chris Kennedy wrote:
> > This is a pretty obvious bug we caught in the thumbnail filter that is
> very
> > subtle and hardly ever shows issues except for certain videos. Yet it
> can
> > be seen how it is blatantly going out of bounds by basing the width
> > increment off of i*3 that resulted in odd crashes in rare cases.
> >
> >
> > Thanks,
> > Chris
> > --
> > ---
> > Chris Kennedy
> > Video Engineer
> > CrunchyRoll - http://www.crunchyroll.com
>
> > diff --git a/libavfilter/vf_thumbnail.c b/libavfilter/vf_thumbnail.c
> > index 1883154..a1272a0 100644
> > --- a/libavfilter/vf_thumbnail.c
> > +++ b/libavfilter/vf_thumbnail.c
> > @@ -142,7 +142,8 @@ static int filter_frame(AVFilterLink *inlink,
> AVFrame *frame)
> >
> > // update current frame RGB histogram
> > for (j = 0; j < inlink->h; j++) {
> > -for (i = 0; i < inlink->w; i++) {
> > +// last third of image, walk every 3 bytes/pixels reading RGB
> > +for (i = 0; i < inlink->w/3; i++) {
>
> width is expressed in pixels, not bytes.
>
Right, this part seems tricky, yet it doesn't make sense to walk the entire
width with var i and then walk it by 3's up to the very last increment.
>
> How to reproduce the issue or crash?
>
> > hist[0*256 + p[i*3]]++;
> > hist[1*256 + p[i*3 + 1]]++;
> > hist[2*256 + p[i*3 + 2]]++;
> >
>
>
The source is copyrighted, and it happens on certain types of encodings it
seems, and only 1 out of every 250 or some really low number. I will work
on getting a reproducible case.
Thanks,
Chris
> --
> Clément B.
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avfilter/paletteuse: add diff_mode
On Wed, Feb 18, 2015 at 03:46:24PM +0100, Clément Bœsch wrote:
> From: Clément Bœsch
>
> TODO: bump minor
> ---
> doc/filters.texi| 15 +
> libavfilter/vf_paletteuse.c | 151
>
> 2 files changed, 153 insertions(+), 13 deletions(-)
>
> diff --git a/doc/filters.texi b/doc/filters.texi
> index 191b52f..d75e39a 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -6991,6 +6991,21 @@ visible pattern for less banding, and higher value
> means less visible pattern
> at the cost of more banding.
>
> The option must be an integer value in the range [0,5]. Default is @var{2}.
> +
> +@item diff_mode
> +If set, define the zone to process
> +
> +@table @samp
> +@item rectangle
> +Only the changing rectangle will be reprocessed. This is similar to GIF
> +cropping/offsetting compression mechanism. This option can be useful for
> speed
> +if only a part of the image is changing, and has use cases such as limiting
> the
> +scope of the error diffusal @option{dither} to the rectangle that bound the
> +moving scene (it leads to more deterministic output if the scene doesn't
> change
> +much, and as a result less moving noise and better GIF compression).
> +@end table
> +
> +Default is @var{none}.
> @end table
this is a nice idea
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
During times of universal deceit, telling the truth becomes a
revolutionary act. -- George Orwell
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] lavd/alsa: set frame_size field.
On Mon, Feb 16, 2015 at 10:22:15PM +0100, Nicolas George wrote: > The value tells the typical size of a packet from the demuxer. > > Signed-off-by: Nicolas George > --- > libavdevice/alsa-audio-common.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavdevice/alsa-audio-common.c b/libavdevice/alsa-audio-common.c > index bf876ed..f4b86bb 100644 > --- a/libavdevice/alsa-audio-common.c > +++ b/libavdevice/alsa-audio-common.c > @@ -260,7 +260,7 @@ av_cold int ff_alsa_open(AVFormatContext *ctx, > snd_pcm_stream_t mode, > snd_strerror(res)); > goto fail; > } > -s->period_size = period_size; > +ctx->streams[0]->codec->frame_size = s->period_size = period_size; doesnt this also set it for the muxer ? otherwise it is probably ok but you know this code better than i do ... [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB There will always be a question for which you do not know the correct answer. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavfilter:vf_thumbnail.c: Fix bug in buffer handling for RGB width
More details attached, debug level and gdb backtrace. Hopefully this
helps, and I will work on getting a file I can share showing the issue.
Thanks
On Wed, Feb 18, 2015 at 4:09 PM, Chris Kennedy wrote:
> On Wed, Feb 18, 2015 at 2:34 PM, Clément Bœsch wrote:
>
>> On Wed, Feb 18, 2015 at 02:22:53PM -0800, Chris Kennedy wrote:
>> > This is a pretty obvious bug we caught in the thumbnail filter that is
>> very
>> > subtle and hardly ever shows issues except for certain videos. Yet it
>> can
>> > be seen how it is blatantly going out of bounds by basing the width
>> > increment off of i*3 that resulted in odd crashes in rare cases.
>> >
>> >
>> > Thanks,
>> > Chris
>> > --
>> > ---
>> > Chris Kennedy
>> > Video Engineer
>> > CrunchyRoll - http://www.crunchyroll.com
>>
>> > diff --git a/libavfilter/vf_thumbnail.c b/libavfilter/vf_thumbnail.c
>> > index 1883154..a1272a0 100644
>> > --- a/libavfilter/vf_thumbnail.c
>> > +++ b/libavfilter/vf_thumbnail.c
>> > @@ -142,7 +142,8 @@ static int filter_frame(AVFilterLink *inlink,
>> AVFrame *frame)
>> >
>> > // update current frame RGB histogram
>> > for (j = 0; j < inlink->h; j++) {
>> > -for (i = 0; i < inlink->w; i++) {
>> > +// last third of image, walk every 3 bytes/pixels reading RGB
>> > +for (i = 0; i < inlink->w/3; i++) {
>>
>> width is expressed in pixels, not bytes.
>>
>
> Right, this part seems tricky, yet it doesn't make sense to walk the
> entire width with var i and then walk it by 3's up to the very last
> increment.
>
>
>>
>> How to reproduce the issue or crash?
>>
>> > hist[0*256 + p[i*3]]++;
>> > hist[1*256 + p[i*3 + 1]]++;
>> > hist[2*256 + p[i*3 + 2]]++;
>> >
>>
>>
> The source is copyrighted, and it happens on certain types of encodings it
> seems, and only 1 out of every 250 or some really low number. I will work
> on getting a reproducible case.
>
> Thanks,
> Chris
>
>
>> --
>> Clément B.
>>
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>>
>
>
ffmpeg -nostdin -nostats -analyzeduration 774552000 -threads 1 -i input.avi
-threads 1 -vsync 0 -q:v 0 -an -vf trim=300:776,fps=fps=29.97,thumbnail=178
video%02d.jpg
Returned: [Parsed_thumbnail_2 @ 0x2f4cac0] frame id #128 (pts_time=351.785118)
selected from a set of 178 images
WIP, backtrace and full debug ready, I am going to hunt now for the issue and
try to fix it:
Starting program: /opt/ffmpeg/ffmpeg -nostdin -nostats -analyzeduration
774552000 -threads 1 -i input.avi -threads 1 -vsync 0 -q:v 0 -an -vf
trim=300:776,fps=fps=29.97,thumbnail=178 -loglevel debug video%02d.jpg
[Thread debugging using libthread_db enabled]
ffmpeg version n2.5.1-22-g26e5e17 Copyright (c) 2000-2014 the FFmpeg developers
built on Feb 17 2015 15:59:56 with gcc 4.4.7 (GCC) 20120313 (Red Hat 4.4.7-11)
configuration: --prefix=/usr --disable-outdev=sdl --disable-ffplay
--disable-ffserver --enable-gpl --enable-nonfree --disable-shared
--disable-optimizations --disable-stripping --enable-debug=3 --enable-static
--disable-mmx --disable-mmxext --disable-ssse3 --extra-cflags='-O0 -fno-inline'
libavutil 54. 15.100 / 54. 15.100
libavcodec 56. 13.100 / 56. 13.100
libavformat 56. 15.102 / 56. 15.102
libavdevice 56. 3.100 / 56. 3.100
libavfilter 5. 2.103 / 5. 2.103
libswscale 3. 1.101 / 3. 1.101
libswresample 1. 1.100 / 1. 1.100
libpostproc 53. 3.100 / 53. 3.100
Splitting the commandline.
Reading option '-nostdin' ... matched as option 'stdin' (enable or disable
interaction on standard input) with argument 0.
Reading option '-nostats' ... matched as option 'stats' (print progress report
during encoding) with argument 0.
Reading option '-analyzeduration' ... matched as AVOption 'analyzeduration'
with argument '774552000'.
Reading option '-threads' ... matched as AVOption 'threads' with argument '1'.
Reading option '-i' ... matched as input file with argument 'input.avi'.
Reading option '-threads' ... matched as AVOption 'threads' with argument '1'.
Reading option '-vsync' ... matched as option 'vsync' (video sync method) with
argument '0'.
Reading option '-q:v' ... matched as option 'q' (use fixed quality scale (VBR))
with argument '0'.
Reading option '-an' ... matched as option 'an' (disable audio) with argument
'1'.
Reading option '-vf' ... matched as option 'vf' (set video filters) with
argument 'trim=300:776,fps=fps=29.97,thumbnail=178'.
Reading option '-loglevel' ... matched as option 'loglevel' (set logging level)
with argument 'debug'.
Reading option 'video%02d.jpg' ... matched as output file.
Finished splitting the commandline.
Parsing a group of options: global .
Applying option nostdin (enable or disable interaction on standard input) with
argument 0.
Applying option nostats (print progress report during encoding) with argument 0.
Applying option vsync (video sync method) with argument 0.
Applying option loglevel (set lo
Re: [FFmpeg-devel] [PATCH] doc/filters: simplify lenscorrection option descriptions
On Mon, 9 Feb 2015 11:04:47 -0900, Lou Logan wrote: > Also mention option defaults. > Also fix incorrect k1 and k2 "no correction" values. > > Signed-off-by: Lou Logan > --- > doc/filters.texi | 14 ++ > 1 file changed, 6 insertions(+), 8 deletions(-) Ping. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavfilter:vf_thumbnail.c: Fix bug in buffer handling for RGB width
On Wed, Feb 18, 2015 at 04:09:39PM -0800, Chris Kennedy wrote:
> On Wed, Feb 18, 2015 at 2:34 PM, Clément Bœsch wrote:
>
> > On Wed, Feb 18, 2015 at 02:22:53PM -0800, Chris Kennedy wrote:
> > > This is a pretty obvious bug we caught in the thumbnail filter that is
> > very
> > > subtle and hardly ever shows issues except for certain videos. Yet it
> > can
> > > be seen how it is blatantly going out of bounds by basing the width
> > > increment off of i*3 that resulted in odd crashes in rare cases.
> > >
> > >
> > > Thanks,
> > > Chris
> > > --
> > > ---
> > > Chris Kennedy
> > > Video Engineer
> > > CrunchyRoll - http://www.crunchyroll.com
> >
> > > diff --git a/libavfilter/vf_thumbnail.c b/libavfilter/vf_thumbnail.c
> > > index 1883154..a1272a0 100644
> > > --- a/libavfilter/vf_thumbnail.c
> > > +++ b/libavfilter/vf_thumbnail.c
> > > @@ -142,7 +142,8 @@ static int filter_frame(AVFilterLink *inlink,
> > AVFrame *frame)
> > >
> > > // update current frame RGB histogram
> > > for (j = 0; j < inlink->h; j++) {
> > > -for (i = 0; i < inlink->w; i++) {
> > > +// last third of image, walk every 3 bytes/pixels reading RGB
> > > +for (i = 0; i < inlink->w/3; i++) {
> >
> > width is expressed in pixels, not bytes.
> >
>
> Right, this part seems tricky, yet it doesn't make sense to walk the entire
> width with var i and then walk it by 3's up to the very last increment.
>
well it's width x 3 components, so I'm not sure I get your problem.
>
> >
> > How to reproduce the issue or crash?
> >
> > > hist[0*256 + p[i*3]]++;
> > > hist[1*256 + p[i*3 + 1]]++;
> > > hist[2*256 + p[i*3 + 2]]++;
> > >
> >
> >
> The source is copyrighted, and it happens on certain types of encodings it
> seems, and only 1 out of every 250 or some really low number. I will work
> on getting a reproducible case.
>
valgrind doesn't give you hints? Or you can't get a coredump & backtrace?
[...]
--
Clément B.
pgpHWmoUT5AbP.pgp
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
