Re: [FFmpeg-devel] possible farewell; dev policy clarification
I agree with the others. There's quite a lot of noise on the ML and having some of your trivial patches (e.g. replacing functions with FFmpeg defined ones) merged into one would help to decrease it. >Currently I am trying to get rid of a >lot of the last aspect to create a foundation for myself to work on >other things. Huh? What's so unclean about the current codebase that you simply can't work on anything else? Can you really not sleep at night if you know there's an unchecked malloc call (never a problem with a non-ancient OS) somewhere in an obscure 90's video game decoder which theoretically works but people lost the only available samples 5 years ago? What other things? Also be careful, the definition of a "foundation to work on" could vary between people. Hence a reason for reviews. >Part of that defense (for me) is examining compiler warnings, Many compilers (don't) warn about things that other compilers would. There compilers have versions which (don't) warn about some things that other versions do. It's pointless and conforming to a method that most compilers don't warn about can be hacky and may cause some compilers difficulty in actually compiling. It's best to choose the absolute least hacky way which works well with the newest (if sane, if not, newest sane) version (!) of the most popular compiler and doesn't emit a warning with the current "-W*" arguments or just keep the current status quo. >fixing undefined behavior, How does one fixed something undefined? Anyway, absolutely nothing wrong with justified undefined behavior, it's just working around the fact that: >conforming to standards when possible the standards are not that well defined or policed or sometimes sane (not really the case with C) to begin with. Rust wants to change that but it just takes away the fun of programming (in C & others). Any compiler which does something different than what other compilers do under undefined behavior which you rely on is in fact a not-very-sane compiler and makes people sad because if many people are stuck with that not-very-sane compiler it means there is a need for a special workaround for the not-very-sane compiler. Which then encourages other compilers to also have some other special way of doing undefined behavior and thus bring more ugly hacks. So yeah, sticking to the standard when possible is the best. From another email in this thread: >None of these things are satisfying, but to be honest, I am not >looking for satisfaction from FFmpeg. So you're not finding your work satisfying, you're probably not getting paid, you're bothering yourself over getting other people bothered by your work, yet you still do it? This is beyond logic. I suggest you make your mind up and either find joy from doing something or money or both. >I am looking for a way to channel frittered away energy obtained >during my transition from undergraduate to graduate life and its >associated increase in flexibility of time allocation. >In other words, I want a way to spend my down-time that is technical >in character. You wrote this as if writing a job application; this is a mailing list of equal adults (more or less) interested in drama, popcorn and the development of FFmpeg, in that order :) Though if you wrote this in a job application I'd hire you. Which is again more or less what anyone would do after they graduate: finding a job. Though nowadays there are other alternatives becoming popular: "finding yourself (by exploring the world)", "football!", "NEETdom", "soccer", "FOOTBALL!", "professional Quake 3 player", etc. >av_gcd patches >algorithmic improvements Yes, your work on ff_ctz was very nice, kudos, I liked it. On 30 October 2015 at 11:34, Ganesh Ajjanagadde wrote: > Hi all, > > Apologies for the length of the email, but there is a lot of stuff I > would like to cover due to my absence on IRC or other venues for "non > patch related" discussion. > > There has been a lot said and still being said regarding some patches > I sent and associated discussion. Issues not related to patches in a > technical sense are being discussed privately. > > In the meantime, I have noticed an increased level of hostility on > ffmpeg-devel lately, both from my end as well as from others. I do not > wish to escalate it further, and want to let work progress as smoothly > as possible. > > In fact, I repeat a statement I made earlier: if overall people think > that if I leave better and more work will be done for the project, I > will gladly do so. That is the only thing I wish for: FFmpeg becoming > better. To clarify a possible confusion on IRC: I by no means intend > to work on Libav - either I work for FFmpeg, or not work at all on > multimedia. This statement holds true regardless of what people > express about the work I do here, whether I am kicked out, etc. > > The reason I repeat this question of leaving is because I dug through > IRC archives, trying to understand better what people here think of > the work I
Re: [FFmpeg-devel] PATCH: gdigrab work for DPI in windows
On 10/28/15, Matt Oliver wrote: > On 5 October 2015 at 20:05, Matt Oliver wrote: > >> On 5 October 2015 at 19:29, Matt Oliver wrote: >> >>> On 30 September 2015 at 02:48, wm4 wrote: >>> On Wed, 23 Sep 2015 12:04:43 -0600 Roger Pack wrote: > From 6a972dda58bd5ab31524cd4e5326b4bcdeaeaa8c Mon Sep 17 00:00:00 2001 > From: rogerdpack > Date: Wed, 23 Sep 2015 12:03:27 -0600 > Subject: [PATCH] gdigrab: grab right desktop size if DPI in use, based on > patch from Alexander Brotzge > > Signed-off-by: rogerdpack > --- > libavdevice/gdigrab.c | 44 +--- > 1 file changed, 29 insertions(+), 15 deletions(-) > > diff --git a/libavdevice/gdigrab.c b/libavdevice/gdigrab.c > index 9a185d4..b0faf45 100644 > --- a/libavdevice/gdigrab.c > +++ b/libavdevice/gdigrab.c > @@ -235,6 +235,9 @@ gdigrab_read_header(AVFormatContext *s1) > AVStream *st = NULL; > > int bpp; > +int vertres; > +int desktopvertres; > +float scale; > RECT virtual_rect; > RECT clip_rect; > BITMAP bmp; > @@ -263,14 +266,34 @@ gdigrab_read_header(AVFormatContext *s1) > goto error; > } > > -if (hwnd) { > -GetClientRect(hwnd, &virtual_rect); > -} else { > +/* This will get the device context for the selected window, or > if > + * none, the primary screen */ > +source_hdc = GetDC(hwnd); > +if (!source_hdc) { > +WIN32_API_ERROR("Couldn't get window device context"); > +ret = AVERROR(EIO); > +goto error; > +} > +bpp = GetDeviceCaps(source_hdc, BITSPIXEL); > + > +scale = 1.0; > +if (hwnd == NULL) { > + /* desktop -- get the right height and width for scaling DPI */ > + vertres = GetDeviceCaps(source_hdc, VERTRES); > + desktopvertres = GetDeviceCaps(source_hdc, DESKTOPVERTRES); > + scale = (float) desktopvertres / (float) vertres; > +} >>> >>> This seems a little redundant as scale is only being set when hwnd is >>> null however in the below lines its then being used in the opposite >>> conditional. Since this checks for hwnd essentially being non null then >>> scale is always going to be the inital value of 1. >>> >>> > + if (hwnd) { > + GetClientRect(hwnd, &virtual_rect); > + virtual_rect.right = virtual_rect.right * scale; > + virtual_rect.bottom = virtual_rect.bottom * scale; > + } else { > virtual_rect.left = GetSystemMetrics(SM_XVIRTUALSCREEN); > virtual_rect.top = GetSystemMetrics(SM_YVIRTUALSCREEN); > -virtual_rect.right = virtual_rect.left + GetSystemMetrics(SM_CXVIRTUALSCREEN); > -virtual_rect.bottom = virtual_rect.top + GetSystemMetrics(SM_CYVIRTUALSCREEN); > -} > +virtual_rect.right = (virtual_rect.left + GetSystemMetrics(SM_CXVIRTUALSCREEN)) * scale; > +virtual_rect.bottom = (virtual_rect.top + GetSystemMetrics(SM_CYVIRTUALSCREEN)) * scale; > + } >>> >>> This if else could be combined with the above if as scale is only a value >>> different to 1 in the 'else' case. Also as wm4 said it would probably be >>> better to keep the scale factors as ints. >>> >>> > > /* If no width or height set, use full screen/window area */ > if (!gdigrab->width || !gdigrab->height) { > @@ -299,15 +322,6 @@ gdigrab_read_header(AVFormatContext *s1) > goto error; > } > > -/* This will get the device context for the selected window, or > if > - * none, the primary screen */ > -source_hdc = GetDC(hwnd); > -if (!source_hdc) { > -WIN32_API_ERROR("Couldn't get window device context"); > -ret = AVERROR(EIO); > -goto error; > -} > -bpp = GetDeviceCaps(source_hdc, BITSPIXEL); > > if (name) { > av_log(s1, AV_LOG_INFO, >>> >>> >>> However I think the basic dpi scaling technique is correct. However I >>> would think it should be more along the lines of the modifications Ive >>> attached. >>> >> >> Woops, allow me to try that again without windows messing up the patches >> line endings. >> > > Does anyone have any issues with the updated patch or can it be pushed? OK sorry for the delay finally got around to testing it and LGTM recommend commit (I'm a gdigrab maintainer). Cheers! -roger- ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/vf_deshake: replace qsort with AV_QSORT
On Fri, Oct 30, 2015 at 07:10:52PM -0400, Ganesh Ajjanagadde wrote: > qsort is called indirectly in filter_frame, suggesting its performance > criticality. AV_QSORT is substantially faster due to the inlining of the > comparison callback. Thus, the increase in performance should be worth > the increase in binary size. > > Sample benchmark (x86-64, Haswell, GNU/Linux): > File: original from https://trac.ffmpeg.org/ticket/1430 > command: ffmpeg -stream_loop 8 -i file.webm -vf deshake=rx=64:ry=64 -f null - > > Timer truncated at 1024 runs. > new: > 28260 decicycles in qsort, 1 runs, 0 skips > 35570 decicycles in qsort, 2 runs, 0 skips > 39010 decicycles in qsort, 4 runs, 0 skips > 46897 decicycles in qsort, 8 runs, 0 skips > 40442 decicycles in qsort, 16 runs, 0 skips > 41611 decicycles in qsort, 32 runs, 0 skips > 40345 decicycles in qsort, 64 runs, 0 skips > 38967 decicycles in qsort, 128 runs, 0 skips > 38647 decicycles in qsort, 256 runs, 0 skips > 40238 decicycles in qsort, 512 runs, 0 skips > 39676 decicycles in qsort,1024 runs, 0 skips > > old: > 1740280 decicycles in qsort, 1 runs, 0 skips > 923560 decicycles in qsort, 2 runs, 0 skips > 511330 decicycles in qsort, 4 runs, 0 skips > 309720 decicycles in qsort, 8 runs, 0 skips > 194900 decicycles in qsort, 16 runs, 0 skips > 142686 decicycles in qsort, 32 runs, 0 skips > 112516 decicycles in qsort, 64 runs, 0 skips > 98166 decicycles in qsort, 128 runs, 0 skips > 88147 decicycles in qsort, 256 runs, 0 skips > 88706 decicycles in qsort, 512 runs, 0 skips > 86783 decicycles in qsort,1024 runs, 0 skips > > Signed-off-by: Ganesh Ajjanagadde > --- > libavfilter/vf_deshake.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) LGTM nice speedup thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The misfortune of the wise is better than the prosperity of the fool. -- Epicurus signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 11/11] avutil/rational: use frexp rather than ad-hoc log to get floating point exponent
On Fri, Oct 30, 2015 at 7:14 PM, Michael Niedermayer wrote: > On Thu, Oct 29, 2015 at 12:20:09AM -0400, Ganesh Ajjanagadde wrote: >> This simplifies and cleans up the code. >> Furthermore, it is much faster due to absence of the slow log computation. >> >> Signed-off-by: Ganesh Ajjanagadde >> --- >> libavutil/rational.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) > > LGTM and nice speedup! pushed, thanks. > > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Dictatorship naturally arises out of democracy, and the most aggravated > form of tyranny and slavery out of the most extreme liberty. -- Plato > > ___ > 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] configure+libm.h: add fmin/fmax/fminf/fmaxf emulation
On Fri, Oct 30, 2015 at 7:29 PM, Michael Niedermayer wrote: > On Fri, Oct 30, 2015 at 06:53:34PM -0400, Ganesh Ajjanagadde wrote: >> On Fri, Oct 30, 2015 at 6:35 PM, Michael Niedermayer >> wrote: >> > From: Michael Niedermayer >> > >> > This should fix the build failure of avf_showcqt.c >> > >> > An alternative solution would be to add a check for fmin/fmax to >> > fate-source and >> > then to replace them by FFMIN/FFMAX, i can do that if preferred? >> > >> > Untested due to lack of a affected platform >> >> I recall some interest on my end to get fmin, fmax etc for different >> reasons, and it was remarked that commit >> 4436a8f44dedc83767b3d9da9beb85d1fae2ca30 may be relevant. The summary >> seems to be that getting it to work on all platforms is not so simple. > > :/ > ill replace the problematic ones by FFMIN/MAX for now so the build > failure on the affected msvc platforms is fixed > tieing a build fix to this complexity would be unwise > > >> I am definitely interested in getting it to work in order to replace >> FFMAX/FFMIN for floating point in especially libavfilter. This will >> allow better nan signalling at a slight performance cost. > > would that performance cost affect all systems or just ones not > having fmin/fmax ? > i think affecting all systems would be bad A correct fmin and fmax will be slower than FFMIN/FFMAX, simply because they do NaN handling. How much slower, I have not tested. Also note that flags may be passed to the compiler to ignore NaN's, something which can possibly be done locally if desired. However, I view FFMAX/FFMIN as the cleaner solution if NaN signalling/propagation is not an issue, so I may not pursue this. > > [...] > -- > 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] configure+libm.h: add fmin/fmax/fminf/fmaxf emulation
On Fri, Oct 30, 2015 at 7:33 PM, Michael Niedermayer wrote: > On Sat, Oct 31, 2015 at 12:14:44AM +0100, Hendrik Leppkes wrote: >> On Fri, Oct 30, 2015 at 11:35 PM, Michael Niedermayer >> wrote: >> > From: Michael Niedermayer >> > >> > This should fix the build failure of avf_showcqt.c >> > >> > An alternative solution would be to add a check for fmin/fmax to >> > fate-source and >> > then to replace them by FFMIN/FFMAX, i can do that if preferred? >> > >> > Untested due to lack of a affected platform >> > >> > Signed-off-by: Michael Niedermayer >> > --- >> > configure|8 >> > libavutil/libm.h | 28 >> > 2 files changed, 36 insertions(+) >> > >> > diff --git a/configure b/configure >> > index 95790f4..e6f5d2c 100755 >> > --- a/configure >> > +++ b/configure >> > @@ -1770,6 +1770,10 @@ MATH_FUNCS=" >> > exp2 >> > exp2f >> > expf >> > +fmax >> > +fmaxf >> > +fmin >> > +fminf >> > isinf >> > isnan >> > ldexpf >> > @@ -5304,6 +5308,10 @@ check_lib math.h sin -lm && LIBM="-lm" >> > disabled crystalhd || check_lib libcrystalhd/libcrystalhd_if.h >> > DtsCrystalHDVersion -lcrystalhd || disable crystalhd >> > >> > atan2f_args=2 >> > +fmax_args=2 >> > +fmaxf_args=2 >> > +fmin_args=2 >> > +fminf_args=2 >> > copysign_args=2 >> > ldexpf_args=2 >> > powf_args=2 >> > diff --git a/libavutil/libm.h b/libavutil/libm.h >> > index 6c17b28..ba837a2 100644 >> > --- a/libavutil/libm.h >> > +++ b/libavutil/libm.h >> > @@ -43,6 +43,34 @@ >> > #define atan2f(y, x) ((float)atan2(y, x)) >> > #endif >> > >> > +#if !HAVE_FMAX >> > +#undef fmax >> > +static av_always_inline double fmax(double x, double y) >> > +{ >> > +if (x < y) return y; >> > +else return x; >> > +} >> > +#endif >> > + >> > +#if !HAVE_FMIN >> > +#undef fmin >> > +static av_always_inline double fmin(double x, double y) >> > +{ >> > +if (x < y) return x; >> > +else return y; >> > +} >> > +#endif >> >> Wasn't there a concern that these emulations don't behave identical to >> the C library versions in regards to NaN handling? >> I faintly remember something in the previous discussion. > > yes, i forgot about that :( > i replaced them by FFMIN / FFMAX I might be missing your exact usage of FFMIN/FFMAX, but note FFMIN/FFMAX by themselves do not do any NaN handling. Maybe this confusion will be clarified when you post v2. Ideas of achieving this may be easily obtained in the commit I mentioned above: 4436a8f44dedc83767b3d9da9beb85d1fae2ca30. > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Those who are best at talking, realize last or never when they are wrong. > > ___ > 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] configure+libm.h: add fmin/fmax/fminf/fmaxf emulation
On Sat, Oct 31, 2015 at 12:14:44AM +0100, Hendrik Leppkes wrote: > On Fri, Oct 30, 2015 at 11:35 PM, Michael Niedermayer > wrote: > > From: Michael Niedermayer > > > > This should fix the build failure of avf_showcqt.c > > > > An alternative solution would be to add a check for fmin/fmax to > > fate-source and > > then to replace them by FFMIN/FFMAX, i can do that if preferred? > > > > Untested due to lack of a affected platform > > > > Signed-off-by: Michael Niedermayer > > --- > > configure|8 > > libavutil/libm.h | 28 > > 2 files changed, 36 insertions(+) > > > > diff --git a/configure b/configure > > index 95790f4..e6f5d2c 100755 > > --- a/configure > > +++ b/configure > > @@ -1770,6 +1770,10 @@ MATH_FUNCS=" > > exp2 > > exp2f > > expf > > +fmax > > +fmaxf > > +fmin > > +fminf > > isinf > > isnan > > ldexpf > > @@ -5304,6 +5308,10 @@ check_lib math.h sin -lm && LIBM="-lm" > > disabled crystalhd || check_lib libcrystalhd/libcrystalhd_if.h > > DtsCrystalHDVersion -lcrystalhd || disable crystalhd > > > > atan2f_args=2 > > +fmax_args=2 > > +fmaxf_args=2 > > +fmin_args=2 > > +fminf_args=2 > > copysign_args=2 > > ldexpf_args=2 > > powf_args=2 > > diff --git a/libavutil/libm.h b/libavutil/libm.h > > index 6c17b28..ba837a2 100644 > > --- a/libavutil/libm.h > > +++ b/libavutil/libm.h > > @@ -43,6 +43,34 @@ > > #define atan2f(y, x) ((float)atan2(y, x)) > > #endif > > > > +#if !HAVE_FMAX > > +#undef fmax > > +static av_always_inline double fmax(double x, double y) > > +{ > > +if (x < y) return y; > > +else return x; > > +} > > +#endif > > + > > +#if !HAVE_FMIN > > +#undef fmin > > +static av_always_inline double fmin(double x, double y) > > +{ > > +if (x < y) return x; > > +else return y; > > +} > > +#endif > > Wasn't there a concern that these emulations don't behave identical to > the C library versions in regards to NaN handling? > I faintly remember something in the previous discussion. yes, i forgot about that :( i replaced them by FFMIN / FFMAX [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are best at talking, realize last or never when they are wrong. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure+libm.h: add fmin/fmax/fminf/fmaxf emulation
On Fri, Oct 30, 2015 at 06:53:34PM -0400, Ganesh Ajjanagadde wrote: > On Fri, Oct 30, 2015 at 6:35 PM, Michael Niedermayer wrote: > > From: Michael Niedermayer > > > > This should fix the build failure of avf_showcqt.c > > > > An alternative solution would be to add a check for fmin/fmax to > > fate-source and > > then to replace them by FFMIN/FFMAX, i can do that if preferred? > > > > Untested due to lack of a affected platform > > I recall some interest on my end to get fmin, fmax etc for different > reasons, and it was remarked that commit > 4436a8f44dedc83767b3d9da9beb85d1fae2ca30 may be relevant. The summary > seems to be that getting it to work on all platforms is not so simple. :/ ill replace the problematic ones by FFMIN/MAX for now so the build failure on the affected msvc platforms is fixed tieing a build fix to this complexity would be unwise > I am definitely interested in getting it to work in order to replace > FFMAX/FFMIN for floating point in especially libavfilter. This will > allow better nan signalling at a slight performance cost. would that performance cost affect all systems or just ones not having fmin/fmax ? i think affecting all systems would be bad [...] -- 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 11/11] avutil/rational: use frexp rather than ad-hoc log to get floating point exponent
On Thu, Oct 29, 2015 at 12:20:09AM -0400, Ganesh Ajjanagadde wrote: > This simplifies and cleans up the code. > Furthermore, it is much faster due to absence of the slow log computation. > > Signed-off-by: Ganesh Ajjanagadde > --- > libavutil/rational.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) LGTM and nice speedup! [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Dictatorship naturally arises out of democracy, and the most aggravated form of tyranny and slavery out of the most extreme liberty. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure+libm.h: add fmin/fmax/fminf/fmaxf emulation
On Fri, Oct 30, 2015 at 11:35 PM, Michael Niedermayer wrote: > From: Michael Niedermayer > > This should fix the build failure of avf_showcqt.c > > An alternative solution would be to add a check for fmin/fmax to fate-source > and > then to replace them by FFMIN/FFMAX, i can do that if preferred? > > Untested due to lack of a affected platform > > Signed-off-by: Michael Niedermayer > --- > configure|8 > libavutil/libm.h | 28 > 2 files changed, 36 insertions(+) > > diff --git a/configure b/configure > index 95790f4..e6f5d2c 100755 > --- a/configure > +++ b/configure > @@ -1770,6 +1770,10 @@ MATH_FUNCS=" > exp2 > exp2f > expf > +fmax > +fmaxf > +fmin > +fminf > isinf > isnan > ldexpf > @@ -5304,6 +5308,10 @@ check_lib math.h sin -lm && LIBM="-lm" > disabled crystalhd || check_lib libcrystalhd/libcrystalhd_if.h > DtsCrystalHDVersion -lcrystalhd || disable crystalhd > > atan2f_args=2 > +fmax_args=2 > +fmaxf_args=2 > +fmin_args=2 > +fminf_args=2 > copysign_args=2 > ldexpf_args=2 > powf_args=2 > diff --git a/libavutil/libm.h b/libavutil/libm.h > index 6c17b28..ba837a2 100644 > --- a/libavutil/libm.h > +++ b/libavutil/libm.h > @@ -43,6 +43,34 @@ > #define atan2f(y, x) ((float)atan2(y, x)) > #endif > > +#if !HAVE_FMAX > +#undef fmax > +static av_always_inline double fmax(double x, double y) > +{ > +if (x < y) return y; > +else return x; > +} > +#endif > + > +#if !HAVE_FMIN > +#undef fmin > +static av_always_inline double fmin(double x, double y) > +{ > +if (x < y) return x; > +else return y; > +} > +#endif Wasn't there a concern that these emulations don't behave identical to the C library versions in regards to NaN handling? I faintly remember something in the previous discussion. > + > +#if !HAVE_FMAXF > +#undef fmaxf > +#define fmaxf(y, x) ((float)fmax(y, x)) > +#endif > + > +#if !HAVE_FMINF > +#undef fminf > +#define fminf(y, x) ((float)fmin(y, x)) > +#endif > + > #if !HAVE_POWF > #undef powf > #define powf(x, y) ((float)pow(x, y)) > -- > 1.7.9.5 > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avfilter/vf_deshake: replace qsort with AV_QSORT
qsort is called indirectly in filter_frame, suggesting its performance criticality. AV_QSORT is substantially faster due to the inlining of the comparison callback. Thus, the increase in performance should be worth the increase in binary size. Sample benchmark (x86-64, Haswell, GNU/Linux): File: original from https://trac.ffmpeg.org/ticket/1430 command: ffmpeg -stream_loop 8 -i file.webm -vf deshake=rx=64:ry=64 -f null - Timer truncated at 1024 runs. new: 28260 decicycles in qsort, 1 runs, 0 skips 35570 decicycles in qsort, 2 runs, 0 skips 39010 decicycles in qsort, 4 runs, 0 skips 46897 decicycles in qsort, 8 runs, 0 skips 40442 decicycles in qsort, 16 runs, 0 skips 41611 decicycles in qsort, 32 runs, 0 skips 40345 decicycles in qsort, 64 runs, 0 skips 38967 decicycles in qsort, 128 runs, 0 skips 38647 decicycles in qsort, 256 runs, 0 skips 40238 decicycles in qsort, 512 runs, 0 skips 39676 decicycles in qsort,1024 runs, 0 skips old: 1740280 decicycles in qsort, 1 runs, 0 skips 923560 decicycles in qsort, 2 runs, 0 skips 511330 decicycles in qsort, 4 runs, 0 skips 309720 decicycles in qsort, 8 runs, 0 skips 194900 decicycles in qsort, 16 runs, 0 skips 142686 decicycles in qsort, 32 runs, 0 skips 112516 decicycles in qsort, 64 runs, 0 skips 98166 decicycles in qsort, 128 runs, 0 skips 88147 decicycles in qsort, 256 runs, 0 skips 88706 decicycles in qsort, 512 runs, 0 skips 86783 decicycles in qsort,1024 runs, 0 skips Signed-off-by: Ganesh Ajjanagadde --- libavfilter/vf_deshake.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/libavfilter/vf_deshake.c b/libavfilter/vf_deshake.c index 885569a..e32436d 100644 --- a/libavfilter/vf_deshake.c +++ b/libavfilter/vf_deshake.c @@ -57,6 +57,7 @@ #include "libavutil/mem.h" #include "libavutil/opt.h" #include "libavutil/pixdesc.h" +#include "libavutil/qsort.h" #include "deshake.h" #include "deshake_opencl.h" @@ -106,7 +107,7 @@ static double clean_mean(double *values, int count) int cut = count / 5; int x; -qsort(values, count, sizeof(double), cmp); +AV_QSORT(values, count, 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
Re: [FFmpeg-devel] [PATCH] configure+libm.h: add fmin/fmax/fminf/fmaxf emulation
On Fri, Oct 30, 2015 at 6:35 PM, Michael Niedermayer wrote: > From: Michael Niedermayer > > This should fix the build failure of avf_showcqt.c > > An alternative solution would be to add a check for fmin/fmax to fate-source > and > then to replace them by FFMIN/FFMAX, i can do that if preferred? > > Untested due to lack of a affected platform I recall some interest on my end to get fmin, fmax etc for different reasons, and it was remarked that commit 4436a8f44dedc83767b3d9da9beb85d1fae2ca30 may be relevant. The summary seems to be that getting it to work on all platforms is not so simple. I am definitely interested in getting it to work in order to replace FFMAX/FFMIN for floating point in especially libavfilter. This will allow better nan signalling at a slight performance cost. > > Signed-off-by: Michael Niedermayer > --- > configure|8 > libavutil/libm.h | 28 > 2 files changed, 36 insertions(+) > > diff --git a/configure b/configure > index 95790f4..e6f5d2c 100755 > --- a/configure > +++ b/configure > @@ -1770,6 +1770,10 @@ MATH_FUNCS=" > exp2 > exp2f > expf > +fmax > +fmaxf > +fmin > +fminf > isinf > isnan > ldexpf > @@ -5304,6 +5308,10 @@ check_lib math.h sin -lm && LIBM="-lm" > disabled crystalhd || check_lib libcrystalhd/libcrystalhd_if.h > DtsCrystalHDVersion -lcrystalhd || disable crystalhd > > atan2f_args=2 > +fmax_args=2 > +fmaxf_args=2 > +fmin_args=2 > +fminf_args=2 > copysign_args=2 > ldexpf_args=2 > powf_args=2 > diff --git a/libavutil/libm.h b/libavutil/libm.h > index 6c17b28..ba837a2 100644 > --- a/libavutil/libm.h > +++ b/libavutil/libm.h > @@ -43,6 +43,34 @@ > #define atan2f(y, x) ((float)atan2(y, x)) > #endif > > +#if !HAVE_FMAX > +#undef fmax > +static av_always_inline double fmax(double x, double y) > +{ > +if (x < y) return y; > +else return x; > +} > +#endif > + > +#if !HAVE_FMIN > +#undef fmin > +static av_always_inline double fmin(double x, double y) > +{ > +if (x < y) return x; > +else return y; > +} > +#endif > + > +#if !HAVE_FMAXF > +#undef fmaxf > +#define fmaxf(y, x) ((float)fmax(y, x)) > +#endif > + > +#if !HAVE_FMINF > +#undef fminf > +#define fminf(y, x) ((float)fmin(y, x)) > +#endif > + > #if !HAVE_POWF > #undef powf > #define powf(x, y) ((float)pow(x, y)) > -- > 1.7.9.5 > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/avf_showcqt: rewrite showcqt and add features
On Thu, Oct 29, 2015 at 02:05:53AM -0300, James Almer wrote: > On 10/27/2015 9:56 PM, Michael Niedermayer wrote: > > On Mon, Oct 26, 2015 at 12:32:58AM +0700, Muhammad Faiz wrote: > >> On Sun, Oct 25, 2015 at 9:51 AM, Michael Niedermayer > >> wrote: > >>> On Sun, Oct 25, 2015 at 08:43:07AM +0700, Muhammad Faiz wrote: > doc/filters.texi | 181 +++-- > libavfilter/avf_showcqt.c | 1546 > +++--- > libavfilter/avf_showcqt.h | 104 +++ > libavfilter/version.h |2 > 4 files changed, 1294 insertions(+), 539 deletions(-) > 3f83a0d334d780da3defa7d1fa3f09b3beb1db2d > 0001-avfilter-avf_showcqt-rewrite-showcqt-and-add-feature.patch > From 337a659f96ef5dcf87aad1d541e745b7c262cbb9 Mon Sep 17 00:00:00 2001 > From: Muhammad Faiz > Date: Sat, 24 Oct 2015 00:44:42 +0700 > Subject: [PATCH] avfilter/avf_showcqt: rewrite showcqt and add features > >>> > >>> this fails to build on "arm-linux-gnueabi-gcc-4.5 (Ubuntu/Linaro > >>> 4.5.3-12ubuntu2) 4.5.3" > >>> In file included from ffmpeg/libavfilter/avf_showcqt.c:41:0: > >>> ffmpeg/libavfilter/avf_showcqt.h:39:30: warning: declaration does not > >>> declare anything > >>> ffmpeg/libavfilter/avf_showcqt.h:40:30: warning: declaration does not > >>> declare anything > >>> ffmpeg/libavfilter/avf_showcqt.c: In function ‘rgb_from_cqt’: > >>> ffmpeg/libavfilter/avf_showcqt.c:668:13: error: ‘ColorFloat’ has no > >>> member named ‘r’ > >>> ffmpeg/libavfilter/avf_showcqt.c:669:13: error: ‘ColorFloat’ has no > >>> member named ‘g’ > >>> ffmpeg/libavfilter/avf_showcqt.c:670:13: error: ‘ColorFloat’ has no > >>> member named ‘b’ > >>> ffmpeg/libavfilter/avf_showcqt.c: In function ‘yuv_from_cqt’: > >>> ffmpeg/libavfilter/avf_showcqt.c:682:13: error: ‘ColorFloat’ has no > >>> member named ‘y’ > >>> ffmpeg/libavfilter/avf_showcqt.c:683:13: error: ‘ColorFloat’ has no > >>> member named ‘u’ > >>> ffmpeg/libavfilter/avf_showcqt.c:684:13: error: ‘ColorFloat’ has no > >>> member named ‘v’ > >> > >> > >> revision: do not use anonymous struct, it seems it is not supported on > >> some platforms > >> > >> thanks > > > >> doc/filters.texi | 181 +++-- > >> libavfilter/avf_showcqt.c | 1546 > >> +++--- > >> libavfilter/avf_showcqt.h | 112 +++ > >> libavfilter/version.h |2 > >> 4 files changed, 1302 insertions(+), 539 deletions(-) > >> be583ed02fc82b34612c9c1782955795fb8b4259 > >> 0001-avfilter-avf_showcqt-rewrite-showcqt-and-add-feature.patch > >> From e6d6243e03439cffd2d58e30d9892c18e2ef0bc4 Mon Sep 17 00:00:00 2001 > >> From: Muhammad Faiz > >> Date: Mon, 26 Oct 2015 00:18:41 +0700 > >> Subject: [PATCH] avfilter/avf_showcqt: rewrite showcqt and add features > >> > >> add yuv444p, yuv422p, and yuv420p output format (lower cpu usage > >> on ffplay playback because it does not do format conversion) > >> custom size with size/s option (fullhd option is deprecated) > >> custom layout with bar_h, axis_h, and sono_h option > >> support rational frame rate (within fps/r/rate option) > >> relaxed frame rate restriction (support fractional sample step) > >> support all input sample rates > >> separate sonogram and bargraph volume (with volume/sono_v and > >> volume2/bar_v) > >> timeclamp option alias (timeclamp/tc) > >> fcount option > >> gamma option alias (gamma/sono_g and gamma2/bar_g) > >> support custom frequency range (basefreq and endfreq) > >> support drawing axis using external image file (axisfile option) > >> alias for disabling drawing to axis (text/axis) > >> possibility to optimize it using arch specific asm code > >> --- > >> doc/filters.texi | 181 -- > >> libavfilter/avf_showcqt.c | 1546 > >> +++-- > >> libavfilter/avf_showcqt.h | 112 > >> libavfilter/version.h |2 +- > >> 4 files changed, 1302 insertions(+), 539 deletions(-) > >> create mode 100644 libavfilter/avf_showcqt.h > > > > applied > > > > thanks > > C:/Dev/ffmpeg/fate/x86_32-msvc2012/src/libavfilter/avf_showcqt.c(316) : error > C4013: 'fmax' undefined; assuming extern returning int > C:/Dev/ffmpeg/fate/x86_32-msvc2012/src/libavfilter/avf_showcqt.c(317) : error > C4013: 'fmin' undefined; assuming extern returning int > C:/Dev/ffmpeg/fate/x86_32-msvc2012/src/libavfilter/avf_showcqt.c(668) : error > C4013: 'fminf' undefined; assuming extern returning int > > If these can't be replaced with FFMIN/FFMAX then maybe a fallback version > should > be added to libavutil/libm.h posted a patch that would attempt that [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If a bugfix only changes things apparently unrelated to the bug with no further explanation, that is a good sign that the bugfix is wrong. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffm
[FFmpeg-devel] [PATCH] configure+libm.h: add fmin/fmax/fminf/fmaxf emulation
From: Michael Niedermayer This should fix the build failure of avf_showcqt.c An alternative solution would be to add a check for fmin/fmax to fate-source and then to replace them by FFMIN/FFMAX, i can do that if preferred? Untested due to lack of a affected platform Signed-off-by: Michael Niedermayer --- configure|8 libavutil/libm.h | 28 2 files changed, 36 insertions(+) diff --git a/configure b/configure index 95790f4..e6f5d2c 100755 --- a/configure +++ b/configure @@ -1770,6 +1770,10 @@ MATH_FUNCS=" exp2 exp2f expf +fmax +fmaxf +fmin +fminf isinf isnan ldexpf @@ -5304,6 +5308,10 @@ check_lib math.h sin -lm && LIBM="-lm" disabled crystalhd || check_lib libcrystalhd/libcrystalhd_if.h DtsCrystalHDVersion -lcrystalhd || disable crystalhd atan2f_args=2 +fmax_args=2 +fmaxf_args=2 +fmin_args=2 +fminf_args=2 copysign_args=2 ldexpf_args=2 powf_args=2 diff --git a/libavutil/libm.h b/libavutil/libm.h index 6c17b28..ba837a2 100644 --- a/libavutil/libm.h +++ b/libavutil/libm.h @@ -43,6 +43,34 @@ #define atan2f(y, x) ((float)atan2(y, x)) #endif +#if !HAVE_FMAX +#undef fmax +static av_always_inline double fmax(double x, double y) +{ +if (x < y) return y; +else return x; +} +#endif + +#if !HAVE_FMIN +#undef fmin +static av_always_inline double fmin(double x, double y) +{ +if (x < y) return x; +else return y; +} +#endif + +#if !HAVE_FMAXF +#undef fmaxf +#define fmaxf(y, x) ((float)fmax(y, x)) +#endif + +#if !HAVE_FMINF +#undef fminf +#define fminf(y, x) ((float)fmin(y, x)) +#endif + #if !HAVE_POWF #undef powf #define powf(x, y) ((float)pow(x, y)) -- 1.7.9.5 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/showcqt: fix dependency with avformat
On Fri, Oct 30, 2015 at 11:57:10PM +0700, Muhammad Faiz wrote: > patch attached > configure|2 +- > libavfilter/Makefile |2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > 10867dc567823f25a5cef17a30f5f8e60eaccc07 > 0001-avfilter-showcqt-fix-dependency-with-avformat.patch > From 1902fc28da0b7d03e0f329397691006f9b432079 Mon Sep 17 00:00:00 2001 > From: Muhammad Faiz > Date: Fri, 30 Oct 2015 23:35:02 +0700 > Subject: [PATCH] avfilter/showcqt: fix dependency with avformat applied thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is what and why we do it that matters, not just one of them. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add audio noise source
On Fri, Oct 30, 2015 at 12:00:23 -0500, Kyle Swanson wrote: > +- noise audio source I actually anticipated this for quite some while, but thought I had figured it out using some random source of input. I can't reproduce my findings (or even my search), so thanks. :-) > +@item duration, d > +Specify the duration of the generated audio stream. Default value is 10 > seconds. Is there a way to specify infinity? Actually, why not let it go infinitely by default, like the sine audio source does? As Nicolas pointed out, AV_OPT_TYPE_DURATION is more generic for durations. I second the notion for other colors of sound (pink). Question: If I use two of these, will they be seeded identically or independantly and randomly? (Like for merging to a left and right channel, and not achieving a mono sound.) Thanks, Moritz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] possible farewell; dev policy clarification
Hi, On Fri, Oct 30, 2015 at 11:35 AM, Ganesh Ajjanagadde wrote: > Most, and perhaps all of them boil down to misunderstanding. This will > hopefully improve over time. I apologize to all who did not like > recent pushes from me. In fact, I can freely let go of my commit > access if these were deemed sufficiently out of line - I do not ask > for a formal "DECISION" or vote. No, that's not necessary. (Punishing for minor, honest mistakes - or misunderstandings - is silly.) Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/5] ffprobe: add support for printing packet strings metadata as packet tags
On Fri, 30 Oct 2015, Stefano Sabatini wrote: On date Saturday 2015-10-24 22:42:12 +0200, Marton Balint encoded: ffprobe.xsd already contains the tag element. Signed-off-by: Marton Balint --- ffprobe.c | 16 +++- 1 file changed, 15 insertions(+), 1 deletion(-) [...] LGTM, thanks. Applied, thanks. Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Update Cookies on Setcookie playlist response
On Fri, Oct 30, 2015 at 12:26:55PM +, Lucas Andrade wrote: > Em sex, 30 de out de 2015 às 07:44, Michael Niedermayer > escreveu: > > > On Tue, Oct 27, 2015 at 11:28:32AM +, Lucas Andrade wrote: > > > Here is the patch to backport it to release/2.8. To be fixed on 2.8.2. > > > Anything else I should do? > > > > > > ps. Sorry, that's my first time on opensource project, I'm a little > > > confused that I needed to add it to the release branch. > > > > > hls.c | 31 +++ > > > 1 file changed, 15 insertions(+), 16 deletions(-) > > > 6b3c2cdc68e5fe0d9665a22a78837bca7d7b39b9 > > b3f3eab029eb429660fc1651a33dafe097cbac0e.patch > > > From b3f3eab029eb429660fc1651a33dafe097cbac0e Mon Sep 17 00:00:00 2001 > > > From: Lucas de Andrade > > > Date: Mon, 26 Oct 2015 10:47:08 -0200 > > > Subject: [PATCH] Update Cookies response with Setcookie > > > > > > Context cookies must be updated when a playlist response return > > Setcookie header. > > > Backported to release/2.8 > > > --- > > > libavformat/hls.c | 31 +++ > > > 1 file changed, 15 insertions(+), 16 deletions(-) > > > > this patch is against n2.8 not release/2.8 > > > > git checkout release/2.8 > > git cherry-pick ... > > error: patch failed: libavformat/hls.c:962 > > error: libavformat/hls.c: patch does not apply > > Patch failed at 0001 Update Cookies response with Setcookie > > The copy of the patch that failed is found in: > >ffmpeg/.git/rebase-apply/patch > > When you have resolved this problem, run "git am --continue". > > If you prefer to skip this patch, run "git am --skip" instead. > > To restore the original branch and stop patching, run "git am --abort". > > > > [...] > > > > -- > > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > > > Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. > > User > > questions about the command line tools should be sent to the ffmpeg-user > > ML. > > And questions about how to use libav* should be sent to the libav-user ML. > > ___ > > ffmpeg-devel mailing list > > ffmpeg-devel@ffmpeg.org > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > Sorry, I needed to update release/2.8. It was a previous version. > Here it is. > hls.c | 31 +++ > 1 file changed, 15 insertions(+), 16 deletions(-) > 245150aacbd311302c9c7ee3e293aeae684323b0 > update_cookies_on_setcookie_response.patch > From 94b7fd78b6e4a50ffe19a3b0523fb88c9036ea5d Mon Sep 17 00:00:00 2001 > From: Lucas de Andrade > Date: Fri, 30 Oct 2015 09:51:26 -0200 > Subject: [PATCH] avformat/hls: update cookies on setcookie response > > Context cookies must be updated when a playlist response return Setcookie > header. > --- > libavformat/hls.c | 31 +++ > 1 file changed, 15 insertions(+), 16 deletions(-) applied to release/2.8 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Dictatorship naturally arises out of democracy, and the most aggravated form of tyranny and slavery out of the most extreme liberty. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv3] all: fix enum definition for large values
On Fri, Oct 30, 2015 at 2:59 PM, Ronald S. Bultje wrote: > Hi, > > On Fri, Oct 30, 2015 at 2:11 PM, 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 it by using alternative expressions that result in identical >> values but do not have this issue. >> >> Tested with FATE. >> >> Signed-off-by: Ganesh Ajjanagadde >> --- >> libavcodec/dca_syncwords.h | 26 -- >> libavformat/cinedec.c | 10 +- >> libavformat/mov_chan.c | 2 +- >> 3 files changed, 18 insertions(+), 20 deletions(-) >> >> diff --git a/libavcodec/dca_syncwords.h b/libavcodec/dca_syncwords.h >> index 3466b6b..6981cb8 100644 >> --- a/libavcodec/dca_syncwords.h >> +++ b/libavcodec/dca_syncwords.h >> @@ -19,19 +19,17 @@ >> #ifndef AVCODEC_DCA_SYNCWORDS_H >> #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, >> -}; >> +#defineDCA_SYNCWORD_CORE_BE 0x7FFE8001U >> +#defineDCA_SYNCWORD_CORE_LE 0xFE7F0180U >> +#defineDCA_SYNCWORD_CORE_14B_BE 0x1FFFE800U >> +#defineDCA_SYNCWORD_CORE_14B_LE 0xFF1F00E8U >> +#defineDCA_SYNCWORD_XCH 0x5A5A5A5AU >> +#defineDCA_SYNCWORD_XXCH 0x47004A03U >> +#defineDCA_SYNCWORD_X96 0x1D95F262U >> +#defineDCA_SYNCWORD_XBR 0x655E315EU >> +#defineDCA_SYNCWORD_LBR 0x0A801921U >> +#defineDCA_SYNCWORD_XLL 0x41A29547U >> +#defineDCA_SYNCWORD_SUBSTREAM0x64582025U >> +#defineDCA_SYNCWORD_SUBSTREAM_CORE 0x02B09261U >> >> #endif /* AVCODEC_DCA_SYNCWORDS_H */ >> diff --git a/libavformat/cinedec.c b/libavformat/cinedec.c >> index 632f46c..3184084 100644 >> --- a/libavformat/cinedec.c >> +++ b/libavformat/cinedec.c >> @@ -49,13 +49,13 @@ enum { >> CFA_VRIV6 = 2, /**< BGGR/GRBG */ >> CFA_BAYER = 3, /**< GB/RG */ >> CFA_BAYERFLIP = 4, /**< RG/GB */ >> - >> -CFA_TLGRAY= 0x8000, >> -CFA_TRGRAY= 0x4000, >> -CFA_BLGRAY= 0x2000, >> -CFA_BRGRAY= 0x1000 >> }; >> >> +#define CFA_TLGRAY 0x8000U >> +#define CFA_TRGRAY 0x4000U >> +#define CFA_BLGRAY 0x2000U >> +#define CFA_BRGRAY 0x1000U >> + >> static int cine_read_probe(AVProbeData *p) >> { >> int HeaderSize; >> diff --git a/libavformat/mov_chan.c b/libavformat/mov_chan.c >> index a2fa8d6..cba07c5 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, >> +#define MOV_CH_LAYOUT_UNKNOWN 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 > > > That last one is admittedly quirky, but I guess that's OK. Yes, I would not classify it as a win-win compromise. > > lgtm. Thanks for the review, pushed. > > Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv3] all: fix enum definition for large values
Hi, On Fri, Oct 30, 2015 at 2:11 PM, 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 it by using alternative expressions that result in identical > values but do not have this issue. > > Tested with FATE. > > Signed-off-by: Ganesh Ajjanagadde > --- > libavcodec/dca_syncwords.h | 26 -- > libavformat/cinedec.c | 10 +- > libavformat/mov_chan.c | 2 +- > 3 files changed, 18 insertions(+), 20 deletions(-) > > diff --git a/libavcodec/dca_syncwords.h b/libavcodec/dca_syncwords.h > index 3466b6b..6981cb8 100644 > --- a/libavcodec/dca_syncwords.h > +++ b/libavcodec/dca_syncwords.h > @@ -19,19 +19,17 @@ > #ifndef AVCODEC_DCA_SYNCWORDS_H > #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, > -}; > +#defineDCA_SYNCWORD_CORE_BE 0x7FFE8001U > +#defineDCA_SYNCWORD_CORE_LE 0xFE7F0180U > +#defineDCA_SYNCWORD_CORE_14B_BE 0x1FFFE800U > +#defineDCA_SYNCWORD_CORE_14B_LE 0xFF1F00E8U > +#defineDCA_SYNCWORD_XCH 0x5A5A5A5AU > +#defineDCA_SYNCWORD_XXCH 0x47004A03U > +#defineDCA_SYNCWORD_X96 0x1D95F262U > +#defineDCA_SYNCWORD_XBR 0x655E315EU > +#defineDCA_SYNCWORD_LBR 0x0A801921U > +#defineDCA_SYNCWORD_XLL 0x41A29547U > +#defineDCA_SYNCWORD_SUBSTREAM0x64582025U > +#defineDCA_SYNCWORD_SUBSTREAM_CORE 0x02B09261U > > #endif /* AVCODEC_DCA_SYNCWORDS_H */ > diff --git a/libavformat/cinedec.c b/libavformat/cinedec.c > index 632f46c..3184084 100644 > --- a/libavformat/cinedec.c > +++ b/libavformat/cinedec.c > @@ -49,13 +49,13 @@ enum { > CFA_VRIV6 = 2, /**< BGGR/GRBG */ > CFA_BAYER = 3, /**< GB/RG */ > CFA_BAYERFLIP = 4, /**< RG/GB */ > - > -CFA_TLGRAY= 0x8000, > -CFA_TRGRAY= 0x4000, > -CFA_BLGRAY= 0x2000, > -CFA_BRGRAY= 0x1000 > }; > > +#define CFA_TLGRAY 0x8000U > +#define CFA_TRGRAY 0x4000U > +#define CFA_BLGRAY 0x2000U > +#define CFA_BRGRAY 0x1000U > + > static int cine_read_probe(AVProbeData *p) > { > int HeaderSize; > diff --git a/libavformat/mov_chan.c b/libavformat/mov_chan.c > index a2fa8d6..cba07c5 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, > +#define MOV_CH_LAYOUT_UNKNOWN 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 That last one is admittedly quirky, but I guess that's OK. lgtm. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCHv3] 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 it by using alternative expressions that result in identical values but do not have this issue. Tested with FATE. Signed-off-by: Ganesh Ajjanagadde --- libavcodec/dca_syncwords.h | 26 -- libavformat/cinedec.c | 10 +- libavformat/mov_chan.c | 2 +- 3 files changed, 18 insertions(+), 20 deletions(-) diff --git a/libavcodec/dca_syncwords.h b/libavcodec/dca_syncwords.h index 3466b6b..6981cb8 100644 --- a/libavcodec/dca_syncwords.h +++ b/libavcodec/dca_syncwords.h @@ -19,19 +19,17 @@ #ifndef AVCODEC_DCA_SYNCWORDS_H #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, -}; +#defineDCA_SYNCWORD_CORE_BE 0x7FFE8001U +#defineDCA_SYNCWORD_CORE_LE 0xFE7F0180U +#defineDCA_SYNCWORD_CORE_14B_BE 0x1FFFE800U +#defineDCA_SYNCWORD_CORE_14B_LE 0xFF1F00E8U +#defineDCA_SYNCWORD_XCH 0x5A5A5A5AU +#defineDCA_SYNCWORD_XXCH 0x47004A03U +#defineDCA_SYNCWORD_X96 0x1D95F262U +#defineDCA_SYNCWORD_XBR 0x655E315EU +#defineDCA_SYNCWORD_LBR 0x0A801921U +#defineDCA_SYNCWORD_XLL 0x41A29547U +#defineDCA_SYNCWORD_SUBSTREAM0x64582025U +#defineDCA_SYNCWORD_SUBSTREAM_CORE 0x02B09261U #endif /* AVCODEC_DCA_SYNCWORDS_H */ diff --git a/libavformat/cinedec.c b/libavformat/cinedec.c index 632f46c..3184084 100644 --- a/libavformat/cinedec.c +++ b/libavformat/cinedec.c @@ -49,13 +49,13 @@ enum { CFA_VRIV6 = 2, /**< BGGR/GRBG */ CFA_BAYER = 3, /**< GB/RG */ CFA_BAYERFLIP = 4, /**< RG/GB */ - -CFA_TLGRAY= 0x8000, -CFA_TRGRAY= 0x4000, -CFA_BLGRAY= 0x2000, -CFA_BRGRAY= 0x1000 }; +#define CFA_TLGRAY 0x8000U +#define CFA_TRGRAY 0x4000U +#define CFA_BLGRAY 0x2000U +#define CFA_BRGRAY 0x1000U + static int cine_read_probe(AVProbeData *p) { int HeaderSize; diff --git a/libavformat/mov_chan.c b/libavformat/mov_chan.c index a2fa8d6..cba07c5 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, +#define MOV_CH_LAYOUT_UNKNOWN 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] avutil/wchar_filename: add av_warn_unused_result
On Fri, Oct 30, 2015 at 12:57 PM, Ganesh Ajjanagadde wrote: > On Fri, Oct 30, 2015 at 6:07 AM, Michael Niedermayer > wrote: >> On Thu, Oct 15, 2015 at 08:01:56PM -0400, Ganesh Ajjanagadde wrote: >>> Current code is fine, this just adds robustness. >>> >>> Signed-off-by: Ganesh Ajjanagadde >>> --- >>> libavutil/wchar_filename.h | 1 + >>> 1 file changed, 1 insertion(+) >>> >>> diff --git a/libavutil/wchar_filename.h b/libavutil/wchar_filename.h >>> index c553c46..2ade321 100644 >>> --- a/libavutil/wchar_filename.h >>> +++ b/libavutil/wchar_filename.h >>> @@ -23,6 +23,7 @@ >>> #include >>> #include "mem.h" >>> >>> +av_warn_unused_result >>> static inline int utf8towchar(const char *filename_utf8, wchar_t >>> **filename_w) >>> { >>> int num_chars; >> >> LGTM >> >> thanks > > thanks, will push later. Please consider all other > av_warn_unused_result patches dropped; I am going to add in a much > more targeted fashion first. Please don't waste time reviewing them. pushed > >> >> [...] >> -- >> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB >> >> Asymptotically faster algorithms should always be preferred if you have >> asymptotical amounts of data >> >> ___ >> 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] avutil/mathematics: correct documentation for av_gcd
On Fri, Oct 30, 2015 at 12:16 PM, Michael Niedermayer wrote: > On Tue, Oct 27, 2015 at 08:18:34PM -0400, Ganesh Ajjanagadde wrote: >> av_gcd is now always defined regardless of input. This documents this >> change in the "documented API". Two benefits (closely related): >> 1. The function is robust, and there is no need to worry about INT64_MIN, >> etc. >> >> 2. Clients of av_gcd, like av_reduce, can now be made fully correct. >> Currently, >> av_reduce can trigger undefined behavior if e.g num is INT64_MIN due to >> integer overflow in the FFABS. Furthermore, this undefined behavior is >> completely undocumented, and could be a fuzzer's paradise. The FFABS was >> needed in the past as >> av_gcd was undefined for negative inputs. In order to make av_reduce >> robust, it is essential to guarantee that av_gcd works for all int64_t. >> >> Signed-off-by: Ganesh Ajjanagadde >> --- >> libavutil/mathematics.h | 6 +++--- >> 1 file changed, 3 insertions(+), 3 deletions(-) >> >> diff --git a/libavutil/mathematics.h b/libavutil/mathematics.h >> index ac94488..6fc2577 100644 >> --- a/libavutil/mathematics.h >> +++ b/libavutil/mathematics.h >> @@ -77,9 +77,9 @@ enum AVRounding { >> }; >> >> /** >> - * Return the greatest common divisor of a and b. >> - * If both a and b are 0 or either or both are <0 then behavior is >> - * undefined. >> + * Compute the greatest common divisor of a and b. >> + * >> + * @return gcd of a and b up to sign; if a and b are both zero returns 0 >> */ >> int64_t av_const av_gcd(int64_t a, int64_t b); > > LGTM > > thanks pushed, thanks > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add audio noise source
Le nonidi 9 brumaire, an CCXXIV, Kyle Swanson a écrit : > Signed-off-by: Kyle Swanson > --- > Changelog| 1 + > doc/filters.texi | 30 ++ > libavfilter/Makefile | 1 + > libavfilter/allfilters.c | 1 + > libavfilter/asrc_noise.c | 141 > +++ > libavfilter/version.h| 2 +- > 6 files changed, 175 insertions(+), 1 deletion(-) > create mode 100644 libavfilter/asrc_noise.c > > diff --git a/Changelog b/Changelog > index c49e383..d2ea2e1 100644 > --- a/Changelog > +++ b/Changelog > @@ -29,6 +29,7 @@ version : > - vibrato filter > - innoHeim/Rsupport Screen Capture Codec decoder > - ADPCM AICA decoder > +- noise audio source Thanks for the patch. See comments below. > version 2.8: > diff --git a/doc/filters.texi b/doc/filters.texi > index 15ea77a..0d901cc 100644 > --- a/doc/filters.texi > +++ b/doc/filters.texi > @@ -3193,6 +3193,36 @@ ffplay -f lavfi flite=text='No more be grieved for > which that thou hast done.' > For more information about libflite, check: > @url{http://www.speech.cs.cmu.edu/flite/} > > +@section noise > + > +Generate a white noise audio signal. > + > +The filter accepts the following options: > + > +@table @option > + > +@item sample_rate, r > +Specify the sample rate. Default value is 48000 Hz. > + > +@item duration, d > +Specify the duration of the generated audio stream. Default value is 10 > seconds. > + > +@item amplitude, a > +Specify the amplitude (0.0 - 1.0) of the generated audio stream. Default > value is 1.0. > + > +@end table > + > +@subsection Examples > + > +@itemize > + > +@item > +Generate 60 seconds of white noise, with a 44.1 kHz sampling rate and an > amplitude of 0.5: > +@example > +noise=d=60:r=44100:a=0.5 > +@end example > +@end itemize > + > @section sine > > Generate an audio signal made of a sine wave with amplitude 1/8. > diff --git a/libavfilter/Makefile b/libavfilter/Makefile > index c5819d4..a0b2232 100644 > --- a/libavfilter/Makefile > +++ b/libavfilter/Makefile > @@ -93,6 +93,7 @@ OBJS-$(CONFIG_VOLUMEDETECT_FILTER) += > af_volumedetect.o > OBJS-$(CONFIG_AEVALSRC_FILTER) += aeval.o > OBJS-$(CONFIG_ANULLSRC_FILTER) += asrc_anullsrc.o > OBJS-$(CONFIG_FLITE_FILTER) += asrc_flite.o > +OBJS-$(CONFIG_NOISE_FILTER) += asrc_noise.o > OBJS-$(CONFIG_SINE_FILTER) += asrc_sine.o > > OBJS-$(CONFIG_ANULLSINK_FILTER) += asink_anullsink.o > diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c > index a538b81..f820441 100644 > --- a/libavfilter/allfilters.c > +++ b/libavfilter/allfilters.c > @@ -115,6 +115,7 @@ void avfilter_register_all(void) > REGISTER_FILTER(AEVALSRC, aevalsrc, asrc); > REGISTER_FILTER(ANULLSRC, anullsrc, asrc); > REGISTER_FILTER(FLITE, flite, asrc); > +REGISTER_FILTER(NOISE, noise, asrc); > REGISTER_FILTER(SINE, sine, asrc); > > REGISTER_FILTER(ANULLSINK, anullsink, asink); > diff --git a/libavfilter/asrc_noise.c b/libavfilter/asrc_noise.c > new file mode 100644 > index 000..00370a6 > --- /dev/null > +++ b/libavfilter/asrc_noise.c > @@ -0,0 +1,141 @@ > +/* > + * Copyright (c) 2015 Kyle Swanson . > + * > + * This file is part of FFmpeg. > + * > + * FFmpeg is free software; you can redistribute it and/or > + * modify it under the terms of the GNU Lesser General Public License > + * as published by the Free Software Foundation; either > + * version 2.1 of the License, or (at your option) any later version. > + * > + * FFmpeg is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU Lesser General Public License for more details. > + * > + * You should have received a copy of the GNU Lesser General Public License > + * along with FFmpeg; if not, write to the Free Software Foundation, Inc., > + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA > + */ > + > +#include > + > +#include "libavutil/opt.h" > +#include "audio.h" > +#include "avfilter.h" > +#include "internal.h" > +#include "libavutil/lfg.h" > + > +typedef struct { > +const AVClass *class; > +int sample_rate; > +double amplitude; > +double dur_sec; > +int64_t dur_samp; > +AVLFG c; The doxy for it says: * Please also consider a simple LCG like state= state*1664525+1013904223, * it may be good enough and faster for your specific use case. Did you test in terms of speed and noise quality? I used this exact LCG for the pink noise and it sounds fine. The LCG has an additional bonus on top of speed: it is seekable; it may come in handy at a later time. > +} NoiseContext; > + > +#define OFFSET(x) offsetof(NoiseContext, x) > +#define FLAGS AV_OPT_FLAG_AUDIO_PARAM|AV_OPT_FLAG_FI
Re: [FFmpeg-devel] [PATCH] avfilter: add audio noise source
On 10/30/15, Kyle Swanson wrote: > Signed-off-by: Kyle Swanson > --- > Changelog| 1 + > doc/filters.texi | 30 ++ > libavfilter/Makefile | 1 + > libavfilter/allfilters.c | 1 + > libavfilter/asrc_noise.c | 141 asrc_anoisesrc > +++ > libavfilter/version.h| 2 +- > 6 files changed, 175 insertions(+), 1 deletion(-) > create mode 100644 libavfilter/asrc_noise.c > > diff --git a/Changelog b/Changelog > index c49e383..d2ea2e1 100644 > --- a/Changelog > +++ b/Changelog > @@ -29,6 +29,7 @@ version : > - vibrato filter > - innoHeim/Rsupport Screen Capture Codec decoder > - ADPCM AICA decoder > +- noise audio source anoisesrc > > > version 2.8: > diff --git a/doc/filters.texi b/doc/filters.texi > index 15ea77a..0d901cc 100644 > --- a/doc/filters.texi > +++ b/doc/filters.texi > @@ -3193,6 +3193,36 @@ ffplay -f lavfi flite=text='No more be grieved for > which that thou hast done.' > For more information about libflite, check: > @url{http://www.speech.cs.cmu.edu/flite/} > > +@section noise anoisesrc > + > +Generate a white noise audio signal. Please add pink and brown noise in same filter, it should be trivial. > + > +The filter accepts the following options: > + > +@table @option > + > +@item sample_rate, r > +Specify the sample rate. Default value is 48000 Hz. > + > +@item duration, d > +Specify the duration of the generated audio stream. Default value is 10 > seconds. > + > +@item amplitude, a > +Specify the amplitude (0.0 - 1.0) of the generated audio stream. Default > value is 1.0. > + > +@end table > + > +@subsection Examples > + > +@itemize > + > +@item > +Generate 60 seconds of white noise, with a 44.1 kHz sampling rate and an > amplitude of 0.5: > +@example > +noise=d=60:r=44100:a=0.5 > +@end example > +@end itemize > + > @section sine > > Generate an audio signal made of a sine wave with amplitude 1/8. > diff --git a/libavfilter/Makefile b/libavfilter/Makefile > index c5819d4..a0b2232 100644 > --- a/libavfilter/Makefile > +++ b/libavfilter/Makefile > @@ -93,6 +93,7 @@ OBJS-$(CONFIG_VOLUMEDETECT_FILTER) += > af_volumedetect.o > OBJS-$(CONFIG_AEVALSRC_FILTER) += aeval.o > OBJS-$(CONFIG_ANULLSRC_FILTER) += asrc_anullsrc.o > OBJS-$(CONFIG_FLITE_FILTER) += asrc_flite.o > +OBJS-$(CONFIG_NOISE_FILTER) += asrc_noise.o > OBJS-$(CONFIG_SINE_FILTER) += asrc_sine.o > > OBJS-$(CONFIG_ANULLSINK_FILTER) += asink_anullsink.o > diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c > index a538b81..f820441 100644 > --- a/libavfilter/allfilters.c > +++ b/libavfilter/allfilters.c > @@ -115,6 +115,7 @@ void avfilter_register_all(void) > REGISTER_FILTER(AEVALSRC, aevalsrc, asrc); > REGISTER_FILTER(ANULLSRC, anullsrc, asrc); > REGISTER_FILTER(FLITE, flite, asrc); > +REGISTER_FILTER(NOISE, noise, asrc); > REGISTER_FILTER(SINE, sine, asrc); > > REGISTER_FILTER(ANULLSINK, anullsink, asink); > diff --git a/libavfilter/asrc_noise.c b/libavfilter/asrc_noise.c > new file mode 100644 > index 000..00370a6 > --- /dev/null > +++ b/libavfilter/asrc_noise.c > @@ -0,0 +1,141 @@ > +/* > + * Copyright (c) 2015 Kyle Swanson . > + * > + * This file is part of FFmpeg. > + * > + * FFmpeg is free software; you can redistribute it and/or > + * modify it under the terms of the GNU Lesser General Public License > + * as published by the Free Software Foundation; either > + * version 2.1 of the License, or (at your option) any later version. > + * > + * FFmpeg is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU Lesser General Public License for more details. > + * > + * You should have received a copy of the GNU Lesser General Public License > + * along with FFmpeg; if not, write to the Free Software Foundation, Inc., > + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA > + */ > + > +#include > + > +#include "libavutil/opt.h" > +#include "audio.h" > +#include "avfilter.h" > +#include "internal.h" > +#include "libavutil/lfg.h" > + > +typedef struct { > +const AVClass *class; > +int sample_rate; > +double amplitude; > +double dur_sec; > +int64_t dur_samp; > +AVLFG c; > +} NoiseContext; > + > +#define OFFSET(x) offsetof(NoiseContext, x) > +#define FLAGS AV_OPT_FLAG_AUDIO_PARAM|AV_OPT_FLAG_FILTERING_PARAM > + > +static const AVOption noise_options[] = { > +{ "sample_rate", "set sample rate",OFFSET(sample_rate), > AV_OPT_TYPE_INT, {.i64 = 48000}, 15, INT_MAX, FLAGS }, > +{ "r", "set sample rate",OFFSET(sample_rate), > AV_OPT_TYPE_INT, {.i64 = 48000}, 15, INT_MAX, FLAGS }, > +{ "amplitude
Re: [FFmpeg-devel] [PATCHv2] avutil/file_open: avoid file handle inheritance on Windows
On Fri, 30 Oct 2015 16:15:30 +0100 Tobias Rapp wrote: > On 30.10.2015 15:06, wm4 wrote: > > On Fri, 30 Oct 2015 11:30:40 +0100 > > Tobias Rapp wrote: > > > >> On 29.10.2015 09:38, Tobias Rapp wrote: > >>> Attached patch fixes file lock issues in my Windows application when a > >>> child process is started with handle inheritance enabled (standard > >>> input/output redirection) while a FFmpeg transcoding is running in the > >>> parent process. > >>> > >>> BTW: It would be great if the patch could also be applied to the 2.7/2.8 > >>> release branches. > >> > >> Forgot to add links relevant to the subject. > >> > >> [1] https://msdn.microsoft.com/en-us/library/w7sa2b22.aspx > >> > >> Describes the _wsopen() function and the O_NOINHERIT flag. File handles > >> opened by _wsopen() are inheritable by default. > >> > >> [2] > >> https://msdn.microsoft.com/en-us/library/windows/desktop/aa363858%28v=vs.85%29.aspx > >> > >> Describes the CreateFile() function. Not directly relevant here, often > >> used in cases outside of C/libc. Opens file without inheritance by > >> default (lpSecurityAttributes is NULL). > >> > >> [3] > >> https://msdn.microsoft.com/en-us/library/windows/desktop/ms682425%28v=vs.85%29.aspx > >> > >> Describes handle inheritance when creating new processes. Handle > >> inheritance must be enabled (bInheritHandles = TRUE) e.g. when you want > >> to pass handles for stdin/stdout via lpStartupInfo. > > > > Would be great if you could put all this stuff into the commit message. > > Have attached a more verbose version of the patch. Thanks. > > Would it make sense to define O_CLOEXEC to O_NOINHERIT on Windows? > > Although to my knowledge O_CLOEXEC and O_NOINHERIT cause the same > behavior it would be confusing to trace when O_CLOEXEC maps to the > original Linux definition and when it maps to the Windows override when > reading source code. If someone finds it useful a definition like > FF_O_CLOEXEC could be added (to which file?) that maps to the correct > flag depending on the platform. OK, since we use it only in 1 place anyway, this is probably not needed. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avfilter: add audio noise source
Signed-off-by: Kyle Swanson --- Changelog| 1 + doc/filters.texi | 30 ++ libavfilter/Makefile | 1 + libavfilter/allfilters.c | 1 + libavfilter/asrc_noise.c | 141 +++ libavfilter/version.h| 2 +- 6 files changed, 175 insertions(+), 1 deletion(-) create mode 100644 libavfilter/asrc_noise.c diff --git a/Changelog b/Changelog index c49e383..d2ea2e1 100644 --- a/Changelog +++ b/Changelog @@ -29,6 +29,7 @@ version : - vibrato filter - innoHeim/Rsupport Screen Capture Codec decoder - ADPCM AICA decoder +- noise audio source version 2.8: diff --git a/doc/filters.texi b/doc/filters.texi index 15ea77a..0d901cc 100644 --- a/doc/filters.texi +++ b/doc/filters.texi @@ -3193,6 +3193,36 @@ ffplay -f lavfi flite=text='No more be grieved for which that thou hast done.' For more information about libflite, check: @url{http://www.speech.cs.cmu.edu/flite/} +@section noise + +Generate a white noise audio signal. + +The filter accepts the following options: + +@table @option + +@item sample_rate, r +Specify the sample rate. Default value is 48000 Hz. + +@item duration, d +Specify the duration of the generated audio stream. Default value is 10 seconds. + +@item amplitude, a +Specify the amplitude (0.0 - 1.0) of the generated audio stream. Default value is 1.0. + +@end table + +@subsection Examples + +@itemize + +@item +Generate 60 seconds of white noise, with a 44.1 kHz sampling rate and an amplitude of 0.5: +@example +noise=d=60:r=44100:a=0.5 +@end example +@end itemize + @section sine Generate an audio signal made of a sine wave with amplitude 1/8. diff --git a/libavfilter/Makefile b/libavfilter/Makefile index c5819d4..a0b2232 100644 --- a/libavfilter/Makefile +++ b/libavfilter/Makefile @@ -93,6 +93,7 @@ OBJS-$(CONFIG_VOLUMEDETECT_FILTER) += af_volumedetect.o OBJS-$(CONFIG_AEVALSRC_FILTER) += aeval.o OBJS-$(CONFIG_ANULLSRC_FILTER) += asrc_anullsrc.o OBJS-$(CONFIG_FLITE_FILTER) += asrc_flite.o +OBJS-$(CONFIG_NOISE_FILTER) += asrc_noise.o OBJS-$(CONFIG_SINE_FILTER) += asrc_sine.o OBJS-$(CONFIG_ANULLSINK_FILTER) += asink_anullsink.o diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c index a538b81..f820441 100644 --- a/libavfilter/allfilters.c +++ b/libavfilter/allfilters.c @@ -115,6 +115,7 @@ void avfilter_register_all(void) REGISTER_FILTER(AEVALSRC, aevalsrc, asrc); REGISTER_FILTER(ANULLSRC, anullsrc, asrc); REGISTER_FILTER(FLITE, flite, asrc); +REGISTER_FILTER(NOISE, noise, asrc); REGISTER_FILTER(SINE, sine, asrc); REGISTER_FILTER(ANULLSINK, anullsink, asink); diff --git a/libavfilter/asrc_noise.c b/libavfilter/asrc_noise.c new file mode 100644 index 000..00370a6 --- /dev/null +++ b/libavfilter/asrc_noise.c @@ -0,0 +1,141 @@ +/* + * Copyright (c) 2015 Kyle Swanson . + * + * This file is part of FFmpeg. + * + * FFmpeg is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public License + * as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * FFmpeg is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public License + * along with FFmpeg; if not, write to the Free Software Foundation, Inc., + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#include + +#include "libavutil/opt.h" +#include "audio.h" +#include "avfilter.h" +#include "internal.h" +#include "libavutil/lfg.h" + +typedef struct { +const AVClass *class; +int sample_rate; +double amplitude; +double dur_sec; +int64_t dur_samp; +AVLFG c; +} NoiseContext; + +#define OFFSET(x) offsetof(NoiseContext, x) +#define FLAGS AV_OPT_FLAG_AUDIO_PARAM|AV_OPT_FLAG_FILTERING_PARAM + +static const AVOption noise_options[] = { +{ "sample_rate", "set sample rate",OFFSET(sample_rate), AV_OPT_TYPE_INT, {.i64 = 48000}, 15, INT_MAX, FLAGS }, +{ "r", "set sample rate",OFFSET(sample_rate), AV_OPT_TYPE_INT, {.i64 = 48000}, 15, INT_MAX, FLAGS }, +{ "amplitude", "set amplitude", OFFSET(amplitude), AV_OPT_TYPE_DOUBLE, {.dbl = 1.},0., 1., FLAGS }, +{ "a", "set amplitude", OFFSET(amplitude), AV_OPT_TYPE_DOUBLE, {.dbl = 1.},0., 1., FLAGS }, +{ "duration","set duration", OFFSET(dur_sec), AV_OPT_TYPE_DOUBLE, {.dbl = 10.}, 0., DBL_MAX, FLAGS }, +{ "d", "set duration",
Re: [FFmpeg-devel] [PATCH] avutil/wchar_filename: add av_warn_unused_result
On Fri, Oct 30, 2015 at 6:07 AM, Michael Niedermayer wrote: > On Thu, Oct 15, 2015 at 08:01:56PM -0400, Ganesh Ajjanagadde wrote: >> Current code is fine, this just adds robustness. >> >> Signed-off-by: Ganesh Ajjanagadde >> --- >> libavutil/wchar_filename.h | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/libavutil/wchar_filename.h b/libavutil/wchar_filename.h >> index c553c46..2ade321 100644 >> --- a/libavutil/wchar_filename.h >> +++ b/libavutil/wchar_filename.h >> @@ -23,6 +23,7 @@ >> #include >> #include "mem.h" >> >> +av_warn_unused_result >> static inline int utf8towchar(const char *filename_utf8, wchar_t >> **filename_w) >> { >> int num_chars; > > LGTM > > thanks thanks, will push later. Please consider all other av_warn_unused_result patches dropped; I am going to add in a much more targeted fashion first. Please don't waste time reviewing them. > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Asymptotically faster algorithms should always be preferred if you have > asymptotical amounts of data > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avfilter/showcqt: fix dependency with avformat
patch attached From 1902fc28da0b7d03e0f329397691006f9b432079 Mon Sep 17 00:00:00 2001 From: Muhammad Faiz Date: Fri, 30 Oct 2015 23:35:02 +0700 Subject: [PATCH] avfilter/showcqt: fix dependency with avformat --- configure| 2 +- libavfilter/Makefile | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/configure b/configure index 3f0ef0d..95790f4 100755 --- a/configure +++ b/configure @@ -2832,7 +2832,7 @@ scale_filter_deps="swscale" scale2ref_filter_deps="swscale" select_filter_select="pixelutils" smartblur_filter_deps="gpl swscale" -showcqt_filter_deps="avcodec swscale" +showcqt_filter_deps="avcodec avformat swscale" showcqt_filter_select="fft" showfreqs_filter_deps="avcodec" showfreqs_filter_select="fft" diff --git a/libavfilter/Makefile b/libavfilter/Makefile index c5819d4..1b23085 100644 --- a/libavfilter/Makefile +++ b/libavfilter/Makefile @@ -272,7 +272,7 @@ OBJS-$(CONFIG_ADRAWGRAPH_FILTER) += f_drawgraph.o OBJS-$(CONFIG_APHASEMETER_FILTER)+= avf_aphasemeter.o OBJS-$(CONFIG_AVECTORSCOPE_FILTER) += avf_avectorscope.o OBJS-$(CONFIG_CONCAT_FILTER) += avf_concat.o -OBJS-$(CONFIG_SHOWCQT_FILTER)+= avf_showcqt.o lswsutils.o +OBJS-$(CONFIG_SHOWCQT_FILTER)+= avf_showcqt.o lswsutils.o lavfutils.o OBJS-$(CONFIG_SHOWFREQS_FILTER) += avf_showfreqs.o OBJS-$(CONFIG_SHOWSPECTRUM_FILTER) += avf_showspectrum.o OBJS-$(CONFIG_SHOWVOLUME_FILTER) += avf_showvolume.o -- 1.8.3.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avutil/mathematics: correct documentation for av_gcd
On Tue, Oct 27, 2015 at 08:18:34PM -0400, Ganesh Ajjanagadde wrote: > av_gcd is now always defined regardless of input. This documents this > change in the "documented API". Two benefits (closely related): > 1. The function is robust, and there is no need to worry about INT64_MIN, etc. > > 2. Clients of av_gcd, like av_reduce, can now be made fully correct. > Currently, > av_reduce can trigger undefined behavior if e.g num is INT64_MIN due to > integer overflow in the FFABS. Furthermore, this undefined behavior is > completely undocumented, and could be a fuzzer's paradise. The FFABS was > needed in the past as > av_gcd was undefined for negative inputs. In order to make av_reduce > robust, it is essential to guarantee that av_gcd works for all int64_t. > > Signed-off-by: Ganesh Ajjanagadde > --- > libavutil/mathematics.h | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/libavutil/mathematics.h b/libavutil/mathematics.h > index ac94488..6fc2577 100644 > --- a/libavutil/mathematics.h > +++ b/libavutil/mathematics.h > @@ -77,9 +77,9 @@ enum AVRounding { > }; > > /** > - * Return the greatest common divisor of a and b. > - * If both a and b are 0 or either or both are <0 then behavior is > - * undefined. > + * Compute the greatest common divisor of a and b. > + * > + * @return gcd of a and b up to sign; if a and b are both zero returns 0 > */ > int64_t av_const av_gcd(int64_t a, int64_t b); LGTM thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] possible farewell; dev policy clarification
On Fri, Oct 30, 2015 at 8:42 AM, Paul B Mahol wrote: > On 10/30/15, Ganesh Ajjanagadde wrote: >> Hi all, >> >> Apologies for the length of the email, but there is a lot of stuff I >> would like to cover due to my absence on IRC or other venues for "non >> patch related" discussion. >> >> There has been a lot said and still being said regarding some patches >> I sent and associated discussion. Issues not related to patches in a >> technical sense are being discussed privately. >> >> In the meantime, I have noticed an increased level of hostility on >> ffmpeg-devel lately, both from my end as well as from others. I do not >> wish to escalate it further, and want to let work progress as smoothly >> as possible. >> >> In fact, I repeat a statement I made earlier: if overall people think >> that if I leave better and more work will be done for the project, I >> will gladly do so. That is the only thing I wish for: FFmpeg becoming >> better. To clarify a possible confusion on IRC: I by no means intend >> to work on Libav - either I work for FFmpeg, or not work at all on >> multimedia. This statement holds true regardless of what people >> express about the work I do here, whether I am kicked out, etc. >> >> The reason I repeat this question of leaving is because I dug through >> IRC archives, trying to understand better what people here think of >> the work I do in light of the increasing hostility on the ML. I got >> the sense that a lot of information that I could have received did not >> reach me as I am, and will not be on IRC. I also got the sense that >> there is a section of FFmpeg developers who are deeply against the >> kinds of things I do and the way I handle them, hence prompting the >> question. >> >> Assuming that you feel I give a net positive benefit to the project, >> please read on. >> >> I am quite puzzled with some of the sentiments expressed there. I >> illustrate below what puzzles me, and ask what I can do on my end: >> >> 1. "Sloppy" patches - I tend to give more verbose commit messages to >> explain rationale than many here. I also outlined why I did not post >> benchmarks initially. I myself still think they are unnecessary and >> not useful for many of my proposed changes, but the community here >> seemed to think otherwise. I have hence started posting benchmarks. >> I generally try to give evidence for things that are more "universal" >> in character when possible, so as not to skew towards any particular >> machine architecture, etc. I do not agree that the log patches were >> "sloppy" - bit accuracy improvements for log10 over log should have >> been obvious. Simplification of the code, a subjective aspect, should >> have been quite a reasonable assumption. Do people here not think such >> things are obvious? >> >> 2. "Increasing warnings" - There were only 2 instances AFAIK where I >> made a mistake, one in apedec. Another was in a test build. Both were >> very quickly resolved. These issues were tiny compared to the general >> level of warning cleanups achieved. Both were reasonable mistakes that >> missed the eyes of reviewers. Please do let me know when I do increase >> such things, I try to test things the best I can on my end. I will >> strive to be more cautious in the future by incorporating the lessons >> learnt with these two failures. >> >> 3. Patch sending mechanism - I have tried both approaches, namely an >> en-masse single patch, versus individual tiny patches. Both were >> frowned upon: the en-masse as "not fond of mass changes", and the >> single patches as "incredibly noisy". Regarding pinging, I pinged a >> single patch in a set of similar patches with a phrase regarding the >> fact that the ping extends to other such similar patches. This ping >> was ignored. I push (following the dev policy) one change after >> sufficient delay, and it was frowned upon. I did not know what to do, >> so I subsequently pinged each of the patches. This resulted in a bunch >> of comments on IRC. For reference, these are the av_warn_unused_result >> patches for avutil. Any suggestions for the future? >> >> 4. av_warn_unused_result not being useful en-masse for all headers - >> This was something remarked upon in IRC. I did not get this >> information in the form of reviews. Please suggest which headers to >> target first: I am currently just going one by one in a natural order >> (so that I can keep track of which ones have been addressed). Of >> course, if people think av_warn_unused_result is inherently bad, that >> is a separate issue that reflects an even deeper gulf. >> >> 5. General communication failures - Clearly, a lot of important stuff >> from IRC is not reaching the ML. I (and some others here) do not use >> IRC, and are pretty firm about not using it. What can be done to >> address the communication gap? I would have at least understood the >> deep hostility to the work I do if I had seen IRC logs a few weeks >> back. The ML got only the "effects" and little of the "c
Re: [FFmpeg-devel] [PATCHv2] avutil/file_open: avoid file handle inheritance on Windows
On 30.10.2015 15:06, wm4 wrote: On Fri, 30 Oct 2015 11:30:40 +0100 Tobias Rapp wrote: On 29.10.2015 09:38, Tobias Rapp wrote: Attached patch fixes file lock issues in my Windows application when a child process is started with handle inheritance enabled (standard input/output redirection) while a FFmpeg transcoding is running in the parent process. BTW: It would be great if the patch could also be applied to the 2.7/2.8 release branches. Forgot to add links relevant to the subject. [1] https://msdn.microsoft.com/en-us/library/w7sa2b22.aspx Describes the _wsopen() function and the O_NOINHERIT flag. File handles opened by _wsopen() are inheritable by default. [2] https://msdn.microsoft.com/en-us/library/windows/desktop/aa363858%28v=vs.85%29.aspx Describes the CreateFile() function. Not directly relevant here, often used in cases outside of C/libc. Opens file without inheritance by default (lpSecurityAttributes is NULL). [3] https://msdn.microsoft.com/en-us/library/windows/desktop/ms682425%28v=vs.85%29.aspx Describes handle inheritance when creating new processes. Handle inheritance must be enabled (bInheritHandles = TRUE) e.g. when you want to pass handles for stdin/stdout via lpStartupInfo. Would be great if you could put all this stuff into the commit message. Have attached a more verbose version of the patch. Would it make sense to define O_CLOEXEC to O_NOINHERIT on Windows? Although to my knowledge O_CLOEXEC and O_NOINHERIT cause the same behavior it would be confusing to trace when O_CLOEXEC maps to the original Linux definition and when it maps to the Windows override when reading source code. If someone finds it useful a definition like FF_O_CLOEXEC could be added (to which file?) that maps to the correct flag depending on the platform. Regards, Tobias >From c2b599c18a173ce3a2f053701bc4ef1f14ef7aea Mon Sep 17 00:00:00 2001 From: Tobias Rapp Date: Thu, 29 Oct 2015 09:11:37 +0100 Subject: [PATCH] avutil/file_open: avoid file handle inheritance on Windows Avoids inheritance of file handles on Windows systems similar to the O_CLOEXEC/FD_CLOEXEC flag on Linux. Fixes file lock issues in Windows applications when a child process is started with handle inheritance enabled (standard input/output redirection) while a FFmpeg transcoding is running in the parent process. Links relevant to the subject: https://msdn.microsoft.com/en-us/library/w7sa2b22.aspx Describes the _wsopen() function and the O_NOINHERIT flag. File handles opened by _wsopen() are inheritable by default. https://msdn.microsoft.com/en-us/library/windows/desktop/ms682425%28v=vs.85%29.aspx Describes handle inheritance when creating new processes. Handle inheritance must be enabled (bInheritHandles = TRUE) e.g. when you want to pass handles for stdin/stdout via lpStartupInfo. Signed-off-by: Tobias Rapp --- libavutil/file_open.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/libavutil/file_open.c b/libavutil/file_open.c index 3f9a67c..9e76127 100644 --- a/libavutil/file_open.c +++ b/libavutil/file_open.c @@ -77,6 +77,9 @@ int avpriv_open(const char *filename, int flags, ...) #ifdef O_CLOEXEC flags |= O_CLOEXEC; #endif +#ifdef O_NOINHERIT +flags |= O_NOINHERIT; +#endif fd = open(filename, flags, mode); #if HAVE_FCNTL -- 1.9.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] possible farewell; dev policy clarification
On Fri, Oct 30, 2015 at 10:07 AM, Nicolas George wrote: > Hi. > > I am not on IRC either, so I can not comment on what happen there. I hope I > have not shown myself what you consider hostility on this list. I will try > to explain what I think may irritate people in your actions on this list. > > I will not comment on the issue of pushing without having addressed > comments and similar issues, they are basically misunderstandings that time > will fix. > > In short: you should have already moved to the next level. > > In less short: you have found a few easy ways of enhancing the code > (consistency in variable naming, enabling warnings and fixing them), and > made good of them. Very well. There is nothing wrong with starting easy, > almost everybody did. I guess this boiled down to a question of timing: I kept postponing the plan to move to the "next level". Maybe I took too much comfort in simple changes, without considering the negative "social aspects". I personally had set roughly Jan/Feb of next year for such a move. Your comments and other reactions have convinced me that is best if I do so ASAP. Here is the solution I propose. I do not want to leave mini-projects I began unfinished. However, I understand the negative reactions. I will limit "cosmetic/simple changes" to one patch per day (at max) to not flood the ML. This will slowly let me get rid of e.g av_warn_unused_result baggage, while transitioning to other work. Does this sound agreeable to all? > > But now, you continue digging in the same veins, although they are mostly > dry. For example, the integer stuff: yes, theoretically it violates the C > standard, but most of it will never be an issue, because the extra > assumptions it makes (32-bits integer, two's complement for sign) will be > kept for ever. Remember that FFmpeg's code is significantly above standard > when it comes to portability: if FFmpeg breaks, a lot more program break > too, and that would not be acceptable for the people who design compilers. > > After your first contributions, people will expect that you would have > become capable of evaluating the value of these bugfixes. Remember that even > a small and obviously correct fix has drawbacks: it may cause merge > conflicts, and therefore more work for Hendrik, it pollutes the output of > git blame and may take one more git bissect step. And simply it may make the > code slightly less readable. Point noted. > > For example, the log10 stuff: yes, the change is valid, but in most places, > it does not matter at all, the extra accuracy and speed are irrelevant. So > do not waste your time, and the time of the people you ask to review your > patches, on this. If you find a place where the difference is critical, then > of course go ahead, well done; if you see new code that should use log10, > comment before it is applied; all this is worthy. But for most of the > existing code, leave it be, because the enhancement is too small compared to > the drawbacks. > > And for yourself: how much thinking efforts did you need to produce the > log10 patches? My guess is: almost none at all, you noticed the possible > change and the rest was completely straightforward. Does it satisfy you? I would have been ok if it did not result in this much ML noise. But given the overall episode, I do regret it. None of these things are satisfying, but to be honest, I am not looking for satisfaction from FFmpeg. I am looking for a way to channel frittered away energy obtained during my transition from undergraduate to graduate life and its associated increase in flexibility of time allocation. In other words, I want a way to spend my down-time that is technical in character. > > Instead, start spending your efforts on more difficult tasks. That is what I > meant by "next level". Unless I am misremembering, all your changes only had > a local influence: the syntax of an integer constant, a formula or a > function call, at most, a whole mathematical function. But you have the > skill to try to understand how the function interact with each other, to > address issues that require understanding how a whole subsystem works. Looking back, I think the first commits I made were perhaps among the best ones I did: they were simple, but fixed tickets in clean ways. I can take it to the next level by focusing on ones that require understanding of interactions. Or perhaps the closest example to what you have in mind is the ffplay volume control, it is something I personally found annoying (I solely use ffplay for playback, mpv and vlc are not even installed on my system). On a lighthearted note, the reason for my setup is because by default, ffplay displays a spectrogram for audio files which appealed a lot to some of my signal processing background :). Any mpv/VLC people can take this as an informal "feature request" - VLC definitely did not do this a year back. > > If you need ideas on what to try, look at the trac ticket, especially the > ones that
Re: [FFmpeg-devel] possible farewell; dev policy clarification
On Fri, Oct 30, 2015 at 01:42:30PM +0100, Paul B Mahol wrote: > On 10/30/15, Ganesh Ajjanagadde wrote: [...] > > e) I have no personal interest in asm optimizations (to address a > > suggestion on IRC). I do appreciate the hard work there, it just does > > not appeal to me for reasons that I can answer privately. I am > > interested in security aspects, algorithmic improvements, bug fixes, > > and clean up (in that order). Currently I am trying to get rid of a > > lot of the last aspect to create a foundation for myself to work on > > other things. Part of that transition is already under way - see e.g > > av_gcd patches as an algorithmic improvement. > > > > Please feel free to add things, send private email, or public > > questions so that we can come to a better understanding. > > I'm just going to tell you that you should ask before pushing something > that was not explicitly approved or even worse, was rejected. There where alot of patches, and i mean alot of good patches but its sometimes difficult to keep track of who said what in patch review. I do think i checked and approved the log* patches that where pushed yesterday. more generally Its possible for review comments to be misunderstood, or even forgotten, both by other reviewers, the author or commiter, I do not think that this leads to any technical problem in practice as people notice very quickly when their comments have not been taken care of the way they expected What i like to ask people is to, if that happens not to assume mallice because that is neither likely nor would it be productive to assume that. If something gets ignored it is IMO basically always some misunderstanding or mistake. Now maybe there are also some simple and small technical changes that could reduce confusion. One would maybe be to add a "Approved-by:" or "Reviewed-by:" line to commit messages when the reviewer differs from the commiter and author This way one can see at a first glance who approved/reviewed each patch. I dont think this needs to be always added but maybe in cases where there is already some confusion it could maybe avoid further misuderstandings [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB DNS cache poisoning attacks, popular search engine, Google internet authority dont be evil, please signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avutil/mathematics: correct documentation for av_gcd
On Thu, Oct 29, 2015 at 07:49:44PM -0400, Ganesh Ajjanagadde wrote: [...] > although you did explain to me where optimizations could be useful at > an algorithmic level privately, I take this as an opportunity to > request for general comments on places that people think could benefit > from performance at a C/algorithmic level (NOT asm/simd stuff for me > personally): yet another ping for Clement. Mmh... without SIMD let me think... You may look at the TODO in libavfilter/f_ebur128.c. There is a PRE-filter and a RLB-filter to merge into one to reduce computation time. This is an already solved mathematical problem. You may want to have a look, it's most likely a good way to speed up that filter algorithmically. Then maybe you can look into adding threading support in some codecs or filters. No other idea that do not involve SIMD right now. [...] -- 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] possible farewell; dev policy clarification
Hi. I am not on IRC either, so I can not comment on what happen there. I hope I have not shown myself what you consider hostility on this list. I will try to explain what I think may irritate people in your actions on this list. I will not comment on the issue of pushing without having addressed comments and similar issues, they are basically misunderstandings that time will fix. In short: you should have already moved to the next level. In less short: you have found a few easy ways of enhancing the code (consistency in variable naming, enabling warnings and fixing them), and made good of them. Very well. There is nothing wrong with starting easy, almost everybody did. But now, you continue digging in the same veins, although they are mostly dry. For example, the integer stuff: yes, theoretically it violates the C standard, but most of it will never be an issue, because the extra assumptions it makes (32-bits integer, two's complement for sign) will be kept for ever. Remember that FFmpeg's code is significantly above standard when it comes to portability: if FFmpeg breaks, a lot more program break too, and that would not be acceptable for the people who design compilers. After your first contributions, people will expect that you would have become capable of evaluating the value of these bugfixes. Remember that even a small and obviously correct fix has drawbacks: it may cause merge conflicts, and therefore more work for Hendrik, it pollutes the output of git blame and may take one more git bissect step. And simply it may make the code slightly less readable. For example, the log10 stuff: yes, the change is valid, but in most places, it does not matter at all, the extra accuracy and speed are irrelevant. So do not waste your time, and the time of the people you ask to review your patches, on this. If you find a place where the difference is critical, then of course go ahead, well done; if you see new code that should use log10, comment before it is applied; all this is worthy. But for most of the existing code, leave it be, because the enhancement is too small compared to the drawbacks. And for yourself: how much thinking efforts did you need to produce the log10 patches? My guess is: almost none at all, you noticed the possible change and the rest was completely straightforward. Does it satisfy you? Instead, start spending your efforts on more difficult tasks. That is what I meant by "next level". Unless I am misremembering, all your changes only had a local influence: the syntax of an integer constant, a formula or a function call, at most, a whole mathematical function. But you have the skill to try to understand how the function interact with each other, to address issues that require understanding how a whole subsystem works. If you need ideas on what to try, look at the trac ticket, especially the ones that are "reproduced by developer" (so you know it is not just a PEBKAC) but not "analyzed by developer". But if dealing with people's bugs annoy you, there are plenty of tasks where your skills could be useful: just find some aspect of FFmpeg's behaviour that you find annoying and try to find a way of enhancing it. Error messages drowned under information messages, more readable output for the stream summaries, etc. And of course, there are many ideas floating around: non-blocking demuxers (hard), more FATE coverage, simplifying codex context cleanup, DATA media type in lavfi (hard), merging the libraries in a single one. And of course, you can come up with your own ideas completely out of the box: a GUI to explore codec options? make an API to access the documentation? a web interface to manage patches? So to summary my advice: try to attack harder problems, you are ready for it and that would make your contributions even more valuable and well received. HTH Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avutil/file_open: avoid file handle inheritance on Windows
On Fri, 30 Oct 2015 11:30:40 +0100 Tobias Rapp wrote: > On 29.10.2015 09:38, Tobias Rapp wrote: > > Attached patch fixes file lock issues in my Windows application when a > > child process is started with handle inheritance enabled (standard > > input/output redirection) while a FFmpeg transcoding is running in the > > parent process. > > > > BTW: It would be great if the patch could also be applied to the 2.7/2.8 > > release branches. > > Forgot to add links relevant to the subject. > > [1] https://msdn.microsoft.com/en-us/library/w7sa2b22.aspx > > Describes the _wsopen() function and the O_NOINHERIT flag. File handles > opened by _wsopen() are inheritable by default. > > [2] > https://msdn.microsoft.com/en-us/library/windows/desktop/aa363858%28v=vs.85%29.aspx > > Describes the CreateFile() function. Not directly relevant here, often > used in cases outside of C/libc. Opens file without inheritance by > default (lpSecurityAttributes is NULL). > > [3] > https://msdn.microsoft.com/en-us/library/windows/desktop/ms682425%28v=vs.85%29.aspx > > Describes handle inheritance when creating new processes. Handle > inheritance must be enabled (bInheritHandles = TRUE) e.g. when you want > to pass handles for stdin/stdout via lpStartupInfo. Would be great if you could put all this stuff into the commit message. Would it make sense to define O_CLOEXEC to O_NOINHERIT on Windows? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avutil/file_open: avoid file handle inheritance on Windows
On 30.10.2015 11:54, Hendrik Leppkes wrote: On Fri, Oct 30, 2015 at 11:30 AM, Tobias Rapp wrote: On 29.10.2015 09:38, Tobias Rapp wrote: Attached patch fixes file lock issues in my Windows application when a child process is started with handle inheritance enabled (standard input/output redirection) while a FFmpeg transcoding is running in the parent process. BTW: It would be great if the patch could also be applied to the 2.7/2.8 release branches. Forgot to add links relevant to the subject. [1] https://msdn.microsoft.com/en-us/library/w7sa2b22.aspx Describes the _wsopen() function and the O_NOINHERIT flag. File handles opened by _wsopen() are inheritable by default. [2] https://msdn.microsoft.com/en-us/library/windows/desktop/aa363858%28v=vs.85%29.aspx Describes the CreateFile() function. Not directly relevant here, often used in cases outside of C/libc. Opens file without inheritance by default (lpSecurityAttributes is NULL). [3] https://msdn.microsoft.com/en-us/library/windows/desktop/ms682425%28v=vs.85%29.aspx Describes handle inheritance when creating new processes. Handle inheritance must be enabled (bInheritHandles = TRUE) e.g. when you want to pass handles for stdin/stdout via lpStartupInfo. Its probably fine, the only concerns I can think of is what happens if you try use ffmpeg.exe as a subprocess operating on a pipe fed by the parent process, would this still work? Yes, in that case you can still create your pipe handle and explicitly set bInheritHandle = TRUE in the security attributes. Then pass the handle to ffmpeg.exe. This is basically what I'm currently doing except that I pass the pipe handles as stdin/stdout to the client ffmpeg.exe process instead of using them within some "pipe:1234" protocol URL. Regards, Tobias ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] possible farewell; dev policy clarification
On Fri, Oct 30, 2015 at 07:34:29AM -0400, Ganesh Ajjanagadde wrote: [...] TL;DR Reviews are not meant to encourage, reviews are meant to find problems. A good review is a review where problems are found and pointed out. Sometimes, reviews mean suggesting way to find issues (which is then generally up to you). The general state of mind is a defense one. As a result, you should not take things personally. If you want more casual communications, you may try IRC. Otherwise, no need to overreact, just focus on the technical aspect. Keep up your good work. Best regards, -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] possible farewell; dev policy clarification
Hi, I'll chime in on a few points. On 10/30/2015 11:34 AM, Ganesh Ajjanagadde wrote: > 1. "Sloppy" patches - I tend to give more verbose commit messages to > explain rationale than many here. I also outlined why I did not post > benchmarks initially. I myself still think they are unnecessary and > not useful for many of my proposed changes, but the community here > seemed to think otherwise. I have hence started posting benchmarks. > I generally try to give evidence for things that are more "universal" > in character when possible, so as not to skew towards any particular > machine architecture, etc. I do not agree that the log patches were > "sloppy" - bit accuracy improvements for log10 over log should have > been obvious. Simplification of the code, a subjective aspect, should > have been quite a reasonable assumption. Do people here not think such > things are obvious? I am sorry to say, this comes off as a bit arrogant. The onus of proving a patchset's worth is on its author, and "it's obvious" is not a valid reasoning. There's no reason to be offended when asked to defend a patch's value; it's one of the main reasons for reviews in the first place. > 3. Patch sending mechanism - I have tried both approaches, namely an > en-masse single patch, versus individual tiny patches. Both were > frowned upon: the en-masse as "not fond of mass changes", and the > single patches as "incredibly noisy". Regarding pinging, I pinged a > single patch in a set of similar patches with a phrase regarding the > fact that the ping extends to other such similar patches. This ping > was ignored. I push (following the dev policy) one change after > sufficient delay, and it was frowned upon. I did not know what to do, > so I subsequently pinged each of the patches. This resulted in a bunch > of comments on IRC. For reference, these are the av_warn_unused_result > patches for avutil. Any suggestions for the future? One thing you could do is provide a little more rigorous testing / investigation. Example: Making sure libm.h was included everywhere where log10 was used. Part of the reason people got a bit annoyed is that they are large changesets that are easy to write, and tedious to review and confirm correct. Providing some info to that aspect in the cover letter, for example, can go a long way. > 5. General communication failures - Clearly, a lot of important stuff > from IRC is not reaching the ML. I (and some others here) do not use > IRC, and are pretty firm about not using it. What can be done to > address the communication gap? I would have at least understood the > deep hostility to the work I do if I had seen IRC logs a few weeks > back. The ML got only the "effects" and little of the "causes". > Overall, my sense is that people let the negative reaction bottle up, > venting every now and then on IRC, since for whatever reason it is > more comfortable, although technically both are publicly recorded and > nearly as easily referenced in mails or commit messages. As a side > note, even some patch review is done on IRC, a situation I do not like > but have not raised so far as I am not affected by it. Valid point, yes. I do think it is beneficial to have real-time conversation to discuss changes, sometimes, however. Summaries should probably sent to the ML, though, for "archival" Overall, I think you may be too defensive of your own code / ideas sometimes. That's understandable, but it's important to not take critical reviews so harshly, I believe. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 8/8] FATE: add crypto protocol test
On Wed, Oct 28, 2015 at 05:39:39AM -0500, Rodger Combs wrote: > --- > tests/Makefile | 5 + > tests/fate/avformat.mak | 1 + > tests/lavf-regression.sh | 9 + > tests/ref/lavf/crypto| 3 +++ > 4 files changed, 18 insertions(+) > create mode 100644 tests/ref/lavf/crypto > > diff --git a/tests/Makefile b/tests/Makefile > index 7ee4a46..c501813 100644 > --- a/tests/Makefile > +++ b/tests/Makefile > @@ -82,6 +82,11 @@ ENCDEC2 = $(call ALLYES, $(firstword $(1))_ENCODER > $(lastword $(1))_DECODER \ > $(firstword $(2))_ENCODER $(lastword $(2))_DECODER > \ > $(firstword $(3))_MUXER $(lastword $(3))_DEMUXER) > > +ENCDEC2PRO = $(call ALLYES, $(firstword $(1))_ENCODER $(lastword > $(1))_DECODER \ > +$(firstword $(2))_ENCODER $(lastword > $(2))_DECODER \ > +$(firstword $(3))_MUXER $(lastword > $(3))_DEMUXER \ > +$(firstword $(4))_PROTOCOL) > + > DEMDEC = $(call ALLYES, $(1)_DEMUXER $(2:%=%_DECODER)) > ENCMUX = $(call ALLYES, $(1:%=%_ENCODER) $(2)_MUXER) > > diff --git a/tests/fate/avformat.mak b/tests/fate/avformat.mak > index 1d13434..e65c3f9 100644 > --- a/tests/fate/avformat.mak > +++ b/tests/fate/avformat.mak > @@ -6,6 +6,7 @@ FATE_LAVF-$(call ENCDEC, PCM_S16BE, AU) >+= au > FATE_LAVF-$(call ENCDEC2, MPEG4, MP2, AVI)+= avi > FATE_LAVF-$(call ENCDEC, BMP, IMAGE2) += bmp > FATE_LAVF-$(call ENCDEC, PCM_S16BE, CAF)+= caf > +FATE_LAVF-$(call ENCDEC2PRO, MPEG4, MP2, NUT, CRYPTO)+= > crypto > FATE_LAVF-$(call ENCDEC, DPX, IMAGE2) += dpx > FATE_LAVF-$(call ENCDEC2, DVVIDEO,PCM_S16LE, AVI)+= > dv_fmt > FATE_LAVF-$(call ENCDEC2, MPEG1VIDEO, MP2, FFM)+= ffm > diff --git a/tests/lavf-regression.sh b/tests/lavf-regression.sh > index a37f714..58287ff 100755 > --- a/tests/lavf-regression.sh > +++ b/tests/lavf-regression.sh iam not sure if new fate tests should use lavf-regression.sh other then that the patch LGTM also tested on mips qemu, mingw32/64 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Observe your enemies, for they first find out your faults. -- Antisthenes signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] possible farewell; dev policy clarification
On 10/30/15, Ganesh Ajjanagadde wrote: > Hi all, > > Apologies for the length of the email, but there is a lot of stuff I > would like to cover due to my absence on IRC or other venues for "non > patch related" discussion. > > There has been a lot said and still being said regarding some patches > I sent and associated discussion. Issues not related to patches in a > technical sense are being discussed privately. > > In the meantime, I have noticed an increased level of hostility on > ffmpeg-devel lately, both from my end as well as from others. I do not > wish to escalate it further, and want to let work progress as smoothly > as possible. > > In fact, I repeat a statement I made earlier: if overall people think > that if I leave better and more work will be done for the project, I > will gladly do so. That is the only thing I wish for: FFmpeg becoming > better. To clarify a possible confusion on IRC: I by no means intend > to work on Libav - either I work for FFmpeg, or not work at all on > multimedia. This statement holds true regardless of what people > express about the work I do here, whether I am kicked out, etc. > > The reason I repeat this question of leaving is because I dug through > IRC archives, trying to understand better what people here think of > the work I do in light of the increasing hostility on the ML. I got > the sense that a lot of information that I could have received did not > reach me as I am, and will not be on IRC. I also got the sense that > there is a section of FFmpeg developers who are deeply against the > kinds of things I do and the way I handle them, hence prompting the > question. > > Assuming that you feel I give a net positive benefit to the project, > please read on. > > I am quite puzzled with some of the sentiments expressed there. I > illustrate below what puzzles me, and ask what I can do on my end: > > 1. "Sloppy" patches - I tend to give more verbose commit messages to > explain rationale than many here. I also outlined why I did not post > benchmarks initially. I myself still think they are unnecessary and > not useful for many of my proposed changes, but the community here > seemed to think otherwise. I have hence started posting benchmarks. > I generally try to give evidence for things that are more "universal" > in character when possible, so as not to skew towards any particular > machine architecture, etc. I do not agree that the log patches were > "sloppy" - bit accuracy improvements for log10 over log should have > been obvious. Simplification of the code, a subjective aspect, should > have been quite a reasonable assumption. Do people here not think such > things are obvious? > > 2. "Increasing warnings" - There were only 2 instances AFAIK where I > made a mistake, one in apedec. Another was in a test build. Both were > very quickly resolved. These issues were tiny compared to the general > level of warning cleanups achieved. Both were reasonable mistakes that > missed the eyes of reviewers. Please do let me know when I do increase > such things, I try to test things the best I can on my end. I will > strive to be more cautious in the future by incorporating the lessons > learnt with these two failures. > > 3. Patch sending mechanism - I have tried both approaches, namely an > en-masse single patch, versus individual tiny patches. Both were > frowned upon: the en-masse as "not fond of mass changes", and the > single patches as "incredibly noisy". Regarding pinging, I pinged a > single patch in a set of similar patches with a phrase regarding the > fact that the ping extends to other such similar patches. This ping > was ignored. I push (following the dev policy) one change after > sufficient delay, and it was frowned upon. I did not know what to do, > so I subsequently pinged each of the patches. This resulted in a bunch > of comments on IRC. For reference, these are the av_warn_unused_result > patches for avutil. Any suggestions for the future? > > 4. av_warn_unused_result not being useful en-masse for all headers - > This was something remarked upon in IRC. I did not get this > information in the form of reviews. Please suggest which headers to > target first: I am currently just going one by one in a natural order > (so that I can keep track of which ones have been addressed). Of > course, if people think av_warn_unused_result is inherently bad, that > is a separate issue that reflects an even deeper gulf. > > 5. General communication failures - Clearly, a lot of important stuff > from IRC is not reaching the ML. I (and some others here) do not use > IRC, and are pretty firm about not using it. What can be done to > address the communication gap? I would have at least understood the > deep hostility to the work I do if I had seen IRC logs a few weeks > back. The ML got only the "effects" and little of the "causes". > Overall, my sense is that people let the negative reaction bottle up, > venting every now and then on IRC, since for whatever reason
Re: [FFmpeg-devel] [PATCH] Update Cookies on Setcookie playlist response
Em sex, 30 de out de 2015 às 07:44, Michael Niedermayer escreveu: > On Tue, Oct 27, 2015 at 11:28:32AM +, Lucas Andrade wrote: > > Here is the patch to backport it to release/2.8. To be fixed on 2.8.2. > > Anything else I should do? > > > > ps. Sorry, that's my first time on opensource project, I'm a little > > confused that I needed to add it to the release branch. > > > hls.c | 31 +++ > > 1 file changed, 15 insertions(+), 16 deletions(-) > > 6b3c2cdc68e5fe0d9665a22a78837bca7d7b39b9 > b3f3eab029eb429660fc1651a33dafe097cbac0e.patch > > From b3f3eab029eb429660fc1651a33dafe097cbac0e Mon Sep 17 00:00:00 2001 > > From: Lucas de Andrade > > Date: Mon, 26 Oct 2015 10:47:08 -0200 > > Subject: [PATCH] Update Cookies response with Setcookie > > > > Context cookies must be updated when a playlist response return > Setcookie header. > > Backported to release/2.8 > > --- > > libavformat/hls.c | 31 +++ > > 1 file changed, 15 insertions(+), 16 deletions(-) > > this patch is against n2.8 not release/2.8 > > git checkout release/2.8 > git cherry-pick ... > error: patch failed: libavformat/hls.c:962 > error: libavformat/hls.c: patch does not apply > Patch failed at 0001 Update Cookies response with Setcookie > The copy of the patch that failed is found in: >ffmpeg/.git/rebase-apply/patch > When you have resolved this problem, run "git am --continue". > If you prefer to skip this patch, run "git am --skip" instead. > To restore the original branch and stop patching, run "git am --abort". > > [...] > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. > User > questions about the command line tools should be sent to the ffmpeg-user > ML. > And questions about how to use libav* should be sent to the libav-user ML. > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel Sorry, I needed to update release/2.8. It was a previous version. Here it is. update cookies on setcookie response.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH][RFC] avcodec: disallow hwaccel with frame threads
On Thu, Oct 29, 2015 at 8:31 PM, Andy Furniss wrote: > Hendrik Leppkes wrote: >> >> On Thu, Oct 22, 2015 at 11:27 AM, Wang Bin >> wrote: >>> >>> VLC is using frame threading with hwaccel >> >> >> Then they should fix their usage, its broken by design, as explained >> in detail my post earlier in this thread. > > > Seems ffmpeg cli does the same by default - OK so users can specify > -threads 1 if they use -hwaccel vdpau. > I thought about a patch to disable threads if hwaccel is requested on the command line, might try to do that in a bit. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] possible farewell; dev policy clarification
Hi all, Apologies for the length of the email, but there is a lot of stuff I would like to cover due to my absence on IRC or other venues for "non patch related" discussion. There has been a lot said and still being said regarding some patches I sent and associated discussion. Issues not related to patches in a technical sense are being discussed privately. In the meantime, I have noticed an increased level of hostility on ffmpeg-devel lately, both from my end as well as from others. I do not wish to escalate it further, and want to let work progress as smoothly as possible. In fact, I repeat a statement I made earlier: if overall people think that if I leave better and more work will be done for the project, I will gladly do so. That is the only thing I wish for: FFmpeg becoming better. To clarify a possible confusion on IRC: I by no means intend to work on Libav - either I work for FFmpeg, or not work at all on multimedia. This statement holds true regardless of what people express about the work I do here, whether I am kicked out, etc. The reason I repeat this question of leaving is because I dug through IRC archives, trying to understand better what people here think of the work I do in light of the increasing hostility on the ML. I got the sense that a lot of information that I could have received did not reach me as I am, and will not be on IRC. I also got the sense that there is a section of FFmpeg developers who are deeply against the kinds of things I do and the way I handle them, hence prompting the question. Assuming that you feel I give a net positive benefit to the project, please read on. I am quite puzzled with some of the sentiments expressed there. I illustrate below what puzzles me, and ask what I can do on my end: 1. "Sloppy" patches - I tend to give more verbose commit messages to explain rationale than many here. I also outlined why I did not post benchmarks initially. I myself still think they are unnecessary and not useful for many of my proposed changes, but the community here seemed to think otherwise. I have hence started posting benchmarks. I generally try to give evidence for things that are more "universal" in character when possible, so as not to skew towards any particular machine architecture, etc. I do not agree that the log patches were "sloppy" - bit accuracy improvements for log10 over log should have been obvious. Simplification of the code, a subjective aspect, should have been quite a reasonable assumption. Do people here not think such things are obvious? 2. "Increasing warnings" - There were only 2 instances AFAIK where I made a mistake, one in apedec. Another was in a test build. Both were very quickly resolved. These issues were tiny compared to the general level of warning cleanups achieved. Both were reasonable mistakes that missed the eyes of reviewers. Please do let me know when I do increase such things, I try to test things the best I can on my end. I will strive to be more cautious in the future by incorporating the lessons learnt with these two failures. 3. Patch sending mechanism - I have tried both approaches, namely an en-masse single patch, versus individual tiny patches. Both were frowned upon: the en-masse as "not fond of mass changes", and the single patches as "incredibly noisy". Regarding pinging, I pinged a single patch in a set of similar patches with a phrase regarding the fact that the ping extends to other such similar patches. This ping was ignored. I push (following the dev policy) one change after sufficient delay, and it was frowned upon. I did not know what to do, so I subsequently pinged each of the patches. This resulted in a bunch of comments on IRC. For reference, these are the av_warn_unused_result patches for avutil. Any suggestions for the future? 4. av_warn_unused_result not being useful en-masse for all headers - This was something remarked upon in IRC. I did not get this information in the form of reviews. Please suggest which headers to target first: I am currently just going one by one in a natural order (so that I can keep track of which ones have been addressed). Of course, if people think av_warn_unused_result is inherently bad, that is a separate issue that reflects an even deeper gulf. 5. General communication failures - Clearly, a lot of important stuff from IRC is not reaching the ML. I (and some others here) do not use IRC, and are pretty firm about not using it. What can be done to address the communication gap? I would have at least understood the deep hostility to the work I do if I had seen IRC logs a few weeks back. The ML got only the "effects" and little of the "causes". Overall, my sense is that people let the negative reaction bottle up, venting every now and then on IRC, since for whatever reason it is more comfortable, although technically both are publicly recorded and nearly as easily referenced in mails or commit messages. As a side note, even some patch review is done on IRC, a situation I d
[FFmpeg-devel] [PATCH 2/3] avformat/segafilm: set audio stream duration
Signed-off-by: Paul B Mahol --- libavformat/segafilm.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/libavformat/segafilm.c b/libavformat/segafilm.c index b4f9b3d..9c346e6 100644 --- a/libavformat/segafilm.c +++ b/libavformat/segafilm.c @@ -247,6 +247,9 @@ static int film_read_header(AVFormatContext *s) } } +if (film->audio_type) +s->streams[film->audio_stream_index]->duration = audio_frame_counter; + film->current_sample = 0; return 0; -- 1.9.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/3] avformat/segafilm: set video stream duration
Signed-off-by: Paul B Mahol --- libavformat/segafilm.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/libavformat/segafilm.c b/libavformat/segafilm.c index 9c346e6..6aef48e 100644 --- a/libavformat/segafilm.c +++ b/libavformat/segafilm.c @@ -93,6 +93,7 @@ static int film_read_header(AVFormatContext *s) int i, ret; unsigned int data_offset; unsigned int audio_frame_counter; +unsigned int video_frame_counter; film->sample_table = NULL; @@ -211,7 +212,7 @@ static int film_read_header(AVFormatContext *s) avpriv_set_pts_info(st, 64, 1, film->audio_samplerate); } -audio_frame_counter = 0; +audio_frame_counter = video_frame_counter = 0; for (i = 0; i < film->sample_count; i++) { /* load the next sample record and transfer it to an internal struct */ if (avio_read(pb, scratch, 16) != 16) { @@ -239,6 +240,7 @@ static int film_read_header(AVFormatContext *s) film->sample_table[i].stream = film->video_stream_index; film->sample_table[i].pts = AV_RB32(&scratch[8]) & 0x7FFF; film->sample_table[i].keyframe = (scratch[8] & 0x80) ? 0 : 1; +video_frame_counter++; av_add_index_entry(s->streams[film->video_stream_index], film->sample_table[i].sample_offset, film->sample_table[i].pts, @@ -250,6 +252,9 @@ static int film_read_header(AVFormatContext *s) if (film->audio_type) s->streams[film->audio_stream_index]->duration = audio_frame_counter; +if (film->video_type) +s->streams[film->video_stream_index]->duration = video_frame_counter; + film->current_sample = 0; return 0; -- 1.9.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/3] avformat/segafilm: implement seeking
Signed-off-by: Paul B Mahol --- libavformat/segafilm.c | 21 + 1 file changed, 21 insertions(+) diff --git a/libavformat/segafilm.c b/libavformat/segafilm.c index 44fa683..b4f9b3d 100644 --- a/libavformat/segafilm.c +++ b/libavformat/segafilm.c @@ -239,6 +239,11 @@ static int film_read_header(AVFormatContext *s) film->sample_table[i].stream = film->video_stream_index; film->sample_table[i].pts = AV_RB32(&scratch[8]) & 0x7FFF; film->sample_table[i].keyframe = (scratch[8] & 0x80) ? 0 : 1; +av_add_index_entry(s->streams[film->video_stream_index], + film->sample_table[i].sample_offset, + film->sample_table[i].pts, + film->sample_table[i].sample_size, 0, + film->sample_table[i].keyframe); } } @@ -279,6 +284,21 @@ static int film_read_packet(AVFormatContext *s, return ret; } +static int film_read_seek(AVFormatContext *s, int stream_index, int64_t timestamp, int flags) +{ +FilmDemuxContext *film = s->priv_data; +AVStream *st = s->streams[stream_index]; +int index = av_index_search_timestamp(st, timestamp, flags); +if (index < 0) +return -1; +if (avio_seek(s->pb, st->index_entries[index].pos, SEEK_SET) < 0) +return -1; + +film->current_sample = index; + +return 0; +} + AVInputFormat ff_segafilm_demuxer = { .name = "film_cpk", .long_name = NULL_IF_CONFIG_SMALL("Sega FILM / CPK"), @@ -287,4 +307,5 @@ AVInputFormat ff_segafilm_demuxer = { .read_header= film_read_header, .read_packet= film_read_packet, .read_close = film_read_close, +.read_seek = film_read_seek, }; -- 1.9.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avutil/file_open: avoid file handle inheritance on Windows
On Fri, Oct 30, 2015 at 11:30 AM, Tobias Rapp wrote: > On 29.10.2015 09:38, Tobias Rapp wrote: >> >> Attached patch fixes file lock issues in my Windows application when a >> child process is started with handle inheritance enabled (standard >> input/output redirection) while a FFmpeg transcoding is running in the >> parent process. >> >> BTW: It would be great if the patch could also be applied to the 2.7/2.8 >> release branches. > > > Forgot to add links relevant to the subject. > > [1] https://msdn.microsoft.com/en-us/library/w7sa2b22.aspx > > Describes the _wsopen() function and the O_NOINHERIT flag. File handles > opened by _wsopen() are inheritable by default. > > [2] > https://msdn.microsoft.com/en-us/library/windows/desktop/aa363858%28v=vs.85%29.aspx > > Describes the CreateFile() function. Not directly relevant here, often used > in cases outside of C/libc. Opens file without inheritance by default > (lpSecurityAttributes is NULL). > > [3] > https://msdn.microsoft.com/en-us/library/windows/desktop/ms682425%28v=vs.85%29.aspx > > Describes handle inheritance when creating new processes. Handle inheritance > must be enabled (bInheritHandles = TRUE) e.g. when you want to pass handles > for stdin/stdout via lpStartupInfo. > Its probably fine, the only concerns I can think of is what happens if you try use ffmpeg.exe as a subprocess operating on a pipe fed by the parent process, would this still work? - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv2] avutil/buffer: add av_warn_unused_result
On Thu, Oct 15, 2015 at 07:10:47PM -0400, Ganesh Ajjanagadde wrote: > Signed-off-by: Ganesh Ajjanagadde > --- > libavutil/buffer.h | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/libavutil/buffer.h b/libavutil/buffer.h > index b4399fd..e0dbc8a 100644 > --- a/libavutil/buffer.h > +++ b/libavutil/buffer.h > @@ -26,6 +26,7 @@ > #define AVUTIL_BUFFER_H > > #include > +#include "attributes.h" > > /** > * @defgroup lavu_buffer AVBuffer > @@ -178,6 +179,7 @@ int av_buffer_get_ref_count(const AVBufferRef *buf); > *written in its place. On failure, buf is left untouched. > * @return 0 on success, a negative AVERROR on failure. > */ > +av_warn_unused_result > int av_buffer_make_writable(AVBufferRef **buf); > > /** > @@ -195,6 +197,7 @@ int av_buffer_make_writable(AVBufferRef **buf); > * reference to it (i.e. the one passed to this function). In all other cases > * a new buffer is allocated and the data is copied. > */ > +av_warn_unused_result > int av_buffer_realloc(AVBufferRef **buf, int size); libavutil/buffer.c in one case checks av_buffer_realloc() for failure by checking the buf poiner after the call instead of the return code. This use seems valid [...] -- 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] ffmpeg_filter: check encoder before using it to set frame size.
Le sextidi 6 brumaire, an CCXXIV, Michael Niedermayer a écrit : > LGTM Thanks, pushed. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avutil/file_open: avoid file handle inheritance on Windows
On 29.10.2015 09:38, Tobias Rapp wrote: Attached patch fixes file lock issues in my Windows application when a child process is started with handle inheritance enabled (standard input/output redirection) while a FFmpeg transcoding is running in the parent process. BTW: It would be great if the patch could also be applied to the 2.7/2.8 release branches. Forgot to add links relevant to the subject. [1] https://msdn.microsoft.com/en-us/library/w7sa2b22.aspx Describes the _wsopen() function and the O_NOINHERIT flag. File handles opened by _wsopen() are inheritable by default. [2] https://msdn.microsoft.com/en-us/library/windows/desktop/aa363858%28v=vs.85%29.aspx Describes the CreateFile() function. Not directly relevant here, often used in cases outside of C/libc. Opens file without inheritance by default (lpSecurityAttributes is NULL). [3] https://msdn.microsoft.com/en-us/library/windows/desktop/ms682425%28v=vs.85%29.aspx Describes handle inheritance when creating new processes. Handle inheritance must be enabled (bInheritHandles = TRUE) e.g. when you want to pass handles for stdin/stdout via lpStartupInfo. Regards, Tobias ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] swresample/swresample: add av_warn_unused_result
On Thu, Oct 15, 2015 at 09:31:59PM -0400, Ganesh Ajjanagadde wrote: > This will trigger a few warnings (e.g in avfilter) that need to be > fixed. > > Signed-off-by: Ganesh Ajjanagadde > --- > libswresample/swresample.h | 9 + > 1 file changed, 9 insertions(+) > > diff --git a/libswresample/swresample.h b/libswresample/swresample.h > index 10eaebc..d21084f 100644 > --- a/libswresample/swresample.h > +++ b/libswresample/swresample.h > @@ -220,6 +220,7 @@ struct SwrContext *swr_alloc(void); > * @param[in,out] s Swr context to initialize > * @return AVERROR error code in case of failure. > */ > +av_warn_unused_result > int swr_init(struct SwrContext *s); > > /** > @@ -307,6 +308,7 @@ void swr_close(struct SwrContext *s); > * > * @return number of samples output per channel, negative value on error > */ > +av_warn_unused_result > int swr_convert(struct SwrContext *s, uint8_t **out, int out_count, > const uint8_t **in , int in_count); > i dont think the user needs to check the return code for simple sample format convertions for example > @@ -354,6 +356,7 @@ int64_t swr_next_pts(struct SwrContext *s, int64_t pts); > *@li compensation unsupported by resampler, or > *@li swr_init() fails when called. > */ > +av_warn_unused_result > int swr_set_compensation(struct SwrContext *s, int sample_delta, int > compensation_distance); > > /** > @@ -364,6 +367,7 @@ int swr_set_compensation(struct SwrContext *s, int > sample_delta, int compensatio > *indexes, -1 for a muted channel) > * @return >= 0 on success, or AVERROR error code in case of failure. > */ > +av_warn_unused_result > int swr_set_channel_mapping(struct SwrContext *s, const int *channel_map); > > /** > @@ -375,6 +379,7 @@ int swr_set_channel_mapping(struct SwrContext *s, const > int *channel_map); > * @param stride offset between lines of the matrix > * @return >= 0 on success, or AVERROR error code in case of failure. > */ > +av_warn_unused_result > int swr_set_matrix(struct SwrContext *s, const double *matrix, int stride); the only failure mode i see is EINVAL, so the user could know that failure wont happen its possible this applies to more functions [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Let us carefully observe those good qualities wherein our enemies excel us and endeavor to excel them, by avoiding what is faulty, and imitating what is excellent in them. -- Plutarch signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avutil/wchar_filename: add av_warn_unused_result
On Thu, Oct 15, 2015 at 08:01:56PM -0400, Ganesh Ajjanagadde wrote: > Current code is fine, this just adds robustness. > > Signed-off-by: Ganesh Ajjanagadde > --- > libavutil/wchar_filename.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/libavutil/wchar_filename.h b/libavutil/wchar_filename.h > index c553c46..2ade321 100644 > --- a/libavutil/wchar_filename.h > +++ b/libavutil/wchar_filename.h > @@ -23,6 +23,7 @@ > #include > #include "mem.h" > > +av_warn_unused_result > static inline int utf8towchar(const char *filename_utf8, wchar_t > **filename_w) > { > int num_chars; LGTM thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Asymptotically faster algorithms should always be preferred if you have asymptotical amounts of data signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avutil/parseutils: add av_warn_unused_result
On Thu, Oct 15, 2015 at 07:52:44PM -0400, Ganesh Ajjanagadde wrote: > This triggers a few warnings that will need to be fixed - not that bad, > the current code is mostly fine. > > Signed-off-by: Ganesh Ajjanagadde > --- > libavutil/parseutils.h | 5 + > 1 file changed, 5 insertions(+) iam unsure about this in practice the input to these functions is most of the time from the user and thus would need to be syntax checked but in principle the input could have been checked already, for example though a previous call to the same function in which case no check is needed anymore [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The worst form of inequality is to try to make unequal things equal. -- 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] avutil/frame: add av_warn_unused_result
On Thu, Oct 15, 2015 at 07:47:47PM -0400, Ganesh Ajjanagadde wrote: > This is going to trigger a lot of warnings all over the place that need > fixing. Main culprits are in avfilter, when one tries to copy a frame > without checking whether src and dest formats actually are compatible. if a filter allocated both source and destination itself with the same parameters then i think it does not need to check if copy fails [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The worst form of inequality is to try to make unequal things equal. -- Aristotle signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/3] tools/crypto_bench: add support for multiple lavu versions by cpuflag
--- tools/crypto_bench.c | 49 + 1 file changed, 41 insertions(+), 8 deletions(-) diff --git a/tools/crypto_bench.c b/tools/crypto_bench.c index 80d5f66..ce61af1 100644 --- a/tools/crypto_bench.c +++ b/tools/crypto_bench.c @@ -32,6 +32,7 @@ #include "libavutil/crc.h" #include "libavutil/intreadwrite.h" #include "libavutil/timer.h" +#include "libavutil/cpu.h" #ifndef AV_READ_TIME #define AV_READ_TIME(x) 0 @@ -65,6 +66,7 @@ struct hash_impl { const char *name; void (*run)(uint8_t *output, const uint8_t *input, unsigned size); const char *output; +int cpu_versions; }; /*** @@ -343,6 +345,16 @@ static unsigned crc32(const uint8_t *data, unsigned size) return av_crc(av_crc_get_table(AV_CRC_32_IEEE), 0, data, size); } +static const struct { +int flag; +const char *name; +} cpu_flag_tab[] = { +#if ARCH_X86 +{ AV_CPU_FLAG_AESNI, "aesni" }, +#endif +{ 0 } +}; + static void run_implementation(const uint8_t *input, uint8_t *output, struct hash_impl *impl, unsigned size) { @@ -353,6 +365,27 @@ static void run_implementation(const uint8_t *input, uint8_t *output, double mtime, ttime = 0, ttime2 = 0, stime; uint8_t outref[MAX_OUTPUT_SIZE]; +if (!strcmp(impl->lib, "lavu")) { +char lib_name[32]; +struct hash_impl impl2 = *impl; +int real_flags = av_get_cpu_flags(); +int current_flags = real_flags; +impl2.cpu_versions = 0; +impl2.lib = lib_name; +for (i = 0; cpu_flag_tab[i].flag; i++) { +if (cpu_flag_tab[i].flag & impl->cpu_versions & real_flags) { +snprintf(lib_name, sizeof(lib_name), "lavu_%s", cpu_flag_tab[i].name); +run_implementation(input, output, &impl2, size); +current_flags &= ~cpu_flag_tab[i].flag; +av_force_cpu_flags(current_flags); +} +} +impl2.lib = "lavu_c"; +run_implementation(input, output, &impl2, size); +av_force_cpu_flags(real_flags); +return; +} + if (enabled_libs && !av_stristr(enabled_libs, impl->lib) || enabled_algos && !av_stristr(enabled_algos, impl->name)) return; @@ -394,8 +427,8 @@ static void run_implementation(const uint8_t *input, uint8_t *output, fflush(stdout); } -#define IMPL_USE(lib, name, symbol, output) \ -{ #lib, name, run_ ## lib ## _ ## symbol, output }, +#define IMPL_USE(lib, name, symbol, output, ...) \ +{ #lib, name, run_ ## lib ## _ ## symbol, output, __VA_ARGS__ }, #define IMPL(lib, ...) IMPL_USE_ ## lib(lib, __VA_ARGS__) #define IMPL_ALL(...) \ IMPL(lavu, __VA_ARGS__) \ @@ -412,12 +445,12 @@ struct hash_impl implementations[] = { IMPL(lavu, "RIPEMD-128", ripemd128, "9ab8bfba2ddccc5d99c9d4cdfb844a5f") IMPL(tomcrypt, "RIPEMD-128", ripemd128, "9ab8bfba2ddccc5d99c9d4cdfb844a5f") IMPL_ALL("RIPEMD-160", ripemd160, "62a5321e4fc8784903bb43ab7752c75f8b25af00") -IMPL_ALL("AES-128-ECB",aes128,"crc:ff6bc888") -IMPL_ALL("AES-192-ECB",aes192,"crc:1022815b") -IMPL_ALL("AES-256-ECB",aes256,"crc:792e4e8a") -IMPL_ALL("AES-128-CBC",aes128cbc, "crc:0efebabe") -IMPL_ALL("AES-192-CBC",aes192cbc, "crc:ee2e34e8") -IMPL_ALL("AES-256-CBC",aes256cbc, "crc:0c9b875c") +IMPL_ALL("AES-128-ECB",aes128,"crc:ff6bc888", AV_CPU_FLAG_AESNI) +IMPL_ALL("AES-192-ECB",aes192,"crc:1022815b", AV_CPU_FLAG_AESNI) +IMPL_ALL("AES-256-ECB",aes256,"crc:792e4e8a", AV_CPU_FLAG_AESNI) +IMPL_ALL("AES-128-CBC",aes128cbc, "crc:0efebabe", AV_CPU_FLAG_AESNI) +IMPL_ALL("AES-192-CBC",aes192cbc, "crc:ee2e34e8", AV_CPU_FLAG_AESNI) +IMPL_ALL("AES-256-CBC",aes256cbc, "crc:0c9b875c", AV_CPU_FLAG_AESNI) IMPL_ALL("CAMELLIA", camellia, "crc:7abb59a7") IMPL_ALL("CAST-128", cast128, "crc:456aa584") IMPL_ALL("BLOWFISH", blowfish, "crc:33e8aa74") -- 2.6.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/3] tools/crypto_bench: macro-ize additional algorithms
This also moves additional libcrypto ciphers to the new (faster) EVP API --- tools/crypto_bench.c | 544 +++ 1 file changed, 110 insertions(+), 434 deletions(-) diff --git a/tools/crypto_bench.c b/tools/crypto_bench.c index 8a468ba..80d5f66 100644 --- a/tools/crypto_bench.c +++ b/tools/crypto_bench.c @@ -109,86 +109,32 @@ DEFINE_LAVU_MD(sha512,AVSHA512, sha512, 512); DEFINE_LAVU_MD(ripemd128, AVRIPEMD, ripemd, 128); DEFINE_LAVU_MD(ripemd160, AVRIPEMD, ripemd, 160); -static void run_lavu_aes128(uint8_t *output, -const uint8_t *input, unsigned size) -{ -static struct AVAES *aes; -if (!aes && !(aes = av_aes_alloc())) -fatal_error("out of memory"); -av_aes_init(aes, hardcoded_key, 128, 0); -av_aes_crypt(aes, output, input, size >> 4, NULL, 0); -} - -static void run_lavu_aes192(uint8_t *output, const uint8_t *input, unsigned size) -{ -static struct AVAES *aes; -if (!aes && !(aes = av_aes_alloc())) -fatal_error("out of memory"); -av_aes_init(aes, hardcoded_key, 192, 0); -av_aes_crypt(aes, output, input, size >> 4, NULL, 0); -} - -static void run_lavu_aes256(uint8_t *output, const uint8_t *input, unsigned size) -{ -static struct AVAES *aes; -if (!aes && !(aes = av_aes_alloc())) -fatal_error("out of memory"); -av_aes_init(aes, hardcoded_key, 256, 0); -av_aes_crypt(aes, output, input, size >> 4, NULL, 0); -} - -static void run_lavu_aes128cbc(uint8_t *output, const uint8_t *input, unsigned size) -{ -static struct AVAES *aes; -static uint8_t *iv; -if ((!aes && !(aes = av_aes_alloc())) || (!iv && !(iv = av_malloc(16 -fatal_error("out of memory"); -memcpy(iv, hardcoded_iv, 16); -av_aes_init(aes, hardcoded_key, 128, 0); -av_aes_crypt(aes, output, input, size >> 4, iv, 0); -} - -static void run_lavu_aes192cbc(uint8_t *output, const uint8_t *input, unsigned size) -{ -static struct AVAES *aes; -static uint8_t *iv; -if ((!aes && !(aes = av_aes_alloc())) || (!iv && !(iv = av_malloc(16 -fatal_error("out of memory"); -memcpy(iv, hardcoded_iv, 16); -av_aes_init(aes, hardcoded_key, 192, 0); -av_aes_crypt(aes, output, input, size >> 4, iv, 0); -} - -static void run_lavu_aes256cbc(uint8_t *output, const uint8_t *input, unsigned size) -{ -static struct AVAES *aes; -static uint8_t *iv; -if ((!aes && !(aes = av_aes_alloc())) || (!iv && !(iv = av_malloc(16 -fatal_error("out of memory"); -memcpy(iv, hardcoded_iv, 16); -av_aes_init(aes, hardcoded_key, 256, 0); -av_aes_crypt(aes, output, input, size >> 4, iv, 0); -} - -static void run_lavu_blowfish(uint8_t *output, - const uint8_t *input, unsigned size) -{ -static struct AVBlowfish *blowfish; -if (!blowfish && !(blowfish = av_blowfish_alloc())) -fatal_error("out of memory"); -av_blowfish_init(blowfish, hardcoded_key, 16); -av_blowfish_crypt(blowfish, output, input, size >> 3, NULL, 0); -} - -static void run_lavu_camellia(uint8_t *output, - const uint8_t *input, unsigned size) -{ -static struct AVCAMELLIA *camellia; -if (!camellia && !(camellia = av_camellia_alloc())) -fatal_error("out of memory"); -av_camellia_init(camellia, hardcoded_key, 128); -av_camellia_crypt(camellia, output, input, size >> 4, NULL, 0); -} +#define DEFINE_LAVU_CRYPT(suffix, type, namespace, ivsize, sshift, ...) \ +static void run_lavu_ ## suffix(uint8_t *output, \ +const uint8_t *input, unsigned size) \ +{\ +static struct type *h; \ +static uint8_t *iv = NULL; \ +if (!h && !(h = av_ ## namespace ## _alloc())) \ +fatal_error("out of memory");\ +if (ivsize && !iv && !(iv = av_malloc(ivsize))) \ +fatal_error("out of memory");\ +if (ivsize) \ +memcpy(iv, hardcoded_iv, ivsize);\ +av_ ## namespace ## _init(h, hardcoded_key, __VA_ARGS__);\ +av_ ## namespace ## _crypt(h, output, input, size >> sshift, iv, 0); \ +} + +DEFINE_LAVU_CRYPT(aes128,AVAES, aes, 0, 4, 128, 0); +DEFINE_LAVU_CRYPT(aes192,AVAES, aes, 0, 4, 192, 0); +DEFINE_LAVU_CRYPT(aes256,AVAES, aes, 0, 4, 256, 0); +DEFINE_LAVU_CRYPT(aes128cbc, AVAES, aes, 16, 4, 128, 0); +DEFINE_LAVU_CRYPT(aes192cbc, AVAES, aes, 16, 4, 192, 0); +DEFINE_LAVU_CRYPT(aes256cbc, AVAES, aes, 16, 4, 256, 0); +D
[FFmpeg-devel] [PATCH 1/3] tools/crypto_bench: switch to OpenSSL's faster AES API
Before: crypto AES-128-CBC size: 1048576 runs: 1024 time: 16.224 +- 2.347 After: crypto AES-128-CBC size: 1048576 runs: 1024 time: 3.056 +- 0.366 --- tools/crypto_bench.c | 85 +--- 1 file changed, 47 insertions(+), 38 deletions(-) diff --git a/tools/crypto_bench.c b/tools/crypto_bench.c index 15bb5f1..8a468ba 100644 --- a/tools/crypto_bench.c +++ b/tools/crypto_bench.c @@ -244,6 +244,7 @@ static void run_lavu_xtea(uint8_t *output, #include #include #include +#include #define DEFINE_CRYPTO_WRAPPER(suffix, function) \ static void run_crypto_ ## suffix(uint8_t *output, \ @@ -258,74 +259,82 @@ DEFINE_CRYPTO_WRAPPER(sha256,SHA256) DEFINE_CRYPTO_WRAPPER(sha512,SHA512) DEFINE_CRYPTO_WRAPPER(ripemd160, RIPEMD160) -static void run_crypto_aes128(uint8_t *output, - const uint8_t *input, unsigned size) +static void run_crypto_aes128(uint8_t *output, const uint8_t *input, unsigned size) { -AES_KEY aes; -unsigned i; +static EVP_CIPHER_CTX *ctx = NULL; +int len = 0; -AES_set_encrypt_key(hardcoded_key, 128, &aes); -size -= 15; -for (i = 0; i < size; i += 16) -AES_encrypt(input + i, output + i, &aes); +if (!ctx && !(ctx = EVP_CIPHER_CTX_new())) +fatal_error("out of memory"); + +EVP_EncryptInit(ctx, EVP_aes_128_ecb(), hardcoded_key, hardcoded_iv); +EVP_EncryptUpdate(ctx, output, &len, input, size); +EVP_CIPHER_CTX_cleanup(ctx); } static void run_crypto_aes192(uint8_t *output, const uint8_t *input, unsigned size) { -AES_KEY aes; -unsigned i; +static EVP_CIPHER_CTX *ctx = NULL; +int len = 0; -AES_set_encrypt_key(hardcoded_key, 192, &aes); -size -= 15; -for (i = 0; i < size; i += 16) -AES_encrypt(input + i, output + i, &aes); +if (!ctx && !(ctx = EVP_CIPHER_CTX_new())) +fatal_error("out of memory"); + +EVP_EncryptInit(ctx, EVP_aes_192_ecb(), hardcoded_key, hardcoded_iv); +EVP_EncryptUpdate(ctx, output, &len, input, size); +EVP_CIPHER_CTX_cleanup(ctx); } static void run_crypto_aes256(uint8_t *output, const uint8_t *input, unsigned size) { -AES_KEY aes; -unsigned i; +static EVP_CIPHER_CTX *ctx = NULL; +int len = 0; -AES_set_encrypt_key(hardcoded_key, 256, &aes); -size -= 15; -for (i = 0; i < size; i += 16) -AES_encrypt(input + i, output + i, &aes); +if (!ctx && !(ctx = EVP_CIPHER_CTX_new())) +fatal_error("out of memory"); + +EVP_EncryptInit(ctx, EVP_aes_256_ecb(), hardcoded_key, hardcoded_iv); +EVP_EncryptUpdate(ctx, output, &len, input, size); +EVP_CIPHER_CTX_cleanup(ctx); } static void run_crypto_aes128cbc(uint8_t *output, const uint8_t *input, unsigned size) { -AES_KEY aes; -static uint8_t *iv; -if ((!iv && !(iv = av_malloc(16 +static EVP_CIPHER_CTX *ctx = NULL; +int len = 0; + +if (!ctx && !(ctx = EVP_CIPHER_CTX_new())) fatal_error("out of memory"); -memcpy(iv, hardcoded_iv, 16); -AES_set_encrypt_key(hardcoded_key, 128, &aes); -AES_cbc_encrypt(input, output, size, &aes, iv, 1); +EVP_EncryptInit(ctx, EVP_aes_128_cbc(), hardcoded_key, hardcoded_iv); +EVP_EncryptUpdate(ctx, output, &len, input, size); +EVP_CIPHER_CTX_cleanup(ctx); } static void run_crypto_aes192cbc(uint8_t *output, const uint8_t *input, unsigned size) { -AES_KEY aes; -static uint8_t *iv; -if ((!iv && !(iv = av_malloc(16 +static EVP_CIPHER_CTX *ctx = NULL; +int len = 0; + +if (!ctx && !(ctx = EVP_CIPHER_CTX_new())) fatal_error("out of memory"); -memcpy(iv, hardcoded_iv, 16); -AES_set_encrypt_key(hardcoded_key, 192, &aes); -AES_cbc_encrypt(input, output, size, &aes, iv, 1); +EVP_EncryptInit(ctx, EVP_aes_192_cbc(), hardcoded_key, hardcoded_iv); +EVP_EncryptUpdate(ctx, output, &len, input, size); +EVP_CIPHER_CTX_cleanup(ctx); } static void run_crypto_aes256cbc(uint8_t *output, const uint8_t *input, unsigned size) { -AES_KEY aes; -static uint8_t *iv; -if ((!iv && !(iv = av_malloc(16 +static EVP_CIPHER_CTX *ctx = NULL; +int len = 0; + +if (!ctx && !(ctx = EVP_CIPHER_CTX_new())) fatal_error("out of memory"); -memcpy(iv, hardcoded_iv, 16); -AES_set_encrypt_key(hardcoded_key, 256, &aes); -AES_cbc_encrypt(input, output, size, &aes, iv, 1); +EVP_EncryptInit(ctx, EVP_aes_256_cbc(), hardcoded_key, hardcoded_iv); +EVP_EncryptUpdate(ctx, output, &len, input, size); +EVP_CIPHER_CTX_cleanup(ctx); } static void run_crypto_blowfish(uint8_t *output, -- 2.6.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/5] concatdec: add metadata for file start time and duration
Le quartidi 4 brumaire, an CCXXIV, Marton Balint a écrit : > I'd rather keep this as it is, the user has to control the metadata he wants > in his output, we never promised there won't be additional packet string > metadata in a certain format, and the way I see it only NUT muxer actually > parses AV_PKT_DATA_STRINGS_METADATA, and none of the encoders parse AVFrame > metadata, so it does not really affect anybody. At some point, some encoders or muxers will take it into account. > If you still think this is problematic, I can do one or both of these > options: > - Add a demuxer option which controls if the demuxer produces this > metadata or not. > - Add an ffconcat file global option which controls this. A demuxer option seems the most natural to me. 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] concatdec: move duration calculating code to open_file
Le quartidi 4 brumaire, an CCXXIV, Marton Balint a écrit : > Hmm. I need this computed here for the next patch. Maybe we could calcualate > the duration here and then update it in open_next_file as well? That is probably possible somehow but a bit tricky. Can you explain why you need the duration at this point? 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 2/5] fate: add concat demuxer tests
Le quartidi 4 brumaire, an CCXXIV, Marton Balint a écrit : > I used this many (25 1-frame segment) because this is also a seek test for > open gop mxf. I can reduce it but in that case I will have to maintain my > own out of tree tests for it which is counter-productive IMHO. It seems that the your script is ready to use several templates: maybe do just that: a short one with full output in the ref file to make testing and debugging easy, and a long one to cover your full MXF test. But only if it is not too much work. 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] Update Cookies on Setcookie playlist response
On Tue, Oct 27, 2015 at 11:28:32AM +, Lucas Andrade wrote: > Here is the patch to backport it to release/2.8. To be fixed on 2.8.2. > Anything else I should do? > > ps. Sorry, that's my first time on opensource project, I'm a little > confused that I needed to add it to the release branch. > hls.c | 31 +++ > 1 file changed, 15 insertions(+), 16 deletions(-) > 6b3c2cdc68e5fe0d9665a22a78837bca7d7b39b9 > b3f3eab029eb429660fc1651a33dafe097cbac0e.patch > From b3f3eab029eb429660fc1651a33dafe097cbac0e Mon Sep 17 00:00:00 2001 > From: Lucas de Andrade > Date: Mon, 26 Oct 2015 10:47:08 -0200 > Subject: [PATCH] Update Cookies response with Setcookie > > Context cookies must be updated when a playlist response return Setcookie > header. > Backported to release/2.8 > --- > libavformat/hls.c | 31 +++ > 1 file changed, 15 insertions(+), 16 deletions(-) this patch is against n2.8 not release/2.8 git checkout release/2.8 git cherry-pick ... error: patch failed: libavformat/hls.c:962 error: libavformat/hls.c: patch does not apply Patch failed at 0001 Update Cookies response with Setcookie The copy of the patch that failed is found in: ffmpeg/.git/rebase-apply/patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User questions about the command line tools should be sent to the ffmpeg-user ML. And questions about how to use libav* should be sent to the libav-user ML. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Idea for a better filter that reduces noise
On Fri, Oct 30, 2015 at 2:14 AM, P. van Gaans wrote: > On 10/29/2015 09:42 AM, Paul B Mahol wrote: > >> On 10/29/15, P. van Gaans wrote: >> >>> You all know the CSI episodes where they read a license plate by >>> "enhancing" some super-grainy security footage. Nonsense, right? Well, >>> maybe not.. If the car was parked. And it seems what I found doesn't >>> exist yet. (but perhaps I overlooked it) >>> >>> If you quickly want to know what I'm on about, take a look at these >>> images: >>> >>> http://members.ziggo.nl/sinaasappel/images/1_original.jpg (original) >>> http://members.ziggo.nl/sinaasappel/images/2_40framewind.jpg (40f WIND) >>> http://members.ziggo.nl/sinaasappel/images/3_wind_hqdn3d.jpg (comparison >>> with hqdn3d and pp=tn) >>> >>> All have limited jpeg compression, but I can deliver PNG files and an >>> XCF to experiment for yourself if desired. >>> >>> So what is WIND? It's what you see if you forget/fail to do motion >>> detection. (like I did in the images) Also, Wind Is Not a Denoiser. ;-) >>> It's a way to increase the exposure time of the camera used to shoot a >>> movie after it's been shot. For the images, I took a 2-second somewhat >>> grainy clip of a building with nearly no motion. I output the frames to >>> PNG and load them as layers in The GIMP. I set the opacity for the >>> bottom layer to 100. The layer above that 50. (100/2) Above that 33.3. >>> (100/3) 25, 20, 16.7 and so on. Every image with noise is "wrong", some >>> too dark and some too light. On average, they are spot-on. The >>> advantage: improved quality and better compression. >>> >>> To make this into a proper useable filter, it would need to do this: >>> >>> 1. Deshake/stabilize the image. >>> 2. Divide image in blocks. (e.g. 8x8 pixels) >>> 3. Figure out it the average color of an 8x8 block is changing during >>> the next X frames. If not, it's probably not moving and you can average >>> the values. If it is or is about to, it should be averaged over fewer >>> frames or not at all. Any area that is about to move will gradually pick >>> up noise so it doesn't look too unnatural. >>> 4. Reshake the image. >>> >>> Will I do this myself? Maybe, but don't hold your breath. I'm just >>> sharing this in case somebody finds it interesting and to make sure >>> nobody can patent it. (assuming it hasn't been done already) >>> >> >> See atadenoise. >> >> >>> Best regards, >>> >>> P. van Gaans >>> ___ >>> 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 >> >> > Thanks Paul! I think I scrolled past atadenoise in the docs a while ago > but had otherwise never heard of it. While searching for it there is little > to find besides the docs and source code. (i.e. no forum threads or > mentions in guides or anything) My ffmpeg doesn't even have it so I guess > it's quite a new thing. I'll first compile a fresh one and get testing. I > hope atadenoise also performs the deshaking internally as I described since > I noticed the camera is usually not fixed, without deshaking it won't be > able to match much. > > I still think WIND would have been a funnier name than atadenoise, but I > don't complain. This will be great if it works as well as my pictures. :-) > > afaik it does not deshake but try it anyway. You can read the paper it's based on, if you're interested in more details. It's mentioned in the source code. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] ffmpeg.c can not process invalid PTS
diff --git a/ffmpeg.c b/ffmpeg.c index f91fb7b..844a03c 100644 --- a/ffmpeg.c +++ b/ffmpeg.c @@ -3864,6 +3864,11 @@ static int process_input(int file_index) if (pkt.dts != AV_NOPTS_VALUE) pkt.dts *= ist->ts_scale; +if (pkt.pts == AV_NOPTS_VALUE) +pkt.pts = av_rescale_q(ist->next_pts, AV_TIME_BASE_Q, ist->st->time_base); +if (pkt.dts == AV_NOPTS_VALUE) +pkt.dts = av_rescale_q(ist->next_dts, AV_TIME_BASE_Q, ist->st->time_base); + if ((ist->dec_ctx->codec_type == AVMEDIA_TYPE_VIDEO || ist->dec_ctx->codec_type == AVMEDIA_TYPE_AUDIO) && pkt.dts != AV_NOPTS_VALUE && ist->next_dts == AV_NOPTS_VALUE && !copy_ts == New patch At 2015-10-30 10:08:43, "hiccupzhu" wrote: >diff --git a/ffmpeg.c b/ffmpeg.c >index f91fb7b..22766b3 100644 >--- a/ffmpeg.c >+++ b/ffmpeg.c >@@ -3864,6 +3864,9 @@ static int process_input(int file_index) > if (pkt.dts != AV_NOPTS_VALUE) > pkt.dts *= ist->ts_scale; > >+if(pkt.pts == AV_NOPTS_VALUE) >+pkt.pts = ist->next_pts; >+ > if ((ist->dec_ctx->codec_type == AVMEDIA_TYPE_VIDEO || > ist->dec_ctx->codec_type == AVMEDIA_TYPE_AUDIO) && > pkt.dts != AV_NOPTS_VALUE && ist->next_dts == AV_NOPTS_VALUE && > !copy_ts > > >Explanation: >In function "process_input" ffmpeg just handle "pts != AV_NOPTS_VALUE", but >not handle "pts == AV_NOPTS_VALUE".Now I fixed it. >if ( current_pts == AV_NOPTS_VALUE) { >current_pts = predicted_pts; >} > > >Reproduce: >1. Download test file http://pan.baidu.com/s/1eQsb9hK; >2. Run command below: >ffmpeg -i ./manga.01.ts -vcodec copy -bsf:v h264_mp4toannexb -hls_list_size 0 >-hls_segment_filename "test_%04d.ts" playlist.m3u8 >3. If the bug not fixed, the HLS slice just one; Then fix the bug, HLS' slice >is normally. > > > > > > > >___ >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