[FFmpeg-devel] [PATCH v3 2/3] avutil/log: add av_log_set_opts function

[wm4]

On Thu, 29 Mar 2018 13:47:55 +0200
Tobias Rapp <t.rapp at noa-archive.com> wrote:

> On 29.03.2018 12:58, wm4 wrote:
> > On Thu, 29 Mar 2018 08:58:12 +0200
> > Tobias Rapp <t.rapp at noa-archive.com> wrote:
> >   
> >> On 28.03.2018 17:11, wm4 wrote:  
> >>> On Wed, 28 Mar 2018 17:03:39 +0200
> >>> Tobias Rapp <t.rapp at noa-archive.com> wrote:
> >>>      
> >>>> Allows to set log level and flag values from string.
> >>>>
> >>>> Signed-off-by: Tobias Rapp <t.rapp at noa-archive.com>
> >>>> ---
> >>>>    doc/APIchanges      |  3 +++
> >>>>    libavutil/log.c     | 76 +++++++++++++++++++++++++++++++++++++++++++++++++++++
> >>>>    libavutil/log.h     | 16 +++++++++++
> >>>>    libavutil/version.h |  2 +-
> >>>>    4 files changed, 96 insertions(+), 1 deletion(-)
> >>>>
> >>>> [...]  
> >>>
> >>> Seems like a step backwards. Why can't it stay in the fftools thing?  
> >>
> >> When v2 of the patch was reviewed in
> >> http://ffmpeg.org/pipermail/ffmpeg-devel/2018-March/227077.html it was
> >> suggested to move the code into libavutil so that other applications can
> >> make use of it. I agree that it can be useful for command-line apps that
> >> interface with libav* to provide a loglevel option which accepts
> >> info/verbose/etc. name strings without the need to do an own
> >> string-to-level parsing.  
> > 
> > That seems completely unnecessary. Applications will have their own
> > conventions and option parsers.  
> 
> In case the function is placed into fftools applications are forced to 
> do their own thing, when it's available inside avutil applications can 
> either use it _or_ implement an own parser. Thus I see no benefit in not 
> having it inside avutil.
> 
> Anyway: my goal still is to add support for setting AV_LOG_PRINT_LEVEL 
> via some (ffmpeg) command-line option. If you're blocking addition to 
> avutil and Michael accepts updating opt_loglevel() in fftools then 
> that's also OK for me.

I'd like to block it, because I don't see it as a good thing that more
fftools specific stuff is leaking into the generic libs. Sorry.