Re: [FFmpeg-devel] [PATCH] avfilter/vf_deshake: replace qsort with AV_QSORT
Le nonidi 9 brumaire, an CCXXIV, Ganesh Ajjanagadde a écrit : > 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: > 39676 decicycles in qsort,1024 runs, 0 skips > > old: > 86783 decicycles in qsort,1024 runs, 0 skips What was inside the start/stop_timer block? I see that the qsort call is after a very expensive loop, I suspect those few thousand cycles may be completely negligible in front of the loop itself. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/vf_deshake: replace qsort with AV_QSORT
On Sat, Oct 31, 2015 at 11:19:04AM +0100, Nicolas George wrote: > Le nonidi 9 brumaire, an CCXXIV, Ganesh Ajjanagadde a écrit : > > 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: > > 39676 decicycles in qsort,1024 runs, 0 skips > > > > old: > > 86783 decicycles in qsort,1024 runs, 0 skips > > What was inside the start/stop_timer block? I see that the qsort call is > after a very expensive loop, I suspect those few thousand cycles may be > completely negligible in front of the loop itself. that loop before IIRC is a exhaustive search motion estimator there are much faster ways to estimate motion like what is implemented in libavcodec/motion_est* or what x264 does then again all the encoder motion estimation is tuned toward finding good matches _for_encoding_blocks_ while for deshake and other filters the goal is to find the actual real world motion. These 2 problems are similar but not identical so the best algorithms may differ [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Complexity theory is the science of finding the exact solution to an approximation. Benchmarking OTOH is finding an approximation of the exact 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/vf_deshake: replace qsort with AV_QSORT
On Sat, Oct 31, 2015 at 6:19 AM, Nicolas George wrote: > Le nonidi 9 brumaire, an CCXXIV, Ganesh Ajjanagadde a écrit : >> 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: >> 39676 decicycles in qsort,1024 runs, 0 skips >> >> old: >> 86783 decicycles in qsort,1024 runs, 0 skips > > What was inside the start/stop_timer block? I see that the qsort call is > after a very expensive loop, I suspect those few thousand cycles may be > completely negligible in front of the loop itself. Entirely possible. I just did this as a low hanging fruit. I highly suspect that the algorithm can be improved (see Michael's comment). The start/stop was just around the qsort statement. Since you asked this, I will add it to the commit message. > > Regards, > > -- > Nicolas George > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] possible farewell; dev policy clarification
On Sat, Oct 31, 2015 at 1:01 AM, Rostislav Pehlivanov wrote: > 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. Could be, but please then answer my question regarding my puzzlement over how to send patches: both en-masse and single things have been frowned upon. I am sending a patch set today with a different approach that I hope people like better. > >>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? Not all the stuff I deal with are such obscure codecs. But yes, generally I am quite picky about these things. I suspect it comes from the fact that I am more theoretical at heart in the work I do. I hence strive towards perfection regardless of the possible impact of a particular file. As Nicolas pointed out, focusing on technical purity and ignoring some of the negative social aspects of e.g one-liners is part of what led to the present juncture. That, together with a lack of tact on my end regarding rate-limiting/smoothing of bursty patch traffic. > What other things? Also be careful, the definition of a "foundation to work > on" could vary > between people. Hence a reason for reviews. The foundation of course may differ, and I want something that works with all. There is some misunderstanding on e.g IRC that "I don't like reviews". I very much do appreciate reviews. Perhaps I am more vociferous about the code I write, but that is because when I write such things, I am honestly convinced of their technical merit. I of course do revise if a suitable point is raised, and have dropped/amended patches many times in the past. Anyway, I have thought about this stuff, and am exploring some more careful ways of sending stuff to the ML that may be liked more. Feedback is welcome when I send such things. > >>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. I completely agree with this. I have hence dropped "hacky" warning fixes, and have toned down on that front, e.g I have dropped the en-masse av_warn_unused_result stuff. However, I believe (and still do believe) some do have benefit. In fact, warnings from obscure compilers are sometimes useful because they might have engineered a particular warning that others have not. For instance, MSVC has pretty terrible warnings, but I found the weird abort() call leading to a Michael's solution because of it. Wparentheses is mostly complete noise, but I found an almost surely incorrect usage that is now being asked for a review by the maintainer. I will amend the style with which I send patches regarding warnings, though. By the way, I also focus on the latest toolchains for essentially your reasons, something I have commented upon in the past before. > >>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). I don't understand this: standards are the base of portability. Sane or insane, it does not matter - many of the things need to be respected. Multimedia is in my view one of the places for seeing the worst of software, in Jean-Baptiste Kempf's words "Everything is broken". Some can be ignored though, and (for instance) I have not sent patches for the 4096 character string literal stuff as I know it is utterly pointless. Comments from especially Michael, Nicolas, and wm4 have given me a better sense for what things can matter and what things are mostly non-issues. > 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 com
Re: [FFmpeg-devel] [PATCH] avfilter/vf_deshake: replace qsort with AV_QSORT
On Sat, Oct 31, 2015 at 08:47:37AM -0400, Ganesh Ajjanagadde wrote: > On Sat, Oct 31, 2015 at 6:19 AM, Nicolas George wrote: > > Le nonidi 9 brumaire, an CCXXIV, Ganesh Ajjanagadde a écrit : > >> 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: > >> 39676 decicycles in qsort,1024 runs, 0 skips > >> > >> old: > >> 86783 decicycles in qsort,1024 runs, 0 skips > > > > What was inside the start/stop_timer block? I see that the qsort call is > > after a very expensive loop, I suspect those few thousand cycles may be > > completely negligible in front of the loop itself. > > Entirely possible. I just did this as a low hanging fruit. I highly > suspect that the algorithm can be improved (see Michael's comment). deshake is a filter that overall needs large rework. Aside from the fact that it doesn't work well (it's an unmaintained half assed simplified version of what vid.stab does), it is also IIRC easily crashable. Ticket #1430 may be of interest. [...] -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/vf_deshake: replace qsort with AV_QSORT
On Sat, Oct 31, 2015 at 9:59 AM, Clément Bœsch wrote: > On Sat, Oct 31, 2015 at 08:47:37AM -0400, Ganesh Ajjanagadde wrote: >> On Sat, Oct 31, 2015 at 6:19 AM, Nicolas George wrote: >> > Le nonidi 9 brumaire, an CCXXIV, Ganesh Ajjanagadde a écrit : >> >> 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: >> >> 39676 decicycles in qsort,1024 runs, 0 skips >> >> >> >> old: >> >> 86783 decicycles in qsort,1024 runs, 0 skips >> > >> > What was inside the start/stop_timer block? I see that the qsort call is >> > after a very expensive loop, I suspect those few thousand cycles may be >> > completely negligible in front of the loop itself. >> >> Entirely possible. I just did this as a low hanging fruit. I highly >> suspect that the algorithm can be improved (see Michael's comment). > > deshake is a filter that overall needs large rework. Aside from the fact > that it doesn't work well (it's an unmaintained half assed simplified > version of what vid.stab does), it is also IIRC easily crashable. > > Ticket #1430 may be of interest. Just now pushed, and have a remark about it in the commit message brought up by Nicolas's comment before reading your email :). > > [...] > > -- > Clément B. > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avutil/opencl_internal: add av_warn_unused_result
On Thu, Oct 29, 2015 at 4:26 PM, Michael Niedermayer
wrote:
> On Wed, Oct 28, 2015 at 10:53:59PM -0400, Ganesh Ajjanagadde wrote:
>> On Thu, Oct 15, 2015 at 6:24 PM, Ganesh Ajjanagadde
>> wrote:
>> > Signed-off-by: Ganesh Ajjanagadde
>> > ---
>> > libavutil/opencl_internal.h | 1 +
>> > 1 file changed, 1 insertion(+)
>> >
>> > diff --git a/libavutil/opencl_internal.h b/libavutil/opencl_internal.h
>> > index dacd930..a4f5885 100644
>> > --- a/libavutil/opencl_internal.h
>> > +++ b/libavutil/opencl_internal.h
>> > @@ -30,4 +30,5 @@ typedef struct {
>> > void *ctx;
>> > } FFOpenclParam;
>> >
>> > +av_warn_unused_result
>> > int avpriv_opencl_set_parameter(FFOpenclParam *opencl_param, ...);
>> > --
>> > 2.6.1
>> >
>>
>> ping
>
> probably ok
Don't think it is ok as is, the header attributes.h needs to be included :).
Added a reference to
https://www.khronos.org/registry/cl/sdk/1.1/docs/man/xhtml/clSetKernelArg.html
since that explains that out of memory errors are possible and thus
need to be propagated.
Pushed with the header include as well due to your general "probably
ok" stance and absence of further comments.
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Many that live deserve death. And some that die deserve life. Can you give
> it to them? Then do not be too eager to deal out death in judgement. For
> even the very wise cannot see all ends. -- Gandalf
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avdevice/dshow_enummediatypes: check return of av_malloc
On Wed, Oct 28, 2015 at 10:05 PM, Ganesh Ajjanagadde wrote:
> On Wed, Oct 28, 2015 at 10:00 PM, Michael Niedermayer
> wrote:
>> On Tue, Oct 27, 2015 at 08:09:03PM -0400, Ganesh Ajjanagadde wrote:
>>> Untested.
>>>
>>> Signed-off-by: Ganesh Ajjanagadde
>>> ---
>>> libavdevice/dshow_enummediatypes.c | 2 ++
>>> 1 file changed, 2 insertions(+)
>>>
>>> diff --git a/libavdevice/dshow_enummediatypes.c
>>> b/libavdevice/dshow_enummediatypes.c
>>> index 5b69a5b..5a24870 100644
>>> --- a/libavdevice/dshow_enummediatypes.c
>>> +++ b/libavdevice/dshow_enummediatypes.c
>>> @@ -37,6 +37,8 @@ libAVEnumMediaTypes_Next(libAVEnumMediaTypes *this,
>>> unsigned long n,
>>> if (!this->pos && n == 1) {
>>> if (!IsEqualGUID(&this->type.majortype, &GUID_NULL)) {
>>> AM_MEDIA_TYPE *type = av_malloc(sizeof(AM_MEDIA_TYPE));
>>> +if (!type)
>>> +return AVERROR(ENOMEM);
>>
>> I cannot test this either but the surrounding code returns
>> E_POINTER, E_OUTOFMEMORY, ...
>> not AVERROR*
>> so this does not look correct, or at least inconsistent
>
> Looks like some Windows thing, I guess E_OUTOFMEMORY is the best
> choice. This needs to wait for a review from a Windows using dev IMO.
Assuming the change from AVERROR(ENOMEM) to E_OUTOFMEMORY, is this
patch ok? Worst case, build should be guaranteed.
>
>>
>> [...]
>> --
>> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>>
>> Freedom in capitalist society always remains about the same as it was in
>> ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin
>>
>> ___
>> 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 0/4] av_warn_unused_result for avutil/eval
This is an attempt on my end to be more systematic and avoid sloppiness and noise while sending patches. As can be seen, I have made use of the cover letter option and have organized an av_warn_unused_result change into one cohesive unit: 1/4 fixes issues of unchecked error codes from av_expr_parse_and_eval, essentially ENOMEM. 2/4 fixes an issue I noticed while working on vf_rotate regarding the above. 3/4 cleans up issues in the test build for avutil/eval, so that 4/4 which adds av_warn_unused_result does not cause warning regressions. Tested with FATE. Please reply to this cover letter if you think my attempt at more structured changes is an improvement over e.g mass av_warn_unused_result changes. Ganesh Ajjanagadde (4): avfilter/all: check and propagate the return code of av_expr_parse_and_eval avfilter/vf_rotate: correct log message avutil/eval: check av_expr_parse_and_eval error code in the test build avutil/eval: add av_warn_unused_result libavfilter/vf_pad.c| 10 ++ libavfilter/vf_rotate.c | 7 +++ libavfilter/vf_scale.c | 5 +++-- libavfilter/vf_zscale.c | 5 +++-- libavutil/eval.c| 22 +- libavutil/eval.h| 2 ++ 6 files changed, 30 insertions(+), 21 deletions(-) -- 2.6.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/4] avfilter/all: check and propagate the return code of av_expr_parse_and_eval
This function can return ENOMEM that needs to be propagated. Signed-off-by: Ganesh Ajjanagadde --- libavfilter/vf_pad.c| 10 ++ libavfilter/vf_rotate.c | 3 +-- libavfilter/vf_scale.c | 5 +++-- libavfilter/vf_zscale.c | 5 +++-- 4 files changed, 13 insertions(+), 10 deletions(-) diff --git a/libavfilter/vf_pad.c b/libavfilter/vf_pad.c index 63dc6a8..e10d41b 100644 --- a/libavfilter/vf_pad.c +++ b/libavfilter/vf_pad.c @@ -114,9 +114,10 @@ static int config_input(AVFilterLink *inlink) var_values[VAR_VSUB] = 1 << s->draw.vsub_max; /* evaluate width and height */ -av_expr_parse_and_eval(&res, (expr = s->w_expr), +if ((ret = av_expr_parse_and_eval(&res, (expr = s->w_expr), var_names, var_values, - NULL, NULL, NULL, NULL, NULL, 0, ctx); + NULL, NULL, NULL, NULL, NULL, 0, ctx)) < 0) +goto eval_fail; s->w = var_values[VAR_OUT_W] = var_values[VAR_OW] = res; if ((ret = av_expr_parse_and_eval(&res, (expr = s->h_expr), var_names, var_values, @@ -131,9 +132,10 @@ static int config_input(AVFilterLink *inlink) s->w = var_values[VAR_OUT_W] = var_values[VAR_OW] = res; /* evaluate x and y */ -av_expr_parse_and_eval(&res, (expr = s->x_expr), +if ((ret = av_expr_parse_and_eval(&res, (expr = s->x_expr), var_names, var_values, - NULL, NULL, NULL, NULL, NULL, 0, ctx); + NULL, NULL, NULL, NULL, NULL, 0, ctx)) < 0) +goto eval_fail; s->x = var_values[VAR_X] = res; if ((ret = av_expr_parse_and_eval(&res, (expr = s->y_expr), var_names, var_values, diff --git a/libavfilter/vf_rotate.c b/libavfilter/vf_rotate.c index f12a103..d5e01e2 100644 --- a/libavfilter/vf_rotate.c +++ b/libavfilter/vf_rotate.c @@ -235,8 +235,7 @@ static int config_props(AVFilterLink *outlink) } while (0) /* evaluate width and height */ -av_expr_parse_and_eval(&res, expr = rot->outw_expr_str, var_names, rot->var_values, - func1_names, func1, NULL, NULL, rot, 0, ctx); +SET_SIZE_EXPR(outw, "out_w"); rot->var_values[VAR_OUT_W] = rot->var_values[VAR_OW] = res; rot->outw = res + 0.5; SET_SIZE_EXPR(outh, "out_w"); diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c index 1032688..2cf14e0 100644 --- a/libavfilter/vf_scale.c +++ b/libavfilter/vf_scale.c @@ -265,9 +265,10 @@ static int config_props(AVFilterLink *outlink) var_values[VAR_OVSUB] = 1 << out_desc->log2_chroma_h; /* evaluate width and height */ -av_expr_parse_and_eval(&res, (expr = scale->w_expr), +if ((ret = av_expr_parse_and_eval(&res, (expr = scale->w_expr), var_names, var_values, - NULL, NULL, NULL, NULL, NULL, 0, ctx); + NULL, NULL, NULL, NULL, NULL, 0, ctx)) < 0) +goto fail; scale->w = var_values[VAR_OUT_W] = var_values[VAR_OW] = res; if ((ret = av_expr_parse_and_eval(&res, (expr = scale->h_expr), var_names, var_values, diff --git a/libavfilter/vf_zscale.c b/libavfilter/vf_zscale.c index 86e5f5f..991f95c 100644 --- a/libavfilter/vf_zscale.c +++ b/libavfilter/vf_zscale.c @@ -206,9 +206,10 @@ static int config_props(AVFilterLink *outlink) var_values[VAR_OVSUB] = 1 << out_desc->log2_chroma_h; /* evaluate width and height */ -av_expr_parse_and_eval(&res, (expr = s->w_expr), +if ((ret = av_expr_parse_and_eval(&res, (expr = s->w_expr), var_names, var_values, - NULL, NULL, NULL, NULL, NULL, 0, ctx); + NULL, NULL, NULL, NULL, NULL, 0, ctx)) < 0) +goto fail; s->w = var_values[VAR_OUT_W] = var_values[VAR_OW] = res; if ((ret = av_expr_parse_and_eval(&res, (expr = s->h_expr), var_names, var_values, -- 2.6.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/4] avfilter/vf_rotate: correct log message
There seems to be some typos in the log messages that are fixed by this. Signed-off-by: Ganesh Ajjanagadde --- libavfilter/vf_rotate.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavfilter/vf_rotate.c b/libavfilter/vf_rotate.c index d5e01e2..33acea6 100644 --- a/libavfilter/vf_rotate.c +++ b/libavfilter/vf_rotate.c @@ -238,12 +238,12 @@ static int config_props(AVFilterLink *outlink) SET_SIZE_EXPR(outw, "out_w"); rot->var_values[VAR_OUT_W] = rot->var_values[VAR_OW] = res; rot->outw = res + 0.5; -SET_SIZE_EXPR(outh, "out_w"); +SET_SIZE_EXPR(outh, "out_h"); rot->var_values[VAR_OUT_H] = rot->var_values[VAR_OH] = res; rot->outh = res + 0.5; /* evaluate the width again, as it may depend on the evaluated output height */ -SET_SIZE_EXPR(outw, "out_h"); +SET_SIZE_EXPR(outw, "out_w"); rot->var_values[VAR_OUT_W] = rot->var_values[VAR_OW] = res; rot->outw = res + 0.5; -- 2.6.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/4] avutil/eval: check av_expr_parse_and_eval error code in the test build
This returns the error code from main in the test, in this case ENOMEM.
This should not matter, and will ensure that no warnings are triggered
when av_warn_unused_result is added to avutil/eval.h.
Signed-off-by: Ganesh Ajjanagadde
---
libavutil/eval.c | 22 +-
1 file changed, 13 insertions(+), 9 deletions(-)
diff --git a/libavutil/eval.c b/libavutil/eval.c
index 7642b91..776a3ee 100644
--- a/libavutil/eval.c
+++ b/libavutil/eval.c
@@ -750,7 +750,7 @@ static const char *const const_names[] = {
int main(int argc, char **argv)
{
-int i;
+int i, ret;
double d;
const char *const *expr;
static const char *const exprs[] = {
@@ -854,30 +854,34 @@ int main(int argc, char **argv)
for (expr = exprs; *expr; expr++) {
printf("Evaluating '%s'\n", *expr);
-av_expr_parse_and_eval(&d, *expr,
+if ((ret = av_expr_parse_and_eval(&d, *expr,
const_names, const_values,
- NULL, NULL, NULL, NULL, NULL, 0, NULL);
+ NULL, NULL, NULL, NULL, NULL, 0, NULL)) < 0)
+return ret;
if (isnan(d))
printf("'%s' -> nan\n\n", *expr);
else
printf("'%s' -> %f\n\n", *expr, d);
}
-av_expr_parse_and_eval(&d, "1+(5-2)^(3-1)+1/2+sin(PI)-max(-2.2,-3.1)",
+if ((ret = av_expr_parse_and_eval(&d,
"1+(5-2)^(3-1)+1/2+sin(PI)-max(-2.2,-3.1)",
const_names, const_values,
- NULL, NULL, NULL, NULL, NULL, 0, NULL);
+ NULL, NULL, NULL, NULL, NULL, 0, NULL)) < 0)
+return ret;
printf("%f == 12.7\n", d);
-av_expr_parse_and_eval(&d, "80G/80Gi",
+if ((ret = av_expr_parse_and_eval(&d, "80G/80Gi",
const_names, const_values,
- NULL, NULL, NULL, NULL, NULL, 0, NULL);
+ NULL, NULL, NULL, NULL, NULL, 0, NULL)) < 0)
+return ret;
printf("%f == 0.931322575\n", d);
if (argc > 1 && !strcmp(argv[1], "-t")) {
for (i = 0; i < 1050; i++) {
START_TIMER;
-av_expr_parse_and_eval(&d,
"1+(5-2)^(3-1)+1/2+sin(PI)-max(-2.2,-3.1)",
+if ((ret = av_expr_parse_and_eval(&d,
"1+(5-2)^(3-1)+1/2+sin(PI)-max(-2.2,-3.1)",
const_names, const_values,
- NULL, NULL, NULL, NULL, NULL, 0, NULL);
+ NULL, NULL, NULL, NULL, NULL, 0, NULL)) < 0)
+return ret;
STOP_TIMER("av_expr_parse_and_eval");
}
}
--
2.6.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 4/4] avutil/eval: add av_warn_unused_result
These functions do mallocs that can fail and return AVERROR(ENOMEM) that needs to be checked. Signed-off-by: Ganesh Ajjanagadde --- libavutil/eval.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/libavutil/eval.h b/libavutil/eval.h index 6159b0f..d65fef1 100644 --- a/libavutil/eval.h +++ b/libavutil/eval.h @@ -48,6 +48,7 @@ typedef struct AVExpr AVExpr; * @return >= 0 in case of success, a negative value corresponding to an * AVERROR code otherwise */ +av_warn_unused_result int av_expr_parse_and_eval(double *res, const char *s, const char * const *const_names, const double *const_values, const char * const *func1_names, double (* const *funcs1)(void *, double), @@ -71,6 +72,7 @@ int av_expr_parse_and_eval(double *res, const char *s, * @return >= 0 in case of success, a negative value corresponding to an * AVERROR code otherwise */ +av_warn_unused_result int av_expr_parse(AVExpr **expr, const char *s, const char * const *const_names, const char * const *func1_names, double (* const *funcs1)(void *, double), -- 2.6.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] IETF Standardization: RFC by November 9
Dear all, We are excited to announce that the our CELLAR working group charter for the standardization of FFV1, Matroska, and FLAC has been made available for external review. What this means is that it is now under review and available for comment to the wider IETF community. Please send any comments you might have(including statement of support)to the IESG mailing list by November 9, 2015. The mailing list for review comments is here: i...@ietf.org In the upcoming weeks, we will begin actively posting to the newly established CELLAR working group mailing list at cel...@ietf.org. Please sign up for the new mailing list here: https://www.ietf.org/mailman/listinfo/cellar I've included the draft charter below, which I've sent to the mailing list previously. The charter can also be found here: https://datatracker.ietf.org/wg/cellar/charter/ Best wishes, Tessa Fallon From: The IESG To: "IETF-Announce" Cc: cel...@ietf.org Subject: WG Review: Codec Encoding for LossLess Archiving and Realtime transmission (cellar) A new IETF working group has been proposed in the Applications and Real-Time Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2015-11-09. Codec Encoding for LossLess Archiving and Realtime transmission (cellar) Current Status: Proposed WG Chairs: Tessa Fallon Assigned Area Director: Ben Campbell Mailing list Address: cel...@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/cellar Archive: https://mailarchive.ietf.org/arch/browse/cellar/ Charter: The preservation of audiovisual materials faces challenges from technological obsolescence, analog media deterioration, and the use of proprietary formats that lack formal open standards. While obsolescence and material degradation are widely addressed, the standardization of open, transparent, self-descriptive, lossless formats remains an important mission to be undertaken by the open source community. FFV1 is a lossless video codec and Matroska is an extensible media container based on EBML (Extensible Binary Meta Language), a binary XML format. There are open source implementations of both formats, and an increasing interest in and support for use of FFV1 and Matroska. However, there are concerns about the sustainability and credibility of existing specifications for the long-term use of these formats. These existing specifications require broader review and formalization in order to encourage widespread adoption. There is also a need for a lossless audio format to complement the lossless video codec and container format. FLAC is a lossless audio codec that has seen widespread adoption in a number of different applications including archival applications. While there are open source implementations of the codec, no formal standards for either the codec itself or its use in container formats currently exist. Review and formalization of the FLAC codec standard and its use in Matroska container formats is needed for wider adoption. Using existing work done by the development communities of Matroska, FFV1, and FLAC, the Working Group will formalize specifications for these open and lossless formats. In order to provide authoritative, standardized specifications for users and developers, the Working Group will seek consensus throughout the process of refining and formalizing these standards. Initial specifications can be accessed here: Specifications: - FFV1: https://mediaarea.net/temp/ffv1.html - Matroska: http://matroska.org/technical/specs/index.html - EBML: http://matroska-org.github.io/libebml/specs.html - FLAC: https://xiph.org/flac/format.html Development Versions: - FFV1: https://github.com/ffmpeg/ffv1 - Matroska:https://github.com/Matroska-Org/foundation-source/blob/master/spectool/specdata.xml - EBML: https://github.com/Matroska-Org/ebml-specification The Working Group will seek consensus and refinements for specifications for both FFV1 and Matroska in order to provide authoritative, standardized specifications for users and developers. Backward compatibility with existing versions 0-3 of the FFV1 and Matroska specifications will be an important goal, while also reviewing and refining the current version 4 under active development. Although not encouraged, non-backwards-compatible changes to the input specifications will be acceptable if the Working Group determines that the modifications are required to meet the group's technical objectives, provided that the reasons for these changes are clearly documented. Deliverables: - Informational specification for Matroska container format versions 1, 2 and 3 to IESG for publication - Standards Track specification for Matroska container format version 4 to IESG for publication - Informational specification for FFV1 video codec version
Re: [FFmpeg-devel] [PATCH] avfilter/vf_deshake: replace qsort with AV_QSORT
Le decadi 10 brumaire, an CCXXIV, Ganesh Ajjanagadde a écrit : > Entirely possible. I just did this as a low hanging fruit. I highly > suspect that the algorithm can be improved (see Michael's comment). > The start/stop was just around the qsort statement. Since you asked So the speedup observed may be completely irrelevant. > this, I will add it to the commit message. I would have appreciated if you waited for the discussion around the patch to finish before pushing it. 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] [FFmpeg-cvslog] avfilter/vf_deshake: replace qsort with AV_QSORT
Le decadi 10 brumaire, an CCXXIV, Ganesh Ajjanagadde a écrit : > Reviewed-by: Nicolas George That is not true. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/vf_deshake: replace qsort with AV_QSORT
On Sat, Oct 31, 2015 at 12:43 PM, Nicolas George wrote: > Le decadi 10 brumaire, an CCXXIV, Ganesh Ajjanagadde a écrit : >> Entirely possible. I just did this as a low hanging fruit. I highly >> suspect that the algorithm can be improved (see Michael's comment). >> The start/stop was just around the qsort statement. Since you asked > > So the speedup observed may be completely irrelevant. > >> this, I will add it to the commit message. > > I would have appreciated if you waited for the discussion around the patch > to finish before pushing it. That was an inexcusable misread on my end: I viewed (incorrectly and hastily) your message as a general remark. Sorry. > > Regards, > > -- > Nicolas George > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/vf_deshake: replace qsort with AV_QSORT
On Sat, Oct 31, 2015 at 1:27 PM, Ganesh Ajjanagadde wrote: > On Sat, Oct 31, 2015 at 12:43 PM, Nicolas George wrote: >> Le decadi 10 brumaire, an CCXXIV, Ganesh Ajjanagadde a écrit : >>> Entirely possible. I just did this as a low hanging fruit. I highly >>> suspect that the algorithm can be improved (see Michael's comment). >>> The start/stop was just around the qsort statement. Since you asked >> >> So the speedup observed may be completely irrelevant. For the benefit of the thread, here is a benchmark for the find_motion function to address this point: new: 2075495840 decicycles in find_motion, 1 runs, 0 skips 1981653450 decicycles in find_motion, 2 runs, 0 skips 1963960877 decicycles in find_motion, 4 runs, 0 skips 1995843222 decicycles in find_motion, 8 runs, 0 skips 1954257600 decicycles in find_motion, 16 runs, 0 skips 1914343743 decicycles in find_motion, 32 runs, 0 skips 1900114312 decicycles in find_motion, 64 runs, 0 skips 1883816712 decicycles in find_motion, 128 runs, 0 skips 1847216223 decicycles in find_motion, 256 runs, 0 skips 1807254028 decicycles in find_motion, 512 runs, 0 skips 1815531917 decicycles in find_motion,1024 runs, 0 skips old: 2137526850 decicycles in find_motion, 1 runs, 0 skips 2032845285 decicycles in find_motion, 2 runs, 0 skips 2049874912 decicycles in find_motion, 4 runs, 0 skips 2047886076 decicycles in find_motion, 8 runs, 0 skips 1989838803 decicycles in find_motion, 16 runs, 0 skips 1929553950 decicycles in find_motion, 32 runs, 0 skips 1929938301 decicycles in find_motion, 64 runs, 0 skips 1914471658 decicycles in find_motion, 128 runs, 0 skips 1975107739 decicycles in find_motion, 256 runs, 0 skips 1879646457 decicycles in find_motion, 512 runs, 0 skips 1900282483 decicycles in find_motion,1024 runs, 0 skips I leave it to the judgement of others whether or not this is significant enough. >> >>> this, I will add it to the commit message. >> >> I would have appreciated if you waited for the discussion around the patch >> to finish before pushing it. > > That was an inexcusable misread on my end: I viewed (incorrectly and > hastily) your message as a general remark. Sorry. > >> >> Regards, >> >> -- >> Nicolas George >> >> ___ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/vf_deshake: replace qsort with AV_QSORT
Le decadi 10 brumaire, an CCXXIV, Ganesh Ajjanagadde a écrit : > For the benefit of the thread, here is a benchmark for the find_motion > function to address this point: > new: > 1815531917 decicycles in find_motion,1024 runs, 0 skips > > old: > 1900282483 decicycles in find_motion,1024 runs, 0 skips So 4-5%. That is nowhere near the values, but that is still a worthy speedup nonetheless. Thanks for running the test. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/vf_deshake: replace qsort with AV_QSORT
On Sat, Oct 31, 2015 at 2:30 PM, Nicolas George wrote: > Le decadi 10 brumaire, an CCXXIV, Ganesh Ajjanagadde a écrit : >> For the benefit of the thread, here is a benchmark for the find_motion >> function to address this point: >> new: >> 1815531917 decicycles in find_motion,1024 runs, 0 skips >> >> old: >> 1900282483 decicycles in find_motion,1024 runs, 0 skips > > So 4-5%. That is nowhere near the values, but that is still a worthy > speedup nonetheless. Thanks for running the test. The gap is not surprising due to your remark regarding the loop, and is a general caveat regarding benchmarking/profiling that I will try to be more cautious about in the future. For future reference, I have adopted the consistent convention of referring to the block of code in the START, STOP macros so as to make it clear what I have benchmarked. If it is a loop in a function, I will be explicit and put line nos, e.g "235-260:foo" where foo is the function name. > > Regards, > > -- > Nicolas George > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] avcodec: add Interplay ACM decoder
Signed-off-by: Paul B Mahol
---
libavcodec/Makefile | 1 +
libavcodec/allcodecs.c| 1 +
libavcodec/avcodec.h | 1 +
libavcodec/codec_desc.c | 7 +
libavcodec/interplayacm.c | 590 ++
5 files changed, 600 insertions(+)
create mode 100644 libavcodec/interplayacm.c
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 8162447..4a879d6 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -145,6 +145,7 @@ OBJS-$(CONFIG_AC3_FIXED_DECODER) += ac3dec_fixed.o
ac3dec_data.o ac3.o kbd
OBJS-$(CONFIG_AC3_ENCODER) += ac3enc_float.o ac3enc.o ac3tab.o \
ac3.o kbdwin.o
OBJS-$(CONFIG_AC3_FIXED_ENCODER) += ac3enc_fixed.o ac3enc.o ac3tab.o
ac3.o
+OBJS-$(CONFIG_ACM_DECODER) += interplayacm.o
OBJS-$(CONFIG_AIC_DECODER) += aic.o
OBJS-$(CONFIG_ALAC_DECODER)+= alac.o alac_data.o alacdsp.o
OBJS-$(CONFIG_ALAC_ENCODER)+= alacenc.o alac_data.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 49478a1..cfb8912 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -371,6 +371,7 @@ void avcodec_register_all(void)
REGISTER_DECODER(AAC_LATM, aac_latm);
REGISTER_ENCDEC (AC3, ac3);
REGISTER_ENCDEC (AC3_FIXED, ac3_fixed);
+REGISTER_DECODER(ACM, acm);
REGISTER_ENCDEC (ALAC, alac);
REGISTER_DECODER(ALS, als);
REGISTER_DECODER(AMRNB, amrnb);
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index b4f113f..91cd6a8 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -496,6 +496,7 @@ enum AVCodecID {
AV_CODEC_ID_DSD_LSBF_PLANAR,
AV_CODEC_ID_DSD_MSBF_PLANAR,
AV_CODEC_ID_4GV,
+AV_CODEC_ID_INTERPLAY_ACM,
/* subtitle codecs */
AV_CODEC_ID_FIRST_SUBTITLE = 0x17000, ///< A dummy ID pointing at
the start of subtitle codecs.
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index bf7c425..58d9d93 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -2622,6 +2622,13 @@ static const AVCodecDescriptor codec_descriptors[] = {
.long_name = NULL_IF_CONFIG_SMALL("DSD (Direct Stream Digital), most
significant bit first, planar"),
.props = AV_CODEC_PROP_LOSSY,
},
+{
+.id= AV_CODEC_ID_INTERPLAY_ACM,
+.type = AVMEDIA_TYPE_AUDIO,
+.name = "acm",
+.long_name = NULL_IF_CONFIG_SMALL("Interplay ACM"),
+.props = AV_CODEC_PROP_LOSSY,
+},
/* subtitle codecs */
{
diff --git a/libavcodec/interplayacm.c b/libavcodec/interplayacm.c
new file mode 100644
index 000..8a2e7c9
--- /dev/null
+++ b/libavcodec/interplayacm.c
@@ -0,0 +1,590 @@
+/*
+ * Interplay ACM decoder
+ *
+ * Copyright (c) 2004-2008, Marko Kreen
+ * Copyright (c) 2008, Adam Gashlin
+ * Copyright (c) 2015 Paul B Mahol
+ *
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#include "libavutil/intreadwrite.h"
+#include "avcodec.h"
+#define BITSTREAM_READER_LE
+#include "get_bits.h"
+#include "internal.h"
+
+static const int8_t map_1bit[] = { -1, +1 };
+static const int8_t map_2bit_near[] = { -2, -1, +1, +2 };
+static const int8_t map_2bit_far[] = { -3, -2, +2, +3 };
+static const int8_t map_3bit[] = { -4, -3, -2, -1, +1, +2, +3, +4 };
+
+static int mul_3x3 [3 * 3 * 3];
+static int mul_3x5 [5 * 5 * 5];
+static int mul_2x11[11 * 11];
+
+typedef struct InterplayACMContext {
+GetBitContext gb;
+uint8_t *bitstream;
+int max_framesize;
+int bitstream_size;
+int bitstream_index;
+
+int level;
+int rows;
+int cols;
+int wrapbuf_len;
+int block_len;
+int skip;
+
+int *block;
+int *wrapbuf;
+int *ampbuf;
+int *midbuf;
+} InterplayACMContext;
+
+static av_cold int decode_init(AVCodecContext *avctx)
+{
+InterplayACMContext *s = avctx->priv_data;
+int x1, x2, x3;
+
+if (avctx->extradata_size < 14)
+return AVERROR_INVALIDDATA;
+
+s->level = AV_RL16(avctx->extradata + 12) & 0xf;
+s->rows = AV_RL16(avctx->extradata + 12) >> 4;
+s->cols = 1 << s->level;
+s->wrapbuf_len = 2 * s->cols - 2;
+s->block_le
[FFmpeg-devel] [PATCH 2/2] avformat: add acm demuxer
Signed-off-by: Paul B Mahol
---
libavformat/Makefile | 1 +
libavformat/acm.c| 71
libavformat/allformats.c | 1 +
3 files changed, 73 insertions(+)
create mode 100644 libavformat/acm.c
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 27aefcb..f2326df 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -63,6 +63,7 @@ OBJS-$(CONFIG_AA_DEMUXER)+= aadec.o
OBJS-$(CONFIG_AAC_DEMUXER) += aacdec.o apetag.o img2.o rawdec.o
OBJS-$(CONFIG_AC3_DEMUXER) += ac3dec.o rawdec.o
OBJS-$(CONFIG_AC3_MUXER) += rawenc.o
+OBJS-$(CONFIG_ACM_DEMUXER) += acm.o rawdec.o
OBJS-$(CONFIG_ACT_DEMUXER) += act.o
OBJS-$(CONFIG_ADF_DEMUXER) += bintext.o sauce.o
OBJS-$(CONFIG_ADP_DEMUXER) += adp.o
diff --git a/libavformat/acm.c b/libavformat/acm.c
new file mode 100644
index 000..a2e0a12
--- /dev/null
+++ b/libavformat/acm.c
@@ -0,0 +1,71 @@
+/*
+ * ACM demuxer
+ * Copyright (c) 2015 Paul B Mahol
+ *
+ * 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 "libavutil/intreadwrite.h"
+#include "avformat.h"
+#include "rawdec.h"
+#include "internal.h"
+
+static int acm_probe(AVProbeData *p)
+{
+if (AV_RB32(p->buf) != 0x97280301)
+return 0;
+
+return AVPROBE_SCORE_MAX / 3 * 2;
+}
+
+static int acm_read_header(AVFormatContext *s)
+{
+AVStream *st;
+int ret;
+
+st = avformat_new_stream(s, NULL);
+if (!st)
+return AVERROR(ENOMEM);
+
+st->codec->codec_type = AVMEDIA_TYPE_AUDIO;
+st->codec->codec_id = AV_CODEC_ID_INTERPLAY_ACM;
+
+ff_alloc_extradata(st->codec, 14);
+if (!st->codec->extradata)
+return AVERROR(ENOMEM);
+ret = avio_read(s->pb, st->codec->extradata, 14);
+if (ret < 10)
+return ret < 0 ? ret : AVERROR_EOF;
+
+st->codec->channels= AV_RL16(st->codec->extradata + 8);
+st->codec->sample_rate = AV_RL16(st->codec->extradata + 10);
+if (st->codec->channels <= 0 || st->codec->sample_rate <= 0)
+return AVERROR_INVALIDDATA;
+st->duration = AV_RL32(st->codec->extradata + 4) /
st->codec->channels;
+avpriv_set_pts_info(st, 64, 1, st->codec->sample_rate);
+
+return 0;
+}
+
+AVInputFormat ff_acm_demuxer = {
+.name = "acm",
+.long_name = NULL_IF_CONFIG_SMALL("Interplay ACM"),
+.read_probe = acm_probe,
+.read_header= acm_read_header,
+.read_packet= ff_raw_read_partial_packet,
+.extensions = "acm",
+};
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index fc42cb7..92e321c 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -63,6 +63,7 @@ void av_register_all(void)
REGISTER_DEMUXER (AA, aa);
REGISTER_DEMUXER (AAC, aac);
REGISTER_MUXDEMUX(AC3, ac3);
+REGISTER_DEMUXER (ACM, acm);
REGISTER_DEMUXER (ACT, act);
REGISTER_DEMUXER (ADF, adf);
REGISTER_DEMUXER (ADP, adp);
--
1.9.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 06/11] avfilter/af_volumedetect: use log10 instead of hardcoded constant
On Wed, Oct 28, 2015 at 9:20 PM, Ganesh Ajjanagadde wrote: > This is likely more precise and conveys the intent better. > > Signed-off-by: Ganesh Ajjanagadde > --- > libavfilter/af_volumedetect.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavfilter/af_volumedetect.c b/libavfilter/af_volumedetect.c > index 01f24ba..ad5fef3 100644 > --- a/libavfilter/af_volumedetect.c > +++ b/libavfilter/af_volumedetect.c > @@ -78,7 +78,7 @@ static inline double logdb(uint64_t v) > double d = v / (double)(0x8000 * 0x8000); > if (!v) > return MAX_DB; > -return log(d) * -4.3429448190325182765112891891660508229; /* -10/log(10) > */ > +return log10(d) * 10; Wouldn't this reverse the sign of the result? > } > > static void print_stats(AVFilterContext *ctx) > -- > 2.6.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 06/11] avfilter/af_volumedetect: use log10 instead of hardcoded constant
On Sat, Oct 31, 2015 at 6:02 PM, Mark Harris wrote: > On Wed, Oct 28, 2015 at 9:20 PM, Ganesh Ajjanagadde > wrote: >> This is likely more precise and conveys the intent better. >> >> Signed-off-by: Ganesh Ajjanagadde >> --- >> libavfilter/af_volumedetect.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/libavfilter/af_volumedetect.c b/libavfilter/af_volumedetect.c >> index 01f24ba..ad5fef3 100644 >> --- a/libavfilter/af_volumedetect.c >> +++ b/libavfilter/af_volumedetect.c >> @@ -78,7 +78,7 @@ static inline double logdb(uint64_t v) >> double d = v / (double)(0x8000 * 0x8000); >> if (!v) >> return MAX_DB; >> -return log(d) * -4.3429448190325182765112891891660508229; /* >> -10/log(10) */ >> +return log10(d) * 10; > > Wouldn't this reverse the sign of the result? Missed the sign, of course you are right. Thanks. I dropped this stuff on my end due to the whole log episode, and don't mind if it gets included or not. Will leave it to the maintainer to decide. > >> } >> >> static void print_stats(AVFilterContext *ctx) >> -- >> 2.6.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] pixblockdsp: Use memcpy for get_pixels_16_c
On Tue, Oct 20, 2015 at 11:29 PM Michael Niedermayer
wrote:
> > diff --git a/libavcodec/pixblockdsp.c b/libavcodec/pixblockdsp.c
> > index 322e1dd..0f23d8a 100644
> > --- a/libavcodec/pixblockdsp.c
> > +++ b/libavcodec/pixblockdsp.c
> > @@ -23,12 +23,38 @@
> > #include "avcodec.h"
> > #include "pixblockdsp.h"
> >
> > -#define BIT_DEPTH 16
> > -#include "pixblockdsp_template.c"
> > -#undef BIT_DEPTH
> > +static void get_pixels_16_c(int16_t *av_restrict block, const uint8_t
> *pixels,
> > +ptrdiff_t line_size)
> > +{
> > +memcpy(block + 0 * 8, pixels + 0 * line_size, sizeof(int16_t) * 8);
> > +memcpy(block + 1 * 8, pixels + 1 * line_size, sizeof(int16_t) * 8);
> > +memcpy(block + 2 * 8, pixels + 2 * line_size, sizeof(int16_t) * 8);
> > +memcpy(block + 3 * 8, pixels + 3 * line_size, sizeof(int16_t) * 8);
> > +memcpy(block + 4 * 8, pixels + 4 * line_size, sizeof(int16_t) * 8);
> > +memcpy(block + 5 * 8, pixels + 5 * line_size, sizeof(int16_t) * 8);
> > +memcpy(block + 6 * 8, pixels + 6 * line_size, sizeof(int16_t) * 8);
> > +memcpy(block + 7 * 8, pixels + 7 * line_size, sizeof(int16_t) * 8);
>
> AV_COPY128(U)
>
Changed.
>
>
> > +}
> > +
> > +static void get_pixels_8_c(int16_t *av_restrict block, const uint8_t
> *pixels,
> > + ptrdiff_t line_size)
> > +{
> > +int i;
> >
> > -#define BIT_DEPTH 8
> > -#include "pixblockdsp_template.c"
> > +/* read the pixels */
> > +for (i = 0; i < 8; i++) {
> > +block[0] = pixels[0];
> > +block[1] = pixels[1];
> > +block[2] = pixels[2];
> > +block[3] = pixels[3];
> > +block[4] = pixels[4];
> > +block[5] = pixels[5];
> > +block[6] = pixels[6];
> > +block[7] = pixels[7];
>
> AV_COPY64(U)
They are not equivalent.
Pushed.
Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
