Re: [FFmpeg-devel] [PATCH] vp9: uses ff_set_dimensions (which sets coded_width/height).
On Sat, Oct 24, 2015 at 3:40 AM, Ronald S. Bultje wrote: > Fixes ticket 4935. > --- > libavcodec/vp9.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c > index 3753e89..cee17d9 100644 > --- a/libavcodec/vp9.c > +++ b/libavcodec/vp9.c > @@ -222,8 +222,7 @@ static int update_size(AVCodecContext *ctx, int w, int h, > enum AVPixelFormat fmt > if (s->intra_pred_data[0] && w == ctx->width && h == ctx->height && > ctx->pix_fmt == fmt) > return 0; > > -ctx->width = w; > -ctx->height = h; > +ff_set_dimensions(ctx, w, h); LGTM. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] libavformat/mxfenc.c: Fix segfault when writing an audio packet when there has not been a video one.
On Wed, 21 Oct 2015 22:43:04 +0200 Tomas Härdin wrote: > On Tue, 2015-10-20 at 16:43 +0200, Marton Balint wrote: > > On Mon, 19 Oct 2015, Tomas Härdin wrote: > > > > > On Mon, 2015-10-19 at 11:40 +0200, Alexis Ballier wrote: > > >> On Mon, 19 Oct 2015 10:30:00 +0200 > > >> Michael Niedermayer wrote: > > >> > > >>> On Fri, Oct 16, 2015 at 10:42:32AM +0200, Alexis Ballier > > >>> wrote: > > This happens when writing the trailer of a file containing > > audio but that has not muxed any video packet. Fixes ticket > > #4817. > > > > > > >>> > > >>> from IRC: > > >>> maybe it should print a warning that there has been no > > >>> video? > > >> > > >> maybe, but what would be the right condition ? just this case ? > > >> or when writing any edit unit without video? or... ? > > >> I haven't been able to find clear references on this (well, > > >> those smpte specs I googled aren't esp. easy to read either), > > >> but e.g. the muxer refuses to mux without exactly one video > > >> stream, so maybe, an empty video stream is also an error; I > > >> don't know > > > > > > I'm not particularly fond of second-guessing these kinds of > > > things. D-10 is really anal about what constitutes a legal file, > > > so it's probably best not to write anything if something seems > > > amiss. In the end, the real test for correctness is whether the > > > output works with all gear for your particular use case. But > > > segfaults are important to fix, so I'm not too concerned here. > > > Plus my main concern is mxfdec, not mxfenc. > > > > Why not simply return error and print an error explaining "An audio > > packet was muxed before a video, this is not supported." > > > > Segfault -> error is much better than segfault -> possibly broken > > file. > > Yes, simply bailing out is infinitely better than segfaulting. It's > also the more conservative approach, which I am for ok, so assuming the error condition is 'muxing first audio packet before first video packet (if any)', I'll re-send with that warning added ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc/hapdec: Correct colour spaces
Tom Butterworth gmail.com> writes: > > Attached patch fixes hap colour spaces as > > reminded by Tom Butterworth. > > LGTM, thanks Patch applied. Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/ingenient: Add a probe function
Michael Niedermayer niedermayer.cc> writes: > > ingenientdec.c | 13 - > > 1 file changed, 12 insertions(+), 1 deletion(-) > > 4fb270cd44d0ed3ee53dbf1216a5cbb4dba00d8c patchingenient.diff > > i cant test either but if it works it should be ok Patch applied. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Use ff_thread_once() to initialize sin/cos static tables.
On Fri, 23 Oct 2015 15:35:15 -0700 Dale Curtis wrote: > Changes from partial initialization which happens for every > initialize call to a full initialization once per process. Changes > as discussed on list by wm4 and rbultje. > > Passes fft-test and fate suite. > > Signed-off-by: Dale Curtis > --- > libavcodec/fft_template.c | 33 - > libavcodec/rdft.c | 41 + > libavcodec/rdft.h | 1 + > 3 files changed, 58 insertions(+), 17 deletions(-) > > diff --git a/libavcodec/fft_template.c b/libavcodec/fft_template.c > index 23ea453..a9a3797 100644 > --- a/libavcodec/fft_template.c > +++ b/libavcodec/fft_template.c > @@ -28,7 +28,9 @@ > > #include > #include > +#include "libavutil/avassert.h" > #include "libavutil/mathematics.h" > +#include "libavutil/thread.h" > #include "fft.h" > #include "fft-internal.h" > > @@ -85,17 +87,30 @@ static int split_radix_permutation(int i, int n, > int inverse) > else return split_radix_permutation(i, m, inverse)*4 - > 1; > } > > -av_cold void ff_init_ff_cos_tabs(int index) > +#if (!CONFIG_HARDCODED_TABLES) && (!FFT_FIXED_32) > +static AVOnce ff_cos_tabs_init = AV_ONCE_INIT; > +static av_cold void ff_init_ff_cos_static_table_init(void) > +{ > +int nbits; > +for (nbits = 4; nbits < 16; nbits++) { > +int i; > +int m = 1 << nbits; > +double freq = 2*M_PI/m; > +FFTSample *tab = FFT_NAME(ff_cos_tabs)[nbits]; > +for (i = 0; i <= m/4; i++) > +tab[i] = FIX15(cos(i*freq)); > +for (i = 1; i < m/4; i++) > +tab[m/2-i] = tab[i]; > +} > +} > +#endif > + > +av_cold void ff_init_ff_cos_tabs(int nbits) > { > #if (!CONFIG_HARDCODED_TABLES) && (!FFT_FIXED_32) > -int i; > -int m = 1< -double freq = 2*M_PI/m; > -FFTSample *tab = FFT_NAME(ff_cos_tabs)[index]; > -for(i=0; i<=m/4; i++) > -tab[i] = FIX15(cos(i*freq)); > -for(i=1; i -tab[m/2-i] = tab[i]; > +av_assert0(nbits >= 4 && nbits <= 16); > +if (ff_thread_once(&ff_cos_tabs_init, &ff_init_ff_cos_static_table_init)) > +av_log(NULL, AV_LOG_ERROR, "failed to initialize cosine tables.\n"); > #endif > } Hm, the fact that fft_template.c is included in several other files via #include makes this quite confusing. In fft.h I see: #define ff_init_ff_cos_tabs FFT_NAME(ff_init_ff_cos_tabs) Well, I guess it's somehow working out. > diff --git a/libavcodec/rdft.c b/libavcodec/rdft.c > index c318aa8..d5a5d50 100644 > --- a/libavcodec/rdft.c > +++ b/libavcodec/rdft.c > @@ -20,7 +20,9 @@ > */ > #include > #include > +#include "libavutil/avassert.h" > #include "libavutil/mathematics.h" > +#include "libavutil/thread.h" > #include "rdft.h" > > /** > @@ -96,6 +98,36 @@ static void rdft_calc_c(RDFTContext *s, FFTSample *data) > } > } > > +#if !CONFIG_HARDCODED_TABLES > +static AVOnce ff_sin_tabs_init = AV_ONCE_INIT; > +static av_cold void ff_init_ff_sin_static_table_init(void) > +{ > +int nbits; > +for (nbits = 4; nbits < 16; nbits++) { > +int n = 1 << nbits; > +int m = n >> 2; > +int offset; > +for (offset = 0; offset < 2; offset++) { > +int i; > +FFTSample* tab = ff_sin_tabs[nbits]+offset*m; > +const double theta = (offset ? -1 : 1) * 2 * M_PI / n; > +for (i = 0; i < m; i++) > +tab[i] = sin(i * theta); > +} > +} > +} > +#endif > + > +av_cold void ff_init_ff_sin_tabs(int nbits, enum RDFTransformType trans) > +{ > +#if !CONFIG_HARDCODED_TABLES > +av_assert0(trans == DFT_R2C || trans == IDFT_C2R || trans == > IDFT_R2C || trans == DFT_C2R); > +av_assert0(nbits >= 4 && nbits <= 16); > +if (ff_thread_once(&ff_sin_tabs_init, &ff_init_ff_sin_static_table_init)) > +av_log(NULL, AV_LOG_ERROR, "Failed to initialize sin tables.\n"); > +#endif > +} > + > av_cold int ff_rdft_init(RDFTContext *s, int nbits, enum > RDFTransformType trans) > { > int n = 1 << nbits; > @@ -112,16 +144,9 @@ av_cold int ff_rdft_init(RDFTContext *s, int > nbits, enum RDFTransformType trans) > return ret; > > ff_init_ff_cos_tabs(nbits); > +ff_init_ff_sin_tabs(nbits, trans); > s->tcos = ff_cos_tabs[nbits]; > s->tsin = ff_sin_tabs[nbits]+(trans == DFT_R2C || trans == > DFT_C2R)*(n>>2); > -#if !CONFIG_HARDCODED_TABLES > -{ > -int i; > -const double theta = (trans == DFT_R2C || trans == DFT_C2R ? > -1 : 1) * 2 * M_PI / n; Your mail client is breaking long lines. Either send the patch as attachment, or use git send-email. > -for (i = 0; i < (n >> 2); i++) > -s->tsin[i] = sin(i * theta); > -} > -#endif > s->rdft_calc = rdft_calc_c; > > if (ARCH_ARM) ff_rdft_init_arm(s); > diff --git a/libavcodec/rdft.h b/libavcodec/rdft.h > index 37c40e7..75bb6b5 100644 > --- a/libavcodec/rdft.h > +++ b/libavco
Re: [FFmpeg-devel] [PATCH 01/11] libavformat/mxfdec.c: klv_read_packet: Properly check klv_decode_ber_length return value.
On Thu, 2015-10-22 at 19:25 +0200, Alexis Ballier wrote: > On Wed, 21 Oct 2015 23:31:29 +0200 > Tomas Härdin wrote: > > > On Wed, 2015-10-21 at 18:00 +0200, Alexis Ballier wrote: > > > klv_decode_ber_length cannot return -1, but can return > > > AVERROR_INVALIDDATA. Store its return value in a signed integer > > > (instead of unsigned KLVPacket.length) and forward the error > > > appropriately. --- libavformat/mxfdec.c | 6 -- > > > 1 file changed, 4 insertions(+), 2 deletions(-) > > > > > > diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c > > > index 00d420b..94a953b 100644 > > > --- a/libavformat/mxfdec.c > > > +++ b/libavformat/mxfdec.c > > > @@ -366,13 +366,15 @@ static int mxf_read_sync(AVIOContext *pb, > > > const uint8_t *key, unsigned size) > > > static int klv_read_packet(KLVPacket *klv, AVIOContext *pb) > > > { > > > +int64_t len; > > > if (!mxf_read_sync(pb, mxf_klv_key, 4)) > > > return AVERROR_INVALIDDATA; > > > klv->offset = avio_tell(pb) - 4; > > > memcpy(klv->key, mxf_klv_key, 4); > > > avio_read(pb, klv->key + 4, 12); > > > -klv->length = klv_decode_ber_length(pb); > > > -return klv->length == -1 ? -1 : 0; > > > +len = klv_decode_ber_length(pb); > > > +klv->length = FFMAX(len, 0); > > > +return FFMIN(len, 0); > > > } > > > > Can't klv_read_packet() return int64_t instead? > > you mean change the return type and return klv->length ? > that might work, but note that what I'm trying to fix is > klv_read_packet setting length to (unsigned)AVERROR_INVALIDDATA, i.e., > something close to 2^64, and returning 0. > I don't see any problem by doing that, so it is as you prefer. Oh, of course - don't let length be some bogus value :) Actually, maybe it doesn't matter so much. Hm /Tomas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] vp9: uses ff_set_dimensions (which sets coded_width/height).
On Fri, 23 Oct 2015 21:40:14 -0400 "Ronald S. Bultje" wrote: > Fixes ticket 4935. > --- > libavcodec/vp9.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c > index 3753e89..cee17d9 100644 > --- a/libavcodec/vp9.c > +++ b/libavcodec/vp9.c > @@ -222,8 +222,7 @@ static int update_size(AVCodecContext *ctx, int w, int h, > enum AVPixelFormat fmt > if (s->intra_pred_data[0] && w == ctx->width && h == ctx->height && > ctx->pix_fmt == fmt) > return 0; > > -ctx->width = w; > -ctx->height = h; > +ff_set_dimensions(ctx, w, h); > ctx->pix_fmt = fmt; > s->sb_cols = (w + 63) >> 6; > s->sb_rows = (h + 63) >> 6; ff_set_dimensions() can fail. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] videodsp: don't overread edges in vfix3 emu_edge.
--- libavcodec/x86/videodsp.asm | 15 +++ 1 file changed, 11 insertions(+), 4 deletions(-) diff --git a/libavcodec/x86/videodsp.asm b/libavcodec/x86/videodsp.asm index 25d4364..48f5ac0 100644 --- a/libavcodec/x86/videodsp.asm +++ b/libavcodec/x86/videodsp.asm @@ -194,8 +194,12 @@ hvar_fn %elif (%2-%%off) == 2 movvalw, [srcq+%2-2] %elifidn %1, body -movvald, [srcq+%2-3] -%else +movvalb, [srcq+%2-1] +salvald, 16 +movvalw, [srcq+%2-3] +%elifidn %1, bottom +movd mm %+ %%mmx_idx, [srcq+%2-4] +%else ; top movd mm %+ %%mmx_idx, [srcq+%2-3] %endif %endif ; (%2-%%off) >= 1 @@ -251,12 +255,15 @@ hvar_fn mov [dstq+%2-2], valw %elifidn %1, body mov [dstq+%2-3], valw -shrvald, 16 +sarvald, 16 mov [dstq+%2-1], valb %else movd vald, mm %+ %%mmx_idx +%ifidn %1, bottom +sarvald, 8 +%endif mov [dstq+%2-3], valw -shrvald, 16 +sarvald, 16 mov [dstq+%2-1], valb %endif %endif ; (%2-%%off) >= 1 -- 2.1.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Wanted to contribute
Hi ! I wanted to contribute in FFMpeg organization. What can be the good starting point? I have Mac OS. Thanks, Rishi ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/huffman: replace qsort with AV_QSORT
On Thu, Oct 22, 2015 at 10:25 PM, Ganesh Ajjanagadde wrote: > > On Thu, Oct 22, 2015 at 9:28 PM, Timothy Gu wrote: > > On Thu, Oct 22, 2015 at 5:01 PM Ganesh Ajjanagadde > > wrote: > >> > >> Sample benchmark (x86-64, Haswell, GNU/Linux), fraps-v2 from FATE: > >> new: > >> 280110 decicycles in qsort, 1 runs, 0 skips > >> 268260 decicycles in qsort, 2 runs, 0 skips > >> > >> old: > >> 1469910 decicycles in qsort, 1 runs, 0 skips > >> 952950 decicycles in qsort, 2 runs, 0 skips > > > > > > Usually it takes more than 2 runs to make sure something is faster than the > > other (try -stream_loop 1 on the input). > > In this case the gain should be obvious due to inlining. Nevertheless, > here are new numbers. I chose vp6 for two reasons: > 1. Above was for fraps-v2, giving vp6 for more "completeness". > 2. stream_loop throws errors: Error while decoding stream #0:0: > Invalid data found when processing input for fraps-v2. > > Here they are: > vp6 (old): > 78930 decicycles in qsort, 1 runs, 0 skips > 45330 decicycles in qsort, 2 runs, 0 skips > 27825 decicycles in qsort, 4 runs, 0 skips > 17471 decicycles in qsort, 8 runs, 0 skips > 12296 decicycles in qsort, 16 runs, 0 skips >9554 decicycles in qsort, 32 runs, 0 skips >8404 decicycles in qsort, 64 runs, 0 skips >7405 decicycles in qsort, 128 runs, 0 skips >6740 decicycles in qsort, 256 runs, 0 skips >7540 decicycles in qsort, 512 runs, 0 skips >9498 decicycles in qsort,1024 runs, 0 skips >9938 decicycles in qsort,2048 runs, 0 skips >8043 decicycles in qsort,4095 runs, 1 skips > > vp6 (new): > 15880 decicycles in qsort, 1 runs, 0 skips > 10730 decicycles in qsort, 2 runs, 0 skips > 10155 decicycles in qsort, 4 runs, 0 skips >7805 decicycles in qsort, 8 runs, 0 skips >6883 decicycles in qsort, 16 runs, 0 skips >6305 decicycles in qsort, 32 runs, 0 skips >5854 decicycles in qsort, 64 runs, 0 skips >5152 decicycles in qsort, 128 runs, 0 skips >4452 decicycles in qsort, 256 runs, 0 skips >4161 decicycles in qsort, 511 runs, 1 skips >4081 decicycles in qsort,1023 runs, 1 skips >4072 decicycles in qsort,2047 runs, 1 skips >4004 decicycles in qsort,4095 runs, 1 skips ping > > > > > Timothy ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] version.sh: add note that ffversion.h is auto-generated
On Thu, Oct 15, 2015 at 7:04 PM, Ganesh Ajjanagadde wrote: > Signed-off-by: Ganesh Ajjanagadde > --- > version.sh | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/version.sh b/version.sh > index f9754eb..a9d7e39 100755 > --- a/version.sh > +++ b/version.sh > @@ -54,6 +54,7 @@ GUARD=$(echo "$2" | sed 's/\//_/' | sed 's/\./_/' | tr > '[:lower:]' '[:upper:]' | > # Update version header only on revision changes to avoid spurious rebuilds > if test "$NEW_REVISION" != "$OLD_REVISION"; then > cat << EOF > "$2" > +/* Automatically generated by version.sh, do not manually edit! */ > #ifndef $GUARD > #define $GUARD > $NEW_REVISION > -- > 2.6.1 > ping ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH][RFC] avcodec/pthread_frame: fix null pointer dereference
Fixes CID 1322329. Signed-off-by: Ganesh Ajjanagadde --- libavcodec/pthread_frame.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c index 7651211..ca06e3d 100644 --- a/libavcodec/pthread_frame.c +++ b/libavcodec/pthread_frame.c @@ -305,7 +305,7 @@ static void release_delayed_buffers(PerThreadContext *p) pthread_mutex_lock(&fctx->buffer_mutex); // fix extended data in case the caller screwed it up -av_assert0(p->avctx->codec_type == AVMEDIA_TYPE_VIDEO || +av_assert0(p->avctx && p->avctx->codec_type == AVMEDIA_TYPE_VIDEO || p->avctx->codec_type == AVMEDIA_TYPE_AUDIO); f = &p->released_buffers[--p->num_released_buffers]; f->extended_data = f->data; -- 2.6.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avutil/opt: print more meaningful default flags values
Example: % ./ffmpeg -h encoder=gif [...] GIF encoder AVOptions: -gifflagsE..V set GIF flags (default offsetting+transdiff) offsetting E..V enable picture offsetting transdiffE..V enable transparency detection between frames --- libavutil/opt.c| 32 ++-- tests/ref/fate/opt | 2 +- 2 files changed, 31 insertions(+), 3 deletions(-) diff --git a/libavutil/opt.c b/libavutil/opt.c index 36eeeb0..da1eb16 100644 --- a/libavutil/opt.c +++ b/libavutil/opt.c @@ -941,6 +941,27 @@ static const char *get_opt_const_name(void *obj, const char *unit, int64_t value return NULL; } +static char *get_opt_flags_string(void *obj, const char *unit, int64_t value) +{ +const AVOption *opt = NULL; +char flags[512]; + +flags[0] = 0; +if (!unit) +return NULL; +while ((opt = av_opt_next(obj, opt))) { +if (opt->type == AV_OPT_TYPE_CONST && !strcmp(opt->unit, unit) && +opt->default_val.i64 & value) { +if (flags[0]) +av_strlcatf(flags, sizeof(flags), "+"); +av_strlcatf(flags, sizeof(flags), "%s", opt->name); +} +} +if (flags[0]) +return av_strdup(flags); +return NULL; +} + static void opt_list(void *obj, void *av_log_obj, const char *unit, int req_flags, int rej_flags) { @@ -1066,9 +1087,16 @@ static void opt_list(void *obj, void *av_log_obj, const char *unit, case AV_OPT_TYPE_BOOL: av_log(av_log_obj, AV_LOG_INFO, "%s", (char *)av_x_if_null(get_bool_name(opt->default_val.i64), "invalid")); break; -case AV_OPT_TYPE_FLAGS: -av_log(av_log_obj, AV_LOG_INFO, "%"PRIX64, opt->default_val.i64); +case AV_OPT_TYPE_FLAGS: { +char *def_flags = get_opt_flags_string(obj, opt->unit, opt->default_val.i64); +if (def_flags) { +av_log(av_log_obj, AV_LOG_INFO, "%s", def_flags); +av_freep(&def_flags); +} else { +av_log(av_log_obj, AV_LOG_INFO, "%"PRIX64, opt->default_val.i64); +} break; +} case AV_OPT_TYPE_DURATION: log_value(av_log_obj, AV_LOG_INFO, opt->default_val.i64); break; diff --git a/tests/ref/fate/opt b/tests/ref/fate/opt index 307da37..e9132a5 100644 --- a/tests/ref/fate/opt +++ b/tests/ref/fate/opt @@ -23,7 +23,7 @@ TestContext AVOptions: -rational E... set rational (from 0 to 10) (default 1/1) -string E... set string (default "default") -escape E... set escape str (default "\=,") - -flags E... set flags (default 1) + -flags E... set flags (default cool) cool E... set cool flag lame E... set lame flag mu E... set mu flag -- 2.6.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH][RFC] avcodec/pthread_frame: fix null pointer dereference
Le tridi 3 brumaire, an CCXXIV, Ganesh Ajjanagadde a écrit : > Fixes CID 1322329. > > Signed-off-by: Ganesh Ajjanagadde > --- > libavcodec/pthread_frame.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c > index 7651211..ca06e3d 100644 > --- a/libavcodec/pthread_frame.c > +++ b/libavcodec/pthread_frame.c > @@ -305,7 +305,7 @@ static void release_delayed_buffers(PerThreadContext *p) > pthread_mutex_lock(&fctx->buffer_mutex); > > // fix extended data in case the caller screwed it up > -av_assert0(p->avctx->codec_type == AVMEDIA_TYPE_VIDEO || > +av_assert0(p->avctx && p->avctx->codec_type == AVMEDIA_TYPE_VIDEO || I think the commit message should explain in what circumstances p->avctx can be NULL. Otherwise, the extra test is only hiding a problem earlier in the code. > p->avctx->codec_type == AVMEDIA_TYPE_AUDIO); > f = &p->released_buffers[--p->num_released_buffers]; > f->extended_data = f->data; Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] swresample: Add support for clipping float/double to -1.0..1.0 range
On Fri, Oct 23, 2015 at 12:41:18PM -0400, Ronald S. Bultje wrote: [...] > ffmpeg -h full, searching to -sws_flags, gives this: > -sws_flags E..V scaler flags (default 4) > fast_bilinearE..V fast bilinear > bilinear E..V bilinear > bicubic E..V bicubic > experimental E..V experimental > neighbor E..V nearest neighbor > area E..V averaging area > bicublin E..V luma bicubic, chroma bilinear > gaussE..V Gaussian > sinc E..V sinc > lanczos E..V Lanczos > spline E..V natural bicubic spline > print_info E..V print info > accurate_rnd E..V accurate rounding > full_chroma_int E..V full chroma interpolation > full_chroma_inp E..V full chroma input > bitexact E..V > error_diffusion E..V error diffusion dither > > OK, so first, there's so many things wrong here, we're using flags as a way > to indicate the scaling method, and mixing up boolean flags. By the way, > did you know "experimental" is a scaling method? Fantastic help. > The default is "4", but we don't know what flag "4" corresponds to. (Just sent for this ♥) [...] -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] swresample: Add support for clipping float/double to -1.0..1.0 range
On Sat, Oct 24, 2015 at 03:16:15PM +0200, Clément Bœsch wrote: > On Fri, Oct 23, 2015 at 12:41:18PM -0400, Ronald S. Bultje wrote: > [...] > > ffmpeg -h full, searching to -sws_flags, gives this: > > -sws_flags E..V scaler flags (default 4) > > fast_bilinearE..V fast bilinear > > bilinear E..V bilinear > > bicubic E..V bicubic > > experimental E..V experimental > > neighbor E..V nearest neighbor > > area E..V averaging area > > bicublin E..V luma bicubic, chroma bilinear > > gaussE..V Gaussian > > sinc E..V sinc > > lanczos E..V Lanczos > > spline E..V natural bicubic spline > > print_info E..V print info > > accurate_rnd E..V accurate rounding > > full_chroma_int E..V full chroma interpolation > > full_chroma_inp E..V full chroma input > > bitexact E..V > > error_diffusion E..V error diffusion dither > > > > OK, so first, there's so many things wrong here, we're using flags as a way > > to indicate the scaling method, and mixing up boolean flags. By the way, > > did you know "experimental" is a scaling method? Fantastic help. > > > The default is "4", but we don't know what flag "4" corresponds to. > > (Just sent for this ♥) > *a patch* -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Wanted to contribute
On Sat, 24 Oct 2015 18:21:45 +0530 rishi shah wrote: > Hi ! > I wanted to contribute in FFMpeg organization. What can be the good > starting point? I have Mac OS. Here's an overview: http://ffmpeg.org/developer.html#Contributing ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Don't needlessly reinitialize ff_cos_## tables.
On Sat, 24 Oct 2015 04:13:18 +0200 Michael Niedermayer wrote: > On Thu, Oct 22, 2015 at 09:48:30PM -0700, Dale Curtis wrote: > > On Wed, Oct 21, 2015 at 6:52 PM, Dale Curtis > > wrote: > > > > > On Tue, Oct 20, 2015 at 11:50 PM, Michael Niedermayer < > > > mich...@niedermayer.cc> wrote: > > >> > > >> the last element to be written should be checked, so that if > > >> initialization is done by 2 threads at the same time, neither can > > >> return from this function without initialization having finished > > >> > > >> also the race detectors are broken if they complain about cases where > > >> a variable that has value a is set to value a, that cannot be part of > > >> a race, not even if a is written byte per byte instead of atomically > > >> unless theres something iam missing > > >> Is this something that can be fixed or disabled on the side of the > > >> race detectors? > > >> It might reduce false positives in FFmpeg and potentially other > > >> tools. > > >> > > > > > > We can suppress it, which I think is more reasonable then the overhead > > > it'd take to make this "race" go away. I notice the sin tables are > > > initialized within the fft context so there's no "race." Is there a reason > > > the cosine tables aren't done this way? > > > > > > > Actually it looks like sin may suffer from the same issues -- it doesn't > > make a copy like I was thinking it did. One of the TSAN folk detailed why > > suppression isn't a good idea here > > > https://codereview.chromium.org/1412123007/#msg7 -- which roughly says we > > can't rely on the compiler to do the right thing here. > > quite independant of the sin/cos discussion here, This statement is > IMHO somewhat problematic > It may be strictly true in a language lawyer sense but > > Lets assume that compilers did add random writes into writable arrays > as long as they restore it before the next function call or return. > like it seems assumed in the linked discussion > > Frame multithreading has one thread decoding a frame and the next > using that frame after it has been written, the individual accesses > are not protected by mutexes nor could they, it would defeat the > idea of parallel decoding ... > Now if the compiler could randomly add writes that exist nowhere in > the C code as long as the thread itself doesnt access it at that time, > then this would break. All what matters is if there are memory barriers between the accesses. So for example if one thread is done with decoding a frame, and is handed off to other threads as reference frame, then the synchronization that takes care of this "handing off" will perform the required memory barrier. Or am I getting this wrong? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH][RFC] avcodec/pthread_frame: fix null pointer dereference
On Sat, Oct 24, 2015 at 9:15 AM, Nicolas George wrote: > Le tridi 3 brumaire, an CCXXIV, Ganesh Ajjanagadde a écrit : >> Fixes CID 1322329. >> >> Signed-off-by: Ganesh Ajjanagadde >> --- >> libavcodec/pthread_frame.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c >> index 7651211..ca06e3d 100644 >> --- a/libavcodec/pthread_frame.c >> +++ b/libavcodec/pthread_frame.c >> @@ -305,7 +305,7 @@ static void release_delayed_buffers(PerThreadContext *p) >> pthread_mutex_lock(&fctx->buffer_mutex); >> >> // fix extended data in case the caller screwed it up >> -av_assert0(p->avctx->codec_type == AVMEDIA_TYPE_VIDEO || > >> +av_assert0(p->avctx && p->avctx->codec_type == AVMEDIA_TYPE_VIDEO || > > I think the commit message should explain in what circumstances p->avctx can > be NULL. Otherwise, the extra test is only hiding a problem earlier in the > code. Ok, will check in more detail. Thanks. > >> p->avctx->codec_type == AVMEDIA_TYPE_AUDIO); >> f = &p->released_buffers[--p->num_released_buffers]; >> f->extended_data = f->data; > > Regards, > > -- > Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/5] all: use function pointer instead of void * data pointer
ISO C does not guarantee that functions and data live in the same address space. It is thus (strictly speaking) illegal to assign to a void * (which is a data pointer) from a function pointer. Found by enabling -Wpedantic on clang 3.7. Signed-off-by: Ganesh Ajjanagadde --- ffmpeg_opt.c | 8 libavcodec/hevc.c | 2 +- libavfilter/vf_drawtext.c | 2 +- libavfilter/vf_lut.c | 6 +++--- libavformat/async.c | 2 +- 5 files changed, 10 insertions(+), 10 deletions(-) diff --git a/ffmpeg_opt.c b/ffmpeg_opt.c index 8f6416c..131dd89 100644 --- a/ffmpeg_opt.c +++ b/ffmpeg_opt.c @@ -3116,7 +3116,7 @@ const OptionDef options[] = { { "target", HAS_ARG | OPT_PERFILE | OPT_OUTPUT, { .func_arg = opt_target }, "specify target file type (\"vcd\", \"svcd\", \"dvd\", \"dv\" or \"dv50\" " "with optional prefixes \"pal-\", \"ntsc-\" or \"film-\")", "type" }, -{ "vsync", HAS_ARG | OPT_EXPERT,{ opt_vsync }, +{ "vsync", HAS_ARG | OPT_EXPERT,{ .func_arg = opt_vsync }, "video sync method", "" }, { "frame_drop_threshold", HAS_ARG | OPT_FLOAT | OPT_EXPERT, { &frame_drop_threshold }, "frame drop threshold", "" }, @@ -3240,9 +3240,9 @@ const OptionDef options[] = { "this option is deprecated, use the yadif filter instead" }, { "psnr", OPT_VIDEO | OPT_BOOL | OPT_EXPERT, { &do_psnr }, "calculate PSNR of compressed frames" }, -{ "vstats", OPT_VIDEO | OPT_EXPERT , { &opt_vstats }, +{ "vstats", OPT_VIDEO | OPT_EXPERT , { .func_arg = opt_vstats }, "dump video coding statistics to file" }, -{ "vstats_file", OPT_VIDEO | HAS_ARG | OPT_EXPERT , { opt_vstats_file }, +{ "vstats_file", OPT_VIDEO | HAS_ARG | OPT_EXPERT , { .func_arg = opt_vstats_file }, "dump video coding statistics to file", "file" }, { "vf", OPT_VIDEO | HAS_ARG | OPT_PERFILE | OPT_OUTPUT, { .func_arg = opt_video_filters }, "set video filters", "filter_graph" }, @@ -3352,7 +3352,7 @@ const OptionDef options[] = { "set the initial demux-decode delay", "seconds" }, { "override_ffserver", OPT_BOOL | OPT_EXPERT | OPT_OUTPUT, { &override_ffserver }, "override the options from ffserver", "" }, -{ "sdp_file", HAS_ARG | OPT_EXPERT | OPT_OUTPUT, { opt_sdp_file }, +{ "sdp_file", HAS_ARG | OPT_EXPERT | OPT_OUTPUT, { .func_arg = opt_sdp_file }, "specify a file in which to print sdp information", "file" }, { "bsf", HAS_ARG | OPT_STRING | OPT_SPEC | OPT_EXPERT | OPT_OUTPUT, { .off = OFFSET(bitstream_filters) }, diff --git a/libavcodec/hevc.c b/libavcodec/hevc.c index cd49718..4b3f199 100644 --- a/libavcodec/hevc.c +++ b/libavcodec/hevc.c @@ -2511,7 +2511,7 @@ static int hls_slice_data_wpp(HEVCContext *s, const HEVCNAL *nal) } if (s->ps.pps->entropy_coding_sync_enabled_flag) -s->avctx->execute2(s->avctx, (void *) hls_decode_entry_wpp, arg, ret, s->sh.num_entry_point_offsets + 1); +s->avctx->execute2(s->avctx, hls_decode_entry_wpp, arg, ret, s->sh.num_entry_point_offsets + 1); for (i = 0; i <= s->sh.num_entry_point_offsets; i++) res += ret[i]; diff --git a/libavfilter/vf_drawtext.c b/libavfilter/vf_drawtext.c index 8e21693..5c4676e 100644 --- a/libavfilter/vf_drawtext.c +++ b/libavfilter/vf_drawtext.c @@ -1087,7 +1087,7 @@ static int draw_glyphs(DrawTextContext *s, AVFrame *frame, continue; dummy.code = code; -glyph = av_tree_find(s->glyphs, &dummy, (void *)glyph_cmp, NULL); +glyph = av_tree_find(s->glyphs, &dummy, glyph_cmp, NULL); bitmap = borderw ? glyph->border_bitmap : glyph->bitmap; diff --git a/libavfilter/vf_lut.c b/libavfilter/vf_lut.c index 7d708f6..f0a2aba 100644 --- a/libavfilter/vf_lut.c +++ b/libavfilter/vf_lut.c @@ -186,9 +186,9 @@ static double compute_gammaval709(void *opaque, double gamma) } static double (* const funcs1[])(void *, double) = { -(void *)clip, -(void *)compute_gammaval, -(void *)compute_gammaval709, +clip, +compute_gammaval, +compute_gammaval709, NULL }; diff --git a/libavformat/async.c b/libavformat/async.c index 9fac84a..f4474b8 100644 --- a/libavformat/async.c +++ b/libavformat/async.c @@ -224,7 +224,7 @@ static void *async_buffer_task(void *arg) pthread_mutex_unlock(&c->mutex); to_copy = FFMIN(4096, fifo_space); -ret = ring_generic_write(ring, (void *)h, to_copy, (void *)wrapped_url_read); +ret = ring_generic_write(ring, (void *)h, to_copy, wrapped_url_read); pthread_mutex_lock(&c->mutex); if (ret <= 0) { -- 2.6.2 ___ ffmpeg-devel mail
[FFmpeg-devel] [PATCH 4/5] avfilter: avoid zero arguments to variadic macro
ISO C requires at least one argument in the place of the ellipsis in a variadic macro. In particular, under -pedantic, this triggers the warning -Wgnu-zero-variadic-macro-arguments on clang 3.7. Signed-off-by: Ganesh Ajjanagadde --- libavfilter/af_asetrate.c | 4 ++-- libavfilter/asrc_sine.c | 18 +- 2 files changed, 11 insertions(+), 11 deletions(-) diff --git a/libavfilter/af_asetrate.c b/libavfilter/af_asetrate.c index 409c48f..66febd7 100644 --- a/libavfilter/af_asetrate.c +++ b/libavfilter/af_asetrate.c @@ -39,8 +39,8 @@ typedef struct { OPT_GENERIC(name, field, def, min, max, descr, INT, i64, __VA_ARGS__) static const AVOption asetrate_options[] = { -OPT_INT("sample_rate", sample_rate, 44100, 1, INT_MAX, "set the sample rate"), -OPT_INT("r", sample_rate, 44100, 1, INT_MAX, "set the sample rate"), +OPT_INT("sample_rate", sample_rate, 44100, 1, INT_MAX, "set the sample rate",), +OPT_INT("r", sample_rate, 44100, 1, INT_MAX, "set the sample rate",), {NULL}, }; diff --git a/libavfilter/asrc_sine.c b/libavfilter/asrc_sine.c index cd43ae4..f361faa 100644 --- a/libavfilter/asrc_sine.c +++ b/libavfilter/asrc_sine.c @@ -67,15 +67,15 @@ typedef struct { OPT_GENERIC(name, field, def, min, max, descr, STRING, str, __VA_ARGS__) static const AVOption sine_options[] = { -OPT_DBL("frequency", frequency,440, 0, DBL_MAX, "set the sine frequency"), -OPT_DBL("f", frequency,440, 0, DBL_MAX, "set the sine frequency"), -OPT_DBL("beep_factor", beep_factor,0, 0, DBL_MAX, "set the beep fequency factor"), -OPT_DBL("b", beep_factor,0, 0, DBL_MAX, "set the beep fequency factor"), -OPT_INT("sample_rate", sample_rate,44100, 1, INT_MAX, "set the sample rate"), -OPT_INT("r", sample_rate,44100, 1, INT_MAX, "set the sample rate"), -OPT_DUR("duration", duration, 0, 0, INT64_MAX, "set the audio duration"), -OPT_DUR("d", duration, 0, 0, INT64_MAX, "set the audio duration"), -OPT_STR("samples_per_frame", samples_per_frame, "1024", 0, 0, "set the number of samples per frame"), +OPT_DBL("frequency", frequency,440, 0, DBL_MAX, "set the sine frequency",), +OPT_DBL("f", frequency,440, 0, DBL_MAX, "set the sine frequency",), +OPT_DBL("beep_factor", beep_factor,0, 0, DBL_MAX, "set the beep fequency factor",), +OPT_DBL("b", beep_factor,0, 0, DBL_MAX, "set the beep fequency factor",), +OPT_INT("sample_rate", sample_rate,44100, 1, INT_MAX, "set the sample rate",), +OPT_INT("r", sample_rate,44100, 1, INT_MAX, "set the sample rate",), +OPT_DUR("duration", duration, 0, 0, INT64_MAX, "set the audio duration",), +OPT_DUR("d", duration, 0, 0, INT64_MAX, "set the audio duration",), +OPT_STR("samples_per_frame", samples_per_frame, "1024", 0, 0, "set the number of samples per frame",), {NULL} }; -- 2.6.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 5/5] all: fix enum definition for large values
ISO C restricts enumerator values to the range of int. Thus (for instance) 0x8000 unfortunately does not work, and throws a warning with -Wpedantic on clang 3.7. This fixes such errors by explicitly casting as an int, doing the desired unsigned to signed conversion. This method works on all current architectures. Tested with FATE. Signed-off-by: Ganesh Ajjanagadde --- libavcodec/dca_syncwords.h | 24 libavformat/cinedec.c | 8 libavformat/mov_chan.c | 2 +- 3 files changed, 17 insertions(+), 17 deletions(-) diff --git a/libavcodec/dca_syncwords.h b/libavcodec/dca_syncwords.h index 3466b6b..a2ff313 100644 --- a/libavcodec/dca_syncwords.h +++ b/libavcodec/dca_syncwords.h @@ -20,18 +20,18 @@ #define AVCODEC_DCA_SYNCWORDS_H enum DCASyncwords { -DCA_SYNCWORD_CORE_BE= 0x7FFE8001U, -DCA_SYNCWORD_CORE_LE= 0xFE7F0180U, -DCA_SYNCWORD_CORE_14B_BE= 0x1FFFE800U, -DCA_SYNCWORD_CORE_14B_LE= 0xFF1F00E8U, -DCA_SYNCWORD_XCH= 0x5A5A5A5AU, -DCA_SYNCWORD_XXCH = 0x47004A03U, -DCA_SYNCWORD_X96= 0x1D95F262U, -DCA_SYNCWORD_XBR= 0x655E315EU, -DCA_SYNCWORD_LBR= 0x0A801921U, -DCA_SYNCWORD_XLL= 0x41A29547U, -DCA_SYNCWORD_SUBSTREAM = 0x64582025U, -DCA_SYNCWORD_SUBSTREAM_CORE = 0x02B09261U, +DCA_SYNCWORD_CORE_BE= 0x7FFE8001U, +DCA_SYNCWORD_CORE_LE= (int)0xFE7F0180U, +DCA_SYNCWORD_CORE_14B_BE= 0x1FFFE800U, +DCA_SYNCWORD_CORE_14B_LE= (int)0xFF1F00E8U, +DCA_SYNCWORD_XCH= 0x5A5A5A5AU, +DCA_SYNCWORD_XXCH = 0x47004A03U, +DCA_SYNCWORD_X96= 0x1D95F262U, +DCA_SYNCWORD_XBR= 0x655E315EU, +DCA_SYNCWORD_LBR= 0x0A801921U, +DCA_SYNCWORD_XLL= 0x41A29547U, +DCA_SYNCWORD_SUBSTREAM = 0x64582025U, +DCA_SYNCWORD_SUBSTREAM_CORE = 0x02B09261U, }; #endif /* AVCODEC_DCA_SYNCWORDS_H */ diff --git a/libavformat/cinedec.c b/libavformat/cinedec.c index 632f46c..9a9023e 100644 --- a/libavformat/cinedec.c +++ b/libavformat/cinedec.c @@ -50,10 +50,10 @@ enum { CFA_BAYER = 3, /**< GB/RG */ CFA_BAYERFLIP = 4, /**< RG/GB */ -CFA_TLGRAY= 0x8000, -CFA_TRGRAY= 0x4000, -CFA_BLGRAY= 0x2000, -CFA_BRGRAY= 0x1000 +CFA_TLGRAY= (int)0x8000, +CFA_TRGRAY= 0x4000, +CFA_BLGRAY= 0x2000, +CFA_BRGRAY= 0x1000 }; static int cine_read_probe(AVProbeData *p) diff --git a/libavformat/mov_chan.c b/libavformat/mov_chan.c index a2fa8d6..cb91a05 100644 --- a/libavformat/mov_chan.c +++ b/libavformat/mov_chan.c @@ -45,7 +45,7 @@ *do not specify a particular ordering of those channels." */ enum MovChannelLayoutTag { -MOV_CH_LAYOUT_UNKNOWN = 0x, +MOV_CH_LAYOUT_UNKNOWN = (int)0x, MOV_CH_LAYOUT_USE_DESCRIPTIONS = ( 0 << 16) | 0, MOV_CH_LAYOUT_USE_BITMAP= ( 1 << 16) | 0, MOV_CH_LAYOUT_DISCRETEINORDER = (147 << 16) | 0, -- 2.6.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/5] avfilter: avoid zero arguments to variadic macro
Le tridi 3 brumaire, an CCXXIV, Ganesh Ajjanagadde a écrit : > ISO C requires at least one argument in the place of the ellipsis in a > variadic macro. In particular, under -pedantic, this triggers the > warning -Wgnu-zero-variadic-macro-arguments on clang 3.7. > > Signed-off-by: Ganesh Ajjanagadde > --- > libavfilter/af_asetrate.c | 4 ++-- > libavfilter/asrc_sine.c | 18 +- > 2 files changed, 11 insertions(+), 11 deletions(-) Ok. Good catch. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/5] all: fix -Wextra-semi reported on clang
Hi all, Apologies for the copy/pasted patch, but can't send via send-email. Copy pasted for review below, attached also for a non-clobbered version. -- >From 82b889a359925d1f9f7496c916cf24146b44e648 Mon Sep 17 00:00:00 2001 From: Ganesh Ajjanagadde Date: Fri, 23 Oct 2015 11:23:42 -0400 Subject: [PATCH 1/5] all: fix -Wextra-semi reported on clang This fixes extra semicolons that clang 3.7 on GNU/Linux warns about. These were trigggered when built under -Wpedantic, which essentially checks for strict ISO compliance in numerous ways. Signed-off-by: Ganesh Ajjanagadde --- ffprobe.c | 20 +- libavcodec/x86/hevcdsp_init.c | 637 ++-- libavcodec/x86/rv40dsp_init.c | 2 +- libavcodec/x86/vp9dsp_init.c| 14 +- libavcodec/x86/vp9dsp_init.h| 6 +- libavcodec/x86/vp9dsp_init_16bpp_template.c | 36 +- libavdevice/alsa.c | 6 +- 7 files changed, 358 insertions(+), 363 deletions(-) diff --git a/ffprobe.c b/ffprobe.c index ac03689..00584d2 100644 --- a/ffprobe.c +++ b/ffprobe.c @@ -3062,16 +3062,16 @@ static int opt_show_versions(const char *opt, const char *arg) return 0; \ } -DEFINE_OPT_SHOW_SECTION(chapters, CHAPTERS); -DEFINE_OPT_SHOW_SECTION(error,ERROR); -DEFINE_OPT_SHOW_SECTION(format, FORMAT); -DEFINE_OPT_SHOW_SECTION(frames, FRAMES); -DEFINE_OPT_SHOW_SECTION(library_versions, LIBRARY_VERSIONS); -DEFINE_OPT_SHOW_SECTION(packets, PACKETS); -DEFINE_OPT_SHOW_SECTION(pixel_formats,PIXEL_FORMATS); -DEFINE_OPT_SHOW_SECTION(program_version, PROGRAM_VERSION); -DEFINE_OPT_SHOW_SECTION(streams, STREAMS); -DEFINE_OPT_SHOW_SECTION(programs, PROGRAMS); +DEFINE_OPT_SHOW_SECTION(chapters, CHAPTERS) +DEFINE_OPT_SHOW_SECTION(error,ERROR) +DEFINE_OPT_SHOW_SECTION(format, FORMAT) +DEFINE_OPT_SHOW_SECTION(frames, FRAMES) +DEFINE_OPT_SHOW_SECTION(library_versions, LIBRARY_VERSIONS) +DEFINE_OPT_SHOW_SECTION(packets, PACKETS) +DEFINE_OPT_SHOW_SECTION(pixel_formats,PIXEL_FORMATS) +DEFINE_OPT_SHOW_SECTION(program_version, PROGRAM_VERSION) +DEFINE_OPT_SHOW_SECTION(streams, STREAMS) +DEFINE_OPT_SHOW_SECTION(programs, PROGRAMS) static const OptionDef real_options[] = { #include "cmdutils_common_opts.h" diff --git a/libavcodec/x86/hevcdsp_init.c b/libavcodec/x86/hevcdsp_init.c index ddc876d..2181f6d 100644 --- a/libavcodec/x86/hevcdsp_init.c +++ b/libavcodec/x86/hevcdsp_init.c @@ -119,8 +119,8 @@ void ff_hevc_put_hevc_bi_##name##W##_##bitd##_##opt(uint8_t *_dst, ptrdiff_t dst } #define mc_rep_funcs(name, bitd, step, W, opt)\ -mc_rep_func(name, bitd, step, W, opt);\ -mc_rep_uni_func(name, bitd, step, W, opt);\ +mc_rep_func(name, bitd, step, W, opt)\ +mc_rep_uni_func(name, bitd, step, W, opt)\ mc_rep_bi_func(name, bitd, step, W, opt) #define mc_rep_func2(name, bitd, step1, step2, W, opt) \ @@ -153,14 +153,9 @@ void ff_hevc_put_hevc_bi_##name##W##_##bitd##_##opt(uint8_t *dst, ptrdiff_t dsts src2 + step1, height, mx, my, width);\ } -#define mc_rep_funcs(name, bitd, step, W, opt)\ -mc_rep_func(name, bitd, step, W, opt);\ -mc_rep_uni_func(name, bitd, step, W, opt);\ -mc_rep_bi_func(name, bitd, step, W, opt) - #define mc_rep_funcs2(name, bitd, step1, step2, W, opt) \ -mc_rep_func2(name, bitd, step1, step2, W, opt); \ -mc_rep_uni_func2(name, bitd, step1, step2, W, opt); \ +mc_rep_func2(name, bitd, step1, step2, W, opt) \ +mc_rep_uni_func2(name, bitd, step1, step2, W, opt) \ mc_rep_bi_func2(name, bitd, step1, step2, W, opt) #if ARCH_X86_64 && HAVE_SSE4_EXTERNAL @@ -196,9 +191,9 @@ void ff_hevc_put_hevc_uni_##name##width1##_10_##opt1(uint8_t *dst, ptrdiff_t dst height, mx, my, width); \ } -#define mc_rep_mixs_10(name, width1, width2, width3, opt1, opt2, width4)\ -mc_rep_mix_10(name, width1, width2, width3, opt1, opt2, width4);\ -mc_bi_rep_mix_10(name, width1, width2, width3, opt1, opt2, width4); \ +#define mc_rep_mixs_10(name, width1, width2, width3, opt1, opt2, width4) \ +mc_rep_mix_10(name, width1, width2, width3, opt1, opt2, width4)\ +mc_bi_rep_mix_10(name, width1, width2, width3, opt1, opt2, width4) \ mc_uni_rep_mix_10(name, width1, width2, width3, opt1, opt2, width4) #define mc_rep_mix_8(name, width1, width2, width3, opt1, opt2) \ @@ -232,199 +227,199 @@ void ff_hevc_put_hevc_uni_##name##width1##_8_##opt1(uint8_t
[FFmpeg-devel] [PATCH 2/5] all: fix incorrect usage of %p format specifier
Hi all, Apologies for the copy/pasted patch, but can't send via send-email. Copy pasted for review below, attached also for a non-clobbered version. -- >From 99cd052b614553757efa1954bf8bf4dd3caf66d0 Mon Sep 17 00:00:00 2001 From: Ganesh Ajjanagadde Date: Fri, 23 Oct 2015 11:59:40 -0400 Subject: [PATCH 2/5] all: fix incorrect usage of %p format specifier ISO C %p format specifier applies to void * data pointers. This casts relevant pointers to void * in order to be strictly correct C. Found by -Wpedantic on clang 3.7 (in particular -Wformat-pedantic). Signed-off-by: Ganesh Ajjanagadde --- libavcodec/alsdec.c | 8 libavcodec/h264_refs.c | 6 +++--- libavcodec/libopencore-amr.c | 2 +- libavcodec/mjpegdec.c| 2 +- libavcodec/mpegpicture.c | 2 +- libavcodec/mpegvideo.c | 8 libavcodec/options.c | 2 +- libavcodec/pthread_frame.c | 6 +++--- libavcodec/utils.c | 4 ++-- libavcodec/vaapi_h264.c | 2 +- libavcodec/vaapi_hevc.c | 2 +- libavcodec/vaapi_mpeg2.c | 2 +- libavcodec/vaapi_mpeg4.c | 2 +- libavcodec/vaapi_vc1.c | 2 +- libavcodec/vorbisdec.c | 2 +- libavfilter/avfilter.c | 6 +++--- libavformat/asfdec_f.c | 2 +- libavformat/rtpdec_h264.c| 2 +- libavformat/utils.c | 2 +- libswscale/swscale.c | 8 20 files changed, 36 insertions(+), 36 deletions(-) diff --git a/libavcodec/alsdec.c b/libavcodec/alsdec.c index ebd364e..19bdbbd 100644 --- a/libavcodec/alsdec.c +++ b/libavcodec/alsdec.c @@ -1308,8 +1308,8 @@ static int revert_channel_correlation(ALSDecContext *ctx, ALSBlockData *bd, FFMAX(end + 1, end + 1 + t) > ctx->raw_buffer + channels * channel_size - master) { av_log(ctx->avctx, AV_LOG_ERROR, "sample pointer range [%p, %p] not contained in raw_buffer [%p, %p].\n", - master + FFMIN(begin - 1, begin - 1 + t), master + FFMAX(end + 1, end + 1 + t), - ctx->raw_buffer, ctx->raw_buffer + channels * channel_size); + (void *)(master + FFMIN(begin - 1, begin - 1 + t)), (void *)(master + FFMAX(end + 1, end + 1 + t)), + (void *)ctx->raw_buffer, (void *)(ctx->raw_buffer + channels * channel_size)); return AVERROR_INVALIDDATA; } @@ -1330,8 +1330,8 @@ static int revert_channel_correlation(ALSDecContext *ctx, ALSBlockData *bd, end + 1 > ctx->raw_buffer + channels * channel_size - master) { av_log(ctx->avctx, AV_LOG_ERROR, "sample pointer range [%p, %p] not contained in raw_buffer [%p, %p].\n", - master + begin - 1, master + end + 1, - ctx->raw_buffer, ctx->raw_buffer + channels * channel_size); + (void *)(master + begin - 1), (void *)(master + end + 1), + (void *)(ctx->raw_buffer), (void *)(ctx->raw_buffer + channels * channel_size)); return AVERROR_INVALIDDATA; } diff --git a/libavcodec/h264_refs.c b/libavcodec/h264_refs.c index 619f2ed..da6e7fd 100644 --- a/libavcodec/h264_refs.c +++ b/libavcodec/h264_refs.c @@ -437,7 +437,7 @@ static H264Picture *find_short(H264Context *h, int frame_num, int *idx) for (i = 0; i < h->short_ref_count; i++) { H264Picture *pic = h->short_ref[i]; if (h->avctx->debug & FF_DEBUG_MMCO) -av_log(h->avctx, AV_LOG_DEBUG, "%d %d %p\n", i, pic->frame_num, pic); +av_log(h->avctx, AV_LOG_DEBUG, "%d %d %p\n", i, pic->frame_num, (void *)pic); if (pic->frame_num == frame_num) { *idx = i; return pic; @@ -543,7 +543,7 @@ static void print_short_term(H264Context *h) for (i = 0; i < h->short_ref_count; i++) { H264Picture *pic = h->short_ref[i]; av_log(h->avctx, AV_LOG_DEBUG, "%"PRIu32" fn:%d poc:%d %p\n", - i, pic->frame_num, pic->poc, pic->f->data[0]); + i, pic->frame_num, pic->poc, (void *)pic->f->data[0]); } } } @@ -560,7 +560,7 @@ static void print_long_term(H264Context *h) H264Picture *pic = h->long_ref[i]; if (pic) { av_log(h->avctx, AV_LOG_DEBUG, "%"PRIu32" fn:%d poc:%d %p\n", - i, pic->frame_num, pic->poc, pic->f->data[0]); + i, pic->frame_num, pic->poc, (void *)pic->f->data[0]); } } } diff --git a/libavcodec/libopencore-amr.c b/libavcodec/libopencore-amr.c index f0e3426..850ad94 100644 --- a/libavcodec/libopencore-amr.c +++ b/libavcodec/libopencore-amr.c @@ -100,7 +100,7 @@ static int amr_nb_decode_frame(AVCodecContext *avctx, void *data, int packet_size, ret; ff_dlog(avctx, "amr_decode_frame buf=%p buf_size=%d frame_cou
Re: [FFmpeg-devel] [PATCH 4/5] avfilter: avoid zero arguments to variadic macro
On Sat, Oct 24, 2015 at 9:33 AM, Nicolas George wrote: > Le tridi 3 brumaire, an CCXXIV, Ganesh Ajjanagadde a écrit : >> ISO C requires at least one argument in the place of the ellipsis in a >> variadic macro. In particular, under -pedantic, this triggers the >> warning -Wgnu-zero-variadic-macro-arguments on clang 3.7. >> >> Signed-off-by: Ganesh Ajjanagadde >> --- >> libavfilter/af_asetrate.c | 4 ++-- >> libavfilter/asrc_sine.c | 18 +- >> 2 files changed, 11 insertions(+), 11 deletions(-) > > Ok. Good catch. Thanks for the super quick review. Will apply shortly. Do you (or others) think adding -Wgnu-zero-variadic-macro-arguments to configure is a good idea? > > Regards, > > -- > Nicolas George > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/5] all: fix incorrect usage of %p format specifier
Le tridi 3 brumaire, an CCXXIV, Ganesh Ajjanagadde a écrit : > Apologies for the copy/pasted patch, but can't send via send-email. Maybe you should take some time to tackle your email troubles? > ISO C %p format specifier applies to void * data pointers. This casts > relevant pointers to void * in order to be strictly correct C. > > Found by -Wpedantic on clang 3.7 (in particular -Wformat-pedantic). I am rather against this change, it makes the code significantly less readable, and this instance I see zero chances of it fixing an actual issue any time. There is a reason these warnings are called "pedantic": there are often irrelevant. Regards, -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/5] all: fix incorrect usage of %p format specifier
On Sat, Oct 24, 2015 at 9:44 AM, Nicolas George wrote: > Le tridi 3 brumaire, an CCXXIV, Ganesh Ajjanagadde a écrit : >> Apologies for the copy/pasted patch, but can't send via send-email. > > Maybe you should take some time to tackle your email troubles? > >> ISO C %p format specifier applies to void * data pointers. This casts >> relevant pointers to void * in order to be strictly correct C. >> >> Found by -Wpedantic on clang 3.7 (in particular -Wformat-pedantic). > > I am rather against this change, it makes the code significantly less > readable, and this instance I see zero chances of it fixing an actual issue > any time. > > There is a reason these warnings are called "pedantic": there are often > irrelevant. Indeed, part of the goal of this patch series was to see which ones people like. Consider the patch dropped unless others have something else to say about it. > > Regards, > > -- > Nicolas George > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/5] avfilter: avoid zero arguments to variadic macro
Le tridi 3 brumaire, an CCXXIV, Ganesh Ajjanagadde a écrit : > Thanks for the super quick review. Will apply shortly. Do you (or > others) think adding -Wgnu-zero-variadic-macro-arguments to configure > is a good idea? Considering that each additional option takes ~15 ms in configure on a fairly powerful box, not counting maintenance burden, I would say rather no. Let us enable by default warnings that detect common or sever mistakes, extra warnings can be enabled manually once in a while to check for harmless mistakes. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv2 1/2] ffplay: use a separate struct for the rescaled YUVA AVSubtitle rectangles
On Sat, 24 Oct 2015, Marton Balint wrote: Current code segfaults since the deprecation of AVSubtitleRect.pict because it freed/realloced AVSubtitleRect.pict.data by itself. The new code stores the generated YUVA AVSubtitle rectangles in their own struct and keeps the original AVSubtitle structure untouched, because overwriting it is considered invalid API usage. Signed-off-by: Marton Balint --- ffplay.c | 48 ++-- 1 file changed, 26 insertions(+), 22 deletions(-) Applied. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] libzvbi-teletextdec: fix AVSubtitleRect pict compatiblity code
On Fri, 23 Oct 2015, Marton Balint wrote: Only set pict if we got a valid rect. Signed-off-by: Marton Balint --- libavcodec/libzvbi-teletextdec.c | 15 +++ 1 file changed, 7 insertions(+), 8 deletions(-) Applied. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/5] avfilter: avoid zero arguments to variadic macro
On Sat, Oct 24, 2015 at 9:52 AM, Nicolas George wrote: > Le tridi 3 brumaire, an CCXXIV, Ganesh Ajjanagadde a écrit : >> Thanks for the super quick review. Will apply shortly. Do you (or >> others) think adding -Wgnu-zero-variadic-macro-arguments to configure >> is a good idea? > > Considering that each additional option takes ~15 ms in configure on a > fairly powerful box, not counting maintenance burden, I would say rather no. > > Let us enable by default warnings that detect common or sever mistakes, > extra warnings can be enabled manually once in a while to check for harmless > mistakes. ok, agreed. Someone (if they feel these things are useful) can set up a FATE client with them that sporadically runs, similar to the sanitizer builds. Of course, it can be done in an unsystematic way (like the way I did here) instead. > > Regards, > > -- > Nicolas George > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/5] avfilter: avoid zero arguments to variadic macro
On Sat, Oct 24, 2015 at 10:16 AM, Ganesh Ajjanagadde wrote: > On Sat, Oct 24, 2015 at 9:52 AM, Nicolas George wrote: >> Le tridi 3 brumaire, an CCXXIV, Ganesh Ajjanagadde a écrit : >>> Thanks for the super quick review. Will apply shortly. Do you (or >>> others) think adding -Wgnu-zero-variadic-macro-arguments to configure >>> is a good idea? >> >> Considering that each additional option takes ~15 ms in configure on a >> fairly powerful box, not counting maintenance burden, I would say rather no. >> >> Let us enable by default warnings that detect common or sever mistakes, >> extra warnings can be enabled manually once in a while to check for harmless >> mistakes. > > ok, agreed. Someone (if they feel these things are useful) can set up > a FATE client with them that sporadically runs, similar to the > sanitizer builds. Of course, it can be done in an unsystematic way > (like the way I did here) instead. pushed > >> >> Regards, >> >> -- >> Nicolas George >> >> ___ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH][RFC] avcodec/pthread_frame: fix null pointer dereference
On Sat, Oct 24, 2015 at 3:26 PM, Ganesh Ajjanagadde wrote: > On Sat, Oct 24, 2015 at 9:15 AM, Nicolas George wrote: >> Le tridi 3 brumaire, an CCXXIV, Ganesh Ajjanagadde a écrit : >>> Fixes CID 1322329. >>> >>> Signed-off-by: Ganesh Ajjanagadde >>> --- >>> libavcodec/pthread_frame.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c >>> index 7651211..ca06e3d 100644 >>> --- a/libavcodec/pthread_frame.c >>> +++ b/libavcodec/pthread_frame.c >>> @@ -305,7 +305,7 @@ static void release_delayed_buffers(PerThreadContext *p) >>> pthread_mutex_lock(&fctx->buffer_mutex); >>> >>> // fix extended data in case the caller screwed it up >>> -av_assert0(p->avctx->codec_type == AVMEDIA_TYPE_VIDEO || >> >>> +av_assert0(p->avctx && p->avctx->codec_type == AVMEDIA_TYPE_VIDEO >>> || >> >> I think the commit message should explain in what circumstances p->avctx can >> be NULL. Otherwise, the extra test is only hiding a problem earlier in the >> code. > > Ok, will check in more detail. Thanks. > More the the point, if this actually can be NULL, then an assert is not what should check that, since asserts are just like crashes (even if safer from a security point) If it can't be NULL, then it seems like a false positive. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/5] all: use function pointer instead of void * data pointer
On Sat, 24 Oct 2015 09:28:52 -0400 Ganesh Ajjanagadde wrote: > ISO C does not guarantee that functions and data live in the same > address space. It is thus (strictly speaking) illegal to assign to a POSIX does. > void * (which is a data pointer) from a function pointer. > > Found by enabling -Wpedantic on clang 3.7. > > Signed-off-by: Ganesh Ajjanagadde ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/5] all: use function pointer instead of void * data pointer
On Sat, Oct 24, 2015 at 11:01 AM, wm4 wrote: > On Sat, 24 Oct 2015 09:28:52 -0400 > Ganesh Ajjanagadde wrote: > >> ISO C does not guarantee that functions and data live in the same >> address space. It is thus (strictly speaking) illegal to assign to a > > POSIX does. Ok. You do not think that the removal of the casts improves readability (ignoring the ISO C part)? > >> void * (which is a data pointer) from a function pointer. >> >> Found by enabling -Wpedantic on clang 3.7. >> >> Signed-off-by: Ganesh Ajjanagadde > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 5/5] all: fix enum definition for large values
On Sat, 24 Oct 2015 09:29:23 -0400 Ganesh Ajjanagadde wrote: > ISO C restricts enumerator values to the range of int. Thus (for instance) > 0x8000 > unfortunately does not work, and throws a warning with -Wpedantic on > clang 3.7. > > This fixes such errors by explicitly casting as an int, doing the > desired unsigned to signed conversion. This method works on all current > architectures. Tested with FATE. > What is the point of trying to fix warnings with -Wpedantic? We don't even use this flag. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/5] all: fix incorrect usage of %p format specifier
On Sat, 24 Oct 2015 09:35:48 -0400 Ganesh Ajjanagadde wrote: > Hi all, > > Apologies for the copy/pasted patch, but can't send via send-email. > Copy pasted for review below, attached also for a non-clobbered > version. > > -- > > From 99cd052b614553757efa1954bf8bf4dd3caf66d0 Mon Sep 17 00:00:00 2001 > From: Ganesh Ajjanagadde > Date: Fri, 23 Oct 2015 11:59:40 -0400 > Subject: [PATCH 2/5] all: fix incorrect usage of %p format specifier > > ISO C %p format specifier applies to void * data pointers. This casts > relevant pointers to void * in order to be strictly correct C. > > Found by -Wpedantic on clang 3.7 (in particular -Wformat-pedantic). > > Signed-off-by: Ganesh Ajjanagadde Utterly pointless and ugly. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 5/5] all: fix enum definition for large values
On Sat, Oct 24, 2015 at 11:08 AM, wm4 wrote: > On Sat, 24 Oct 2015 09:29:23 -0400 > Ganesh Ajjanagadde wrote: > >> ISO C restricts enumerator values to the range of int. Thus (for instance) >> 0x8000 >> unfortunately does not work, and throws a warning with -Wpedantic on >> clang 3.7. >> >> This fixes such errors by explicitly casting as an int, doing the >> desired unsigned to signed conversion. This method works on all current >> architectures. Tested with FATE. >> > > What is the point of trying to fix warnings with -Wpedantic? We don't > even use this flag. We don't. There are some things it shows that needed fixing (e.g the variadic macros thing), some things which may improve readability, some things which are highly subjective, and some things which are utterly useless. As an example of the useless things that I did not bother at all with, ISO C99 only guarantees correct handling of string literals only up to 4095 characters (C89 was ~500, forgot the number). Clang has -Woverlength-strings for this. This is completely pointless in my view, even though (as you can clearly tell), I fall on the more conservative end with respect to warnings. You may ask: why do I even bother with all this? I would like to know/understand C better, and seeing what ISO does and does not guarantee is educative for me. The fact that FFmpeg can (sometimes) benefit, e.g via the variadic macros thing, is a side benefit. > _ __ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/5] all: fix incorrect usage of %p format specifier
On Sat, Oct 24, 2015 at 9:44 AM, Nicolas George wrote: > Le tridi 3 brumaire, an CCXXIV, Ganesh Ajjanagadde a écrit : >> Apologies for the copy/pasted patch, but can't send via send-email. > > Maybe you should take some time to tackle your email troubles? I have spent some time on this. Given up on gmail, as it is not in my control, and is inconsistent. I have tried following my university's mail configuration, but it does not work. Will need to speak with them at some point. Until then, I view this is a reasonable compromise for large patches. > >> ISO C %p format specifier applies to void * data pointers. This casts >> relevant pointers to void * in order to be strictly correct C. >> >> Found by -Wpedantic on clang 3.7 (in particular -Wformat-pedantic). > > I am rather against this change, it makes the code significantly less > readable, and this instance I see zero chances of it fixing an actual issue > any time. > > There is a reason these warnings are called "pedantic": there are often > irrelevant. > > Regards, > > -- > Nicolas George > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/5] all: fix incorrect usage of %p format specifier
On Sat, Oct 24, 2015 at 5:29 PM, Ganesh Ajjanagadde wrote: > On Sat, Oct 24, 2015 at 9:44 AM, Nicolas George wrote: >> Le tridi 3 brumaire, an CCXXIV, Ganesh Ajjanagadde a écrit : >>> Apologies for the copy/pasted patch, but can't send via send-email. >> >> Maybe you should take some time to tackle your email troubles? > > I have spent some time on this. Given up on gmail, as it is not in my > control, and is inconsistent. I have tried following my university's > mail configuration, but it does not work. Will need to speak with them > at some point. Until then, I view this is a reasonable compromise for > large patches. > I've never had a problem sending any size of patch using gmail's smtp server. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/5] all: fix incorrect usage of %p format specifier
Le tridi 3 brumaire, an CCXXIV, Ganesh Ajjanagadde a écrit : > I have spent some time on this. Given up on gmail, as it is not in my > control, and is inconsistent. I have tried following my university's > mail configuration, but it does not work. Will need to speak with them > at some point. Until then, I view this is a reasonable compromise for > large patches. I am rather surprised by your troubles with gmail. You are definitely not the only person using it, but you are the only one I heard have trouble at this kind of level. And this is not the only issue. A decent MUA should not mangle patches, even copy-pasted ones. We can not urge random contributors to completely change their habits, but since you are obviously here to stay, you should certainly make sure you use good tools as soon as possible. Anyway, this was just advice, but I stick to it: you can probably get things working by yourself (possibly with help, but without requiring intervention from administrators), and I believe you would gain time overall by addressing it as soon as possible. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] videodsp: don't overread edges in vfix3 emu_edge.
On 24.10.2015 14:47, Ronald S. Bultje wrote: > --- > libavcodec/x86/videodsp.asm | 15 +++ > 1 file changed, 11 insertions(+), 4 deletions(-) > > diff --git a/libavcodec/x86/videodsp.asm b/libavcodec/x86/videodsp.asm > index 25d4364..48f5ac0 100644 > --- a/libavcodec/x86/videodsp.asm > +++ b/libavcodec/x86/videodsp.asm > @@ -194,8 +194,12 @@ hvar_fn > %elif (%2-%%off) == 2 > movvalw, [srcq+%2-2] > %elifidn %1, body > -movvald, [srcq+%2-3] > -%else > +movvalb, [srcq+%2-1] > +salvald, 16 > +movvalw, [srcq+%2-3] > +%elifidn %1, bottom > +movd mm %+ %%mmx_idx, [srcq+%2-4] > +%else ; top > movd mm %+ %%mmx_idx, [srcq+%2-3] > %endif > %endif ; (%2-%%off) >= 1 > @@ -251,12 +255,15 @@ hvar_fn > mov [dstq+%2-2], valw > %elifidn %1, body > mov [dstq+%2-3], valw > -shrvald, 16 > +sarvald, 16 > mov [dstq+%2-1], valb > %else > movd vald, mm %+ %%mmx_idx > +%ifidn %1, bottom > +sarvald, 8 > +%endif > mov [dstq+%2-3], valw > -shrvald, 16 > +sarvald, 16 > mov [dstq+%2-1], valb > %endif > %endif ; (%2-%%off) >= 1 > This fixes the crash and passes FATE, so looks good to me. Maybe mention the bug report in the commit message, e.g.: Bug-Debian: https://bugs.debian.org/801745 Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] videodsp: don't overread edges in vfix3 emu_edge.
Hi Andreas, On Sat, Oct 24, 2015 at 11:41 AM, Andreas Cadhalpun < andreas.cadhal...@googlemail.com> wrote: > On 24.10.2015 14:47, Ronald S. Bultje wrote: > > --- > > libavcodec/x86/videodsp.asm | 15 +++ > > 1 file changed, 11 insertions(+), 4 deletions(-) > > > > diff --git a/libavcodec/x86/videodsp.asm b/libavcodec/x86/videodsp.asm > > index 25d4364..48f5ac0 100644 > > --- a/libavcodec/x86/videodsp.asm > > +++ b/libavcodec/x86/videodsp.asm > > @@ -194,8 +194,12 @@ hvar_fn > > %elif (%2-%%off) == 2 > > movvalw, [srcq+%2-2] > > %elifidn %1, body > > -movvald, [srcq+%2-3] > > -%else > > +movvalb, [srcq+%2-1] > > +salvald, 16 > > +movvalw, [srcq+%2-3] > > +%elifidn %1, bottom > > +movd mm %+ %%mmx_idx, [srcq+%2-4] > > +%else ; top > > movd mm %+ %%mmx_idx, [srcq+%2-3] > > %endif > > %endif ; (%2-%%off) >= 1 > > @@ -251,12 +255,15 @@ hvar_fn > > mov [dstq+%2-2], valw > > %elifidn %1, body > > mov [dstq+%2-3], valw > > -shrvald, 16 > > +sarvald, 16 > > mov [dstq+%2-1], valb > > %else > > movd vald, mm %+ %%mmx_idx > > +%ifidn %1, bottom > > +sarvald, 8 > > +%endif > > mov [dstq+%2-3], valw > > -shrvald, 16 > > +sarvald, 16 > > mov [dstq+%2-1], valb > > %endif > > %endif ; (%2-%%off) >= 1 > > > > This fixes the crash and passes FATE, so looks good to me. > Maybe mention the bug report in the commit message, e.g.: > Bug-Debian: https://bugs.debian.org/801745 Thanks for testing, so this does actually fix the bug? Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] videodsp: don't overread edges in vfix3 emu_edge.
Hi Ronald, On 24.10.2015 17:55, Ronald S. Bultje wrote: > On Sat, Oct 24, 2015 at 11:41 AM, Andreas Cadhalpun < > andreas.cadhal...@googlemail.com> wrote: > >> On 24.10.2015 14:47, Ronald S. Bultje wrote: >>> --- >>> libavcodec/x86/videodsp.asm | 15 +++ >>> 1 file changed, 11 insertions(+), 4 deletions(-) >>> >>> diff --git a/libavcodec/x86/videodsp.asm b/libavcodec/x86/videodsp.asm >>> index 25d4364..48f5ac0 100644 >>> --- a/libavcodec/x86/videodsp.asm >>> +++ b/libavcodec/x86/videodsp.asm >>> @@ -194,8 +194,12 @@ hvar_fn >>> %elif (%2-%%off) == 2 >>> movvalw, [srcq+%2-2] >>> %elifidn %1, body >>> -movvald, [srcq+%2-3] >>> -%else >>> +movvalb, [srcq+%2-1] >>> +salvald, 16 >>> +movvalw, [srcq+%2-3] >>> +%elifidn %1, bottom >>> +movd mm %+ %%mmx_idx, [srcq+%2-4] >>> +%else ; top >>> movd mm %+ %%mmx_idx, [srcq+%2-3] >>> %endif >>> %endif ; (%2-%%off) >= 1 >>> @@ -251,12 +255,15 @@ hvar_fn >>> mov [dstq+%2-2], valw >>> %elifidn %1, body >>> mov [dstq+%2-3], valw >>> -shrvald, 16 >>> +sarvald, 16 >>> mov [dstq+%2-1], valb >>> %else >>> movd vald, mm %+ %%mmx_idx >>> +%ifidn %1, bottom >>> +sarvald, 8 >>> +%endif >>> mov [dstq+%2-3], valw >>> -shrvald, 16 >>> +sarvald, 16 >>> mov [dstq+%2-1], valb >>> %endif >>> %endif ; (%2-%%off) >= 1 >>> >> >> This fixes the crash and passes FATE, so looks good to me. >> Maybe mention the bug report in the commit message, e.g.: >> Bug-Debian: https://bugs.debian.org/801745 > > > Thanks for testing, so this does actually fix the bug? Yes, at least I couldn't reproduce the crash anymore with this patch applied. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Can we drop OpenJPEG 1.5 in favor of 2.x?
tl;dr: I've got a patch that updates OpenJPEG to 2.0/2.1. Currently, I've opted to drop OpenJPEG 1.5. Should I proceed with preparing this patch for submission, or should I alter it to keep 1.5 support? The OpenJPEG API went through a bit of an overhaul in the 1.x to 2.x transition. This means that supporting 1.5 and 2.x concurrently in ffmpeg would be possible, but would require some (ugly) macros. Given that v2.0 was released ~19 months ago, I think it's been long enough that users should, most likely, have access to a modern 2.x OpenJPEG on their machine. So I don't think dropping 1.5 would be catastrophic. But, on the other hand, it's nice to be a swiss army knife that works with everything, so I can understand if others think supporting 1.5 is important. I don't want to submit my patch (as is) if I'm just going to be told to go back and keep 1.5 support. If ya'll still want 1.5 support, I'd rather include that from the get-go rather than revising the patch during the review. Opinions on whether 1.5 should be dropped in favor of 2.x? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Can we drop OpenJPEG 1.5 in favor of 2.x?
Michael Bradshaw gmail.com> writes: > tl;dr: I've got a patch that updates OpenJPEG to 2.0/2.1. > Currently, I've opted to drop OpenJPEG 1.5. Should I > proceed with preparing this patch for submission, or > should I alter it to keep 1.5 support? Do distributions support (contain) 2.x? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/7] lavfi/avf_concat: return immediately after requesting a frame on input.
Signed-off-by: Nicolas George --- libavfilter/avf_concat.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/libavfilter/avf_concat.c b/libavfilter/avf_concat.c index 5a4b356..4fa9447 100644 --- a/libavfilter/avf_concat.c +++ b/libavfilter/avf_concat.c @@ -347,10 +347,9 @@ static int request_frame(AVFilterLink *outlink) if (cat->in[str].eof) continue; ret = ff_request_frame(ctx->inputs[str]); -if (ret == AVERROR_EOF) -close_input(ctx, str); -else if (ret < 0) +if (ret != AVERROR_EOF) return ret; +close_input(ctx, str); } ret = flush_segment(ctx); if (ret < 0) -- 2.6.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/7] lavfi/fifo: do not assume request_frame() returns a frame.
Signed-off-by: Nicolas George --- libavfilter/fifo.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/libavfilter/fifo.c b/libavfilter/fifo.c index e477cff..f0b77ff 100644 --- a/libavfilter/fifo.c +++ b/libavfilter/fifo.c @@ -201,7 +201,8 @@ static int return_audio_frame(AVFilterContext *ctx) break; } else if (ret < 0) return ret; -av_assert0(s->root.next); // If ff_request_frame() succeeded then we should have a frame +if (!s->root.next) +return 0; } head = s->root.next->frame; @@ -237,7 +238,8 @@ static int request_frame(AVFilterLink *outlink) return return_audio_frame(outlink->src); return ret; } -av_assert0(fifo->root.next); +if (!fifo->root.next) +return 0; } if (outlink->request_samples) { -- 2.6.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 4/7] lavfi/af_join: partially fix scheduling.
Signed-off-by: Nicolas George --- libavfilter/af_join.c | 50 +- 1 file changed, 33 insertions(+), 17 deletions(-) diff --git a/libavfilter/af_join.c b/libavfilter/af_join.c index f5a1c50..bd780cc 100644 --- a/libavfilter/af_join.c +++ b/libavfilter/af_join.c @@ -78,11 +78,13 @@ static const AVOption join_options[] = { AVFILTER_DEFINE_CLASS(join); +static int try_push_frame(AVFilterContext *ctx); + static int filter_frame(AVFilterLink *link, AVFrame *frame) { AVFilterContext *ctx = link->dst; JoinContext *s = ctx->priv; -int i; +int i, j; for (i = 0; i < ctx->nb_inputs; i++) if (link == ctx->inputs[i]) @@ -91,7 +93,17 @@ static int filter_frame(AVFilterLink *link, AVFrame *frame) av_assert0(!s->input_frames[i]); s->input_frames[i] = frame; -return 0; +/* request the same number of samples on all inputs */ +/* FIXME that means a frame arriving asynchronously on a different input + will not have the requested number of samples */ +if (i == 0) { +int nb_samples = s->input_frames[0]->nb_samples; + +for (j = 1; !i && j < ctx->nb_inputs; j++) +ctx->inputs[j]->request_samples = nb_samples; +} + +return try_push_frame(ctx); } static int parse_maps(AVFilterContext *ctx) @@ -387,27 +399,31 @@ static int join_request_frame(AVFilterLink *outlink) { AVFilterContext *ctx = outlink->src; JoinContext *s = ctx->priv; -AVFrame *frame; -int linesize = INT_MAX; -int nb_samples = 0; -int nb_buffers = 0; -int i, j, ret; +int i; /* get a frame on each input */ for (i = 0; i < ctx->nb_inputs; i++) { AVFilterLink *inlink = ctx->inputs[i]; +if (!s->input_frames[i]) +return ff_request_frame(inlink); +} +return 0; +} -if (!s->input_frames[i] && -(ret = ff_request_frame(inlink)) < 0) -return ret; - -/* request the same number of samples on all inputs */ -if (i == 0) { -nb_samples = s->input_frames[0]->nb_samples; +static int try_push_frame(AVFilterContext *ctx) +{ +AVFilterLink *outlink = ctx->outputs[0]; +JoinContext *s = ctx->priv; +AVFrame *frame; +int linesize = INT_MAX; +int nb_samples = INT_MAX; +int nb_buffers = 0; +int i, j, ret; -for (j = 1; !i && j < ctx->nb_inputs; j++) -ctx->inputs[j]->request_samples = nb_samples; -} +for (i = 0; i < ctx->nb_inputs; i++) { +if (!s->input_frames[i]) +return 0; +nb_samples = FFMIN(nb_samples, s->input_frames[i]->nb_samples); } /* setup the output frame */ -- 2.6.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 6/7] lavfi/af_amix: mostly fix scheduling.
Signed-off-by: Nicolas George --- libavfilter/af_amix.c | 142 ++ 1 file changed, 62 insertions(+), 80 deletions(-) diff --git a/libavfilter/af_amix.c b/libavfilter/af_amix.c index 434dd90..223328b 100644 --- a/libavfilter/af_amix.c +++ b/libavfilter/af_amix.c @@ -44,9 +44,8 @@ #include "formats.h" #include "internal.h" -#define INPUT_OFF 0/**< input has reached EOF */ #define INPUT_ON 1/**< input is active */ -#define INPUT_INACTIVE 2/**< input is on, but is currently inactive */ +#define INPUT_EOF 2/**< input has reached EOF (may still be active) */ #define DURATION_LONGEST 0 #define DURATION_SHORTEST 1 @@ -209,7 +208,7 @@ static void calculate_scales(MixContext *s, int nb_samples) } for (i = 0; i < s->nb_inputs; i++) { -if (s->input_state[i] == INPUT_ON) +if (s->input_state[i] & INPUT_ON) s->input_scale[i] = 1.0f / s->scale_norm; else s->input_scale[i] = 0.0f; @@ -264,15 +263,52 @@ static int config_output(AVFilterLink *outlink) return 0; } +static int calc_active_inputs(MixContext *s); + /** * Read samples from the input FIFOs, mix, and write to the output link. */ -static int output_frame(AVFilterLink *outlink, int nb_samples) +static int output_frame(AVFilterLink *outlink) { AVFilterContext *ctx = outlink->src; MixContext *s = ctx->priv; AVFrame *out_buf, *in_buf; -int i; +int nb_samples, ns, ret, i; + +ret = calc_active_inputs(s); +if (ret < 0) +return ret; + +if (s->input_state[0] & INPUT_ON) { +/* first input live: use the corresponding frame size */ +nb_samples = frame_list_next_frame_size(s->frame_list); +for (i = 1; i < s->nb_inputs; i++) { +if (s->input_state[i] & INPUT_ON) { +ns = av_audio_fifo_size(s->fifos[i]); +if (ns < nb_samples) { +if (!(s->input_state[i] & INPUT_EOF)) +/* unclosed input with not enough samples */ +return 0; +/* closed input to drain */ +nb_samples = ns; +} +} +} +} else { +/* first input closed: use the available samples */ +nb_samples = INT_MAX; +for (i = 1; i < s->nb_inputs; i++) { +if (s->input_state[i] & INPUT_ON) { +ns = av_audio_fifo_size(s->fifos[i]); +nb_samples = FFMIN(nb_samples, ns); +} +} +if (nb_samples == INT_MAX) +return AVERROR_EOF; +} + +s->next_pts = frame_list_next_pts(s->frame_list); +frame_list_remove_samples(s->frame_list, nb_samples); calculate_scales(s, nb_samples); @@ -287,7 +323,7 @@ static int output_frame(AVFilterLink *outlink, int nb_samples) } for (i = 0; i < s->nb_inputs; i++) { -if (s->input_state[i] == INPUT_ON) { +if (s->input_state[i] & INPUT_ON) { int planes, plane_size, p; av_audio_fifo_read(s->fifos[i], (void **)in_buf->extended_data, @@ -314,29 +350,6 @@ static int output_frame(AVFilterLink *outlink, int nb_samples) } /** - * Returns the smallest number of samples available in the input FIFOs other - * than that of the first input. - */ -static int get_available_samples(MixContext *s) -{ -int i; -int available_samples = INT_MAX; - -av_assert0(s->nb_inputs > 1); - -for (i = 1; i < s->nb_inputs; i++) { -int nb_samples; -if (s->input_state[i] == INPUT_OFF) -continue; -nb_samples = av_audio_fifo_size(s->fifos[i]); -available_samples = FFMIN(available_samples, nb_samples); -} -if (available_samples == INT_MAX) -return 0; -return available_samples; -} - -/** * Requests a frame, if needed, from each input link other than the first. */ static int request_samples(AVFilterContext *ctx, int min_samples) @@ -348,19 +361,21 @@ static int request_samples(AVFilterContext *ctx, int min_samples) for (i = 1; i < s->nb_inputs; i++) { ret = 0; -if (s->input_state[i] == INPUT_OFF) +if (!(s->input_state[i] & INPUT_ON)) continue; -while (!ret && av_audio_fifo_size(s->fifos[i]) < min_samples) -ret = ff_request_frame(ctx->inputs[i]); +if (av_audio_fifo_size(s->fifos[i]) >= min_samples) +continue; +ret = ff_request_frame(ctx->inputs[i]); if (ret == AVERROR_EOF) { +s->input_state[i] |= INPUT_EOF; if (av_audio_fifo_size(s->fifos[i]) == 0) { -s->input_state[i] = INPUT_OFF; +s->input_state[i] = 0; continue; } } else if (ret < 0) return ret; } -return 0; +return output_frame(ctx->outputs[0]); } /** @@ -374,11 +389,11 @@ static int calc_acti
[FFmpeg-devel] [PATCH 5/7] lavfi/vf_framepack: fix scheduling.
Signed-off-by: Nicolas George --- libavfilter/vf_framepack.c | 18 +++--- 1 file changed, 15 insertions(+), 3 deletions(-) diff --git a/libavfilter/vf_framepack.c b/libavfilter/vf_framepack.c index be52507..621a034 100644 --- a/libavfilter/vf_framepack.c +++ b/libavfilter/vf_framepack.c @@ -268,25 +268,26 @@ static av_always_inline void spatial_frame_pack(AVFilterLink *outlink, } } +static int try_push_frame(AVFilterContext *ctx); + static int filter_frame_left(AVFilterLink *inlink, AVFrame *frame) { FramepackContext *s = inlink->dst->priv; s->input_views[LEFT] = frame; -return 0; +return try_push_frame(inlink->dst); } static int filter_frame_right(AVFilterLink *inlink, AVFrame *frame) { FramepackContext *s = inlink->dst->priv; s->input_views[RIGHT] = frame; -return 0; +return try_push_frame(inlink->dst); } static int request_frame(AVFilterLink *outlink) { AVFilterContext *ctx = outlink->src; FramepackContext *s = ctx->priv; -AVStereo3D *stereo; int ret, i; /* get a frame on the either input, stop as soon as a video ends */ @@ -297,7 +298,18 @@ static int request_frame(AVFilterLink *outlink) return ret; } } +return 0; +} + +static int try_push_frame(AVFilterContext *ctx) +{ +FramepackContext *s = ctx->priv; +AVFilterLink *outlink = ctx->outputs[0]; +AVStereo3D *stereo; +int ret, i; +if (!(s->input_views[0] && s->input_views[1])) +return 0; if (s->format == AV_STEREO3D_FRAMESEQUENCE) { if (s->double_pts == AV_NOPTS_VALUE) s->double_pts = s->input_views[LEFT]->pts; -- 2.6.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/7] lavfi: remove astreamsync.
It was only useful for very specific testing purposes and appears to be currently partially broken. Signed-off-by: Nicolas George --- MAINTAINERS | 1 - doc/filters.texi | 36 --- libavfilter/Makefile | 1 - libavfilter/af_astreamsync.c | 243 --- libavfilter/allfilters.c | 1 - 5 files changed, 282 deletions(-) delete mode 100644 libavfilter/af_astreamsync.c I had a hard time getting the filters from libav to behave correctly, but now I have a non-recursive version of request_frame() working. It still needs some work, two filters still have a loop in request_frame() that I need to remove (and no FATE test), and then some cleanup. But It is getting there. FATE passes after each patch in this series, and also with the non-recursive request_frame(). The affected parts in this series are either mine or from libav, so there is not really anyone else to approve them. If there are no objection I will push in a few days. diff --git a/MAINTAINERS b/MAINTAINERS index 25cff79..a08adf7 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -347,7 +347,6 @@ Filters: af_aphaser.c Paul B Mahol af_aresample.cMichael Niedermayer af_astats.c Paul B Mahol - af_astreamsync.c Nicolas George af_atempo.c Pavel Koshevoy af_biquads.c Paul B Mahol af_chorus.c Paul B Mahol diff --git a/doc/filters.texi b/doc/filters.texi index 5a35bde..6e8931e 100644 --- a/doc/filters.texi +++ b/doc/filters.texi @@ -1170,42 +1170,6 @@ Number of occasions (not the number of samples) that the signal attained either Overall bit depth of audio. Number of bits used for each sample. @end table -@section astreamsync - -Forward two audio streams and control the order the buffers are forwarded. - -The filter accepts the following options: - -@table @option -@item expr, e -Set the expression deciding which stream should be -forwarded next: if the result is negative, the first stream is forwarded; if -the result is positive or zero, the second stream is forwarded. It can use -the following variables: - -@table @var -@item b1 b2 -number of buffers forwarded so far on each stream -@item s1 s2 -number of samples forwarded so far on each stream -@item t1 t2 -current timestamp of each stream -@end table - -The default value is @code{t1-t2}, which means to always forward the stream -that has a smaller timestamp. -@end table - -@subsection Examples - -Stress-test @code{amerge} by randomly sending buffers on the wrong -input, while avoiding too much of a desynchronization: -@example -amovie=file.ogg [a] ; amovie=file.mp3 [b] ; -[a] [b] astreamsync=(2*random(1))-1+tanh(5*(t1-t2)) [a2] [b2] ; -[a2] [b2] amerge -@end example - @section asyncts Synchronize audio data with timestamps by squeezing/stretching it and/or diff --git a/libavfilter/Makefile b/libavfilter/Makefile index 8e776c1..f2f6dd1 100644 --- a/libavfilter/Makefile +++ b/libavfilter/Makefile @@ -50,7 +50,6 @@ OBJS-$(CONFIG_ASETTB_FILTER) += settb.o OBJS-$(CONFIG_ASHOWINFO_FILTER) += af_ashowinfo.o OBJS-$(CONFIG_ASPLIT_FILTER) += split.o OBJS-$(CONFIG_ASTATS_FILTER) += af_astats.o -OBJS-$(CONFIG_ASTREAMSYNC_FILTER)+= af_astreamsync.o OBJS-$(CONFIG_ASYNCTS_FILTER)+= af_asyncts.o OBJS-$(CONFIG_ATEMPO_FILTER) += af_atempo.o OBJS-$(CONFIG_ATRIM_FILTER) += trim.o diff --git a/libavfilter/af_astreamsync.c b/libavfilter/af_astreamsync.c deleted file mode 100644 index d08da26..000 diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c index 9385fdf..e7f6bec 100644 --- a/libavfilter/allfilters.c +++ b/libavfilter/allfilters.c @@ -72,7 +72,6 @@ void avfilter_register_all(void) REGISTER_FILTER(ASHOWINFO, ashowinfo, af); REGISTER_FILTER(ASPLIT, asplit, af); REGISTER_FILTER(ASTATS, astats, af); -REGISTER_FILTER(ASTREAMSYNC,astreamsync,af); REGISTER_FILTER(ASYNCTS,asyncts,af); REGISTER_FILTER(ATEMPO, atempo, af); REGISTER_FILTER(ATRIM, atrim, af); -- 2.6.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 7/7] lavfi/af_asyncts: remove looping on request_frame().
Signed-off-by: Nicolas George --- libavfilter/af_asyncts.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/libavfilter/af_asyncts.c b/libavfilter/af_asyncts.c index 214cefd..209fc4c 100644 --- a/libavfilter/af_asyncts.c +++ b/libavfilter/af_asyncts.c @@ -139,8 +139,7 @@ static int request_frame(AVFilterLink *link) int nb_samples; s->got_output = 0; -while (ret >= 0 && !s->got_output) -ret = ff_request_frame(ctx->inputs[0]); +ret = ff_request_frame(ctx->inputs[0]); /* flush the fifo */ if (ret == AVERROR_EOF) { -- 2.6.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avutil/opt: print more meaningful default flags values
On Sat, Oct 24, 2015 at 03:14:33PM +0200, Clément Bœsch wrote: > Example: > % ./ffmpeg -h encoder=gif > [...] > GIF encoder AVOptions: > -gifflagsE..V set GIF flags (default > offsetting+transdiff) > offsetting E..V enable picture offsetting > transdiffE..V enable transparency detection > between frames > --- > libavutil/opt.c| 32 ++-- > tests/ref/fate/opt | 2 +- > 2 files changed, 31 insertions(+), 3 deletions(-) LGTM thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Freedom in capitalist society always remains about the same as it was in ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Can we drop OpenJPEG 1.5 in favor of 2.x?
On Sat, Oct 24, 2015 at 12:59 PM, Carl Eugen Hoyos wrote: > Michael Bradshaw gmail.com> writes: > >> tl;dr: I've got a patch that updates OpenJPEG to 2.0/2.1. >> Currently, I've opted to drop OpenJPEG 1.5. Should I >> proceed with preparing this patch for submission, or >> should I alter it to keep 1.5 support? > > Do distributions support (contain) 2.x? Definitely not. Even Arch Linux, generally an early adopter, does not use openjpeg2, but instead openjpeg for most things. 1.5 support is very much needed for now. > > Carl Eugen > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Can we drop OpenJPEG 1.5 in favor of 2.x?
On Sat, Oct 24, 2015 at 09:03:43AM -0700, Michael Bradshaw wrote: > tl;dr: I've got a patch that updates OpenJPEG to 2.0/2.1. Currently, I've > opted to drop OpenJPEG 1.5. Should I proceed with preparing this patch for > submission, or should I alter it to keep 1.5 support? > > > > The OpenJPEG API went through a bit of an overhaul in the 1.x to 2.x > transition. This means that supporting 1.5 and 2.x concurrently in ffmpeg > would be possible, but would require some (ugly) macros. > > Given that v2.0 was released ~19 months ago, I think it's been long enough > that users should, most likely, have access to a modern 2.x OpenJPEG on > their machine. So I don't think dropping 1.5 would be catastrophic. > > But, on the other hand, it's nice to be a swiss army knife that works with > everything, so I can understand if others think supporting 1.5 is important. > > I don't want to submit my patch (as is) if I'm just going to be told to go > back and keep 1.5 support. If ya'll still want 1.5 support, I'd rather > include that from the get-go rather than revising the patch during the > review. > > Opinions on whether 1.5 should be dropped in favor of 2.x? If we consider the set of distributions which are supported by their upstreams still, how many of these ship 2.x and how many an older OpenJPEG version ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is dangerous to be right in matters on which the established authorities are wrong. -- Voltaire signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Can we drop OpenJPEG 1.5 in favor of 2.x?
Le tridi 3 brumaire, an CCXXIV, Ganesh Ajjanagadde a écrit : > Definitely not. Even Arch Linux, generally an early adopter, does not > use openjpeg2, but instead openjpeg for most things. https://www.archlinux.org/packages/community/x86_64/openjpeg2/ Are you sure of your statement? Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Can we drop OpenJPEG 1.5 in favor of 2.x?
On Sat, Oct 24, 2015 at 1:09 PM, Nicolas George wrote: > Le tridi 3 brumaire, an CCXXIV, Ganesh Ajjanagadde a écrit : >> Definitely not. Even Arch Linux, generally an early adopter, does not >> use openjpeg2, but instead openjpeg for most things. > > https://www.archlinux.org/packages/community/x86_64/openjpeg2/ > > Are you sure of your statement? I did not say it is not present, just that more packages rely on openjpeg instead of openjpeg2. For instance, openjpeg2 is not even installed on my system. Or just look at the repo classification: openjpeg2 is in community, while openjpeg is in extra, a more "core" group of packages. > > Regards, > > -- > Nicolas George > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Can we drop OpenJPEG 1.5 in favor of 2.x?
On 24.10.2015 18:59, Carl Eugen Hoyos wrote: > Michael Bradshaw gmail.com> writes: > >> tl;dr: I've got a patch that updates OpenJPEG to 2.0/2.1. >> Currently, I've opted to drop OpenJPEG 1.5. Should I >> proceed with preparing this patch for submission, or >> should I alter it to keep 1.5 support? > > Do distributions support (contain) 2.x? Debian has a separate openjpeg2 package [1], even in stable. So from my point of view there is no need to keep compatibility with openjpeg 1.5, if that's too difficult/ugly. Best regards, Andreas 1: https://tracker.debian.org/pkg/openjpeg2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Can we drop OpenJPEG 1.5 in favor of 2.x?
Le tridi 3 brumaire, an CCXXIV, Ganesh Ajjanagadde a écrit : > I did not say it is not present, just that more packages rely on > openjpeg instead of openjpeg2. Ok. But having it available is enough, we do not really care how many other programs use it, only that Michael, the maintainer for this part of FFmpeg, likes it better, and that it is easy to install for users. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/5] all: use function pointer instead of void * data pointer
On Sat, Oct 24, 2015 at 09:28:52AM -0400, Ganesh Ajjanagadde wrote: > ISO C does not guarantee that functions and data live in the same > address space. It is thus (strictly speaking) illegal to assign to a > void * (which is a data pointer) from a function pointer. > > Found by enabling -Wpedantic on clang 3.7. > > Signed-off-by: Ganesh Ajjanagadde > --- > ffmpeg_opt.c | 8 > libavcodec/hevc.c | 2 +- > libavfilter/vf_drawtext.c | 2 +- > libavfilter/vf_lut.c | 6 +++--- > libavformat/async.c | 2 +- > 5 files changed, 10 insertions(+), 10 deletions(-) if these dont add any new warnings then LGTM but the commit message should rather point to code cleanup and not ISO C [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The bravest are surely those who have the clearest vision of what is before them, glory and danger alike, and yet notwithstanding go out to meet it. -- Thucydides signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Can we drop OpenJPEG 1.5 in favor of 2.x?
On Sat, Oct 24, 2015 at 1:24 PM, Nicolas George wrote: > Le tridi 3 brumaire, an CCXXIV, Ganesh Ajjanagadde a écrit : >> I did not say it is not present, just that more packages rely on >> openjpeg instead of openjpeg2. > > Ok. But having it available is enough, we do not really care how many other > programs use it, only that Michael, the maintainer for this part of FFmpeg, > likes it better, and that it is easy to install for users. Sure, I do not oppose such a change if it leads to benefits. > > 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] lavfi/vf_decimate: do not compare the first frame to itself.
This is a waste of computing power and will result to 0, making it always dropped. Use maximum difference values instead. Signed-off-by: Nicolas George --- libavfilter/vf_decimate.c | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/libavfilter/vf_decimate.c b/libavfilter/vf_decimate.c index 26f3ce0..3b146cd 100644 --- a/libavfilter/vf_decimate.c +++ b/libavfilter/vf_decimate.c @@ -167,9 +167,12 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in) if (in) { /* update frame metrics */ prv = dm->fid ? dm->queue[dm->fid - 1].frame : dm->last; -if (!prv) -prv = in; -calc_diffs(dm, &dm->queue[dm->fid], prv, in); +if (!prv) { +dm->queue[dm->fid].maxbdiff = INT64_MAX; +dm->queue[dm->fid].totdiff = INT64_MAX; +} else { +calc_diffs(dm, &dm->queue[dm->fid], prv, in); +} if (++dm->fid != dm->cycle) return 0; av_frame_free(&dm->last); -- 2.6.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/5] avfilter: avoid zero arguments to variadic macro
On Sat, Oct 24, 2015 at 03:52:25PM +0200, Nicolas George wrote: > Le tridi 3 brumaire, an CCXXIV, Ganesh Ajjanagadde a écrit : > > Thanks for the super quick review. Will apply shortly. Do you (or > > others) think adding -Wgnu-zero-variadic-macro-arguments to configure > > is a good idea? > > Considering that each additional option takes ~15 ms in configure on a > fairly powerful box, not counting maintenance burden, I would say rather no. about 10ms here with time ./configure about 1.5ms here with time ./configure --cc='ccache gcc' --tempprefix=/home/michael/ffconftemp also we could speed configure up with something like this: (or a more generic "all before each" checker) diff --git a/configure b/configure index a38b290..6fa3273 100755 --- a/configure +++ b/configure @@ -5637,6 +5637,9 @@ disabled iconv || check_func_headers iconv.h iconv || check_lib2 iconv.h iconv - enabled debug && add_cflags -g"$debuglevel" && add_asflags -g"$debuglevel" # add some useful compiler flags if supported +if ! check_cflags -Wdeclaration-after-statement -Wall -Wdisabled-optimization -Wpointer-arith -Wredundant-decls \ + -Wwrite-strings -Wtype-limits -Wundef -Wmissing-prototypes -Wno-pointer-to-int-cast -Wstrict-prototypes -Wempty-body ; then + check_cflags -Wdeclaration-after-statement check_cflags -Wall check_cflags -Wdisabled-optimization @@ -5649,6 +5652,9 @@ check_cflags -Wmissing-prototypes check_cflags -Wno-pointer-to-int-cast check_cflags -Wstrict-prototypes check_cflags -Wempty-body +#Note, if you add a check_cflags here, also add it to the if above +fi + enabled extra_warnings && check_cflags -Winline check_disable_warning(){ -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No snowflake in an avalanche ever feels responsible. -- Voltaire signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] videodsp: don't overread edges in vfix3 emu_edge.
Hi Andreas, On Sat, Oct 24, 2015 at 11:58 AM, Andreas Cadhalpun < andreas.cadhal...@googlemail.com> wrote: > Hi Ronald, > > On 24.10.2015 17:55, Ronald S. Bultje wrote: > > On Sat, Oct 24, 2015 at 11:41 AM, Andreas Cadhalpun < > > andreas.cadhal...@googlemail.com> wrote: > > > >> On 24.10.2015 14:47, Ronald S. Bultje wrote: > >>> --- > >>> libavcodec/x86/videodsp.asm | 15 +++ > >>> 1 file changed, 11 insertions(+), 4 deletions(-) > >>> > >>> diff --git a/libavcodec/x86/videodsp.asm b/libavcodec/x86/videodsp.asm > >>> index 25d4364..48f5ac0 100644 > >>> --- a/libavcodec/x86/videodsp.asm > >>> +++ b/libavcodec/x86/videodsp.asm > >>> @@ -194,8 +194,12 @@ hvar_fn > >>> %elif (%2-%%off) == 2 > >>> movvalw, [srcq+%2-2] > >>> %elifidn %1, body > >>> -movvald, [srcq+%2-3] > >>> -%else > >>> +movvalb, [srcq+%2-1] > >>> +salvald, 16 > >>> +movvalw, [srcq+%2-3] > >>> +%elifidn %1, bottom > >>> +movd mm %+ %%mmx_idx, [srcq+%2-4] > >>> +%else ; top > >>> movd mm %+ %%mmx_idx, [srcq+%2-3] > >>> %endif > >>> %endif ; (%2-%%off) >= 1 > >>> @@ -251,12 +255,15 @@ hvar_fn > >>> mov [dstq+%2-2], valw > >>> %elifidn %1, body > >>> mov [dstq+%2-3], valw > >>> -shrvald, 16 > >>> +sarvald, 16 > >>> mov [dstq+%2-1], valb > >>> %else > >>> movd vald, mm %+ %%mmx_idx > >>> +%ifidn %1, bottom > >>> +sarvald, 8 > >>> +%endif > >>> mov [dstq+%2-3], valw > >>> -shrvald, 16 > >>> +sarvald, 16 > >>> mov [dstq+%2-1], valb > >>> %endif > >>> %endif ; (%2-%%off) >= 1 > >>> > >> > >> This fixes the crash and passes FATE, so looks good to me. > >> Maybe mention the bug report in the commit message, e.g.: > >> Bug-Debian: https://bugs.debian.org/801745 > > > > > > Thanks for testing, so this does actually fix the bug? > > Yes, at least I couldn't reproduce the crash anymore with this patch > applied. Great, thanks for verifying that. I'll apply with your suggested addition to the commit message. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/5] avfilter: avoid zero arguments to variadic macro
On Sat, Oct 24, 2015 at 1:48 PM, Michael Niedermayer wrote: > On Sat, Oct 24, 2015 at 03:52:25PM +0200, Nicolas George wrote: >> Le tridi 3 brumaire, an CCXXIV, Ganesh Ajjanagadde a écrit : >> > Thanks for the super quick review. Will apply shortly. Do you (or >> > others) think adding -Wgnu-zero-variadic-macro-arguments to configure >> > is a good idea? >> >> Considering that each additional option takes ~15 ms in configure on a >> fairly powerful box, not counting maintenance burden, I would say rather no. > > about 10ms here with > time ./configure > about 1.5ms here with > time ./configure --cc='ccache gcc' --tempprefix=/home/michael/ffconftemp > > also we could speed configure up with something like this: > (or a more generic "all before each" checker) > > diff --git a/configure b/configure > index a38b290..6fa3273 100755 > --- a/configure > +++ b/configure > @@ -5637,6 +5637,9 @@ disabled iconv || check_func_headers iconv.h iconv || > check_lib2 iconv.h iconv - > enabled debug && add_cflags -g"$debuglevel" && add_asflags -g"$debuglevel" > > # add some useful compiler flags if supported > +if ! check_cflags -Wdeclaration-after-statement -Wall > -Wdisabled-optimization -Wpointer-arith -Wredundant-decls \ > + -Wwrite-strings -Wtype-limits -Wundef -Wmissing-prototypes > -Wno-pointer-to-int-cast -Wstrict-prototypes -Wempty-body ; then > + > check_cflags -Wdeclaration-after-statement > check_cflags -Wall > check_cflags -Wdisabled-optimization > @@ -5649,6 +5652,9 @@ check_cflags -Wmissing-prototypes > check_cflags -Wno-pointer-to-int-cast > check_cflags -Wstrict-prototypes > check_cflags -Wempty-body > +#Note, if you add a check_cflags here, also add it to the if above > +fi > + > enabled extra_warnings && check_cflags -Winline > > check_disable_warning(){ Will leave it to you (or others) for such patches (to speed up configure and/or add warnings), I am fine either way. > > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > No snowflake in an avalanche ever feels responsible. -- Voltaire > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Can we drop OpenJPEG 1.5 in favor of 2.x?
On 10/24/2015 1:03 PM, Michael Bradshaw wrote: > tl;dr: I've got a patch that updates OpenJPEG to 2.0/2.1. Currently, I've > opted to drop OpenJPEG 1.5. Should I proceed with preparing this patch for > submission, or should I alter it to keep 1.5 support? > > > > The OpenJPEG API went through a bit of an overhaul in the 1.x to 2.x > transition. This means that supporting 1.5 and 2.x concurrently in ffmpeg > would be possible, but would require some (ugly) macros. > > Given that v2.0 was released ~19 months ago, I think it's been long enough > that users should, most likely, have access to a modern 2.x OpenJPEG on > their machine. So I don't think dropping 1.5 would be catastrophic. > > But, on the other hand, it's nice to be a swiss army knife that works with > everything, so I can understand if others think supporting 1.5 is important. > > I don't want to submit my patch (as is) if I'm just going to be told to go > back and keep 1.5 support. If ya'll still want 1.5 support, I'd rather > include that from the get-go rather than revising the patch during the > review. > > Opinions on whether 1.5 should be dropped in favor of 2.x? Why does configure even check for 2.x if the actual lavc wrappers don't currently support it? Gentoo and Debian both seem to ship it. Arch does as well but on their Community repository (ffmpeg adopting it may be incentive enough for them to move it to Extra). No idea about other distros, but in any case, if there's any that doesn't ship it then we should keep supporting it for a while, even if it means adding some ugly macros. We could even add some deprecation warning during configure if 1.5 is used, to urge distros to switch. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Can we drop OpenJPEG 1.5 in favor of 2.x?
James Almer gmail.com> writes: > Why does configure even check for 2.x if the actual > lavc wrappers don't currently support it? It is possible to use openjpeg2 with current FFmpeg (I use it for testing) but it is everything but user-friendly. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] videodsp: don't overread edges in vfix3 emu_edge.
Ronald S. Bultje gmail.com> writes: > Great, thanks for verifying that. I'll apply with > your suggested addition to the commit message. Please do, you could also mention ticket #3226: I was never able to reproduce (I can reproduce the Debian bug) but it has a very similar description iirc. (And you could mention Andreas' analysis.) Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Can we drop OpenJPEG 1.5 in favor of 2.x?
On Sat, Oct 24, 2015 at 11:03 AM James Almer wrote: > Gentoo and Debian both seem to ship it. Arch does as well but on their > Community repository (ffmpeg adopting it may be incentive enough for them > to move it to Extra). > In fact, at least two of the reverse dependencies (out of 8, not counting duplicates) of the Arch openjpeg package already support openjpeg2 (poppler and gst-plugins-bad). I would prefer if we keep compat for both since Ubuntu 14.04 LTS doesn't have openjpeg2 yet, and that's unfortunately not going away any time soon. Timothy ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 5/5] all: fix enum definition for large values
On Sat, Oct 24, 2015 at 09:29:23AM -0400, Ganesh Ajjanagadde wrote: > ISO C restricts enumerator values to the range of int. Thus (for instance) > 0x8000 > unfortunately does not work, and throws a warning with -Wpedantic on > clang 3.7. > > This fixes such errors by explicitly casting as an int, doing the > desired unsigned to signed conversion. This method works on all current > architectures. Tested with FATE. > > Signed-off-by: Ganesh Ajjanagadde Simply changing the values to signed is not correct / not sufficient the code assumes that they are unsigned [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many things microsoft did are stupid, but not doing something just because microsoft did it is even more stupid. If everything ms did were stupid they would be bankrupt already. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] videodsp: don't overread edges in vfix3 emu_edge.
Hi, On Sat, Oct 24, 2015 at 2:13 PM, Carl Eugen Hoyos wrote: > Ronald S. Bultje gmail.com> writes: > > > Great, thanks for verifying that. I'll apply with > > your suggested addition to the commit message. > > Please do, you could also mention ticket #3226: I > was never able to reproduce (I can reproduce the > Debian bug) but it has a very similar description > iirc. > (And you could mention Andreas' analysis.) Yes, sounds like it's the same, added that + a thank-you to Andreas. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 5/5] all: fix enum definition for large values
On Sat, Oct 24, 2015 at 2:33 PM, Michael Niedermayer wrote: > On Sat, Oct 24, 2015 at 09:29:23AM -0400, Ganesh Ajjanagadde wrote: >> ISO C restricts enumerator values to the range of int. Thus (for instance) >> 0x8000 >> unfortunately does not work, and throws a warning with -Wpedantic on >> clang 3.7. >> >> This fixes such errors by explicitly casting as an int, doing the >> desired unsigned to signed conversion. This method works on all current >> architectures. Tested with FATE. >> >> Signed-off-by: Ganesh Ajjanagadde > > Simply changing the values to signed is not correct / not sufficient > the code assumes that they are unsigned enums are ints (and hence signed). I doubt code assumed that they are unsigned. If code depended on these being unsigned constants, then there is no way of placing them in an enum. Are you fine with a macro, or do you prefer a static const style? Generally, it seems like FFmpeg prefers the macro method for defining such constants/flags. > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Many things microsoft did are stupid, but not doing something just because > microsoft did it is even more stupid. If everything ms did were stupid they > would be bankrupt already. > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/5] avfilter: avoid zero arguments to variadic macro
On Sat, Oct 24, 2015 at 02:01:07PM -0400, Ganesh Ajjanagadde wrote: > On Sat, Oct 24, 2015 at 1:48 PM, Michael Niedermayer > wrote: > > On Sat, Oct 24, 2015 at 03:52:25PM +0200, Nicolas George wrote: > >> Le tridi 3 brumaire, an CCXXIV, Ganesh Ajjanagadde a écrit : > >> > Thanks for the super quick review. Will apply shortly. Do you (or > >> > others) think adding -Wgnu-zero-variadic-macro-arguments to configure > >> > is a good idea? > >> > >> Considering that each additional option takes ~15 ms in configure on a > >> fairly powerful box, not counting maintenance burden, I would say rather > >> no. > > > > about 10ms here with > > time ./configure > > about 1.5ms here with > > time ./configure --cc='ccache gcc' > > --tempprefix=/home/michael/ffconftemp > > > > also we could speed configure up with something like this: > > (or a more generic "all before each" checker) > > > > diff --git a/configure b/configure > > index a38b290..6fa3273 100755 > > --- a/configure > > +++ b/configure > > @@ -5637,6 +5637,9 @@ disabled iconv || check_func_headers iconv.h iconv || > > check_lib2 iconv.h iconv - > > enabled debug && add_cflags -g"$debuglevel" && add_asflags -g"$debuglevel" > > > > # add some useful compiler flags if supported > > +if ! check_cflags -Wdeclaration-after-statement -Wall > > -Wdisabled-optimization -Wpointer-arith -Wredundant-decls \ > > + -Wwrite-strings -Wtype-limits -Wundef > > -Wmissing-prototypes -Wno-pointer-to-int-cast -Wstrict-prototypes > > -Wempty-body ; then > > + > > check_cflags -Wdeclaration-after-statement > > check_cflags -Wall > > check_cflags -Wdisabled-optimization > > @@ -5649,6 +5652,9 @@ check_cflags -Wmissing-prototypes > > check_cflags -Wno-pointer-to-int-cast > > check_cflags -Wstrict-prototypes > > check_cflags -Wempty-body > > +#Note, if you add a check_cflags here, also add it to the if above > > +fi > > + > > enabled extra_warnings && check_cflags -Winline > > > > check_disable_warning(){ > > Will leave it to you (or others) for such patches (to speed up > configure and/or add warnings), I am fine either way. i can apply above code if wanted, beyond that ill leave it to others as well, like for writing a nice generic "all before each" checker as in check_each check_cflags -Wdeclaration-after-statement -Wall -Wdisabled-optimization -Wpointer-arith -Wredundant-decls [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Everything should be made as simple as possible, but not simpler. -- Albert Einstein signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 5/5] all: fix enum definition for large values
Le tridi 3 brumaire, an CCXXIV, Ganesh Ajjanagadde a écrit : > or do you prefer a static const style? static const is not build-time constant, and therefore unusable for this: impossible to use it as case label or constant initializer. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Can we drop OpenJPEG 1.5 in favor of 2.x?
Le tridi 3 brumaire, an CCXXIV, James Almer a écrit : > No idea about other distros, but in any case, if there's any that doesn't > ship it then we should keep supporting it for a while, even if it means > adding some ugly macros. Depending on the ugliness of the macros, maybe duplicating the file as libopenjpeg15.c and libopenjpeg2.c, and having the build system use one (or possibly both, for testing) would be a better option. Duplicating code is of course not a good practice, but littering the bug with conditional compilation is horrible too, whichever is the least horrible in this particular case should be considered. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 5/5] all: fix enum definition for large values
On Sat, Oct 24, 2015 at 2:48 PM, Nicolas George wrote: > Le tridi 3 brumaire, an CCXXIV, Ganesh Ajjanagadde a écrit : >> or do you prefer a static const style? > > static const is not build-time constant, and therefore unusable for this: > impossible to use it as case label or constant initializer. Ah, my bad: I believe this works in C++ and got mixed up. > > 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] avcodec: add SDX2 DPCM decoder
Hi, See attached. From 3c26a0554397d623ab61671beaf2879d61911024 Mon Sep 17 00:00:00 2001 From: Paul B Mahol Date: Sat, 24 Oct 2015 20:41:32 +0200 Subject: [PATCH] avcodec: add SDX2 DPCM decoder Signed-off-by: Paul B Mahol --- libavcodec/Makefile | 1 + libavcodec/allcodecs.c | 1 + libavcodec/avcodec.h| 2 ++ libavcodec/codec_desc.c | 7 +++ libavcodec/dpcm.c | 32 libavformat/aiff.h | 1 + libavformat/aiffdec.c | 1 + libavformat/genh.c | 4 8 files changed, 45 insertions(+), 4 deletions(-) diff --git a/libavcodec/Makefile b/libavcodec/Makefile index f85fc18..4afb473 100644 --- a/libavcodec/Makefile +++ b/libavcodec/Makefile @@ -458,6 +458,7 @@ OBJS-$(CONFIG_S302M_DECODER) += s302m.o OBJS-$(CONFIG_S302M_ENCODER) += s302menc.o OBJS-$(CONFIG_SANM_DECODER)+= sanm.o OBJS-$(CONFIG_SCREENPRESSO_DECODER)+= screenpresso.o +OBJS-$(CONFIG_SDX2_DPCM_DECODER) += dpcm.o OBJS-$(CONFIG_SGI_DECODER) += sgidec.o OBJS-$(CONFIG_SGI_ENCODER) += sgienc.o rle.o OBJS-$(CONFIG_SGIRLE_DECODER) += sgirledec.o diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c index 7279620..52606a3 100644 --- a/libavcodec/allcodecs.c +++ b/libavcodec/allcodecs.c @@ -287,6 +287,7 @@ void avcodec_register_all(void) REGISTER_ENCDEC (S302M, s302m); REGISTER_DECODER(SANM, sanm); REGISTER_DECODER(SCREENPRESSO, screenpresso); +REGISTER_DECODER(SDX2_DPCM, sdx2_dpcm); REGISTER_ENCDEC (SGI, sgi); REGISTER_DECODER(SGIRLE,sgirle); REGISTER_DECODER(SMACKER, smacker); diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h index 7d47698..490bcd2 100644 --- a/libavcodec/avcodec.h +++ b/libavcodec/avcodec.h @@ -410,6 +410,8 @@ enum AVCodecID { AV_CODEC_ID_XAN_DPCM, AV_CODEC_ID_SOL_DPCM, +AV_CODEC_ID_SDX2_DPCM = 0x14800, + /* audio codecs */ AV_CODEC_ID_MP2 = 0x15000, AV_CODEC_ID_MP3, ///< preferred ID for decoding MPEG audio layer 1, 2 or 3 diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c index 2f5cefd..61a9986 100644 --- a/libavcodec/codec_desc.c +++ b/libavcodec/codec_desc.c @@ -2054,6 +2054,13 @@ static const AVCodecDescriptor codec_descriptors[] = { .long_name = NULL_IF_CONFIG_SMALL("DPCM Sol"), .props = AV_CODEC_PROP_LOSSY, }, +{ +.id= AV_CODEC_ID_SDX2_DPCM, +.type = AVMEDIA_TYPE_AUDIO, +.name = "sdx2_dpcm", +.long_name = NULL_IF_CONFIG_SMALL("DPCM SDX2"), +.props = AV_CODEC_PROP_LOSSY, +}, /* audio codecs */ { diff --git a/libavcodec/dpcm.c b/libavcodec/dpcm.c index c13945e..0770e19 100644 --- a/libavcodec/dpcm.c +++ b/libavcodec/dpcm.c @@ -44,7 +44,7 @@ #include "mathops.h" typedef struct DPCMContext { -int16_t roq_square_array[256]; +int16_t square_array[256]; int sample[2]; ///< previous sample (for SOL_DPCM) const int8_t *sol_table;///< delta table for SOL_DPCM } DPCMContext; @@ -130,8 +130,8 @@ static av_cold int dpcm_decode_init(AVCodecContext *avctx) /* initialize square table */ for (i = 0; i < 128; i++) { int16_t square = i * i; -s->roq_square_array[i ] = square; -s->roq_square_array[i + 128] = -square; +s->square_array[i ] = square; +s->square_array[i + 128] = -square; } break; @@ -153,6 +153,13 @@ static av_cold int dpcm_decode_init(AVCodecContext *avctx) } break; +case AV_CODEC_ID_SDX2_DPCM: +for (i = -128; i < 128; i++) { +int16_t square = i * i * 2; +s->square_array[i+128] = i < 0 ? -square: square; +} +break; + default: break; } @@ -200,6 +207,9 @@ static int dpcm_decode_frame(AVCodecContext *avctx, void *data, else out = buf_size; break; +case AV_CODEC_ID_SDX2_DPCM: +out = buf_size; +break; } if (out <= 0) { av_log(avctx, AV_LOG_ERROR, "packet is too small\n"); @@ -230,7 +240,7 @@ static int dpcm_decode_frame(AVCodecContext *avctx, void *data, /* decode the samples */ while (output_samples < samples_end) { -predictor[ch] += s->roq_square_array[bytestream2_get_byteu(&gb)]; +predictor[ch] += s->square_array[bytestream2_get_byteu(&gb)]; predictor[ch] = av_clip_int16(predictor[ch]); *output_samples++ = predictor[ch]; @@ -318,6 +328,19 @@ static int dpcm_decode_frame(AVCodecContext *avctx, void *data, } } break; + +case AV_CODEC_ID_SDX2_DPCM: +while (output_samples < samples_end) { +int8_t n = bytestream2_get_byteu(&gb); + +if (!(n & 1)) +s->sample[ch]
Re: [FFmpeg-devel] [PATCH 5/5] all: fix enum definition for large values
On Sat, Oct 24, 2015 at 02:41:59PM -0400, Ganesh Ajjanagadde wrote: > On Sat, Oct 24, 2015 at 2:33 PM, Michael Niedermayer > wrote: > > On Sat, Oct 24, 2015 at 09:29:23AM -0400, Ganesh Ajjanagadde wrote: > >> ISO C restricts enumerator values to the range of int. Thus (for instance) > >> 0x8000 > >> unfortunately does not work, and throws a warning with -Wpedantic on > >> clang 3.7. > >> > >> This fixes such errors by explicitly casting as an int, doing the > >> desired unsigned to signed conversion. This method works on all current > >> architectures. Tested with FATE. > >> > >> Signed-off-by: Ganesh Ajjanagadde > > > > Simply changing the values to signed is not correct / not sufficient > > the code assumes that they are unsigned > > enums are ints (and hence signed). this is not true (though thats off topic but you seemed interrested in the C spec) 6.7.2.2 Enumeration specifiers ... 4 Each enumerated type shall be compatible with char, a signed integer type, or an unsigned integer type. The choice of type is implementation-defined,110) but shall be capable of representing the values of all the members of the enumeration. The enumerated type is incomplete until after the } that terminates the list of enumerator declarations. so a enum type can be almost anything the implementation likes it to be. 2 enums dont even need to be using the same type and this is not just specification talk, gcc does this actually, for example it will use (u)int64 as type when things dont fit in an (unsigned) int also on at least some embeded platforms gcc will use shorts for enums that fit in a short int (no i dont know which exactly but i read about people stumbling into this so it must happen on some platform) > I doubt code assumed that they are > unsigned. If code depended on these being unsigned constants, then > there is no way of placing them in an enum. Are you fine with a macro, > or do you prefer a static const style? Generally, it seems like FFmpeg > prefers the macro method for defining such constants/flags. if have no preferrance for anything beyond the code working [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many that live deserve death. And some that die deserve life. Can you give it to them? Then do not be too eager to deal out death in judgement. For even the very wise cannot see all ends. -- Gandalf signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 5/5] all: fix enum definition for large values
On Sat, Oct 24, 2015 at 8:58 PM, Michael Niedermayer wrote: > On Sat, Oct 24, 2015 at 02:41:59PM -0400, Ganesh Ajjanagadde wrote: >> On Sat, Oct 24, 2015 at 2:33 PM, Michael Niedermayer >> wrote: >> > On Sat, Oct 24, 2015 at 09:29:23AM -0400, Ganesh Ajjanagadde wrote: >> >> ISO C restricts enumerator values to the range of int. Thus (for >> >> instance) 0x8000 >> >> unfortunately does not work, and throws a warning with -Wpedantic on >> >> clang 3.7. >> >> >> >> This fixes such errors by explicitly casting as an int, doing the >> >> desired unsigned to signed conversion. This method works on all current >> >> architectures. Tested with FATE. >> >> >> >> Signed-off-by: Ganesh Ajjanagadde >> > >> > Simply changing the values to signed is not correct / not sufficient >> > the code assumes that they are unsigned >> >> enums are ints (and hence signed). > > this is not true (though thats off topic but you seemed interrested in > the C spec) > 6.7.2.2 Enumeration specifiers > ... > 4 Each enumerated type shall be compatible with char, a signed integer type, > or an > unsigned integer type. The choice of type is implementation-defined,110) > but shall be > capable of representing the values of all the members of the enumeration. > The > enumerated type is incomplete until after the } that terminates the list of > enumerator > declarations. > > so a enum type can be almost anything the implementation likes it to > be. 2 enums dont even need to be using the same type and this is not > just specification talk, gcc does this actually, for example it will > use (u)int64 as type when things dont fit in an (unsigned) int > also on at least some embeded platforms gcc will use shorts > for enums that fit in a short int (no i dont know which exactly but > i read about people stumbling into this so it must happen on some > platform) > > >> I doubt code assumed that they are >> unsigned. If code depended on these being unsigned constants, then >> there is no way of placing them in an enum. Are you fine with a macro, >> or do you prefer a static const style? Generally, it seems like FFmpeg >> prefers the macro method for defining such constants/flags. > > if have no preferrance for anything beyond the code working > If the current code is correct according to the spec (ie. the enum gets represented as unsigned or int64), then it should just remain as it is. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 5/5] all: fix enum definition for large values
On Sat, Oct 24, 2015 at 02:41:59PM -0400, Ganesh Ajjanagadde wrote: > On Sat, Oct 24, 2015 at 2:33 PM, Michael Niedermayer > wrote: > > On Sat, Oct 24, 2015 at 09:29:23AM -0400, Ganesh Ajjanagadde wrote: > >> ISO C restricts enumerator values to the range of int. Thus (for instance) > >> 0x8000 > >> unfortunately does not work, and throws a warning with -Wpedantic on > >> clang 3.7. > >> > >> This fixes such errors by explicitly casting as an int, doing the > >> desired unsigned to signed conversion. This method works on all current > >> architectures. Tested with FATE. > >> > >> Signed-off-by: Ganesh Ajjanagadde > > > > Simply changing the values to signed is not correct / not sufficient > > the code assumes that they are unsigned > > enums are ints (and hence signed). > I doubt code assumed that they are > unsigned. it did for example (uint64_t)DCA_SYNCWORD_CORE_LE will change its value with this patch, if thats the only one of if there are dozends more i dont know [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When you are offended at any man's fault, turn to yourself and study your own failings. Then you will forget your anger. -- Epictetus signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 5/5] all: fix enum definition for large values
On Sat, Oct 24, 2015 at 09:02:29PM +0200, Hendrik Leppkes wrote: > On Sat, Oct 24, 2015 at 8:58 PM, Michael Niedermayer > wrote: > > On Sat, Oct 24, 2015 at 02:41:59PM -0400, Ganesh Ajjanagadde wrote: > >> On Sat, Oct 24, 2015 at 2:33 PM, Michael Niedermayer > >> wrote: > >> > On Sat, Oct 24, 2015 at 09:29:23AM -0400, Ganesh Ajjanagadde wrote: > >> >> ISO C restricts enumerator values to the range of int. Thus (for > >> >> instance) 0x8000 > >> >> unfortunately does not work, and throws a warning with -Wpedantic on > >> >> clang 3.7. > >> >> > >> >> This fixes such errors by explicitly casting as an int, doing the > >> >> desired unsigned to signed conversion. This method works on all current > >> >> architectures. Tested with FATE. > >> >> > >> >> Signed-off-by: Ganesh Ajjanagadde > >> > > >> > Simply changing the values to signed is not correct / not sufficient > >> > the code assumes that they are unsigned > >> > >> enums are ints (and hence signed). > > > > this is not true (though thats off topic but you seemed interrested in > > the C spec) > > 6.7.2.2 Enumeration specifiers > > ... > > 4 Each enumerated type shall be compatible with char, a signed integer > > type, or an > > unsigned integer type. The choice of type is implementation-defined,110) > > but shall be > > capable of representing the values of all the members of the enumeration. > > The > > enumerated type is incomplete until after the } that terminates the list > > of enumerator > > declarations. > > > > so a enum type can be almost anything the implementation likes it to > > be. 2 enums dont even need to be using the same type and this is not > > just specification talk, gcc does this actually, for example it will > > use (u)int64 as type when things dont fit in an (unsigned) int > > also on at least some embeded platforms gcc will use shorts > > for enums that fit in a short int (no i dont know which exactly but > > i read about people stumbling into this so it must happen on some > > platform) > > > > > >> I doubt code assumed that they are > >> unsigned. If code depended on these being unsigned constants, then > >> there is no way of placing them in an enum. Are you fine with a macro, > >> or do you prefer a static const style? Generally, it seems like FFmpeg > >> prefers the macro method for defining such constants/flags. > > > > if have no preferrance for anything beyond the code working > > > > If the current code is correct according to the spec (ie. the enum > gets represented as unsigned or int64), then it should just remain as > it is. i think the current code is not correct in a strict reading of the spec, Ganesh is correct about that IIUC the spec says the implementation can use any integer type it likes but it also says elsewhere that things must fit in an int [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No great genius has ever existed without some touch of madness. -- Aristotle signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/5] all: use function pointer instead of void * data pointer
On Sat, Oct 24, 2015 at 1:23 PM, Michael Niedermayer wrote: > On Sat, Oct 24, 2015 at 09:28:52AM -0400, Ganesh Ajjanagadde wrote: >> ISO C does not guarantee that functions and data live in the same >> address space. It is thus (strictly speaking) illegal to assign to a >> void * (which is a data pointer) from a function pointer. >> >> Found by enabling -Wpedantic on clang 3.7. >> >> Signed-off-by: Ganesh Ajjanagadde >> --- >> ffmpeg_opt.c | 8 >> libavcodec/hevc.c | 2 +- >> libavfilter/vf_drawtext.c | 2 +- >> libavfilter/vf_lut.c | 6 +++--- >> libavformat/async.c | 2 +- >> 5 files changed, 10 insertions(+), 10 deletions(-) > > if these dont add any new warnings then LGTM > but the commit message should rather point to code cleanup and > not ISO C They do not add warnings as far as I can tell (under standard warning flags). Reworded message to reflect that it represents a cleanup, and pushed. Thanks. > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > The bravest are surely those who have the clearest vision > of what is before them, glory and danger alike, and yet > notwithstanding go out to meet it. -- Thucydides > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/5] all: fix -Wextra-semi reported on clang
On Sat, Oct 24, 2015 at 09:33:22AM -0400, Ganesh Ajjanagadde wrote: > Hi all, > > Apologies for the copy/pasted patch, but can't send via send-email. > Copy pasted for review below, attached also for a non-clobbered > version. > > -- > > From 82b889a359925d1f9f7496c916cf24146b44e648 Mon Sep 17 00:00:00 2001 > From: Ganesh Ajjanagadde > Date: Fri, 23 Oct 2015 11:23:42 -0400 > Subject: [PATCH 1/5] all: fix -Wextra-semi reported on clang > > This fixes extra semicolons that clang 3.7 on GNU/Linux warns about. > These were trigggered when built under -Wpedantic, which essentially > checks for strict ISO compliance in numerous ways. > > Signed-off-by: Ganesh Ajjanagadde > --- > ffprobe.c | 20 +- > libavcodec/x86/hevcdsp_init.c | 637 > ++-- > libavcodec/x86/rv40dsp_init.c | 2 +- > libavcodec/x86/vp9dsp_init.c| 14 +- > libavcodec/x86/vp9dsp_init.h| 6 +- > libavcodec/x86/vp9dsp_init_16bpp_template.c | 36 +- > libavdevice/alsa.c | 6 +- > 7 files changed, 358 insertions(+), 363 deletions(-) removing one of duplicate or unneeded ; should be ok [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many that live deserve death. And some that die deserve life. Can you give it to them? Then do not be too eager to deal out death in judgement. For even the very wise cannot see all ends. -- Gandalf signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/5] all: fix -Wextra-semi reported on clang
On Sat, Oct 24, 2015 at 4:12 PM, Michael Niedermayer wrote: > On Sat, Oct 24, 2015 at 09:33:22AM -0400, Ganesh Ajjanagadde wrote: >> Hi all, >> >> Apologies for the copy/pasted patch, but can't send via send-email. >> Copy pasted for review below, attached also for a non-clobbered >> version. >> >> -- >> >> From 82b889a359925d1f9f7496c916cf24146b44e648 Mon Sep 17 00:00:00 2001 >> From: Ganesh Ajjanagadde >> Date: Fri, 23 Oct 2015 11:23:42 -0400 >> Subject: [PATCH 1/5] all: fix -Wextra-semi reported on clang >> >> This fixes extra semicolons that clang 3.7 on GNU/Linux warns about. >> These were trigggered when built under -Wpedantic, which essentially >> checks for strict ISO compliance in numerous ways. >> >> Signed-off-by: Ganesh Ajjanagadde >> --- >> ffprobe.c | 20 +- >> libavcodec/x86/hevcdsp_init.c | 637 >> ++-- >> libavcodec/x86/rv40dsp_init.c | 2 +- >> libavcodec/x86/vp9dsp_init.c| 14 +- >> libavcodec/x86/vp9dsp_init.h| 6 +- >> libavcodec/x86/vp9dsp_init_16bpp_template.c | 36 +- >> libavdevice/alsa.c | 6 +- >> 7 files changed, 358 insertions(+), 363 deletions(-) > > removing one of duplicate or unneeded ; should be ok sorry, did not follow: are you suggesting a commit message rewording? > > [...] > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Many that live deserve death. And some that die deserve life. Can you give > it to them? Then do not be too eager to deal out death in judgement. For > even the very wise cannot see all ends. -- Gandalf > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/5] all: fix -Wextra-semi reported on clang
On Sat, Oct 24, 2015 at 04:16:56PM -0400, Ganesh Ajjanagadde wrote: > On Sat, Oct 24, 2015 at 4:12 PM, Michael Niedermayer > wrote: > > On Sat, Oct 24, 2015 at 09:33:22AM -0400, Ganesh Ajjanagadde wrote: > >> Hi all, > >> > >> Apologies for the copy/pasted patch, but can't send via send-email. > >> Copy pasted for review below, attached also for a non-clobbered > >> version. > >> > >> -- > >> > >> From 82b889a359925d1f9f7496c916cf24146b44e648 Mon Sep 17 00:00:00 2001 > >> From: Ganesh Ajjanagadde > >> Date: Fri, 23 Oct 2015 11:23:42 -0400 > >> Subject: [PATCH 1/5] all: fix -Wextra-semi reported on clang > >> > >> This fixes extra semicolons that clang 3.7 on GNU/Linux warns about. > >> These were trigggered when built under -Wpedantic, which essentially > >> checks for strict ISO compliance in numerous ways. > >> > >> Signed-off-by: Ganesh Ajjanagadde > >> --- > >> ffprobe.c | 20 +- > >> libavcodec/x86/hevcdsp_init.c | 637 > >> ++-- > >> libavcodec/x86/rv40dsp_init.c | 2 +- > >> libavcodec/x86/vp9dsp_init.c| 14 +- > >> libavcodec/x86/vp9dsp_init.h| 6 +- > >> libavcodec/x86/vp9dsp_init_16bpp_template.c | 36 +- > >> libavdevice/alsa.c | 6 +- > >> 7 files changed, 358 insertions(+), 363 deletions(-) > > > > removing one of duplicate or unneeded ; should be ok > > sorry, did not follow: are you suggesting a commit message rewording? no, ill restart in verbose mode the patch seems to remove duplicate or unneeded ; in case of any duplicate ; there would be 2, either of which could be removed, i have no oppinion on which if there are any cases that have alternative resolutions except that the patch should be fine [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I know you won't believe me, but the highest form of Human Excellence is to question oneself and others. -- Socrates signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/5] all: fix incorrect usage of %p format specifier
On Sat, Oct 24, 2015 at 11:29:15AM -0400, Ganesh Ajjanagadde wrote: > On Sat, Oct 24, 2015 at 9:44 AM, Nicolas George wrote: > > Le tridi 3 brumaire, an CCXXIV, Ganesh Ajjanagadde a écrit : > >> Apologies for the copy/pasted patch, but can't send via send-email. > > > > Maybe you should take some time to tackle your email troubles? > > I have spent some time on this. Given up on gmail, as it is not in my > control, and is inconsistent. I have tried following my university's > mail configuration, but it does not work. Will need to speak with them > at some point. Until then, I view this is a reasonable compromise for > large patches. a very wild guess ... others use gmail and it works for them you use gmai and it does not if i assume you both use the same server, i would try to use strict SSL with cert checks for the connection to gmails servers. Its theoretically possible that something in your network intercepts SMTP and rejects large mails as some kind of spam/virus protection but then this is a very far fetched guess that could be far off [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB While the State exists there can be no freedom; when there is freedom there will be no State. -- Vladimir Lenin signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/5] ffprobe: add support for printing packet strings metadata as packet tags
ffprobe.xsd already contains the tag element. Signed-off-by: Marton Balint --- ffprobe.c | 16 +++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/ffprobe.c b/ffprobe.c index ac03689..f5930ae 100644 --- a/ffprobe.c +++ b/ffprobe.c @@ -77,6 +77,7 @@ static int do_show_format_tags = 0; static int do_show_frame_tags = 0; static int do_show_program_tags = 0; static int do_show_stream_tags = 0; +static int do_show_packet_tags = 0; static int show_value_unit = 0; static int use_value_prefix = 0; @@ -135,6 +136,7 @@ typedef enum { SECTION_ID_LIBRARY_VERSION, SECTION_ID_LIBRARY_VERSIONS, SECTION_ID_PACKET, +SECTION_ID_PACKET_TAGS, SECTION_ID_PACKETS, SECTION_ID_PACKETS_AND_FRAMES, SECTION_ID_PACKET_SIDE_DATA_LIST, @@ -178,7 +180,8 @@ static struct section sections[] = { [SECTION_ID_LIBRARY_VERSION] ={ SECTION_ID_LIBRARY_VERSION, "library_version", 0, { -1 } }, [SECTION_ID_PACKETS] ={ SECTION_ID_PACKETS, "packets", SECTION_FLAG_IS_ARRAY, { SECTION_ID_PACKET, -1} }, [SECTION_ID_PACKETS_AND_FRAMES] = { SECTION_ID_PACKETS_AND_FRAMES, "packets_and_frames", SECTION_FLAG_IS_ARRAY, { SECTION_ID_PACKET, -1} }, -[SECTION_ID_PACKET] = { SECTION_ID_PACKET, "packet", 0, { SECTION_ID_PACKET_SIDE_DATA_LIST, -1 } }, +[SECTION_ID_PACKET] = { SECTION_ID_PACKET, "packet", 0, { SECTION_ID_PACKET_TAGS, SECTION_ID_PACKET_SIDE_DATA_LIST, -1 } }, +[SECTION_ID_PACKET_TAGS] ={ SECTION_ID_PACKET_TAGS, "tags", SECTION_FLAG_HAS_VARIABLE_FIELDS, { -1 }, .element_name = "tag", .unique_name = "packet_tags" }, [SECTION_ID_PACKET_SIDE_DATA_LIST] ={ SECTION_ID_PACKET_SIDE_DATA_LIST, "side_data_list", SECTION_FLAG_IS_ARRAY, { SECTION_ID_PACKET_SIDE_DATA, -1 } }, [SECTION_ID_PACKET_SIDE_DATA] = { SECTION_ID_PACKET_SIDE_DATA, "side_data", 0, { -1 } }, [SECTION_ID_PIXEL_FORMATS] = { SECTION_ID_PIXEL_FORMATS, "pixel_formats", SECTION_FLAG_IS_ARRAY, { SECTION_ID_PIXEL_FORMAT, -1 } }, @@ -1762,6 +1765,16 @@ static void show_packet(WriterContext *w, AVFormatContext *fmt_ctx, AVPacket *pk if (pkt->side_data_elems) { int i; +int size; +const uint8_t *side_metadata; + +side_metadata = av_packet_get_side_data(pkt, AV_PKT_DATA_STRINGS_METADATA, &size); +if (side_metadata && size && do_show_packet_tags) { +AVDictionary *dict = NULL; +if (av_packet_unpack_dictionary(side_metadata, size, &dict) >= 0) +show_tags(w, dict, SECTION_ID_PACKET_TAGS); +av_dict_free(&dict); +} writer_print_section_header(w, SECTION_ID_PACKET_SIDE_DATA_LIST); for (i = 0; i < pkt->side_data_elems; i++) { AVPacketSideData *sd = &pkt->side_data[i]; @@ -3178,6 +3191,7 @@ int main(int argc, char **argv) SET_DO_SHOW(FRAME_TAGS, frame_tags); SET_DO_SHOW(PROGRAM_TAGS, program_tags); SET_DO_SHOW(STREAM_TAGS, stream_tags); +SET_DO_SHOW(PACKET_TAGS, packet_tags); if (do_bitexact && (do_show_program_version || do_show_library_versions)) { av_log(NULL, AV_LOG_ERROR, -- 2.1.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/5] fate: add concat demuxer tests
Signed-off-by: Marton Balint --- tests/Makefile | 1 + tests/fate-run.sh | 14 tests/fate/concatdec.mak | 12 tests/ref/fate/concat-demuxer-lavf-mxf | 1 + tests/ref/fate/concat-demuxer-lavf-mxf_d10 | 1 + tests/ref/fate/concat-demuxer-lavf-ts | 1 + tests/test_template.ffconcat | 112 + 7 files changed, 142 insertions(+) create mode 100644 tests/fate/concatdec.mak create mode 100644 tests/ref/fate/concat-demuxer-lavf-mxf create mode 100644 tests/ref/fate/concat-demuxer-lavf-mxf_d10 create mode 100644 tests/ref/fate/concat-demuxer-lavf-ts create mode 100644 tests/test_template.ffconcat diff --git a/tests/Makefile b/tests/Makefile index 7ee4a46..62544d0 100644 --- a/tests/Makefile +++ b/tests/Makefile @@ -113,6 +113,7 @@ include $(SRC_PATH)/tests/fate/audio.mak include $(SRC_PATH)/tests/fate/bmp.mak include $(SRC_PATH)/tests/fate/cdxl.mak include $(SRC_PATH)/tests/fate/checkasm.mak +include $(SRC_PATH)/tests/fate/concatdec.mak include $(SRC_PATH)/tests/fate/cover-art.mak include $(SRC_PATH)/tests/fate/demux.mak include $(SRC_PATH)/tests/fate/dfa.mak diff --git a/tests/fate-run.sh b/tests/fate-run.sh index a3938dc..2056093 100755 --- a/tests/fate-run.sh +++ b/tests/fate-run.sh @@ -249,6 +249,20 @@ gapless(){ do_md5sum $decfile3 } +concat(){ +template=$(target_path $1) +sample=$(target_path $2) + +concatfile="${outdir}/${test}.ffconcat" +packetfile="${outdir}/${test}.ffprobe" +cleanfiles="$concatfile $packetfile" + +awk "{gsub(/%SRCFILE%/, \"$sample\"); print}" $template > $concatfile +run ffprobe${PROGSUF} -show_streams -show_packets -v 0 -fflags keepside -f concat $concatfile > $packetfile + +do_md5sum $packetfile +} + mkdir -p "$outdir" # Disable globbing: command arguments may contain globbing characters and diff --git a/tests/fate/concatdec.mak b/tests/fate/concatdec.mak new file mode 100644 index 000..89d5409 --- /dev/null +++ b/tests/fate/concatdec.mak @@ -0,0 +1,12 @@ +FATE_CONCAT_TEMPLATE=tests/test_template.ffconcat + +FATE_CONCAT_DEMUXER_LAVF-$(call ENCDEC2, MPEG2VIDEO, MP2, MPEGTS)+= ts +FATE_CONCAT_DEMUXER_LAVF-$(call ENCDEC2, MPEG2VIDEO, PCM_S16LE, MXF) += mxf +FATE_CONCAT_DEMUXER_LAVF-$(call ENCDEC2, MPEG2VIDEO, PCM_S16LE, MXF) += mxf_d10 + +$(foreach D,$(FATE_CONCAT_DEMUXER_LAVF-yes),$(eval fate-concat-demuxer-lavf-$(D): ffprobe$(PROGSSUF)$(EXESUF) fate-lavf-$(D))) +$(foreach D,$(FATE_CONCAT_DEMUXER_LAVF-yes),$(eval fate-concat-demuxer-lavf-$(D): CMD = concat $(FATE_CONCAT_TEMPLATE) tests/data/lavf/lavf.$(D))) + +FATE_CONCAT_DEMUXER-$(CONFIG_CONCAT_DEMUXER) += $(FATE_CONCAT_DEMUXER_LAVF-yes:%=fate-concat-demuxer-lavf-%) + +FATE-$(CONFIG_FFPROBE) += $(FATE_CONCAT_DEMUXER-yes) diff --git a/tests/ref/fate/concat-demuxer-lavf-mxf b/tests/ref/fate/concat-demuxer-lavf-mxf new file mode 100644 index 000..a6fa554 --- /dev/null +++ b/tests/ref/fate/concat-demuxer-lavf-mxf @@ -0,0 +1 @@ +56359998da34c3957124a8928fb58f3d *tests/data/fate/concat-demuxer-lavf-mxf.ffprobe diff --git a/tests/ref/fate/concat-demuxer-lavf-mxf_d10 b/tests/ref/fate/concat-demuxer-lavf-mxf_d10 new file mode 100644 index 000..018d631 --- /dev/null +++ b/tests/ref/fate/concat-demuxer-lavf-mxf_d10 @@ -0,0 +1 @@ +89c81149b4673c60aba7cf5f27cec823 *tests/data/fate/concat-demuxer-lavf-mxf_d10.ffprobe diff --git a/tests/ref/fate/concat-demuxer-lavf-ts b/tests/ref/fate/concat-demuxer-lavf-ts new file mode 100644 index 000..2e8ba46 --- /dev/null +++ b/tests/ref/fate/concat-demuxer-lavf-ts @@ -0,0 +1 @@ +1993b3613952fa76da8c5c260a16a96a *tests/data/fate/concat-demuxer-lavf-ts.ffprobe diff --git a/tests/test_template.ffconcat b/tests/test_template.ffconcat new file mode 100644 index 000..e9b685d --- /dev/null +++ b/tests/test_template.ffconcat @@ -0,0 +1,112 @@ +#ffconcat version 1.0 +# ^ header is commented out to avoid probing therefore enable unsafe paths + +file %SRCFILE% + +file %SRCFILE% +file_packet_metadata dummy=1 +duration 1 + +file %SRCFILE% +inpoint 00:00.00 +outpoint 00:00.04 + +file %SRCFILE% +inpoint 00:00.04 +outpoint 00:00.08 + +file %SRCFILE% +inpoint 00:00.08 +outpoint 00:00.12 + +file %SRCFILE% +inpoint 00:00.12 +outpoint 00:00.16 + +file %SRCFILE% +inpoint 00:00.16 +outpoint 00:00.20 + +file %SRCFILE% +inpoint 00:00.20 +outpoint 00:00.24 + +file %SRCFILE% +inpoint 00:00.24 +outpoint 00:00.28 + +file %SRCFILE% +inpoint 00:00.28 +outpoint 00:00.32 + +file %SRCFILE% +inpoint 00:00.32 +outpoint 00:00.36 + +file %SRCFILE% +inpoint 00:00.36 +outpoint 00:00.40 + +file %SRCFILE% +inpoint 00:00.40 +outpoint 00:00.44 + +file %SRCFILE% +inpoint 00:00.44 +outpoint 00:00.48 + +file %SRCFILE% +inpoint 00:00.48 +outpoint 00:00.52 + +file %SRCFILE% +inpoint 00:00.52 +outpoint 00:00.56
[FFmpeg-devel] [PATCH 3/5] concatdec: move duration calculating code to open_file
Signed-off-by: Marton Balint --- libavformat/concatdec.c | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/libavformat/concatdec.c b/libavformat/concatdec.c index 7686f28..f262d44 100644 --- a/libavformat/concatdec.c +++ b/libavformat/concatdec.c @@ -316,6 +316,14 @@ static int open_file(AVFormatContext *avf, unsigned fileno) cat->files[fileno - 1].duration; file->file_start_time = (cat->avf->start_time == AV_NOPTS_VALUE) ? 0 : cat->avf->start_time; file->file_inpoint = (file->inpoint == AV_NOPTS_VALUE) ? file->file_start_time : file->inpoint; +if (file->duration == AV_NOPTS_VALUE) { +file->duration = cat->avf->duration; +if (file->inpoint != AV_NOPTS_VALUE) +file->duration -= (file->inpoint - file->file_start_time); +if (file->outpoint != AV_NOPTS_VALUE) +file->duration -= cat->avf->duration - (file->outpoint - file->file_start_time); +} + if ((ret = match_streams(avf)) < 0) return ret; if (file->inpoint != AV_NOPTS_VALUE) { @@ -469,14 +477,6 @@ static int open_next_file(AVFormatContext *avf) ConcatContext *cat = avf->priv_data; unsigned fileno = cat->cur_file - cat->files; -if (cat->cur_file->duration == AV_NOPTS_VALUE) { -cat->cur_file->duration = cat->avf->duration; -if (cat->cur_file->inpoint != AV_NOPTS_VALUE) -cat->cur_file->duration -= (cat->cur_file->inpoint - cat->cur_file->file_start_time); -if (cat->cur_file->outpoint != AV_NOPTS_VALUE) -cat->cur_file->duration -= cat->avf->duration - (cat->cur_file->outpoint - cat->cur_file->file_start_time); -} - if (++fileno >= cat->nb_files) { cat->eof = 1; return AVERROR_EOF; -- 2.1.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 4/5] concatdec: add metadata for file start time and duration
Signed-off-by: Marton Balint --- libavformat/concatdec.c| 6 ++ tests/ref/fate/concat-demuxer-lavf-mxf | 2 +- tests/ref/fate/concat-demuxer-lavf-mxf_d10 | 2 +- tests/ref/fate/concat-demuxer-lavf-ts | 2 +- 4 files changed, 9 insertions(+), 3 deletions(-) diff --git a/libavformat/concatdec.c b/libavformat/concatdec.c index f262d44..51b9703 100644 --- a/libavformat/concatdec.c +++ b/libavformat/concatdec.c @@ -289,6 +289,7 @@ static int open_file(AVFormatContext *avf, unsigned fileno) { ConcatContext *cat = avf->priv_data; ConcatFile *file = &cat->files[fileno]; +AVDictionaryEntry *entry; int ret; if (cat->avf) @@ -324,6 +325,11 @@ static int open_file(AVFormatContext *avf, unsigned fileno) file->duration -= cat->avf->duration - (file->outpoint - file->file_start_time); } +if (!(entry = av_dict_get(file->metadata, "lavf.concatdec.start_time", NULL, 0))) +av_dict_set_int(&file->metadata, "lavf.concatdec.start_time", file->start_time, 0); +if (!(entry = av_dict_get(file->metadata, "lavf.concatdec.duration", NULL, 0))) +av_dict_set_int(&file->metadata, "lavf.concatdec.duration", file->duration, 0); + if ((ret = match_streams(avf)) < 0) return ret; if (file->inpoint != AV_NOPTS_VALUE) { diff --git a/tests/ref/fate/concat-demuxer-lavf-mxf b/tests/ref/fate/concat-demuxer-lavf-mxf index a6fa554..d6c82d6 100644 --- a/tests/ref/fate/concat-demuxer-lavf-mxf +++ b/tests/ref/fate/concat-demuxer-lavf-mxf @@ -1 +1 @@ -56359998da34c3957124a8928fb58f3d *tests/data/fate/concat-demuxer-lavf-mxf.ffprobe +23cd3acf3db9ee19228f381f05f1f3b9 *tests/data/fate/concat-demuxer-lavf-mxf.ffprobe diff --git a/tests/ref/fate/concat-demuxer-lavf-mxf_d10 b/tests/ref/fate/concat-demuxer-lavf-mxf_d10 index 018d631..08777f7 100644 --- a/tests/ref/fate/concat-demuxer-lavf-mxf_d10 +++ b/tests/ref/fate/concat-demuxer-lavf-mxf_d10 @@ -1 +1 @@ -89c81149b4673c60aba7cf5f27cec823 *tests/data/fate/concat-demuxer-lavf-mxf_d10.ffprobe +bd1c6cc871fe5193186a03554ebc84c1 *tests/data/fate/concat-demuxer-lavf-mxf_d10.ffprobe diff --git a/tests/ref/fate/concat-demuxer-lavf-ts b/tests/ref/fate/concat-demuxer-lavf-ts index 2e8ba46..a01f712 100644 --- a/tests/ref/fate/concat-demuxer-lavf-ts +++ b/tests/ref/fate/concat-demuxer-lavf-ts @@ -1 +1 @@ -1993b3613952fa76da8c5c260a16a96a *tests/data/fate/concat-demuxer-lavf-ts.ffprobe +728e773e5009f7f652c1677573b6c8d2 *tests/data/fate/concat-demuxer-lavf-ts.ffprobe -- 2.1.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 5/5] lavfi/select: add support for concatdec_select option
This option can be used to select useful frames from an ffconcat file which is using inpoints and outpoints but where the source files are not intra frame only. Signed-off-by: Marton Balint --- doc/filters.texi | 17 + libavfilter/f_select.c | 20 2 files changed, 37 insertions(+) diff --git a/doc/filters.texi b/doc/filters.texi index 5a35bde..093eec5 100644 --- a/doc/filters.texi +++ b/doc/filters.texi @@ -13160,6 +13160,16 @@ value between 0 and 1 to indicate a new scene; a low value reflects a low probability for the current frame to introduce a new scene, while a higher value means the current frame is more likely to be one (see the example below) +@item concatdec_select +The concat demuxer sets the @var{lavf.concat.start_time} and the +@var{lavf.concat.duration} packet metadata values which are also present in the +decoded frames. These metadata entries contain the start_time and the duration +of the respective file segments in the concatenated output. + +The @var{concatdec_select} variable is -1 if the frame pts is at least +start_time but less than start_time + duration, 0 otherwise, and NaN if the +mentioned metadata entires are not present. + @end table The default value of the select expression is "1". @@ -13234,6 +13244,13 @@ Send even and odd frames to separate outputs, and compose them: @example select=n=2:e='mod(n, 2)+1' [odd][even]; [odd] pad=h=2*ih [tmp]; [tmp][even] overlay=y=h @end example + +@item +Select useful frames from an ffconcat file which is using inpoints and +outpoints but where the source files are not intra frame only. +@example +ffmpeg -copyts -vsync 0 -i input.ffconcat -vf select=concatdec_select -af aselect=concatdec_select output.avi +@end example @end itemize @section selectivecolor diff --git a/libavfilter/f_select.c b/libavfilter/f_select.c index 2b926e1..d5f1470 100644 --- a/libavfilter/f_select.c +++ b/libavfilter/f_select.c @@ -82,6 +82,8 @@ static const char *const var_names[] = { "scene", +"concatdec_select", ///< frame usefulness based on pts and frame metadata originating from the concat demuxer + NULL }; @@ -132,6 +134,8 @@ enum var_name { VAR_SCENE, +VAR_CONCATDEC_SELECT, + VAR_VARS_NB }; @@ -278,6 +282,21 @@ static double get_scene_score(AVFilterContext *ctx, AVFrame *frame) return ret; } +static double get_concatdec_select(AVFrame *frame, int64_t pts) +{ +AVDictionary *metadata = av_frame_get_metadata(frame); +AVDictionaryEntry *e1 = av_dict_get(metadata, "lavf.concatdec.start_time", NULL, 0); +AVDictionaryEntry *e2 = av_dict_get(metadata, "lavf.concatdec.duration", NULL, 0); +if (e1 && e1->value && e2 && e2->value) { +int64_t start_time = strtoll(e1->value, NULL, 10); +int64_t duration = strtoll(e2->value, NULL, 10); +if (pts >= start_time && pts < start_time + duration) +return -1; +return 0; +} +return NAN; +} + #define D2TS(d) (isnan(d) ? AV_NOPTS_VALUE : (int64_t)(d)) #define TS2D(ts) ((ts) == AV_NOPTS_VALUE ? NAN : (double)(ts)) @@ -297,6 +316,7 @@ static void select_frame(AVFilterContext *ctx, AVFrame *frame) select->var_values[VAR_T ] = TS2D(frame->pts) * av_q2d(inlink->time_base); select->var_values[VAR_POS] = av_frame_get_pkt_pos(frame) == -1 ? NAN : av_frame_get_pkt_pos(frame); select->var_values[VAR_KEY] = frame->key_frame; +select->var_values[VAR_CONCATDEC_SELECT] = get_concatdec_select(frame, av_rescale_q(frame->pts, inlink->time_base, AV_TIME_BASE_Q)); switch (inlink->type) { case AVMEDIA_TYPE_AUDIO: -- 2.1.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Can we drop OpenJPEG 1.5 in favor of 2.x?
On Sat, Oct 24, 2015 at 11:11 AM, Carl Eugen Hoyos wrote: > James Almer gmail.com> writes: > > > Why does configure even check for 2.x if the actual > > lavc wrappers don't currently support it? > > It is possible to use openjpeg2 with current > FFmpeg (I use it for testing) but it is > everything but user-friendly. > Kind of. The openmj2 library that openjpeg2 comes with hasn't been touched in ~3 years[1] (the only recent commits to that part of the library have been cosmetic/build related, so it's substantially out of date compared to openjp2). This patch updates ffmpeg to use openjp2, not openmj2 (as it currently does). openjp2 has a ton of fixes and improvements. I have no idea why the openmj2 library exists, or why its just sitting there stagnating in the OpenJPEG repo. It'll be nice to get ffmpeg off of it. [1]: https://github.com/uclouvain/openjpeg/commits/master/src/lib/openmj2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Can we drop OpenJPEG 1.5 in favor of 2.x?
On Sat, Oct 24, 2015 at 11:28 AM, Timothy Gu wrote: > On Sat, Oct 24, 2015 at 11:03 AM James Almer wrote: > > > Gentoo and Debian both seem to ship it. Arch does as well but on their > > Community repository (ffmpeg adopting it may be incentive enough for them > > to move it to Extra). > > > In fact, at least two of the reverse dependencies (out of 8, not counting > duplicates) of the Arch openjpeg package already support openjpeg2 (poppler > and gst-plugins-bad). > > I would prefer if we keep compat for both since Ubuntu 14.04 LTS doesn't > have openjpeg2 yet, and that's unfortunately not going away any time soon. Crap, you're right. Before I started this I checked if Ubuntu had openjpeg2 and they do[1] but it turns out it's really just openjpeg 1.3 (if anyone knows why they made a separate package named libopenjpeg2 when it's really openjpeg 1.3, I'd be curious to learn why). Well that settles it for me, then. I'll keep compatibility with 1.5. [1]: http://packages.ubuntu.com/trusty/libopenjpeg2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/5] all: fix -Wextra-semi reported on clang
On Sat, Oct 24, 2015 at 4:28 PM, Michael Niedermayer wrote: > On Sat, Oct 24, 2015 at 04:16:56PM -0400, Ganesh Ajjanagadde wrote: >> On Sat, Oct 24, 2015 at 4:12 PM, Michael Niedermayer >> wrote: >> > On Sat, Oct 24, 2015 at 09:33:22AM -0400, Ganesh Ajjanagadde wrote: >> >> Hi all, >> >> >> >> Apologies for the copy/pasted patch, but can't send via send-email. >> >> Copy pasted for review below, attached also for a non-clobbered >> >> version. >> >> >> >> -- >> >> >> >> From 82b889a359925d1f9f7496c916cf24146b44e648 Mon Sep 17 00:00:00 2001 >> >> From: Ganesh Ajjanagadde >> >> Date: Fri, 23 Oct 2015 11:23:42 -0400 >> >> Subject: [PATCH 1/5] all: fix -Wextra-semi reported on clang >> >> >> >> This fixes extra semicolons that clang 3.7 on GNU/Linux warns about. >> >> These were trigggered when built under -Wpedantic, which essentially >> >> checks for strict ISO compliance in numerous ways. >> >> >> >> Signed-off-by: Ganesh Ajjanagadde >> >> --- >> >> ffprobe.c | 20 +- >> >> libavcodec/x86/hevcdsp_init.c | 637 >> >> ++-- >> >> libavcodec/x86/rv40dsp_init.c | 2 +- >> >> libavcodec/x86/vp9dsp_init.c| 14 +- >> >> libavcodec/x86/vp9dsp_init.h| 6 +- >> >> libavcodec/x86/vp9dsp_init_16bpp_template.c | 36 +- >> >> libavdevice/alsa.c | 6 +- >> >> 7 files changed, 358 insertions(+), 363 deletions(-) >> > >> > removing one of duplicate or unneeded ; should be ok >> >> sorry, did not follow: are you suggesting a commit message rewording? > > no, ill restart in verbose mode > the patch seems to remove duplicate or unneeded ; > in case of any duplicate ; there would be 2, either of which could be > removed, i have no oppinion on which if there are any cases that have > alternative resolutions > except that the patch should be fine ok, pushed. > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > I know you won't believe me, but the highest form of Human Excellence is > to question oneself and others. -- Socrates > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/3] avfilter/vf_deshake: use a void * comparator for consistency
For generality, qsort uses a comparator whose elements are void *. This makes the comparator have such a form, and thus makes the void * cast of the comparator pointer useless. Furthermore, this makes the code more consistent with other usages of qsort across the codebase. Signed-off-by: Ganesh Ajjanagadde --- libavfilter/vf_deshake.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/libavfilter/vf_deshake.c b/libavfilter/vf_deshake.c index ac13ecd..3f96f7d 100644 --- a/libavfilter/vf_deshake.c +++ b/libavfilter/vf_deshake.c @@ -91,9 +91,10 @@ static const AVOption deshake_options[] = { AVFILTER_DEFINE_CLASS(deshake); -static int cmp(const double *a, const double *b) +static int cmp(const void *a, const void *b) { -return *a < *b ? -1 : ( *a > *b ? 1 : 0 ); +double va = *(double *)a, vb = *(double *)b; +return va < vb ? -1 : ( va > vb ? 1 : 0 ); } /** @@ -105,7 +106,7 @@ static double clean_mean(double *values, int count) int cut = count / 5; int x; -qsort(values, count, sizeof(double), (void*)cmp); +qsort(values, count, sizeof(double), cmp); for (x = cut; x < count - cut; x++) { mean += values[x]; -- 2.6.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/3] avutil/tree: improve documentation for av_tree_find, av_tree_insert
This documents the additional constness, and provides a useful libc reference for the API specification of the comparator. Signed-off-by: Ganesh Ajjanagadde --- libavutil/tree.h | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/libavutil/tree.h b/libavutil/tree.h index a14fa91..16dd8de 100644 --- a/libavutil/tree.h +++ b/libavutil/tree.h @@ -56,6 +56,8 @@ struct AVTreeNode *av_tree_node_alloc(void); * @param next If next is not NULL, then next[0] will contain the previous * element and next[1] the next element. If either does not exist, * then the corresponding entry in next is unchanged. + * @param cmp compare function used to compare elements in the tree, + *API identical to that of libc's qsort * @return An element with cmp(key, elem) == 0 or NULL if no such element * exists in the tree. */ @@ -99,7 +101,8 @@ void *av_tree_find(const struct AVTreeNode *root, void *key, * return av_tree_insert(rootp, key, cmp, next); * } * @endcode - * @param cmp compare function used to compare elements in the tree + * @param cmp compare function used to compare elements in the tree, API identical + *to that of libc's qsort * @return If no insertion happened, the found element; if an insertion or * removal happened, then either key or NULL will be returned. * Which one it is depends on the tree state and the implementation. You -- 2.6.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/3] avutil/tree: add additional const qualifier to the comparator
libc's qsort comparator has a const qualifier on both arguments. This adds a missing const qualifier to exactly match the comparator API. Existing usages of av_tree_find, av_tree_insert are appropriately modified: type signature changes of the comparators, and removal of unnecessary void * casts of function pointers. Signed-off-by: Ganesh Ajjanagadde --- libavfilter/vf_drawtext.c | 2 +- libavformat/cache.c | 2 +- libavformat/nut.c | 12 +++- libavformat/nut.h | 4 ++-- libavformat/nutdec.c | 6 +++--- libavformat/nutenc.c | 2 +- libavutil/tree.c | 4 ++-- libavutil/tree.h | 4 ++-- 8 files changed, 19 insertions(+), 17 deletions(-) diff --git a/libavfilter/vf_drawtext.c b/libavfilter/vf_drawtext.c index 5c4676e..fc77be4 100644 --- a/libavfilter/vf_drawtext.c +++ b/libavfilter/vf_drawtext.c @@ -288,7 +288,7 @@ typedef struct Glyph { int bitmap_top; } Glyph; -static int glyph_cmp(void *key, const void *b) +static int glyph_cmp(const void *key, const void *b) { const Glyph *a = key, *bb = b; int64_t diff = (int64_t)a->code - (int64_t)bb->code; diff --git a/libavformat/cache.c b/libavformat/cache.c index d3d12bb..7f6b6e4 100644 --- a/libavformat/cache.c +++ b/libavformat/cache.c @@ -65,7 +65,7 @@ typedef struct Context { int read_ahead_limit; } Context; -static int cmp(void *key, const void *node) +static int cmp(const void *key, const void *node) { return (*(int64_t *) key) - ((const CacheEntry *) node)->logical_pos; } diff --git a/libavformat/nut.c b/libavformat/nut.c index c6fdb0b..b68ed6e 100644 --- a/libavformat/nut.c +++ b/libavformat/nut.c @@ -237,14 +237,16 @@ int64_t ff_lsb2full(StreamContext *stream, int64_t lsb) return ((lsb - delta) & mask) + delta; } -int ff_nut_sp_pos_cmp(const Syncpoint *a, const Syncpoint *b) +int ff_nut_sp_pos_cmp(const void *a, const void *b) { -return ((a->pos - b->pos) >> 32) - ((b->pos - a->pos) >> 32); +Syncpoint va = *(Syncpoint *)a, vb = *(Syncpoint *)b; +return ((va.pos - vb.pos) >> 32) - ((vb.pos - va.pos) >> 32); } -int ff_nut_sp_pts_cmp(const Syncpoint *a, const Syncpoint *b) +int ff_nut_sp_pts_cmp(const void *a, const void *b) { -return ((a->ts - b->ts) >> 32) - ((b->ts - a->ts) >> 32); +Syncpoint va = *(Syncpoint *)a, vb = *(Syncpoint *)b; +return ((va.ts - vb.ts) >> 32) - ((vb.ts - va.ts) >> 32); } int ff_nut_add_sp(NUTContext *nut, int64_t pos, int64_t back_ptr, int64_t ts) @@ -263,7 +265,7 @@ int ff_nut_add_sp(NUTContext *nut, int64_t pos, int64_t back_ptr, int64_t ts) sp->pos = pos; sp->back_ptr = back_ptr; sp->ts = ts; -av_tree_insert(&nut->syncpoints, sp, (void *) ff_nut_sp_pos_cmp, &node); +av_tree_insert(&nut->syncpoints, sp, ff_nut_sp_pos_cmp, &node); if (node) { av_free(sp); av_free(node); diff --git a/libavformat/nut.h b/libavformat/nut.h index 45aa55c..a4409ee 100644 --- a/libavformat/nut.h +++ b/libavformat/nut.h @@ -132,8 +132,8 @@ typedef struct Dispositions { void ff_nut_reset_ts(NUTContext *nut, AVRational time_base, int64_t val); int64_t ff_lsb2full(StreamContext *stream, int64_t lsb); -int ff_nut_sp_pos_cmp(const Syncpoint *a, const Syncpoint *b); -int ff_nut_sp_pts_cmp(const Syncpoint *a, const Syncpoint *b); +int ff_nut_sp_pos_cmp(const void *a, const void *b); +int ff_nut_sp_pts_cmp(const void *a, const void *b); int ff_nut_add_sp(NUTContext *nut, int64_t pos, int64_t back_ptr, int64_t ts); void ff_nut_free_sp(NUTContext *nut); diff --git a/libavformat/nutdec.c b/libavformat/nutdec.c index 63b0cd2..deceb03 100644 --- a/libavformat/nutdec.c +++ b/libavformat/nutdec.c @@ -1271,7 +1271,7 @@ static int read_seek(AVFormatContext *s, int stream_index, pos2 = st->index_entries[index].pos; ts = st->index_entries[index].timestamp; } else { -av_tree_find(nut->syncpoints, &dummy, (void *) ff_nut_sp_pts_cmp, +av_tree_find(nut->syncpoints, &dummy, ff_nut_sp_pts_cmp, (void **) next_node); av_log(s, AV_LOG_DEBUG, "%"PRIu64"-%"PRIu64" %"PRId64"-%"PRId64"\n", next_node[0]->pos, next_node[1]->pos, next_node[0]->ts, @@ -1286,7 +1286,7 @@ static int read_seek(AVFormatContext *s, int stream_index, if (!(flags & AVSEEK_FLAG_BACKWARD)) { dummy.pos= pos + 16; next_node[1] = &nopts_sp; -av_tree_find(nut->syncpoints, &dummy, (void *) ff_nut_sp_pos_cmp, +av_tree_find(nut->syncpoints, &dummy, ff_nut_sp_pos_cmp, (void **) next_node); pos2 = ff_gen_search(s, -2, dummy.pos, next_node[0]->pos, next_node[1]->pos, next_node[1]->pos, @@ -1297,7 +1297,7 @@ static int read_seek(AVFormatContext *s, int stream_index, // FIXME dir but I think it does not matter } dummy.pos = pos; -sp = av_tree_find(nut->syncpoints
[FFmpeg-devel] [PATCH] x86/intmath: allow the source operand for icc/icl ff_ctzll to be a memory location
This gives the compiler some flexibility Signed-off-by: James Almer --- libavutil/x86/intmath.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavutil/x86/intmath.h b/libavutil/x86/intmath.h index 7881e3c..10d3e7f 100644 --- a/libavutil/x86/intmath.h +++ b/libavutil/x86/intmath.h @@ -36,7 +36,7 @@ static av_always_inline av_const int ff_ctzll_x86(long long v) { # if ARCH_X86_64 uint64_t c; -__asm__("bsfq %1,%0" : "=r" (c) : "r" (v)); +__asm__ ("bsfq %1,%0" : "=r" (c) : "rm" (v)); return c; # else return ((uint32_t)v == 0) ? _bit_scan_forward((uint32_t)(v >> 32)) + 32 : _bit_scan_forward((uint32_t)v); -- 2.6.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel