Re: [FFmpeg-devel] [PATCH] tests/api: Fix API test build on windows with --enable-shared
On Wed, Dec 2, 2015 at 2:29 AM, Michael Niedermayer wrote: > On Tue, Dec 01, 2015 at 08:04:22PM +0100, Hendrik Leppkes wrote: >> On Mon, Nov 30, 2015 at 10:50 PM, Hendrik Leppkes >> wrote: >> > --- >> > I'm not quite sure if this fix is 100% correct, but it works here. >> > >> > The problem is that FF_DEP_LIBS points to the .dll files, but you can't >> > link to the .dll files, >> > you need to point to the import libraries. Unfortunately there is no >> > variable which simply >> > holds all import libraries - but they do appear to be part of >> > FF_EXTRALIBS, so thats used instead. >> > >> > tests/api/Makefile | 2 +- >> > 1 file changed, 1 insertion(+), 1 deletion(-) >> > >> > diff --git a/tests/api/Makefile b/tests/api/Makefile >> > index c48c34a..a6d8e42 100644 >> > --- a/tests/api/Makefile >> > +++ b/tests/api/Makefile >> > @@ -14,7 +14,7 @@ $(APITESTOBJS) $(APITESTOBJS:.o=.i): CPPFLAGS += -DTEST >> > $(APITESTOBJS) $(APITESTOBJS:.o=.i): CFLAGS += -Umain >> > >> > $(APITESTPROGS): %$(EXESUF): %.o $(EXEOBJS) $(FF_DEP_LIBS) >> > - $(LD) $(LDFLAGS) $(LDEXEFLAGS) $(LD_O) $(filter %.o,$^) >> > $(FF_DEP_LIBS) $(FFEXTRALIBS) $(ELIBS) >> > + $(LD) $(LDFLAGS) $(LDEXEFLAGS) $(LD_O) $(filter %.o,$^) >> > $(FF_EXTRALIBS) $(ELIBS) >> > >> > testclean:: >> > $(RM) $(addprefix $(APITESTSDIR)/,$(CLEANSUFFIXES) *-test$(EXESUF)) >> > -- >> > 2.6.2.windows.1 >> > >> >> Anyone that knows the build system a bit more? Or maybe anyone that > >> just feels like testing on some other systems than mine? :) > > seems to work on everything i tried but that probably is a small > subset of what is out there > Considering this is only in the FATE Makefile, I'll push this later and address any fallout on FATE, if any, unless someone objects in the next couple hours. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mp3dec: prefer "fast_seek" to TOC seek for CBR files.
On Wed, 2 Dec 2015 02:23:15 +0100 Michael Niedermayer wrote: > On Tue, Dec 01, 2015 at 10:47:53AM -0800, Chris Cunningham wrote: > > Thanks wm4, next patch will fix that declaration. > > > > Michael, any concerns? > > iam fine with the patch > > > > > > On Mon, Nov 30, 2015 at 2:51 PM, wm4 wrote: > [...] > > > Other than that LGTM. > > wm4, your replies are missing from the mailing list Must be my mail client again, which replied to the CC instead of the ML. > (and i dont know what "Other" was meant for so dunno if i should apply > or wait) > > [...] There was a declaration after statement. I guess I can fix as I push, later. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/3] libavutil/tablegen: add missing math.h include
--- libavutil/tablegen.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/libavutil/tablegen.h b/libavutil/tablegen.h index f81b46b..02acdd6 100644 --- a/libavutil/tablegen.h +++ b/libavutil/tablegen.h @@ -24,6 +24,8 @@ #ifndef AVUTIL_TABLEGEN_H #define AVUTIL_TABLEGEN_H +#include + // we lack some functions on all host platforms, and we don't care about // performance and/or strict ISO C semantics as it's performed at build time static inline double ff_cbrt(double x) -- 2.6.2.windows.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/3] avcodec: include tablegen compat header before the tablegen functionality
--- libavcodec/cbrt_tablegen_template.c | 2 +- libavcodec/mpegaudio_tablegen.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/libavcodec/cbrt_tablegen_template.c b/libavcodec/cbrt_tablegen_template.c index 1d71d34..7dcab91 100644 --- a/libavcodec/cbrt_tablegen_template.c +++ b/libavcodec/cbrt_tablegen_template.c @@ -22,8 +22,8 @@ #include #define CONFIG_HARDCODED_TABLES 0 -#include "cbrt_tablegen.h" #include "libavutil/tablegen.h" +#include "cbrt_tablegen.h" #include "tableprint.h" int main(void) diff --git a/libavcodec/mpegaudio_tablegen.c b/libavcodec/mpegaudio_tablegen.c index 9a9bb4d..ede7c8e 100644 --- a/libavcodec/mpegaudio_tablegen.c +++ b/libavcodec/mpegaudio_tablegen.c @@ -22,8 +22,8 @@ #include #define CONFIG_HARDCODED_TABLES 0 -#include "mpegaudio_tablegen.h" #include "libavutil/tablegen.h" +#include "mpegaudio_tablegen.h" #include "tableprint.h" int main(void) -- 2.6.2.windows.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/3] libavcodec/aacsbr_tablegen: fix tablegen on windows
Including these headers is not needed and breaks building on Windows as it tries to activate the full compat tools, which are not needed for host tools. --- libavcodec/aacsbr_fixed_tablegen.c | 3 --- libavcodec/aacsbr_tablegen.c| 3 --- libavcodec/aacsbr_tablegen_common.h | 3 ++- 3 files changed, 2 insertions(+), 7 deletions(-) diff --git a/libavcodec/aacsbr_fixed_tablegen.c b/libavcodec/aacsbr_fixed_tablegen.c index b896d75..832fcb7 100644 --- a/libavcodec/aacsbr_fixed_tablegen.c +++ b/libavcodec/aacsbr_fixed_tablegen.c @@ -21,9 +21,6 @@ */ #include -#include "libavutil/internal.h" -#include "libavutil/common.h" -#undef CONFIG_HARDCODED_TABLES #define CONFIG_HARDCODED_TABLES 0 #define USE_FIXED 1 #include "aacsbr_fixed_tablegen.h" diff --git a/libavcodec/aacsbr_tablegen.c b/libavcodec/aacsbr_tablegen.c index ee0d818..c331c57 100644 --- a/libavcodec/aacsbr_tablegen.c +++ b/libavcodec/aacsbr_tablegen.c @@ -21,9 +21,6 @@ */ #include -#include "libavutil/internal.h" -#include "libavutil/common.h" -#undef CONFIG_HARDCODED_TABLES #define CONFIG_HARDCODED_TABLES 0 #define USE_FIXED 0 #include "aacsbr_tablegen.h" diff --git a/libavcodec/aacsbr_tablegen_common.h b/libavcodec/aacsbr_tablegen_common.h index 0a64552..d7fc306 100644 --- a/libavcodec/aacsbr_tablegen_common.h +++ b/libavcodec/aacsbr_tablegen_common.h @@ -22,7 +22,8 @@ #ifndef AVCODEC_AACSBR_TABLEGEN_COMMON_H #define AVCODEC_AACSBR_TABLEGEN_COMMON_H -#include "aac.h" +#include "aac_defines.h" +#include "libavutil/mem.h" #if CONFIG_HARDCODED_TABLES #define aacsbr_tableinit() -- 2.6.2.windows.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] libavutil/tablegen: add missing math.h include
On 12/2/15, Hendrik Leppkes wrote: > --- > libavutil/tablegen.h | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/libavutil/tablegen.h b/libavutil/tablegen.h > index f81b46b..02acdd6 100644 > --- a/libavutil/tablegen.h > +++ b/libavutil/tablegen.h > @@ -24,6 +24,8 @@ > #ifndef AVUTIL_TABLEGEN_H > #define AVUTIL_TABLEGEN_H > > +#include > + > // we lack some functions on all host platforms, and we don't care about > // performance and/or strict ISO C semantics as it's performed at build > time > static inline double ff_cbrt(double x) > -- > 2.6.2.windows.1 > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ok ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mp3dec: prefer "fast_seek" to TOC seek for CBR files.
On Tue, 1 Dec 2015 10:54:38 -0800 chcunning...@chromium.org wrote: > From: Chris Cunningham > > "Fast seek" uses linear interpolation to find the position of the > requested seek time. For CBR this is more direct than using the > mp3 TOC and bypassing the TOC avoids problems with TOC precision. > (see https://crbug.com/545914#c13) > > For VBR, fast seek is not precise, so continue to prefer the TOC > when available (the lesser of two evils). > > Also, some re-ordering of the logic in mp3_seek to simplify and > give usetoc=1 precedence over fastseek flag. > --- > libavformat/mp3dec.c| 39 +++ > libavformat/seek-test.c | 8 +--- > tests/fate/seek.mak | 2 +- > 3 files changed, 25 insertions(+), 24 deletions(-) > > diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c > index 32ca00c..04c9861 100644 > --- a/libavformat/mp3dec.c > +++ b/libavformat/mp3dec.c > @@ -115,7 +115,8 @@ static void read_xing_toc(AVFormatContext *s, int64_t > filesize, int64_t duration > { > int i; > MP3DecContext *mp3 = s->priv_data; > -int fill_index = mp3->usetoc == 1 && duration > 0; > +int fast_seek = s->flags & AVFMT_FLAG_FAST_SEEK; > +int fill_index = (mp3->usetoc || fast_seek) && duration > 0; > > if (!filesize && > !(filesize = avio_size(s->pb))) { > @@ -344,9 +345,6 @@ static int mp3_read_header(AVFormatContext *s) > int ret; > int i; > > -if (mp3->usetoc < 0) > -mp3->usetoc = (s->flags & AVFMT_FLAG_FAST_SEEK) ? 1 : 2; > - > st = avformat_new_stream(s, NULL); > if (!st) > return AVERROR(ENOMEM); > @@ -501,35 +499,36 @@ static int mp3_seek(AVFormatContext *s, int > stream_index, int64_t timestamp, > MP3DecContext *mp3 = s->priv_data; > AVIndexEntry *ie, ie1; > AVStream *st = s->streams[0]; > -int64_t ret = av_index_search_timestamp(st, timestamp, flags); > int64_t best_pos; > -int fast_seek = (s->flags & AVFMT_FLAG_FAST_SEEK) ? 1 : 0; > +int fast_seek = s->flags & AVFMT_FLAG_FAST_SEEK; > int64_t filesize = mp3->header_filesize; > > -if (mp3->usetoc == 2) > -return -1; // generic index code > - > if (filesize <= 0) { > int64_t size = avio_size(s->pb); > if (size > 0 && size > s->internal->data_offset) > filesize = size - s->internal->data_offset; > } > > -if ( (mp3->is_cbr || fast_seek) > -&& (mp3->usetoc == 0 || !mp3->xing_toc) > -&& st->duration > 0 > -&& filesize > 0) { > -ie = &ie1; > -timestamp = av_clip64(timestamp, 0, st->duration); > -ie->timestamp = timestamp; > -ie->pos = av_rescale(timestamp, filesize, st->duration) + > s->internal->data_offset; > -} else if (mp3->xing_toc) { > +if (mp3->xing_toc && (mp3->usetoc || (fast_seek && !mp3->is_cbr))) { > +// NOTE: The MP3 TOC is not a precise lookup table. Accuracy is worse > +// for bigger files. > +av_log(s, AV_LOG_WARNING, "Using MP3 TOC to seek; may be > imprecise.\n"); > + > +int64_t ret = av_index_search_timestamp(st, timestamp, flags); I moved this line above the av_log() to avoid declaration-after-statement. > if (ret < 0) > return ret; > > ie = &st->index_entries[ret]; > +} else if (fast_seek && st->duration > 0 && filesize > 0) { > +if (!mp3->is_cbr) > +av_log(s, AV_LOG_WARNING, "Using scaling to seek VBR MP3; may be > imprecise.\n"); > + > +ie = &ie1; > +timestamp = av_clip64(timestamp, 0, st->duration); > +ie->timestamp = timestamp; > +ie->pos = av_rescale(timestamp, filesize, st->duration) + > s->internal->data_offset; > } else { > -return -1; > +return -1; // generic index code > } > > best_pos = mp3_sync(s, ie->pos, flags); > @@ -546,7 +545,7 @@ static int mp3_seek(AVFormatContext *s, int stream_index, > int64_t timestamp, > } > > static const AVOption options[] = { > -{ "usetoc", "use table of contents", offsetof(MP3DecContext, usetoc), > AV_OPT_TYPE_INT, {.i64 = -1}, -1, 2, AV_OPT_FLAG_DECODING_PARAM}, > +{ "usetoc", "use table of contents", offsetof(MP3DecContext, usetoc), > AV_OPT_TYPE_INT, {.i64 = 0}, 0, 1, AV_OPT_FLAG_DECODING_PARAM}, > { NULL }, > }; > > diff --git a/libavformat/seek-test.c b/libavformat/seek-test.c > index 1926f21..bfd06db 100644 > --- a/libavformat/seek-test.c > +++ b/libavformat/seek-test.c > @@ -56,7 +56,7 @@ static void ts_str(char buffer[60], int64_t ts, AVRational > base) > int main(int argc, char **argv) > { > const char *filename; > -AVFormatContext *ic = NULL; > +AVFormatContext *ic = avformat_alloc_context(); > int i, ret, stream_id; > int j; > int64_t timestamp; > @@ -76,8 +76,10 @@ int main(int argc, char **argv) > frame_count = atoi(argv[i+1]); > } else if(!strcmp(argv[i],
Re: [FFmpeg-devel] [PATCH] Fix sample_aspect_ratio computation for stereo matroska content.
On Wed, 02 Dec 2015 00:32:46 + Aaron Colwell wrote: > On Mon, Nov 30, 2015 at 4:35 PM wm4 wrote: > > > > > I tried your patch, and it actually makes it work better (looks correct > > with the patch). The patch itself also LGTM. > > > > > Ok. Great. Thanks for the review. What do I need to do next to get this > checked in. I don't have commit access. Well, first it has to be determined whether the patch is accepted, and then someone has to push it. I just did the latter. Before pushing, I slightly modified the subject line to add a prefix and to make it somewhat shorter (as the prefix made it too long). I hope this is ok. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] AAC encoder: improve SF range utilization
On Tue, Dec 1, 2015 at 11:12 PM, Claudio Freire wrote: > On Tue, Dec 1, 2015 at 10:47 PM, Michael Niedermayer wrote: >>> libavcodec/aaccoder.c | 60 -- >>> libavcodec/aaccoder_twoloop.h | 136 >>> -- >>> libavcodec/aacenc.c |2 >>> libavcodec/aacenc_is.c| 11 ++- >>> libavcodec/aacenc_utils.h | 63 +++ >>> libavcodec/aacpsy.c | 20 -- >>> libavcodec/psymodel.c |1 >>> libavcodec/psymodel.h |1 >>> tests/fate/aac.mak| 18 ++--- >>> 9 files changed, 231 insertions(+), 81 deletions(-) >>> 404ff616bb267619be431a7c45afa4db82070b65 >>> 0001-AAC-encoder-improve-SF-range-utilization.patch >> >> some stuff in mips will need to be updated by someone or disabled >> after this is pushed: >> CC libavcodec/aacpsy.o >> /ffmpeg/libavcodec/aacpsy.c: In function ‘psy_3gpp_analyze_channel’: >> /ffmpeg/libavcodec/aacpsy.c:666: error: too many arguments to function >> ‘calc_thr_3gpp_mips’ >> make: *** [libavcodec/aacpsy.o] Error 1 >> make: Target `all' not remade because of errors. > > > Oh, didn't realize mips had an alternative calc_thr_3gpp. > > I'll see about updating it as I push. Also refreshed search_for_ms_mips and pushed. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avutil/threadmessage: add av_thread_message_flush()
On Tue, Dec 01, 2015 at 06:49:29PM +0100, Nicolas George wrote: > Le primidi 11 frimaire, an CCXXIV, Clement Boesch a écrit : > > Ah. Well then the user can not do it himself since he has no way of > > acquiring the queue lock (AVThreadMessageQueue is opaque) > > Yes, but why does it matter, if the elements are to be discarded anyway. > because concurrent read/write accesses on the fifo needs to be locked? I don't understand... -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/9] avfilter/af_stereotools: use lrint instead of floor hack
On 12/2/15, Paul B Mahol wrote: > On 12/2/15, Ganesh Ajjanagadde wrote: >> Signed-off-by: Ganesh Ajjanagadde >> --- >> libavfilter/af_stereotools.c | 8 >> 1 file changed, 4 insertions(+), 4 deletions(-) >> >> diff --git a/libavfilter/af_stereotools.c b/libavfilter/af_stereotools.c >> index a22efb0..e878824 100644 >> --- a/libavfilter/af_stereotools.c >> +++ b/libavfilter/af_stereotools.c >> @@ -139,10 +139,10 @@ static int filter_frame(AVFilterLink *inlink, >> AVFrame >> *in) >> const double sc_level = s->sc_level; >> const double delay = s->delay; >> const int length = s->length; >> -const int mute_l = floor(s->mute_l + 0.5); >> -const int mute_r = floor(s->mute_r + 0.5); >> -const int phase_l = floor(s->phase_l + 0.5); >> -const int phase_r = floor(s->phase_r + 0.5); >> +const int mute_l = lrint(s->mute_l); >> +const int mute_r = lrint(s->mute_r); >> +const int phase_l = lrint(s->phase_l); >> +const int phase_r = lrint(s->phase_r); >> double *buffer = s->buffer; >> AVFrame *out; >> double *dst; >> -- >> 2.6.2 >> >> ___ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> > > ok > Actually lrint is not needed. Fixed differently. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/9] avfilter/af_flanger: use rint instead of floor hack
On Wed, Dec 2, 2015 at 1:18 AM, Paul B Mahol wrote: > On 12/2/15, Ganesh Ajjanagadde wrote: >> Signed-off-by: Ganesh Ajjanagadde >> --- >> libavfilter/af_flanger.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/libavfilter/af_flanger.c b/libavfilter/af_flanger.c >> index f8ec830..a92367c 100644 >> --- a/libavfilter/af_flanger.c >> +++ b/libavfilter/af_flanger.c >> @@ -130,7 +130,7 @@ static int config_input(AVFilterLink *inlink) >> return AVERROR(ENOMEM); >> >> ff_generate_wave_table(s->wave_shape, AV_SAMPLE_FMT_FLT, s->lfo, >> s->lfo_length, >> - floor(s->delay_min * inlink->sample_rate + 0.5), >> + rint(s->delay_min * inlink->sample_rate), >> s->max_samples - 2., 3 * M_PI_2); >> >> return av_samples_alloc_array_and_samples(&s->delay_buffer, NULL, >> -- >> 2.6.2 >> >> ___ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> > > Have you checked that output is same? Well if is not, rint is more accurate than floor, this is the whole point of the patch. What I can tell is that FATE passes. One can craft input so that floor(x + 0.5) is not identical to rint(x), and that is the point of these patches - to be more accurate when we can be. A simple example: what happens at half-integers, i.e 1.5? Then, floor always returns the next up, e.g 2.0, while rint(x) rounds to the nearest even integer in accord with IEEE-754. This is done to reduce rounding biases on floating point numbers - think of a large number of half integer samples, the floor hack results in consistent upward bias, the rint (or llrint, lrint more generally) avoids this. I care about technical purity of filters; you seem to care about copying it over from some other place and matching another filter exactly, regardless of the quality of such filters. In that case, I think FFmpeg's monolithic filter design needs to be reconsidered; we should allow seamless integration of external filters. These two goals are at odds with each other, and I will always personally prefer the first, since it actually allows greater flexibility for improvements. Ultimately, I am not a maintainer for these things and I have no say on the matter or personal interest in it. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/9] avfilter/af_stereotools: use lrint instead of floor hack
On Wed, Dec 2, 2015 at 6:03 AM, Paul B Mahol wrote: > On 12/2/15, Paul B Mahol wrote: >> On 12/2/15, Ganesh Ajjanagadde wrote: >>> Signed-off-by: Ganesh Ajjanagadde >>> --- >>> libavfilter/af_stereotools.c | 8 >>> 1 file changed, 4 insertions(+), 4 deletions(-) >>> >>> diff --git a/libavfilter/af_stereotools.c b/libavfilter/af_stereotools.c >>> index a22efb0..e878824 100644 >>> --- a/libavfilter/af_stereotools.c >>> +++ b/libavfilter/af_stereotools.c >>> @@ -139,10 +139,10 @@ static int filter_frame(AVFilterLink *inlink, >>> AVFrame >>> *in) >>> const double sc_level = s->sc_level; >>> const double delay = s->delay; >>> const int length = s->length; >>> -const int mute_l = floor(s->mute_l + 0.5); >>> -const int mute_r = floor(s->mute_r + 0.5); >>> -const int phase_l = floor(s->phase_l + 0.5); >>> -const int phase_r = floor(s->phase_r + 0.5); >>> +const int mute_l = lrint(s->mute_l); >>> +const int mute_r = lrint(s->mute_r); >>> +const int phase_l = lrint(s->phase_l); >>> +const int phase_r = lrint(s->phase_r); >>> double *buffer = s->buffer; >>> AVFrame *out; >>> double *dst; >>> -- >>> 2.6.2 >>> >>> ___ >>> ffmpeg-devel mailing list >>> ffmpeg-devel@ffmpeg.org >>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >>> >> >> ok >> > > Actually lrint is not needed. Fixed differently. thanks ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/9] avfilter/af_flanger: use rint instead of floor hack
On 12/2/15, Ganesh Ajjanagadde wrote: > On Wed, Dec 2, 2015 at 1:18 AM, Paul B Mahol wrote: >> On 12/2/15, Ganesh Ajjanagadde wrote: >>> Signed-off-by: Ganesh Ajjanagadde >>> --- >>> libavfilter/af_flanger.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/libavfilter/af_flanger.c b/libavfilter/af_flanger.c >>> index f8ec830..a92367c 100644 >>> --- a/libavfilter/af_flanger.c >>> +++ b/libavfilter/af_flanger.c >>> @@ -130,7 +130,7 @@ static int config_input(AVFilterLink *inlink) >>> return AVERROR(ENOMEM); >>> >>> ff_generate_wave_table(s->wave_shape, AV_SAMPLE_FMT_FLT, s->lfo, >>> s->lfo_length, >>> - floor(s->delay_min * inlink->sample_rate + >>> 0.5), >>> + rint(s->delay_min * inlink->sample_rate), >>> s->max_samples - 2., 3 * M_PI_2); >>> >>> return av_samples_alloc_array_and_samples(&s->delay_buffer, NULL, >>> -- >>> 2.6.2 >>> >>> ___ >>> ffmpeg-devel mailing list >>> ffmpeg-devel@ffmpeg.org >>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >>> >> >> Have you checked that output is same? > > Well if is not, rint is more accurate than floor, this is the whole > point of the patch. What I can tell is that FATE passes. > > One can craft input so that floor(x + 0.5) is not identical to > rint(x), and that is the point of these patches - to be more accurate > when we can be. A simple example: what happens at half-integers, i.e > 1.5? Then, floor always returns the next up, e.g 2.0, while rint(x) > rounds to the nearest even integer in accord with IEEE-754. This is > done to reduce rounding biases on floating point numbers - think of a > large number of half integer samples, the floor hack results in > consistent upward bias, the rint (or llrint, lrint more generally) > avoids this. > > I care about technical purity of filters; you seem to care about > copying it over from some other place and matching another filter > exactly, regardless of the quality of such filters. In that case, I > think FFmpeg's monolithic filter design needs to be reconsidered; we > should allow seamless integration of external filters. These two goals > are at odds with each other, and I will always personally prefer the > first, since it actually allows greater flexibility for improvements. > Ultimately, I am not a maintainer for these things and I have no say > on the matter or personal interest in it. > On 2nd look, patch should be fine. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avutil/threadmessage: add av_thread_message_flush()
Le duodi 12 frimaire, an CCXXIV, Clement Boesch a écrit : > because concurrent read/write accesses on the fifo needs to be locked? No, of course not. > I don't understand... *I* do not understand what you need, what you want to do with this API. To discard all elements, just read them until there are no more, no need of locking (except internally to read them, of course), no need for anything else. So what am I missing? 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]lavf/rtpenc_jpeg: Fix huffman table test
On Monday 30 November 2015 10:57:32 pm Michael Niedermayer wrote: > On Mon, Nov 30, 2015 at 01:18:21AM +0100, Carl Eugen Hoyos wrote: > > On Saturday 28 November 2015 02:32:37 am Carl Eugen Hoyos wrote: > > > Hi! > > > > > > Jpeg over rtp requires standard huffman tables, but the test I > > > implemented was too strict. Attached patch tries to improve this, > > > related to ticket #3823. > > > > New patch attached. > > > > Please review, Carl Eugen > > should be ok if it works I applied a variant of this. Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] avcodec: include tablegen compat header before the tablegen functionality
On Wed, Dec 02, 2015 at 09:52:02AM +0100, Hendrik Leppkes wrote: > --- > libavcodec/cbrt_tablegen_template.c | 2 +- > libavcodec/mpegaudio_tablegen.c | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) should be ok (ugly though that the order matters) [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The misfortune of the wise is better than the prosperity of the fool. -- Epicurus signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Allow mpjpeg demuxer to process MIME parts which do not include Content-Length header.
On 11/30/15 10:35 AM, Alexander Agranovsky wrote: On 11/30/15 10:24 AM, Nicolas George wrote: Le decadi 10 frimaire, an CCXXIV, Alexander Agranovsky a écrit : Without getting into a religious debate This is the reason I gave practical argument. As pointed later in the thread, lu is used elsewhere. And yes, MS makes it interesting in this case. wm4 explained that point. Really, long and short should only ever be used by libc headers to implement intXX_t. I've pondered the change, but with if (!av_stristart(start, "boundary=")) { start += 9; '9' seems a bit random, and with This is the reason for the third argument of av_stristart(): if (av_stristart(start, "boundary=", &start)) { // no need to add 9, av_stristart() does it } Ah, missed that. Thanks -- attaching new iteration with this change. Regards, ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel Hi guys -- where do we stand with this? Are there any additional comments? - A. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avutil/threadmessage: add av_thread_message_flush()
On Wed, Dec 02, 2015 at 03:13:33PM +0100, Nicolas George wrote: > Le duodi 12 frimaire, an CCXXIV, Clement Boesch a écrit : > > because concurrent read/write accesses on the fifo needs to be locked? > > No, of course not. I was talking about the fifo itself, not the threadmessage API. > > > I don't understand... > > *I* do not understand what you need, what you want to do with this API. To > discard all elements, just read them until there are no more, no need of > locking (except internally to read them, of course), no need for anything > else. So what am I missing? I'd say it prevents the sender (application side) to become a reader in order to read every message concurrently with the dedicated reader(s) in the goal of discarding them so they can't read them. In case I'm not clear, one simple scenario would be the following: - there is a large queue of packets, almost filled - there is one fast sender filling the queue (the demuxer) - there is a bunch of slow readers reading from the queue (the decoders) - the sender "receives" a seek event from the user - the sender now wants to stop as fast as possible readers (decoders) from reading all kind of packets If that sender has to lock for every message it's going to read & drop, while the decoders are still fighting to read them from the queue, it looks very ineffective to me. Hopefully this clarifies. I'm not sure what kind of similar information I could write in the doxy. If you have any suggestion... I will send a new patchset very soon (with important bug fixes and improvements) Regards, -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avutil/threadmessage: add av_thread_message_flush()
Le duodi 12 frimaire, an CCXXIV, Clement Boesch a écrit : > - there is a large queue of packets, almost filled > - there is one fast sender filling the queue (the demuxer) > - there is a bunch of slow readers reading from the queue (the decoders) > - the sender "receives" a seek event from the user > - the sender now wants to stop as fast as possible readers (decoders) >from reading all kind of packets Ok. > If that sender has to lock for every message it's going to read & drop, > while the decoders are still fighting to read them from the queue, it > looks very ineffective to me. This, especially "looks very ineffective", sounds like premature optimization. I am not against it, but then the documentation should tell it is an optimization. And conversely, if it is not only a matter of efficiency but also of correctness, the documentation must explain what the risk is. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] threadmessage improvements v2
Improvements & changes regarding last iteration: [PATCH 1/3] avutil/threadmessage: add av_thread_message_flush() - the flushing function can be set through a dedicated function instead of a new constructor prototype - the flush function is now fixed regarding messages larger than a pointer... [PATCH 2/3] fate/api: test threadmessage - the test program is greatly improved by allowing multiple readers in addition to multiple senders. - the flush now occurs randomly in readers and senders - the messages are now larger than a pointer (see bug fix in 1/3) with a magic check [PATCH 3/3] avutil/threadmessage: fix condition broadcasting - instead of an inefficient wide signal broadcasting, it's now using 2 distinct conditions for reading and sending ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/3] avutil/threadmessage: add av_thread_message_flush()
From: Clément Bœsch --- libavutil/threadmessage.c | 37 ++--- libavutil/threadmessage.h | 21 ++--- 2 files changed, 52 insertions(+), 6 deletions(-) diff --git a/libavutil/threadmessage.c b/libavutil/threadmessage.c index b7fcbe2..87ce8dc 100644 --- a/libavutil/threadmessage.c +++ b/libavutil/threadmessage.c @@ -40,14 +40,16 @@ struct AVThreadMessageQueue { int err_send; int err_recv; unsigned elsize; +void (*free_func)(void *msg); #else int dummy; #endif }; -int av_thread_message_queue_alloc(AVThreadMessageQueue **mq, - unsigned nelem, - unsigned elsize) +int av_thread_message_queue_alloc2(AVThreadMessageQueue **mq, + unsigned nelem, + unsigned elsize, + void (*free_func)(void *msg)) { #if HAVE_THREADS AVThreadMessageQueue *rmq; @@ -73,6 +75,7 @@ int av_thread_message_queue_alloc(AVThreadMessageQueue **mq, return AVERROR(ret); } rmq->elsize = elsize; +rmq->free_func = free_func; *mq = rmq; return 0; #else @@ -81,10 +84,18 @@ int av_thread_message_queue_alloc(AVThreadMessageQueue **mq, #endif /* HAVE_THREADS */ } +int av_thread_message_queue_alloc(AVThreadMessageQueue **mq, + unsigned nelem, + unsigned elsize) +{ +return av_thread_message_queue_alloc2(mq, nelem, elsize, NULL); +} + void av_thread_message_queue_free(AVThreadMessageQueue **mq) { #if HAVE_THREADS if (*mq) { +av_thread_message_flush(*mq); av_fifo_freep(&(*mq)->fifo); pthread_cond_destroy(&(*mq)->cond); pthread_mutex_destroy(&(*mq)->lock); @@ -182,3 +193,23 @@ void av_thread_message_queue_set_err_recv(AVThreadMessageQueue *mq, pthread_mutex_unlock(&mq->lock); #endif /* HAVE_THREADS */ } + +void av_thread_message_flush(AVThreadMessageQueue *mq) +{ +#if HAVE_THREADS +int used, off; + +pthread_mutex_lock(&mq->lock); +used = av_fifo_size(mq->fifo); +if (mq->free_func) { +for (off = 0; off < used; off += mq->elsize) { +void *msg; +av_fifo_generic_peek_at(mq->fifo, &msg, off, mq->elsize, NULL); +mq->free_func(msg); +} +} +av_fifo_drain(mq->fifo, used); +pthread_cond_broadcast(&mq->cond); +pthread_mutex_unlock(&mq->lock); +#endif /* HAVE_THREADS */ +} diff --git a/libavutil/threadmessage.h b/libavutil/threadmessage.h index a8481d8..f9004a8 100644 --- a/libavutil/threadmessage.h +++ b/libavutil/threadmessage.h @@ -33,17 +33,27 @@ typedef enum AVThreadMessageFlags { } AVThreadMessageFlags; /** + * @deprecated use av_thread_message_queue_alloc2 instead + */ +attribute_deprecated +int av_thread_message_queue_alloc(AVThreadMessageQueue **mq, + unsigned nelem, + unsigned elsize); + +/** * Allocate a new message queue. * * @param mq pointer to the message queue * @param nelem maximum number of elements in the queue * @param elsize size of each element in the queue + * @param free_func free message callback function, can be NULL * @return >=0 for success; <0 for error, in particular AVERROR(ENOSYS) if * lavu was built without thread support */ -int av_thread_message_queue_alloc(AVThreadMessageQueue **mq, - unsigned nelem, - unsigned elsize); +int av_thread_message_queue_alloc2(AVThreadMessageQueue **mq, + unsigned nelem, + unsigned elsize, + void (*free_func)(void *msg)); /** * Free a message queue. @@ -88,4 +98,9 @@ void av_thread_message_queue_set_err_send(AVThreadMessageQueue *mq, void av_thread_message_queue_set_err_recv(AVThreadMessageQueue *mq, int err); +/** + * Flush the message queue + */ +void av_thread_message_flush(AVThreadMessageQueue *mq); + #endif /* AVUTIL_THREADMESSAGE_H */ -- 2.6.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/3] fate/api: test threadmessage
From: Clément Bœsch --- tests/api/Makefile | 1 + tests/api/api-threadmessage-test.c | 202 + tests/fate/api.mak | 6 ++ 3 files changed, 209 insertions(+) create mode 100644 tests/api/api-threadmessage-test.c diff --git a/tests/api/Makefile b/tests/api/Makefile index c48c34a..3556a9b 100644 --- a/tests/api/Makefile +++ b/tests/api/Makefile @@ -3,6 +3,7 @@ APITESTPROGS-$(call DEMDEC, H264, H264) += api-h264 APITESTPROGS-yes += api-seek APITESTPROGS-yes += api-codec-param APITESTPROGS-$(call DEMDEC, H263, H263) += api-band +APITESTPROGS-yes += api-threadmessage APITESTPROGS += $(APITESTPROGS-yes) APITESTOBJS := $(APITESTOBJS:%=$(APITESTSDIR)%) $(APITESTPROGS:%=$(APITESTSDIR)/%-test.o) diff --git a/tests/api/api-threadmessage-test.c b/tests/api/api-threadmessage-test.c new file mode 100644 index 000..abf0154 --- /dev/null +++ b/tests/api/api-threadmessage-test.c @@ -0,0 +1,202 @@ +/* + * Permission is hereby granted, free of charge, to any person obtaining a copy + * of this software and associated documentation files (the "Software"), to deal + * in the Software without restriction, including without limitation the rights + * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell + * copies of the Software, and to permit persons to whom the Software is + * furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice shall be included in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN + * THE SOFTWARE. + */ + +/** + * Thread message API test + */ + +#include + +#include "libavutil/frame.h" +#include "libavutil/avstring.h" +#include "libavutil/threadmessage.h" + +struct tdata { +int id; +pthread_t tid; +int workload; +AVThreadMessageQueue *queue; +}; + +static void free_frame(void *arg) +{ +AVFrame *frame = arg; +av_frame_free(&frame); +} + +/* Frame producing thread. Will flush the queue half way just to be a jerk */ +static void *worker_thread(void *arg) +{ +int i, ret; +struct tdata *td = arg; + +av_log(NULL, AV_LOG_INFO, "worker #%d: workload=%d\n", td->id, td->workload); +for (i = 0; i < td->workload; i++) { +if (i == td->workload/2) { +av_log(NULL, AV_LOG_INFO, "worker #%d: flushing the queue\n", td->id); +av_thread_message_flush(td->queue); +} else { +char *val; +AVDictionary *meta = NULL; +AVFrame *frame = av_frame_alloc(); +if (!frame) { +ret = AVERROR(ENOMEM); +break; +} + +/* we add some metadata to identify the frames */ +val = av_asprintf("frame from worker %d", td->id); +if (!val) { +av_frame_free(&frame); +ret = AVERROR(ENOMEM); +break; +} +ret = av_dict_set(&meta, "sig", val, AV_DICT_DONT_STRDUP_VAL); +if (ret < 0) { +av_frame_free(&frame); +break; +} +av_frame_set_metadata(frame, meta); + +/* allocate a real frame in order to simulate "real" work */ +frame->format = AV_PIX_FMT_RGBA; +frame->width = 320; +frame->height = 240; +ret = av_frame_get_buffer(frame, 32); +if (ret < 0) { +av_frame_free(&frame); +break; +} + +/* push the frame in the common queue */ +av_log(NULL, AV_LOG_INFO, "worker #%d: sending my work (%p), %d left\n", + td->id, frame, td->workload - i - 1); +ret = av_thread_message_queue_send(td->queue, &frame, 0); +if (ret < 0) { +av_frame_free(&frame); +break; +} +} +} +av_log(NULL, AV_LOG_INFO, "worker #%d: my work is done here (%s)\n", + td->id, av_err2str(ret)); +av_thread_message_queue_set_err_recv(td->queue, ret < 0 ? ret : AVERROR_EOF); +return NULL; +} + +static int consume_queue(AVThreadMessageQueue *q, int n) +{ +int i, ret = 0; + +for (i = 0; i < n; i++) { +AVFrame *frame; +AVDictionary *meta; +AVDictionaryEntry *e; + +ret = av_thread_message_queue_recv(q, &frame, 0); +if (ret < 0) +break; +meta = av_frame_get_metadata(frame); +e = av_dict_get(meta, "si
[FFmpeg-devel] [PATCH 3/3] avutil/threadmessage: fix condition broadcasting
From: Clément Bœsch Fix a dead lock under certain conditions. Let's assume we have a queue of 1 message max, 2 senders, and 1 receiver. Scenario (real record obtained with debug added): [...] SENDER #0: acquired lock SENDER #0: queue is full, wait SENDER #1: acquired lock SENDER #1: queue is full, wait RECEIVER: acquired lock RECEIVER: reading a msg from the queue RECEIVER: signal the cond RECEIVER: acquired lock RECEIVER: queue is empty, wait SENDER #0: writing a msg the queue SENDER #0: signal the cond SENDER #0: acquired lock SENDER #0: queue is full, wait SENDER #1: queue is full, wait Translated: - initially the queue contains 1/1 message with 2 senders blocking on it, waiting to push another message. - Meanwhile the receiver is obtaining the lock, read the message, signal & release the lock. For some reason it is able to acquire the lock again before the signal wakes up one of the sender. Since it just emptied the queue, the reader waits for the queue to fill up again. - The signal finally reaches one of the sender, which writes a message and then signal the condition. Unfortunately, instead of waking up the reader, it actually wakes up the other worker (signal = notify the condition just for 1 waiter), who can't push another message in the queue because it's full. - Meanwhile, the receiver is still waiting. Deadlock. This scenario can be triggered with for example: tests/api/api-threadmessage-test 2 1 100 100 999 The fix is simply to make sure to notify everyone when work is done (be it reading or writing). Another solution would be to use 2 distincts conditions. --- libavutil/threadmessage.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavutil/threadmessage.c b/libavutil/threadmessage.c index 87ce8dc..ec62c2d 100644 --- a/libavutil/threadmessage.c +++ b/libavutil/threadmessage.c @@ -118,7 +118,7 @@ static int av_thread_message_queue_send_locked(AVThreadMessageQueue *mq, if (mq->err_send) return mq->err_send; av_fifo_generic_write(mq->fifo, msg, mq->elsize, NULL); -pthread_cond_signal(&mq->cond); +pthread_cond_broadcast(&mq->cond); return 0; } @@ -134,7 +134,7 @@ static int av_thread_message_queue_recv_locked(AVThreadMessageQueue *mq, if (av_fifo_size(mq->fifo) < mq->elsize) return mq->err_recv; av_fifo_generic_read(mq->fifo, msg, mq->elsize, NULL); -pthread_cond_signal(&mq->cond); +pthread_cond_broadcast(&mq->cond); return 0; } -- 2.6.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2 11/13] Remove the MIPS "generic" core in favor of "*"
Dear Andreas Cadhalpun, On 20/11/15 20:10, Andreas Cadhalpun wrote: > On 18.11.2015 12:13, Vicente Olivert Riera wrote: >> There is no point to have a "generic" core when we can catch all >> unsupported cores with the "*" option, so remove it. >> >> Signed-off-by: Vicente Olivert Riera >> --- >> Changes v1 -> v2: >> - Nothing. >> >> configure |4 >> 1 files changed, 0 insertions(+), 4 deletions(-) >> >> diff --git a/configure b/configure >> index fc3d559..7d87e5c 100755 >> --- a/configure >> +++ b/configure >> @@ -4154,10 +4154,6 @@ elif enabled mips; then >> ;; >> esac >> ;; >> -generic) >> -disable mips64r6 >> -disable msa >> -;; >> *) >> disable mipsfpu >> disable mips32r2 >> > > This is a bad idea. > If the cpu is not explicitly set via configure options, it is set to generic. > Removing this generic case here, will force-disable all mips optimizations, > even if they were explicitly enabled with configure options. > That would e.g. break how the Debian ffmpeg package is built for mips64el. Aha, I see. But I don't understand why msa is disabled for a generic cpu and not the dsp or dspr2. Either we disable everything, or nothing. But just disabling features randomly doesn't make any sense, at least for me. What about this? generic) # We don't disable anything. Is up to the user to # disable the unwanted features. ;; *) # Unknown CPU. Disable everything. disable mipsfpu disable mips32r2 ... ;; Regards, Vincent. > Best regards, > Andreas > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] (no subject)
GIT: [PATCH 1/3] avutil/threadmessage: add av_thread_message_flush() GIT: [PATCH 2/3] fate/api: test threadmessage GIT: [PATCH 3/3] avutil/threadmessage: fix condition broadcasting ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/3] avutil/threadmessage: add av_thread_message_flush()
From: Clément Bœsch --- libavutil/threadmessage.c | 32 libavutil/threadmessage.h | 12 2 files changed, 44 insertions(+) diff --git a/libavutil/threadmessage.c b/libavutil/threadmessage.c index b7fcbe2..66b5fc6 100644 --- a/libavutil/threadmessage.c +++ b/libavutil/threadmessage.c @@ -40,6 +40,8 @@ struct AVThreadMessageQueue { int err_send; int err_recv; unsigned elsize; +void (*free_func)(void *msg); +void *tmp_msg; #else int dummy; #endif @@ -81,10 +83,21 @@ int av_thread_message_queue_alloc(AVThreadMessageQueue **mq, #endif /* HAVE_THREADS */ } +int av_thread_message_queue_set_free_func(AVThreadMessageQueue *mq, + void (*free_func)(void *msg)) +{ +mq->free_func = free_func; +av_freep(&mq->tmp_msg); +mq->tmp_msg = av_mallocz(mq->elsize); +return mq->tmp_msg ? 0 : AVERROR(ENOMEM); +} + void av_thread_message_queue_free(AVThreadMessageQueue **mq) { #if HAVE_THREADS if (*mq) { +av_thread_message_flush(*mq); +av_freep(&(*mq)->tmp_msg); av_fifo_freep(&(*mq)->fifo); pthread_cond_destroy(&(*mq)->cond); pthread_mutex_destroy(&(*mq)->lock); @@ -182,3 +195,22 @@ void av_thread_message_queue_set_err_recv(AVThreadMessageQueue *mq, pthread_mutex_unlock(&mq->lock); #endif /* HAVE_THREADS */ } + +void av_thread_message_flush(AVThreadMessageQueue *mq) +{ +#if HAVE_THREADS +int used, off; + +pthread_mutex_lock(&mq->lock); +used = av_fifo_size(mq->fifo); +if (mq->free_func) { +for (off = 0; off < used; off += mq->elsize) { +av_fifo_generic_peek_at(mq->fifo, mq->tmp_msg, off, mq->elsize, NULL); +mq->free_func(mq->tmp_msg); +} +} +av_fifo_drain(mq->fifo, used); +pthread_cond_broadcast(&mq->cond); +pthread_mutex_unlock(&mq->lock); +#endif /* HAVE_THREADS */ +} diff --git a/libavutil/threadmessage.h b/libavutil/threadmessage.h index a8481d8..c59cb06 100644 --- a/libavutil/threadmessage.h +++ b/libavutil/threadmessage.h @@ -88,4 +88,16 @@ void av_thread_message_queue_set_err_send(AVThreadMessageQueue *mq, void av_thread_message_queue_set_err_recv(AVThreadMessageQueue *mq, int err); +/** + * Set the optional free message callback function which will be called if an + * operation is removing messages from the queue. + */ +int av_thread_message_queue_set_free_func(AVThreadMessageQueue *mq, + void (*free_func)(void *msg)); + +/** + * Flush the message queue + */ +void av_thread_message_flush(AVThreadMessageQueue *mq); + #endif /* AVUTIL_THREADMESSAGE_H */ -- 2.6.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] (no subject)
___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] threadmessage improvements v2.1
sorry wrong patchset. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/3] fate/api: test threadmessage
From: Clément Bœsch --- tests/api/Makefile | 1 + tests/api/api-threadmessage-test.c | 263 + tests/fate/api.mak | 6 + 3 files changed, 270 insertions(+) create mode 100644 tests/api/api-threadmessage-test.c diff --git a/tests/api/Makefile b/tests/api/Makefile index c48c34a..3556a9b 100644 --- a/tests/api/Makefile +++ b/tests/api/Makefile @@ -3,6 +3,7 @@ APITESTPROGS-$(call DEMDEC, H264, H264) += api-h264 APITESTPROGS-yes += api-seek APITESTPROGS-yes += api-codec-param APITESTPROGS-$(call DEMDEC, H263, H263) += api-band +APITESTPROGS-yes += api-threadmessage APITESTPROGS += $(APITESTPROGS-yes) APITESTOBJS := $(APITESTOBJS:%=$(APITESTSDIR)%) $(APITESTPROGS:%=$(APITESTSDIR)/%-test.o) diff --git a/tests/api/api-threadmessage-test.c b/tests/api/api-threadmessage-test.c new file mode 100644 index 000..5c75051 --- /dev/null +++ b/tests/api/api-threadmessage-test.c @@ -0,0 +1,263 @@ +/* + * Permission is hereby granted, free of charge, to any person obtaining a copy + * of this software and associated documentation files (the "Software"), to deal + * in the Software without restriction, including without limitation the rights + * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell + * copies of the Software, and to permit persons to whom the Software is + * furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice shall be included in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN + * THE SOFTWARE. + */ + +/** + * Thread message API test + */ + +#include + +#include "libavutil/avassert.h" +#include "libavutil/avstring.h" +#include "libavutil/frame.h" +#include "libavutil/threadmessage.h" + +struct worker_data { +int id; +pthread_t tid; +int workload; +AVThreadMessageQueue *queue; +}; + +/* same as worker_data but shuffled for testing purpose */ +struct reader_data { +pthread_t tid; +int workload; +int id; +AVThreadMessageQueue *queue; +}; + +struct message { +AVFrame *frame; +// we add some junk in the message to make sure the message size is > +// sizeof(void*) +int magic; +}; + +#define MAGIC 0xdeadc0de + +static void free_frame(void *arg) +{ +struct message *msg = arg; +av_assert0(msg->magic == MAGIC); +av_frame_free(&msg->frame); +} + +static void *worker_thread(void *arg) +{ +int i, ret = 0; +struct worker_data *wd = arg; + +av_log(NULL, AV_LOG_INFO, "worker #%d: workload=%d\n", wd->id, wd->workload); +for (i = 0; i < wd->workload; i++) { +if (rand() % wd->workload < wd->workload / 10) { +av_log(NULL, AV_LOG_INFO, "worker #%d: flushing the queue\n", wd->id); +av_thread_message_flush(wd->queue); +} else { +char *val; +AVDictionary *meta = NULL; +struct message msg = { +.magic = MAGIC, +.frame = av_frame_alloc(), +}; + +if (!msg.frame) { +ret = AVERROR(ENOMEM); +break; +} + +/* we add some metadata to identify the frames */ +val = av_asprintf("frame from worker %d", wd->id); +if (!val) { +av_frame_free(&msg.frame); +ret = AVERROR(ENOMEM); +break; +} +ret = av_dict_set(&meta, "sig", val, AV_DICT_DONT_STRDUP_VAL); +if (ret < 0) { +av_frame_free(&msg.frame); +break; +} +av_frame_set_metadata(msg.frame, meta); + +/* allocate a real frame in order to simulate "real" work */ +msg.frame->format = AV_PIX_FMT_RGBA; +msg.frame->width = 320; +msg.frame->height = 240; +ret = av_frame_get_buffer(msg.frame, 32); +if (ret < 0) { +av_frame_free(&msg.frame); +break; +} + +/* push the frame in the common queue */ +av_log(NULL, AV_LOG_INFO, "worker #%d: sending my work (frame:%p), %d left\n", + wd->id, msg.frame, wd->workload - i - 1); +ret = av_thread_message_queue_send(wd->queue, &msg, 0); +if (ret < 0) { +av_frame_free(&msg.frame); +break; +} +} +} +av_log(NULL, AV_LOG_INFO, "worker #%d: my work is done here (%s)\n"
Re: [FFmpeg-devel] threadmessage improvements v2
On Wed, Dec 02, 2015 at 04:01:40PM +0100, Nicolas George wrote: > Le duodi 12 frimaire, an CCXXIV, Clement Boesch a écrit : > > - the flushing function can be set through a dedicated function instead of a > > new constructor prototype > > If I read the patch correctly, you seem to have fumbled your rebasing. The > deprecation is still there and the setter function is not. Yeah I sent the wrong patchset, see v2.1. Sorry about that. It seems git also sent 2 empty compose message for whatever reason. Sorry about the noise. -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] threadmessage improvements v2
Le duodi 12 frimaire, an CCXXIV, Clement Boesch a écrit : > - the flushing function can be set through a dedicated function instead of a > new constructor prototype If I read the patch correctly, you seem to have fumbled your rebasing. The deprecation is still there and the setter function is not. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/3] avutil/threadmessage: fix condition broadcasting
From: Clément Bœsch Fix a dead lock under certain conditions. Let's assume we have a queue of 1 message max, 2 senders, and 1 receiver. Scenario (real record obtained with debug added): [...] SENDER #0: acquired lock SENDER #0: queue is full, wait SENDER #1: acquired lock SENDER #1: queue is full, wait RECEIVER: acquired lock RECEIVER: reading a msg from the queue RECEIVER: signal the cond RECEIVER: acquired lock RECEIVER: queue is empty, wait SENDER #0: writing a msg the queue SENDER #0: signal the cond SENDER #0: acquired lock SENDER #0: queue is full, wait SENDER #1: queue is full, wait Translated: - initially the queue contains 1/1 message with 2 senders blocking on it, waiting to push another message. - Meanwhile the receiver is obtaining the lock, read the message, signal & release the lock. For some reason it is able to acquire the lock again before the signal wakes up one of the sender. Since it just emptied the queue, the reader waits for the queue to fill up again. - The signal finally reaches one of the sender, which writes a message and then signal the condition. Unfortunately, instead of waking up the reader, it actually wakes up the other worker (signal = notify the condition just for 1 waiter), who can't push another message in the queue because it's full. - Meanwhile, the receiver is still waiting. Deadlock. This scenario can be triggered with for example: tests/api/api-threadmessage-test 1 2 100 100 1 1000 1000 One working solution is to make av_thread_message_queue_{send,recv}() call pthread_cond_broadcast() instead of pthread_cond_signal() so both senders and receivers are unlocked when work is done (be it reading or writing). This second solution replaces the condition with two: one to notify the senders, and one to notify the receivers. This prevents senders from notifying other senders instead of a reader, and the other way around. It also avoid broadcasting to everyone like the first solution, and is, as a result in theory more optimized. --- libavutil/threadmessage.c | 35 --- 1 file changed, 24 insertions(+), 11 deletions(-) diff --git a/libavutil/threadmessage.c b/libavutil/threadmessage.c index 66b5fc6..783855f 100644 --- a/libavutil/threadmessage.c +++ b/libavutil/threadmessage.c @@ -36,7 +36,8 @@ struct AVThreadMessageQueue { #if HAVE_THREADS AVFifoBuffer *fifo; pthread_mutex_t lock; -pthread_cond_t cond; +pthread_cond_t cond_recv; +pthread_cond_t cond_send; int err_send; int err_recv; unsigned elsize; @@ -63,13 +64,20 @@ int av_thread_message_queue_alloc(AVThreadMessageQueue **mq, av_free(rmq); return AVERROR(ret); } -if ((ret = pthread_cond_init(&rmq->cond, NULL))) { +if ((ret = pthread_cond_init(&rmq->cond_recv, NULL))) { +pthread_mutex_destroy(&rmq->lock); +av_free(rmq); +return AVERROR(ret); +} +if ((ret = pthread_cond_init(&rmq->cond_send, NULL))) { +pthread_cond_destroy(&rmq->cond_recv); pthread_mutex_destroy(&rmq->lock); av_free(rmq); return AVERROR(ret); } if (!(rmq->fifo = av_fifo_alloc(elsize * nelem))) { -pthread_cond_destroy(&rmq->cond); +pthread_cond_destroy(&rmq->cond_send); +pthread_cond_destroy(&rmq->cond_recv); pthread_mutex_destroy(&rmq->lock); av_free(rmq); return AVERROR(ret); @@ -99,7 +107,8 @@ void av_thread_message_queue_free(AVThreadMessageQueue **mq) av_thread_message_flush(*mq); av_freep(&(*mq)->tmp_msg); av_fifo_freep(&(*mq)->fifo); -pthread_cond_destroy(&(*mq)->cond); +pthread_cond_destroy(&(*mq)->cond_send); +pthread_cond_destroy(&(*mq)->cond_recv); pthread_mutex_destroy(&(*mq)->lock); av_freep(mq); } @@ -115,12 +124,13 @@ static int av_thread_message_queue_send_locked(AVThreadMessageQueue *mq, while (!mq->err_send && av_fifo_space(mq->fifo) < mq->elsize) { if ((flags & AV_THREAD_MESSAGE_NONBLOCK)) return AVERROR(EAGAIN); -pthread_cond_wait(&mq->cond, &mq->lock); +pthread_cond_wait(&mq->cond_send, &mq->lock); } if (mq->err_send) return mq->err_send; av_fifo_generic_write(mq->fifo, msg, mq->elsize, NULL); -pthread_cond_signal(&mq->cond); +/* one message is sent, signal one receiver */ +pthread_cond_signal(&mq->cond_recv); return 0; } @@ -131,12 +141,13 @@ static int av_thread_message_queue_recv_locked(AVThreadMessageQueue *mq, while (!mq->err_recv && av_fifo_size(mq->fifo) < mq->elsize) { if ((flags & AV_THREAD_MESSAGE_NONBLOCK)) return AVERROR(EAGAIN); -pthread_cond_wait(&mq->cond, &mq->lock); +pthread_cond_wait(&mq->cond_recv, &mq->lock); } if (av_fifo_size(mq->fifo) < mq->elsize) return mq->err_recv
Re: [FFmpeg-devel] [PATCH] Allow mpjpeg demuxer to process MIME parts which do not include Content-Length header.
On Wed, 2 Dec 2015 09:28:40 -0500 Alexander Agranovsky wrote: > Hi guys -- where do we stand with this? Are there any additional comments? > > - A. Looks fine now. The trim_right() still looks a bit awkward IMHO, but it should be correct (whoever really cares can send a follow-up patch to change it). I'll apply this tonight, I guess. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] AAC experimental flag: the sequel
So, here comes the discussion again. This time, the AAC encoder is in good shape. It's not perfect. I have a list of known bugs to address that still has some issues, but I'm not really certain whether they should block the flag's removal. The bugs will be addressed in time, but maybe the encoder is in good enough shape as it is? It needs more testing. My tests have all been centered on one configuration: AAC-LC + PNS + M/S + I/S, ABR, twoloop coder. I haven't yet thoroughly tested any other configuration, or any other coder, and it's possible the other coders are kaputt. I have plans for the other coders but they haven't been fleshed out yet. There are two possibilities here: 1. Wait until the other coders at least don't crash before removing the flag 2. Remove the flag now, and document the other coders' instability Which one to go for depends a lot on what removing the flag means to other people. Does it mean "it is stable" or does it mean "it's stable for most uses"? (a subtle but important distinction). IE: what's the contract between us developers and users when we remove the flag? I'm rather new at this. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] AAC experimental flag: the sequel
On Wed, Dec 02, 2015 at 12:37:00PM -0300, Claudio Freire wrote: > So, here comes the discussion again. > > This time, the AAC encoder is in good shape. It's not perfect. I have > a list of known bugs to address that still has some issues, but I'm > not really certain whether they should block the flag's removal. > What kind of bugs? If it's crashes, I think they should be fixed before removing the flag (for security reasons). If it's about efficiency (regarding compression or speed), I don't think it should be blocking the drop of the flag. Note that dropping the flag means it will be a white flag for the beginning of extended tests & benchmarks Regards, [...] -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] AAC experimental flag: the sequel
On Wed, Dec 2, 2015 at 4:42 PM, Clément Bœsch wrote: > On Wed, Dec 02, 2015 at 12:37:00PM -0300, Claudio Freire wrote: >> So, here comes the discussion again. >> >> This time, the AAC encoder is in good shape. It's not perfect. I have >> a list of known bugs to address that still has some issues, but I'm >> not really certain whether they should block the flag's removal. >> > > What kind of bugs? If it's crashes, I think they should be fixed before > removing the flag (for security reasons). Maybe the other coders could just be disabled unless the experimental flag is set, and only allow twoloop otherwise. > > If it's about efficiency (regarding compression or speed), I don't think > it should be blocking the drop of the flag. > > Note that dropping the flag means it will be a white flag for the > beginning of extended tests & benchmarks > > Regards, > > [...] > > -- > 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] AAC experimental flag: the sequel
On Wed, Dec 2, 2015 at 10:37 AM, Claudio Freire wrote: > So, here comes the discussion again. > > This time, the AAC encoder is in good shape. It's not perfect. I have > a list of known bugs to address that still has some issues, but I'm > not really certain whether they should block the flag's removal. > > The bugs will be addressed in time, but maybe the encoder is in good > enough shape as it is? IIUC, JBK responded at VDD 2015 to the question of for which types of files they don't use avcodec. He mentioned AAC due to some user's complaints about quality on certain files. This was likely referring to the decoder and not encoder. Nevertheless, I suggest a conversation with them (or other users) to obtain problematic files to test. If it works fine wrt users (who really are the main people affected by removal of such "strict" flags), and the more immediate possible concerns of Clement are met, then I am ok with this change. Or in other words, for me removal of the flag is "stable beyond fuzzing/security, and stable for integration by important users". If there are known crashes, it is an immediate nack from me. [...] ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] avutil/threadmessage: add av_thread_message_flush()
Le duodi 12 frimaire, an CCXXIV, Clement Boesch a écrit : > From: Clément Bœsch > > --- > libavutil/threadmessage.c | 32 > libavutil/threadmessage.h | 12 > 2 files changed, 44 insertions(+) > > diff --git a/libavutil/threadmessage.c b/libavutil/threadmessage.c > index b7fcbe2..66b5fc6 100644 > --- a/libavutil/threadmessage.c > +++ b/libavutil/threadmessage.c > @@ -40,6 +40,8 @@ struct AVThreadMessageQueue { > int err_send; > int err_recv; > unsigned elsize; > +void (*free_func)(void *msg); > +void *tmp_msg; > #else > int dummy; > #endif > @@ -81,10 +83,21 @@ int av_thread_message_queue_alloc(AVThreadMessageQueue > **mq, > #endif /* HAVE_THREADS */ > } > > +int av_thread_message_queue_set_free_func(AVThreadMessageQueue *mq, > + void (*free_func)(void *msg)) > +{ > +mq->free_func = free_func; > +av_freep(&mq->tmp_msg); > +mq->tmp_msg = av_mallocz(mq->elsize); > +return mq->tmp_msg ? 0 : AVERROR(ENOMEM); > +} > + > void av_thread_message_queue_free(AVThreadMessageQueue **mq) > { > #if HAVE_THREADS > if (*mq) { > +av_thread_message_flush(*mq); > +av_freep(&(*mq)->tmp_msg); > av_fifo_freep(&(*mq)->fifo); > pthread_cond_destroy(&(*mq)->cond); > pthread_mutex_destroy(&(*mq)->lock); > @@ -182,3 +195,22 @@ void > av_thread_message_queue_set_err_recv(AVThreadMessageQueue *mq, > pthread_mutex_unlock(&mq->lock); > #endif /* HAVE_THREADS */ > } > + > +void av_thread_message_flush(AVThreadMessageQueue *mq) > +{ > +#if HAVE_THREADS > +int used, off; > + > +pthread_mutex_lock(&mq->lock); > +used = av_fifo_size(mq->fifo); > +if (mq->free_func) { > +for (off = 0; off < used; off += mq->elsize) { > +av_fifo_generic_peek_at(mq->fifo, mq->tmp_msg, off, mq->elsize, > NULL); > +mq->free_func(mq->tmp_msg); Could this use av_fifo_generic_peek() to avoid the ugly extra allocation? > +} > +} > +av_fifo_drain(mq->fifo, used); > +pthread_cond_broadcast(&mq->cond); > +pthread_mutex_unlock(&mq->lock); > +#endif /* HAVE_THREADS */ > +} > diff --git a/libavutil/threadmessage.h b/libavutil/threadmessage.h > index a8481d8..c59cb06 100644 > --- a/libavutil/threadmessage.h > +++ b/libavutil/threadmessage.h > @@ -88,4 +88,16 @@ void > av_thread_message_queue_set_err_send(AVThreadMessageQueue *mq, > void av_thread_message_queue_set_err_recv(AVThreadMessageQueue *mq, >int err); > > +/** > + * Set the optional free message callback function which will be called if an > + * operation is removing messages from the queue. > + */ > +int av_thread_message_queue_set_free_func(AVThreadMessageQueue *mq, > + void (*free_func)(void *msg)); > + > +/** > + * Flush the message queue I will not block for that, but I am still not satisfied with the explanations, and therefore I find this documentation insufficient. Maybe wait for other advice? > + */ > +void av_thread_message_flush(AVThreadMessageQueue *mq); > + > #endif /* AVUTIL_THREADMESSAGE_H */ 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] AAC experimental flag: the sequel
Le duodi 12 frimaire, an CCXXIV, Ganesh Ajjanagadde a écrit : > He mentioned AAC due to some user's > complaints about quality on certain files. This was likely referring > to the decoder and not encoder. I remember it about the MP3 decoder compared to libmp3, not AAC. 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 1/3] avutil/threadmessage: add av_thread_message_flush()
On Wed, Dec 02, 2015 at 04:59:15PM +0100, Nicolas George wrote: [...] > > +av_fifo_generic_peek_at(mq->fifo, mq->tmp_msg, off, > > mq->elsize, NULL); > > +mq->free_func(mq->tmp_msg); > > Could this use av_fifo_generic_peek() to avoid the ugly extra allocation? > What would be the difference? both av_fifo_generic_peek and av_fifo_generic_peek_at require a copy of the element in a destination buffer, unless I'm missing something. > > +} > > +} > > +av_fifo_drain(mq->fifo, used); > > +pthread_cond_broadcast(&mq->cond); > > +pthread_mutex_unlock(&mq->lock); > > +#endif /* HAVE_THREADS */ > > +} > > diff --git a/libavutil/threadmessage.h b/libavutil/threadmessage.h > > index a8481d8..c59cb06 100644 > > --- a/libavutil/threadmessage.h > > +++ b/libavutil/threadmessage.h > > @@ -88,4 +88,16 @@ void > > av_thread_message_queue_set_err_send(AVThreadMessageQueue *mq, > > void av_thread_message_queue_set_err_recv(AVThreadMessageQueue *mq, > >int err); > > > > +/** > > + * Set the optional free message callback function which will be called if > > an > > + * operation is removing messages from the queue. > > + */ > > +int av_thread_message_queue_set_free_func(AVThreadMessageQueue *mq, > > + void (*free_func)(void *msg)); > > + > > +/** > > > + * Flush the message queue > > I will not block for that, but I am still not satisfied with the > explanations, and therefore I find this documentation insufficient. Maybe > wait for other advice? > Sure, no problem. -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] avutil/threadmessage: add av_thread_message_flush()
Le duodi 12 frimaire, an CCXXIV, Clement Boesch a écrit : > What would be the difference? both av_fifo_generic_peek and > av_fifo_generic_peek_at require a copy of the element in a destination > buffer, unless I'm missing something. As I see it, av_fifo_generic_peek() does NOT require a copy if a callback is supplied. 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 1/3] avutil/threadmessage: add av_thread_message_flush()
On Wed, Dec 02, 2015 at 05:09:23PM +0100, Nicolas George wrote: > Le duodi 12 frimaire, an CCXXIV, Clement Boesch a écrit : > > What would be the difference? both av_fifo_generic_peek and > > av_fifo_generic_peek_at require a copy of the element in a destination > > buffer, unless I'm missing something. > > As I see it, av_fifo_generic_peek() does NOT require a copy if a callback is > supplied. > Ah, indeed. av_fifo_generic_peek_at seems to have the same, I didn't realize. Code is much simpler that way, thanks. -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2 11/13] Remove the MIPS "generic" core in favor of "*"
On 02.12.2015 15:54, Vicente Olivert Riera wrote: > On 20/11/15 20:10, Andreas Cadhalpun wrote: >> If the cpu is not explicitly set via configure options, it is set to generic. >> Removing this generic case here, will force-disable all mips optimizations, >> even if they were explicitly enabled with configure options. >> That would e.g. break how the Debian ffmpeg package is built for mips64el. > > Aha, I see. > > But I don't understand why msa is disabled for a generic cpu and not the > dsp or dspr2. That was added in commit 8af3ce5, with the following comment: "MIPS 'generic' case is added, with mips32r2 arch as default (fpu and dsp opt enabled)." I'm not sure why this combination was chosen for the generic case. > Either we disable everything, or nothing. But just > disabling features randomly doesn't make any sense, at least for me. > > What about this? > > generic) > # We don't disable anything. Is up to the user to > # disable the unwanted features. > ;; That would be fine with me. > *) > # Unknown CPU. Disable everything. I think it would be good if configure printed a warning in this case. > disable mipsfpu > disable mips32r2 > ... > ;; Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] AAC experimental flag: the sequel
Dana 2. 12. 2015. 16:54 osoba "Nicolas George" napisala je: > > Le duodi 12 frimaire, an CCXXIV, Ganesh Ajjanagadde a écrit : > > He mentioned AAC due to some user's > > complaints about quality on certain files. This was likely referring > > to the decoder and not encoder. > > I remember it about the MP3 decoder compared to libmp3, not AAC. > It it on range of golden cables. > 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] Incorrect FourCC for HE-AAC in ISMV manifest
Hi, According to Microsoft's specs [1] (and after experiencing issues with the Unified Streaming Platform [2] server), content encoded with HE-AAC audio should use the AACH FourCC, but the value AACL is hardcoded in the manifest generation code. So I created the attached patch to fix this. It passes "test fate" and its effects can be seen using the commands bellow and compatible server. Although I tried to follow the patch submission checklist don't hesitate to point errors or mistakes. Yann Sample command lines: ffmpeg -i video.mp4 -vn -acodec libfdk_aac -profile:a aac_low -ab 128k -ar 44.1k -movflags isml -f ismv http://example.com/ FourCC of audio track in manifest is AACL as before ffmpeg -i video.mp4 -vn -acodec libfdk_aac -profile:a aac_he -ab 64k -ar 44.1k -movflags isml -f ismv http://example.com/ FourCC is AACH ffmpeg -i video.mp4 -vn -acodec libfdk_aac -profile:a aac_he_v2 -ab 64k -ar 44.1k -movflags isml -f ismv http://example.com/ FourCC is AACP [1] https://msdn.microsoft.com/en-us/library/ff728116%28v=vs.95%29.aspx [2] http://www.unified-streaming.com/ 0001-HE-AAC-correct-FourCC-in-ISML.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] web/download: remove architecture lists
On 25.11.2015 02:30, Timothy Gu wrote: > On Wed, Nov 25, 2015 at 12:35:03AM +0100, Andreas Cadhalpun wrote: >> They are not very helpful and feel out-of-place. >> >> Suggested-by: Timothy Gu >> Signed-off-by: Andreas Cadhalpun >> --- >> src/download | 6 +- >> 1 file changed, 1 insertion(+), 5 deletions(-) > > LGTM. Pushed. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Fix sample_aspect_ratio computation for stereo matroska content.
On Wed, Dec 2, 2015 at 2:16 AM wm4 wrote: > On Wed, 02 Dec 2015 00:32:46 + > Aaron Colwell wrote: > > > On Mon, Nov 30, 2015 at 4:35 PM wm4 wrote: > > > > > > > > I tried your patch, and it actually makes it work better (looks correct > > > with the patch). The patch itself also LGTM. > > > > > > > > Ok. Great. Thanks for the review. What do I need to do next to get this > > checked in. I don't have commit access. > > Well, first it has to be determined whether the patch is accepted, and > then someone has to push it. I just did the latter. > > Before pushing, I slightly modified the subject line to add a prefix > and to make it somewhat shorter (as the prefix made it too long). I > hope this is ok. > Yes. That is fine. Thank you again for your help. I appreciate it. Aaron ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] AAC experimental flag: the sequel
On Wed, Dec 2, 2015 at 12:50 PM, Hendrik Leppkes wrote: > On Wed, Dec 2, 2015 at 4:42 PM, Clément Bœsch wrote: >> On Wed, Dec 02, 2015 at 12:37:00PM -0300, Claudio Freire wrote: >>> So, here comes the discussion again. >>> >>> This time, the AAC encoder is in good shape. It's not perfect. I have >>> a list of known bugs to address that still has some issues, but I'm >>> not really certain whether they should block the flag's removal. >>> >> >> What kind of bugs? If it's crashes, I think they should be fixed before >> removing the flag (for security reasons). > > > Maybe the other coders could just be disabled unless the experimental > flag is set, and only allow twoloop otherwise. That's not a bad idea in fact. But yeah, the issue is that they might crash. I don't know, because they haven't been tested enough. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Makefile: add cleanup of pkg-config files created by configure to distclean
On 25.11.2015 11:56, Tobias Rapp wrote: > Subject: [PATCH] Makefile: add cleanup of pkg-config files created by > configure to distclean > > --- > Makefile | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Makefile b/Makefile > index 306f060..58f1a3a 100644 > --- a/Makefile > +++ b/Makefile > @@ -181,6 +181,7 @@ clean:: > distclean:: > $(RM) $(DISTCLEANSUFFIXES) > $(RM) config.* .config libavutil/avconfig.h .version avversion.h > version.h libavutil/ffversion.h libavcodec/codec_names.h > + $(RM) -rf doc/examples/pc-uninstalled > > config: > $(SRC_PATH)/configure $(value FFMPEG_CONFIGURATION) > -- 1.9.1 This looks good to me, so applied and pushed. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec: add OpenJPEG 2.x compatibility
> On Nov 19, 2015, at 6:31 PM, Michael Niedermayer wrote: > >> On Wed, Nov 18, 2015 at 09:22:57PM -0800, Michael Bradshaw wrote: >> On Wed, Nov 18, 2015 at 8:00 AM, Michael Niedermayer >> wrote: >> On Tue, Nov 17, 2015 at 07:27:55AM -0800, Michael Bradshaw wrote: Hi, Attached patch adds support for OpenJPEG 2.0/2.1. Please review. Thanks, Michael Bradshaw >>> configure |5 libavcodec/libopenjpegdec.c | 173 libavcodec/libopenjpegenc.c | 269 >>> +--- 3 files changed, 382 insertions(+), 65 deletions(-) 4e7c94ca16fa09210c4d74a4cf589ae9db540e9a >>> 0001-avcodec-add-OpenJPEG-2.x-compatibility.patch From 1cdf996b7fdaed429731054e96f9e6b565c9436d Mon Sep 17 00:00:00 2001 From: Michael Bradshaw Date: Sun, 1 Nov 2015 19:11:12 -0800 Subject: [PATCH] avcodec: add OpenJPEG 2.x compatibility >>> >>> this seems breaking the decoder >>> >>> ./ffmpeg -i matrixbench_mpeg2.mpg -vcodec libopenjpeg -vframes 1 test.j2k >>> >>> ./ffmpeg -strict -2 -vcodec libopenjpeg -i test.j2k -f null - >>> >>> [libopenjpeg @ 0x28f3220] Error decoding codestream header. >>> [j2k_pipe @ 0x28d1bc0] decoding for stream 0 failed >>> [j2k_pipe @ 0x28d1bc0] Could not find codec parameters for stream 0 >>> (Video: jpeg2000, none): unspecified size >>> Consider increasing the value for the 'analyzeduration' and 'probesize' >>> options >>> test.j2k: could not find codec parameters >> >> >> Oops, misplaced a ! in some last minute cleanup. Fixed patch attached. > >> configure |5 >> libavcodec/libopenjpegdec.c | 173 >> libavcodec/libopenjpegenc.c | 269 >> +--- >> 3 files changed, 382 insertions(+), 65 deletions(-) >> dc1ec76dc92d0a03c8fec0d4c14228e14f1c4e1e >> 0001-avcodec-add-OpenJPEG-2.x-compatibility.patch >> From 2fff5b8f6832d93ae65a75953db842c3fe6d9e86 Mon Sep 17 00:00:00 2001 >> From: Michael Bradshaw >> Date: Sun, 1 Nov 2015 19:11:12 -0800 >> Subject: [PATCH] avcodec: add OpenJPEG 2.x compatibility > > should i apply this ? > (it seems working, but it seems some people where nt entirely happy > are there objectiosn remaiing after Michael Bradshaws replies?) Ping. Any objections/nits from anyone? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/5] lavfi: deprecate avfilter_link_set_closed().
On 29.11.2015 17:21, Nicolas George wrote: > Applications are not supposed to mess with links, > they should close the sinks. > Furthermore, this function does not distinguish what end > of the link caused the close and does not have a timestamp. > > Signed-off-by: Nicolas George > --- > libavfilter/avfilter.h | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/libavfilter/avfilter.h b/libavfilter/avfilter.h > index a6aa919..58a0cbd 100644 > --- a/libavfilter/avfilter.h > +++ b/libavfilter/avfilter.h > @@ -541,7 +541,10 @@ int avfilter_link_get_channels(AVFilterLink *link); > > /** > * Set the closed field of a link. > + * @deprecated applications are not supposed to mess with links, they should > + * close the sinks. > */ > +attribute_deprecated > void avfilter_link_set_closed(AVFilterLink *link, int closed); > > /** > It would be nice to mention this deprecation in APIchanges. Other than that, this deprecation should be fine, as there seem to be no users of this function. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] common.mak: Use CCFLAGS for assembly generation as well
On Tue, Dec 01, 2015 at 09:46:04PM -0800, Timothy Gu wrote: > CCFLAGS is equivalent to CPPFLAGS + CFLAGS. > --- > common.mak | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) does this fix any case or just simplifies common.mak ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The greatest way to live with honor in this world is to be what we pretend to be. -- Socrates signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] aacenc: remove experimental flag
This commit removes the experimental flag from the native AAC Encoder and thus makes it the default. After a lot of work, done by myself and Claudio Freire, the quality of this encoder rivals and surpasses libfdk_aac in some situations. The encoder had instability issues earlier which prevented it from having its experimental flag removed, however the last commit done by Claudio removed the last known source of instability and solved a lot of problems which were previously observed. The issues were caused by the various coding tools interfering with the scalefactor indices. Thus, with these problems solved, it should now be possible to declare this encoder as the default and recommend that the users should use it instead of others provided by external libraries, as it is both faster and has a subjectively higher quality with selected tracks. The encoder has still yet to be fine tuned for every possible audio file type like music or voice, so it is hoped that with the experimental flag removed the users should be able to provide feedback and make the encoder better than the alternatives for every type of audio. The documentation will be edited and commited with a later commit. --- libavcodec/aacenc.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/libavcodec/aacenc.c b/libavcodec/aacenc.c index 971f8ab..2473a14 100644 --- a/libavcodec/aacenc.c +++ b/libavcodec/aacenc.c @@ -1039,8 +1039,7 @@ AVCodec ff_aac_encoder = { .close = aac_encode_end, .supported_samplerates = mpeg4audio_sample_rates, .caps_internal = FF_CODEC_CAP_INIT_THREADSAFE, -.capabilities = AV_CODEC_CAP_SMALL_LAST_FRAME | AV_CODEC_CAP_DELAY | - AV_CODEC_CAP_EXPERIMENTAL, +.capabilities = AV_CODEC_CAP_SMALL_LAST_FRAME | AV_CODEC_CAP_DELAY, .sample_fmts= (const enum AVSampleFormat[]){ AV_SAMPLE_FMT_FLTP, AV_SAMPLE_FMT_NONE }, .priv_class = &aacenc_class, -- 2.6.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] aacenc: remove experimental flag
On Wed, Dec 2, 2015 at 4:14 PM, Rostislav Pehlivanov wrote: > This commit removes the experimental flag from the native AAC Encoder > and thus makes it the default. > > After a lot of work, done by myself and Claudio Freire, the quality of > this encoder rivals and surpasses libfdk_aac in some situations. The > encoder had instability issues earlier which prevented it from having > its experimental flag removed, however the last commit done by Claudio > removed the last known source of instability and solved a lot of > problems which were previously observed. The issues were caused by the > various coding tools interfering with the scalefactor indices. Thus, > with these problems solved, it should now be possible to declare this > encoder as the default and recommend that the users should use it > instead of others provided by external libraries, as it is both faster > and has a subjectively higher quality with selected tracks. > The encoder has still yet to be fine tuned for every possible audio file > type like music or voice, so it is hoped that with the experimental flag > removed the users should be able to provide feedback and make the > encoder better than the alternatives for every type of audio. > > The documentation will be edited and commited with a later commit. Did you check the discussion about this? http://ffmpeg.org/pipermail/ffmpeg-devel/2015-December/184393.html There Hendrik Leppkes had a good idea to shield us from possible instability in the nondefault coders (anmr, fast, etc). It would be desirable to implement it with this commit (unless you did the testing/fuzzing of those coders of course). ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] git-howto: mention how to clone ffmpeg-web
On 25.11.2015 01:26, Andreas Cadhalpun wrote: > Subject: [PATCH] git-howto: mention how to clone ffmpeg-web > > Signed-off-by: Andreas Cadhalpun > --- > doc/git-howto.texi | 15 +++ > 1 file changed, 15 insertions(+) > > diff --git a/doc/git-howto.texi b/doc/git-howto.texi > index bf37bcc..e5e3c81 100644 > --- a/doc/git-howto.texi > +++ b/doc/git-howto.texi > @@ -65,6 +65,21 @@ git clone git@@source.ffmpeg.org:ffmpeg > This will put the FFmpeg sources into the directory @var{} and let > you push back your changes to the remote repository. > > +@example > +git clone gil@@ffmpeg.org:ffmpeg-web > +@end example > + > +This will put the source of the FFmpeg website into the directory > +@var{} and let you push back your changes to the remote repository. > +(Note that @var{gil} stands for GItoLite and is not a typo of @var{git}.) > + > +If you don't have write-access to the ffmpeg-web repository, you can > +create patches after making a read-only ffmpeg-web clone: > + > +@example > +git clone git://ffmpeg.org/ffmpeg-web > +@end example > + > Make sure that you do not have Windows line endings in your checkouts, > otherwise you may experience spurious compilation failures. One way to > achieve this is to run I pushed this version now. Feel free to improve it further. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] aacenc: mark coders other than twoloop as experimental
This commit marks any coders beside twoloop as experimental and gives out a warning that some of they might be silently removed in the future. Users are highly encouraged to use the twoloop coder, which is the default. --- libavcodec/aacenc.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/libavcodec/aacenc.c b/libavcodec/aacenc.c index 971f8ab..7a34806 100644 --- a/libavcodec/aacenc.c +++ b/libavcodec/aacenc.c @@ -967,6 +967,8 @@ static av_cold int aac_encode_init(AVCodecContext *avctx) s->coder = &ff_aac_coders[s->options.coder]; if (s->options.coder != AAC_CODER_TWOLOOP) { +ERROR_IF(avctx->strict_std_compliance > FF_COMPLIANCE_EXPERIMENTAL, + "Coders other than twoloop require -strict -2 and some may be removed in the future\n"); s->options.intensity_stereo = 0; s->options.pns = 0; } -- 2.6.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] aacsbr: ensure strictly monotone time borders
On 08.11.2015 22:04, Andreas Cadhalpun wrote: > This fixes a SIGFPE crash in the aac_fixed decoder. > > Signed-off-by: Andreas Cadhalpun > --- > libavcodec/aacsbr_template.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/libavcodec/aacsbr_template.c b/libavcodec/aacsbr_template.c > index 66f4159..f69d2f8 100644 > --- a/libavcodec/aacsbr_template.c > +++ b/libavcodec/aacsbr_template.c > @@ -718,8 +718,8 @@ static int read_sbr_grid(AACContext *ac, > SpectralBandReplication *sbr, > } > > for (i = 1; i <= ch_data->bs_num_env; i++) { > -if (ch_data->t_env[i-1] > ch_data->t_env[i]) { > -av_log(ac->avctx, AV_LOG_ERROR, "Non monotone time borders\n"); > +if (ch_data->t_env[i-1] >= ch_data->t_env[i]) { > +av_log(ac->avctx, AV_LOG_ERROR, "Not strictly monotone time > borders\n"); > return -1; > } > } > Ping. Unless there are objections, I'll push this soon, as it fixes crashes. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] aac_fixed: fix overflow in sbr_sum_square_c
On 19.11.2015 01:01, Andreas Cadhalpun wrote: > Subject: [PATCH] sbrdsp_fixed: assert that input values for sbr_sum_square_c > are valid > > Larger values can cause overflows, leading to this function returning a > negative value. > > Signed-off-by: Andreas Cadhalpun > --- > libavcodec/sbrdsp_fixed.c | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/libavcodec/sbrdsp_fixed.c b/libavcodec/sbrdsp_fixed.c > index 5b7b7a6..f4e3de0 100644 > --- a/libavcodec/sbrdsp_fixed.c > +++ b/libavcodec/sbrdsp_fixed.c > @@ -38,9 +38,14 @@ static SoftFloat sbr_sum_square_c(int (*x)[2], int n) > int i, nz, round; > > for (i = 0; i < n; i += 2) { > +// Larger values are inavlid and could cause overflows of accu. > +av_assert2(FFABS(x[i + 0][0]) >> 29 == 0); > accu += (int64_t)x[i + 0][0] * x[i + 0][0]; > +av_assert2(FFABS(x[i + 0][1]) >> 29 == 0); > accu += (int64_t)x[i + 0][1] * x[i + 0][1]; > +av_assert2(FFABS(x[i + 1][0]) >> 29 == 0); > accu += (int64_t)x[i + 1][0] * x[i + 1][0]; > +av_assert2(FFABS(x[i + 1][1]) >> 29 == 0); > accu += (int64_t)x[i + 1][1] * x[i + 1][1]; > } > Ping. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] sbr_qmf_analysis: sanitize input for 32-bit imdct
On 19.11.2015 01:02, Andreas Cadhalpun wrote: > If the input contains too many too large values, the imdct can overflow. > Even if it didn't, the output would be larger than the valid range of 29 > bits. > > Note that this is a very delicate limit: Allowing values up to 1<<25 > does not prevent input larger than 1<<29 from arriving at > sbr_sum_square, while limiting values to 1<<23 breaks the > fate-aac-fixed-al_sbr_hq_cm_48_5.1 test. > > Signed-off-by: Andreas Cadhalpun > --- > > Nedeljko, do you have an explanation why larger input values here > are invalid? > > By the way, the imdct calculations in imdct_and_windowing and > sbr_qmf_synthesis can also overflow, so maybe need a similar check. > > --- > libavcodec/aacsbr_template.c | 18 ++ > 1 file changed, 18 insertions(+) > > diff --git a/libavcodec/aacsbr_template.c b/libavcodec/aacsbr_template.c > index 66f4159..f48ddd0 100644 > --- a/libavcodec/aacsbr_template.c > +++ b/libavcodec/aacsbr_template.c > @@ -1153,6 +1153,9 @@ static void sbr_qmf_analysis(AVFloatDSPContext *dsp, > FFTContext *mdct, > INTFLOAT z[320], INTFLOAT W[2][32][32][2], int > buf_idx) > { > int i; > +#if USE_FIXED > +int j; > +#endif > memcpy(x, x+1024, (320-32)*sizeof(x[0])); > memcpy(x+288, in, 1024*sizeof(x[0])); > for (i = 0; i < 32; i++) { // numTimeSlots*RATE = 16*2 as 960 sample > frames > @@ -1160,6 +1163,21 @@ static void sbr_qmf_analysis(AVFloatDSPContext *dsp, > FFTContext *mdct, > dsp->vector_fmul_reverse(z, sbr_qmf_window_ds, x, 320); > sbrdsp->sum64x5(z); > sbrdsp->qmf_pre_shuffle(z); > +#if USE_FIXED > +for (j = 64; j < 128; j++) { > +if (z[j] > 1<<24) { > +av_log(NULL, AV_LOG_WARNING, > + "sbr_qmf_analysis: value %09d too large, setting to > %09d\n", > + z[j], 1<<24); > +z[j] = 1<<24; > +} else if (z[j] < -(1<<24)) { > +av_log(NULL, AV_LOG_WARNING, > + "sbr_qmf_analysis: value %09d too small, setting to > %09d\n", > + z[j], -(1<<24)); > +z[j] = -(1<<24); > +} > +} > +#endif > mdct->imdct_half(mdct, z, z+64); > sbrdsp->qmf_post_shuffle(W[buf_idx][i], z); > x += 32; > Ping. If nobody objects, I'll push this soon, as it fixes crashes. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] vp9: always keep s->bytesperpixel and ctx->pix_fmt in sync.
Hi, On Tue, Dec 1, 2015 at 1:21 PM, Ronald S. Bultje wrote: > Hi, > > On Tue, Dec 1, 2015 at 12:34 PM, Hendrik Leppkes > wrote: > >> On Tue, Dec 1, 2015 at 6:24 PM, Ronald S. Bultje >> wrote: >> > Fixes mozilla bug 1229128. >> > --- >> > libavcodec/vp9.c | 43 ++- >> > 1 file changed, 22 insertions(+), 21 deletions(-) >> > >> > diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c >> > index d4061e2..dc0 100644 >> > --- a/libavcodec/vp9.c >> > +++ b/libavcodec/vp9.c >> > @@ -69,6 +69,7 @@ typedef struct VP9Context { >> > uint8_t ss_h, ss_v; >> > uint8_t last_bpp, bpp, bpp_index, bytesperpixel; >> > uint8_t last_keyframe; >> > +enum AVPixelFormat pix_fmt, last_fmt; >> > ThreadFrame next_refs[8]; >> > >> > struct { >> > @@ -211,7 +212,7 @@ static int vp9_ref_frame(AVCodecContext *ctx, >> VP9Frame *dst, VP9Frame *src) >> > return 0; >> > } >> > >> > -static int update_size(AVCodecContext *ctx, int w, int h, enum >> AVPixelFormat fmt) >> > +static int update_size(AVCodecContext *ctx, int w, int h) >> > { >> > VP9Context *s = ctx->priv_data; >> > uint8_t *p; >> > @@ -219,12 +220,12 @@ static int update_size(AVCodecContext *ctx, int >> w, int h, enum AVPixelFormat fmt >> > >> > av_assert0(w > 0 && h > 0); >> > >> > -if (s->intra_pred_data[0] && w == ctx->width && h == ctx->height >> && ctx->pix_fmt == fmt) >> > +if (s->intra_pred_data[0] && w == ctx->width && h == ctx->height >> && s->pix_fmt == s->last_fmt) >> > return 0; >> > >> > if ((res = ff_set_dimensions(ctx, w, h)) < 0) >> > return res; >> > -ctx->pix_fmt = fmt; >> > +s->last_fmt = ctx->pix_fmt = s->pix_fmt; >> > s->sb_cols = (w + 63) >> 6; >> > s->sb_rows = (h + 63) >> 6; >> > s->cols = (w + 7) >> 3; >> > @@ -383,14 +384,13 @@ static int update_prob(VP56RangeCoder *c, int p) >> > 255 - inv_recenter_nonneg(inv_map_table[d], 255 - >> p); >> > } >> > >> > -static enum AVPixelFormat read_colorspace_details(AVCodecContext *ctx) >> > +static int read_colorspace_details(AVCodecContext *ctx) >> > { >> > static const enum AVColorSpace colorspaces[8] = { >> > AVCOL_SPC_UNSPECIFIED, AVCOL_SPC_BT470BG, AVCOL_SPC_BT709, >> AVCOL_SPC_SMPTE170M, >> > AVCOL_SPC_SMPTE240M, AVCOL_SPC_BT2020_NCL, AVCOL_SPC_RESERVED, >> AVCOL_SPC_RGB, >> > }; >> > VP9Context *s = ctx->priv_data; >> > -enum AVPixelFormat res; >> > int bits = ctx->profile <= 1 ? 0 : 1 + get_bits1(&s->gb); // 0:8, >> 1:10, 2:12 >> > >> > s->bpp_index = bits; >> > @@ -401,10 +401,10 @@ static enum AVPixelFormat >> read_colorspace_details(AVCodecContext *ctx) >> > static const enum AVPixelFormat pix_fmt_rgb[3] = { >> > AV_PIX_FMT_GBRP, AV_PIX_FMT_GBRP10, AV_PIX_FMT_GBRP12 >> > }; >> > +s->ss_h = s->ss_v = 0; >> > +ctx->color_range = AVCOL_RANGE_JPEG; >> > +s->pix_fmt = pix_fmt_rgb[bits]; >> > if (ctx->profile & 1) { >> > -s->ss_h = s->ss_v = 0; >> > -res = pix_fmt_rgb[bits]; >> > -ctx->color_range = AVCOL_RANGE_JPEG; >> > if (get_bits1(&s->gb)) { >> > av_log(ctx, AV_LOG_ERROR, "Reserved bit set in RGB\n"); >> > return AVERROR_INVALIDDATA; >> > @@ -427,7 +427,8 @@ static enum AVPixelFormat >> read_colorspace_details(AVCodecContext *ctx) >> > if (ctx->profile & 1) { >> > s->ss_h = get_bits1(&s->gb); >> > s->ss_v = get_bits1(&s->gb); >> > -if ((res = pix_fmt_for_ss[bits][s->ss_v][s->ss_h]) == >> AV_PIX_FMT_YUV420P) { >> > +s->pix_fmt = pix_fmt_for_ss[bits][s->ss_v][s->ss_h]; >> > +if (s->pix_fmt == AV_PIX_FMT_YUV420P) { >> > av_log(ctx, AV_LOG_ERROR, "YUV 4:2:0 not supported in >> profile %d\n", >> > ctx->profile); >> > return AVERROR_INVALIDDATA; >> > @@ -438,11 +439,11 @@ static enum AVPixelFormat >> read_colorspace_details(AVCodecContext *ctx) >> > } >> > } else { >> > s->ss_h = s->ss_v = 1; >> > -res = pix_fmt_for_ss[bits][1][1]; >> > +s->pix_fmt = pix_fmt_for_ss[bits][1][1]; >> > } >> > } >> > >> > -return res; >> > +return 0; >> > } >> > >> > static int decode_frame_header(AVCodecContext *ctx, >> > @@ -450,7 +451,6 @@ static int decode_frame_header(AVCodecContext *ctx, >> > { >> > VP9Context *s = ctx->priv_data; >> > int c, i, j, k, l, m, n, w, h, max, size2, res, sharp; >> > -enum AVPixelFormat fmt = ctx->pix_fmt; >> > int last_invisible; >> > const uint8_t *data2; >> > >> > @@ -486,8 +486,8 @@ static int decode_frame_header(AVCodecContext *ctx, >> > av_log(ctx, AV_LOG_ERROR, "Invalid sync code\n"); >> > return AVERROR_INVALIDDATA; >> > } >> > -if ((fmt = read_co
Re: [FFmpeg-devel] [PATCH 1/2] avutil/mathematics: return INT64_MIN (=AV_NOPTS_VALUE) from av_rescale_rnd() for overflows
On Tue, Dec 01, 2015 at 01:50:13PM +0100, Michael Niedermayer wrote: > From: Michael Niedermayer > > Fixes integer overflow > Fixes: mozilla bug 1229167 > > Found-by: Tyson Smith > Signed-off-by: Michael Niedermayer > --- > libavutil/mathematics.c | 13 ++--- > 1 file changed, 10 insertions(+), 3 deletions(-) patchset applied [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No snowflake in an avalanche ever feels responsible. -- Voltaire signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] mjpegdec: consider chroma subsampling in size check
If the chroma components are subsampled, smaller buffers are allocated for them. In that case the maximal block_offset for the chroma components is not as large as for the luma component. This fixes out of bounds writes causing segmentation faults or memory corruption. Signed-off-by: Andreas Cadhalpun --- libavcodec/mjpegdec.c | 13 + 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c index cfc59ac..303b990 100644 --- a/libavcodec/mjpegdec.c +++ b/libavcodec/mjpegdec.c @@ -1246,7 +1246,7 @@ static int mjpeg_decode_scan(MJpegDecodeContext *s, int nb_components, int Ah, int mb_bitmask_size, const AVFrame *reference) { -int i, mb_x, mb_y; +int i, mb_x, mb_y, chroma_h_shift, chroma_v_shift; uint8_t *data[MAX_COMPONENTS]; const uint8_t *reference_data[MAX_COMPONENTS]; int linesize[MAX_COMPONENTS]; @@ -1271,6 +1271,9 @@ static int mjpeg_decode_scan(MJpegDecodeContext *s, int nb_components, int Ah, s->coefs_finished[c] |= 1; } +av_pix_fmt_get_chroma_sub_sample(s->avctx->pix_fmt, &chroma_h_shift, + &chroma_v_shift); + for (mb_y = 0; mb_y < s->mb_height; mb_y++) { for (mb_x = 0; mb_x < s->mb_width; mb_x++) { const int copy_mb = mb_bitmask && !get_bits1(&mb_bitmask_gb); @@ -1285,7 +1288,7 @@ static int mjpeg_decode_scan(MJpegDecodeContext *s, int nb_components, int Ah, } for (i = 0; i < nb_components; i++) { uint8_t *ptr; -int n, h, v, x, y, c, j; +int n, h, v, x, y, c, j, h_shift, v_shift; int block_offset; n = s->nb_blocks[i]; c = s->comp_index[i]; @@ -1293,14 +1296,16 @@ static int mjpeg_decode_scan(MJpegDecodeContext *s, int nb_components, int Ah, v = s->v_scount[i]; x = 0; y = 0; +h_shift = c ? chroma_h_shift: 0; +v_shift = c ? chroma_v_shift: 0; for (j = 0; j < n; j++) { block_offset = (((linesize[c] * (v * mb_y + y) * 8) + (h * mb_x + x) * 8 * bytes_per_pixel) >> s->avctx->lowres); if (s->interlaced && s->bottom_field) block_offset += linesize[c] >> 1; -if ( 8*(h * mb_x + x) < s->width -&& 8*(v * mb_y + y) < s->height) { +if ( 8*(h * mb_x + x) < (s->width + (1 << h_shift) - 1) >> h_shift +&& 8*(v * mb_y + y) < (s->height + (1 << v_shift) - 1) >> v_shift) { ptr = data[c] + block_offset; } else ptr = NULL; -- 2.6.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] aacenc: mark coders other than twoloop as experimental
On Wed, Dec 2, 2015 at 4:47 PM, Rostislav Pehlivanov wrote: > This commit marks any coders beside twoloop as experimental and gives > out a warning that some of they might be silently removed in the future. > > Users are highly encouraged to use the twoloop coder, which is the > default. > --- > libavcodec/aacenc.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/libavcodec/aacenc.c b/libavcodec/aacenc.c > index 971f8ab..7a34806 100644 > --- a/libavcodec/aacenc.c > +++ b/libavcodec/aacenc.c > @@ -967,6 +967,8 @@ static av_cold int aac_encode_init(AVCodecContext *avctx) > s->coder = &ff_aac_coders[s->options.coder]; > > if (s->options.coder != AAC_CODER_TWOLOOP) { > +ERROR_IF(avctx->strict_std_compliance > FF_COMPLIANCE_EXPERIMENTAL, > + "Coders other than twoloop require -strict -2 and some may > be removed in the future\n"); > s->options.intensity_stereo = 0; > s->options.pns = 0; > } LGTM ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Allow mpjpeg demuxer to process MIME parts which do not include Content-Length header.
On Wed, 2 Dec 2015 09:28:40 -0500 Alexander Agranovsky wrote: > Hi guys -- where do we stand with this? Are there any additional comments? > > - A. Pushed both patches. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] ffmdec: reject zero-sized chunks
If size is zero, avio_get_str fails, leaving the buffer uninitialized. This causes invalid reads in av_set_options_string. Signed-off-by: Andreas Cadhalpun --- libavformat/ffmdec.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavformat/ffmdec.c b/libavformat/ffmdec.c index 9ad771e..afba905 100644 --- a/libavformat/ffmdec.c +++ b/libavformat/ffmdec.c @@ -423,7 +423,7 @@ static int ffm2_read_header(AVFormatContext *s) } break; case MKBETAG('S', '2', 'V', 'I'): -if (f_stvi++) { +if (f_stvi++ || !size) { ret = AVERROR(EINVAL); goto fail; } @@ -438,7 +438,7 @@ static int ffm2_read_header(AVFormatContext *s) goto fail; break; case MKBETAG('S', '2', 'A', 'U'): -if (f_stau++) { +if (f_stau++ || !size) { ret = AVERROR(EINVAL); goto fail; } -- 2.6.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] ffmdec: only seek back at EOF if a server is attached
Otherwise the ffm demuxer can return the same packets endlessly, if there is no server attached. --- I haven't tested ffserver, but since it sets server_attached, it should still work as previously. --- libavformat/ffmdec.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/libavformat/ffmdec.c b/libavformat/ffmdec.c index e7c1449..9ad771e 100644 --- a/libavformat/ffmdec.c +++ b/libavformat/ffmdec.c @@ -100,7 +100,10 @@ static int ffm_read_data(AVFormatContext *s, len = size; if (len == 0) { if (avio_tell(pb) == ffm->file_size) -avio_seek(pb, ffm->packet_size, SEEK_SET); +if (ffm->server_attached) +avio_seek(pb, ffm->packet_size, SEEK_SET); +else +return AVERROR_EOF; retry_read: if (pb->buffer_size != ffm->packet_size) { int64_t tell = avio_tell(pb); -- 2.6.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] aacenc: mark coders other than twoloop as experimental
On Wed, Dec 2, 2015 at 10:04 PM, Claudio Freire wrote: > On Wed, Dec 2, 2015 at 4:47 PM, Rostislav Pehlivanov > wrote: >> This commit marks any coders beside twoloop as experimental and gives >> out a warning that some of they might be silently removed in the future. >> >> Users are highly encouraged to use the twoloop coder, which is the >> default. >> --- >> libavcodec/aacenc.c | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/libavcodec/aacenc.c b/libavcodec/aacenc.c >> index 971f8ab..7a34806 100644 >> --- a/libavcodec/aacenc.c >> +++ b/libavcodec/aacenc.c >> @@ -967,6 +967,8 @@ static av_cold int aac_encode_init(AVCodecContext *avctx) >> s->coder = &ff_aac_coders[s->options.coder]; >> >> if (s->options.coder != AAC_CODER_TWOLOOP) { >> +ERROR_IF(avctx->strict_std_compliance > FF_COMPLIANCE_EXPERIMENTAL, >> + "Coders other than twoloop require -strict -2 and some may >> be removed in the future\n"); >> s->options.intensity_stereo = 0; >> s->options.pns = 0; >> } > > > LGTM Sounds good to me, thanks! ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/9] avfilter/af_flanger: use rint instead of floor hack
On Wed, Dec 2, 2015 at 7:39 AM, Paul B Mahol wrote: > On 12/2/15, Ganesh Ajjanagadde wrote: >> On Wed, Dec 2, 2015 at 1:18 AM, Paul B Mahol wrote: >>> On 12/2/15, Ganesh Ajjanagadde wrote: Signed-off-by: Ganesh Ajjanagadde --- libavfilter/af_flanger.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavfilter/af_flanger.c b/libavfilter/af_flanger.c index f8ec830..a92367c 100644 --- a/libavfilter/af_flanger.c +++ b/libavfilter/af_flanger.c @@ -130,7 +130,7 @@ static int config_input(AVFilterLink *inlink) return AVERROR(ENOMEM); ff_generate_wave_table(s->wave_shape, AV_SAMPLE_FMT_FLT, s->lfo, s->lfo_length, - floor(s->delay_min * inlink->sample_rate + 0.5), + rint(s->delay_min * inlink->sample_rate), s->max_samples - 2., 3 * M_PI_2); return av_samples_alloc_array_and_samples(&s->delay_buffer, NULL, -- 2.6.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >>> >>> Have you checked that output is same? >> >> Well if is not, rint is more accurate than floor, this is the whole >> point of the patch. What I can tell is that FATE passes. >> >> One can craft input so that floor(x + 0.5) is not identical to >> rint(x), and that is the point of these patches - to be more accurate >> when we can be. A simple example: what happens at half-integers, i.e >> 1.5? Then, floor always returns the next up, e.g 2.0, while rint(x) >> rounds to the nearest even integer in accord with IEEE-754. This is >> done to reduce rounding biases on floating point numbers - think of a >> large number of half integer samples, the floor hack results in >> consistent upward bias, the rint (or llrint, lrint more generally) >> avoids this. >> >> I care about technical purity of filters; you seem to care about >> copying it over from some other place and matching another filter >> exactly, regardless of the quality of such filters. In that case, I >> think FFmpeg's monolithic filter design needs to be reconsidered; we >> should allow seamless integration of external filters. These two goals >> are at odds with each other, and I will always personally prefer the >> first, since it actually allows greater flexibility for improvements. >> Ultimately, I am not a maintainer for these things and I have no say >> on the matter or personal interest in it. >> > > On 2nd look, patch should be fine. pushed, thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/9] avfilter/vsrc_mptestsrc: use lrint instead of floor hack
On Tue, Dec 1, 2015 at 9:11 PM, Michael Niedermayer wrote: > On Tue, Dec 01, 2015 at 07:27:50PM -0500, Ganesh Ajjanagadde wrote: >> lrint is faster, and is more consistent across the codebase. >> >> Signed-off-by: Ganesh Ajjanagadde >> --- >> libavfilter/vsrc_mptestsrc.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) > > should be ok pushed, thanks > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > While the State exists there can be no freedom; when there is freedom there > will be no State. -- Vladimir Lenin > > ___ > 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/9] avfilter/vf_perspective: use lrint instead of floor hack
On Tue, Dec 1, 2015 at 9:10 PM, Michael Niedermayer wrote: > On Tue, Dec 01, 2015 at 07:27:51PM -0500, Ganesh Ajjanagadde wrote: >> Signed-off-by: Ganesh Ajjanagadde >> --- >> libavfilter/vf_perspective.c | 10 +- >> 1 file changed, 5 insertions(+), 5 deletions(-) > > should be ok pushed, thanks > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Old school: Use the lowest level language in which you can solve the problem > conveniently. > New school: Use the highest level language in which the latest supercomputer > can solve the problem without the user falling asleep waiting. > > ___ > 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] avutil/crc: avoid needless space wastage of hardcoded crc table
On Tue, Dec 1, 2015 at 8:38 PM, James Almer wrote: > On 12/1/2015 10:35 PM, Ganesh Ajjanagadde wrote: >> On Tue, Dec 1, 2015 at 8:08 PM, James Almer wrote: >>> On 12/1/2015 9:53 PM, Ganesh Ajjanagadde wrote: There was no reason AFAIK for making AV_CRC_24_IEEE 12. This simply resulted in wasted space under --enable-hardcoded-tables: dynamic: 1318672 libavutil/libavutil.so.55 old: 1330680 libavutil/libavutil.so.55 new: 1326488 libavutil/libavutil.so.55 Minor version number is bumped, with ifdefry due to API breakage. Signed-off-by: Ganesh Ajjanagadde --- libavutil/crc.h | 4 libavutil/version.h | 5 - 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/libavutil/crc.h b/libavutil/crc.h index e86bf1d..9af4421 100644 --- a/libavutil/crc.h +++ b/libavutil/crc.h @@ -40,7 +40,11 @@ typedef enum { AV_CRC_32_IEEE, AV_CRC_32_IEEE_LE, /*< reversed bitorder version of AV_CRC_32_IEEE */ AV_CRC_16_ANSI_LE, /*< reversed bitorder version of AV_CRC_16_ANSI */ +#if FF_API_CRC_BIG_TABLE AV_CRC_24_IEEE = 12, +#else +AV_CRC_24_IEEE, +#endif /* FF_API_CRC_BIG_TABLE */ AV_CRC_MAX, /*< Not part of public API! Do not use outside libavutil. */ }AVCRCId; diff --git a/libavutil/version.h b/libavutil/version.h index e0ddfd2..67e778a 100644 --- a/libavutil/version.h +++ b/libavutil/version.h @@ -56,7 +56,7 @@ */ #define LIBAVUTIL_VERSION_MAJOR 55 -#define LIBAVUTIL_VERSION_MINOR 9 +#define LIBAVUTIL_VERSION_MINOR 10 #define LIBAVUTIL_VERSION_MICRO 100 #define LIBAVUTIL_VERSION_INT AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \ @@ -108,6 +108,9 @@ #ifndef FF_API_ERROR_FRAME #define FF_API_ERROR_FRAME (LIBAVUTIL_VERSION_MAJOR < 56) #endif +#ifndef FF_API_CRC_BIG_TABLE +#define FF_API_CRC_BIG_TABLE(LIBAVUTIL_VERSION_INT < AV_VERSION_INT(55, 10, 100)) >>> >>> This is wrong. With this check, FF_API_CRC_BIG_TABLE is false. The point >>> of these FF_API defines is to make sure they are true until the next major >>> bump. That's why you use LIBAVUTIL_VERSION_MAJOR < 56, like it's being >>> done for the rest. >> >> Finally getting a sense for these things, thanks. Barring that, does >> it look fine? > > Yes. You can also skip bumping minor. You're scheduling a change for the next > major bump and not making any changes with immediate effects, so a minor bump > is not necessary. pushed with an additional header include version.h needed to work correctly, thanks. > >> >>> +#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 >> > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] common.mak: Use CCFLAGS for assembly generation as well
On Wed, Dec 02, 2015 at 08:03:33PM +0100, Michael Niedermayer wrote: > On Tue, Dec 01, 2015 at 09:46:04PM -0800, Timothy Gu wrote: > > CCFLAGS is equivalent to CPPFLAGS + CFLAGS. > > --- > > common.mak | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > does this fix any case or just simplifies common.mak ? > It just simplifies it. I'll amend the commit message. Timothy ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] AAC experimental flag: the sequel
On Wed, Dec 2, 2015 at 12:51 PM, Ganesh Ajjanagadde wrote: > On Wed, Dec 2, 2015 at 10:37 AM, Claudio Freire > wrote: >> So, here comes the discussion again. >> >> This time, the AAC encoder is in good shape. It's not perfect. I have >> a list of known bugs to address that still has some issues, but I'm >> not really certain whether they should block the flag's removal. >> >> The bugs will be addressed in time, but maybe the encoder is in good >> enough shape as it is? > > IIUC, JBK responded at VDD 2015 to the question of for which types of > files they don't use avcodec. He mentioned AAC due to some user's > complaints about quality on certain files. This was likely referring > to the decoder and not encoder. Nevertheless, I suggest a conversation > with them (or other users) to obtain problematic files to test. I'm always on the lookout for problematic files to add to my "test samples" collection, so if anyone has one they should contact me in private. In fact fate needs a few more samples since most of the samples there fail to trigger any of the bugs we've been working on of late. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] avutil/crc: avoid needless space wastage of hardcoded crc table
Le tridi 13 frimaire, an CCXXIV, Ganesh Ajjanagadde a écrit : > There was no reason AFAIK for making AV_CRC_24_IEEE 12. The reason was to leave room for the fork to add its own new constants without causing ABI incompatibilities. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel