Open jtdaugherty opened 8 years ago
This is a great question. I looked into it in the past, but didn't see it through. This SO page has a few suggestions. Any thoughts on the API? We could do things in a WriterT
-like thing where we accumulate the log output, or we could just shut it off. Controlling the log level is very stateful, but maybe just sticking to that is the best option.
When it's a nuisance I can imagine wanting to just buffer it all and maybe look at it later in case of a problem. But I can also see it being useful to want live streaming access to the log output as it arrives. In my case that would be nice; I'm updating my ray tracer to stream rendered frames to a movie as the rendering progresses, and it would be nice to have an ffmpeg output area in my brick
UI that would show ffmpeg's progress. To that end -- and I don't know what dragons lurk here -- what would be really cool is if I could pass a haskell function logFFmpeg :: String -> IO ()
that would be called when there's log output, and then I could decide what I want that to be (in my case, update my brick
UI). Is that feasible?
One problem I foresee is that the log output may be intended for a terminal, i.e., it might contain escape sequences for coloring, and I wouldn't want any of that if I just wanted strings suitable for my own use. So another consideration would be whether the color escapes can be disabled: I recall seeing something about this at https://ffmpeg.org/ffmpeg.html (see AV_LOG_FORCE_NOCOLOR
). For maximum flexibility it might be important to provide an option to let the library user turn this on or off in case the log output is ultimately destined for a terminal (as opposed to, say, a log file where escapes would be undesirable).
This is starting to annoy me, too. But from a quick look here:
https://www.ffmpeg.org/doxygen/3.0/group__lavu__log.html#ga14034761faf581a8b9ed6ef19b313708
It is not obvious to me what is the scope where a call to av_log_set_callback
affects the logging. Maybe it applies to the full process, or just a thread or something else?
If it's global, it might be enough to provide some very lightweight Haskell wrappers which allow the user of ffmpeg-light
to redirect the output wherever he desires.
I added very basic support to at least turn the logging output off without losing stderr
. Is this enough, or should we keep this issue open in the hopes someone can do the full callback implementation?
I'm not using this library at the moment like I was when I requested this, but I would still enjoy having more control over the log output without having to redirect stderr
.
When I run programs using
ffmpeg-light
I getffmpeg
log output in the terminal. Is there any way to get more control over ffmpeg's log output? I'm using this in an application that also does curses-style terminal manipulation so any ffmpeg output is garbled. I could redirect stderr, but what I really want is to get more control over the library so I can use stderr for my own purposes.