On 29.03.2018 12:58, wm4 wrote:
On Thu, 29 Mar 2018 08:58:12 +0200
Tobias Rapp <t.r...@noa-archive.com> wrote:
On 28.03.2018 17:11, wm4 wrote:
On Wed, 28 Mar 2018 17:03:39 +0200
Tobias Rapp <t.r...@noa-archive.com> wrote:
Allows to set log level and flag values from string.
Signed-off-by: Tobias Rapp <t.r...@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.
Regards,
Tobias
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
