[MPlayer-dev-eng] r23403 - in trunk/libavcodec: eval.c eval.h

[Reinhard Tartler]

The following message is a courtesy copy of an article
that has been posted to gmane.comp.video.ffmpeg.cvs as well.

On Di, Jun 01, 2010 at 12:02:21 (CEST), Stefano Sabatini wrote:

> On date Tuesday 2010-06-01 11:54:07 +0200, Reinhard Tartler wrote:
>> On Di, Jun 01, 2010 at 10:07:12 (CEST), stefano wrote:
>> 
>> > Author: stefano
>> > Date: Tue Jun  1 10:07:12 2010
>> > New Revision: 23403
>> >
>> > Log:
>> > Cosmetics: rename ff_parse_expr() and ff_parse_and_eval_expr() parameters:
>> > const_name    -> const_names
>> > const_value   -> const_values
>> > func[12]_name -> func[12]_names
>> > func[12]      -> funcs[12]
>> 
>> 
>> this broke compilation of mplayer:
>> 
>> libmpcodecs/vf_geq.c: In function 'vf_open':
>> libmpcodecs/vf_geq.c:175: warning: initialization from incompatible pointer type
>> libmpcodecs/vf_geq.c:176: warning: initialization from incompatible pointer type
>> libmpcodecs/vf_geq.c:177: warning: initialization from incompatible pointer type
>> libmpcodecs/vf_geq.c:178: warning: initialization from incompatible pointer type
>> libmpcodecs/vf_geq.c:181: warning: passing argument 1 of 'ff_parse_and_eval_expr' from incompatible pointer type
>> ./libavcodec/eval.h:49: note: expected 'double *' but argument is of type 'char *'
>> libmpcodecs/vf_geq.c:181: warning: passing argument 2 of 'ff_parse_and_eval_expr' from incompatible pointer type
>> ./libavcodec/eval.h:49: note: expected 'const char *' but argument is of type 'const char **'
>> libmpcodecs/vf_geq.c:181: warning: passing argument 6 of 'ff_parse_and_eval_expr' from incompatible pointer type
>> ./libavcodec/eval.h:49: note: expected 'double (* const*)(void *, double)' but argument is of type 'double (**)(void *, double,  double)'
>> libmpcodecs/vf_geq.c:181: error: too few arguments to function 'ff_parse_and_eval_expr'
>> make: *** [libmpcodecs/vf_geq.o] Error 1
>
> Not this, but the previous commit changed signature to the
> functions. Hopefully these kind of breakages will gone away as the
> eval API will be made public. And I hope you agree with me that making
> MPlayer use the internal API of FFmpeg was a bad idea in the first
> place.

I totally agree.

copying mplayer mailing list: we need to make mplayer use the public
eval API now!


-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4