Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Control over log output #19

Open
jtdaugherty opened this issue Dec 28, 2015 · 5 comments
Open

Control over log output #19

jtdaugherty opened this issue Dec 28, 2015 · 5 comments

Comments

@jtdaugherty
Copy link
Collaborator

When I run programs using ffmpeg-light I get ffmpeg 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.

@acowley
Copy link
Owner

acowley commented Dec 28, 2015

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.

@jtdaugherty
Copy link
Collaborator Author

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).

@waldheinz
Copy link
Contributor

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.

acowley added a commit that referenced this issue Mar 18, 2016
This doesn't do anything fancy; it just allows Haskell code to control
the log level.

Related to Issue #19
@acowley
Copy link
Owner

acowley commented Mar 18, 2016

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?

@jtdaugherty
Copy link
Collaborator Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants