[FFmpeg-devel] [PATCH 1/5] Change eval internal functions, ff_parse_expr() and ff_parse_and_eval_expr() interface.

[Michael Niedermayer]

On Sat, May 08, 2010 at 01:03:57PM +0200, Stefano Sabatini wrote:
> On date Wednesday 2010-04-28 22:37:22 +0200, Michael Niedermayer encoded:
> > On Sun, Apr 25, 2010 at 02:18:19AM +0200, Stefano Sabatini wrote:
> > > On date Wednesday 2010-04-21 23:36:05 +0200, Michael Niedermayer encoded:
> > > > On Wed, Apr 21, 2010 at 02:22:58AM +0200, Stefano Sabatini wrote:
> > > > > On date Tuesday 2010-04-20 02:37:55 +0200, Michael Niedermayer encoded:
> > > > > > On Tue, Apr 20, 2010 at 01:18:01AM +0200, Stefano Sabatini wrote:
> > > > > [...]
> > > > > > > > > A possible solution would be to add a simple flag log_error to
> > > > > > > > > ff_parse_expr()/ff_parse_and_eval_expr().
> > > > > > > > 
> > > > > > > > iam against this, its unreasonable unflexible, even a offset to the
> > > > > > > > log level would be better
> > > > > > > 
> > > > > > > Problem with the map is that we don't have just 8 values for log, it
> > > > > > > is an int ranging from -8 to 48, that's why I can't grasp the 8 entry
> > > > > > > array map idea, please elaborate.
> > > > > > 
> > > > > > right, sorry, i meant something like:
> > > > > > level += map[av_clip(level>>3,...)]
> > > > > 
> > > > > If I understood it correctly this would mean to set an ad-hoc log
> > > > > level for each log context, right?
> > > > 
> > > > it would allow to compensate the log level per context.
> > > > without it or a equialent system av_log() can not be used in generic utility
> > > > code ever. This also would mean all uses in libavutil would have to be
> > > > removed
> > > > the global log level, that is for example "print errors" breaks down once
> > > > you go down into a function of some generic util, its error might not be
> > > > an error for the main application at all or it might be it all depends on
> > > > what the failure of such util means in each specific instance to the main
> > > > application.
> > > 
> > > My idea is to implement something of the kind:
> > > 
> > > static inline int av_log_get_level_offset(void *log_ctx)
> > > {
> > >     int *log_level = log_ctx ? log_ctx+sizeof(AVClass *) : NULL;
> > >     
> > >     return log_level ? *log_level : 0;
> > > }
> > > 
> > > static inline int av_log_set_level_offset(void *log_ctx) { ... };
> > > 
> > > But this would require to put ant int log_level_offset in the contexts
> > > just after the class pointers:
> > 
> > You are confused
> > we can add fields to structures since ages (at the end) this doesnt break
> > ABI.
> > We can access them through AVOptions in a generic way 
> > (thats what AVOptions are there for)
> 
> The idea crossed my mind, but I considered it a little expensive
> efficiency-wise, having to make av_get_int() for every av_log() is
> going to be a little slow, av_log() is supposed to be fast, anyway I

so put a offset to the field in AVClass


> won't object if you like this approach.
> 
> Also in this case we need some way to tell to AVOptions which are the
> "reserved" options, an idea could be to prefix with "_" the options
> which have a special meaning, e.g. we could have _log_level_offset.

we dont need that. 
log_level_offset is a variable like any, the user can have very good reason
why he wants to make a specific component like libavformat less or more
verbose

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 3
"Rare item" - "Common item with rare defect or maybe just a lie"
"Professional" - "'Toy' made in china, not functional except as doorstop"
"Experts will know" - "The seller hopes you are not an expert"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100508/e7b2a1e3/attachment.pgp>