VSPipe logging

[zorr]

I hit a little snag using VSPipe to run the scripts in the optimizer. With Avisynth I'm using Groucho2004's avrs (https://forum.doom9.org/showthread.php?t=173259) tool which doesn't write the output video at all. Therefore it can output errors to stderr and normal output messages to stdout. AvisynthOptimizer interprets any messages to stderr as errors and stops running.

The situation with VSPipe is a bit more complex as it also outputs the video and especially when it's piped to other applications using stdout. For that reason (correct me if I'm wrong) it outputs all log messages to stderr.

I thought I can handle this however by detecting the most common stderr message which is "Output N frames in..." and not interpret that as an error. However I noticed plugins can also write all kinds of messages via the logMessage function. In this particular case rawsource always outputs "raws: check_args: src_format=..."-type message with log level mtDebug so it's just a debug message but it still comes out of stderr and the optimizer cannot know if that is a real error message or not.

So what I'd like to propose is a small behavior change to VSPipe when the outfile is a dot (.). In this case the video is not written to stdout so it could be used for normal log messages. The error messages would still go to stderr and the optimizer will then know that they're truly errors. What do you say Myrsloik, can it be done?

[EDIT] I had another idea: a new VSPipe option --loglevel which would filter out all log messages with lower level than the one specified. With that option as --loglevel mtCritical the optimizer would only receive real error messages. Probably easier to implement?

[Myrsloik]

I hit a little snag using VSPipe to run the scripts in the optimizer. With Avisynth I'm using Groucho2004's avrs (https://forum.doom9.org/showthread.php?t=173259) tool which doesn't write the output video at all. Therefore it can output errors to stderr and normal output messages to stdout. AvisynthOptimizer interprets any messages to stderr as errors and stops running.

The situation with VSPipe is a bit more complex as it also outputs the video and especially when it's piped to other applications using stdout. For that reason (correct me if I'm wrong) it outputs all log messages to stderr.

I thought I can handle this however by detecting the most common stderr message which is "Output N frames in..." and not interpret that as an error. However I noticed plugins can also write all kinds of messages via the logMessage function. In this particular case rawsource always outputs "raws: check_args: src_format=..."-type message with log level mtDebug so it's just a debug message but it still comes out of stderr and the optimizer cannot know if that is a real error message or not.

So what I'd like to propose is a small behavior change to VSPipe when the outfile is a dot (.). In this case the video is not written to stdout so it could be used for normal log messages. The error messages would still go to stderr and the optimizer will then know that they're truly errors. What do you say Myrsloik, can it be done?

[EDIT] I had another idea: a new VSPipe option --loglevel which would filter out all log messages with lower level than the one specified. With that option as --loglevel mtCritical the optimizer would only receive real error messages. Probably easier to implement?

Just ignore stderr. If there's a serious error vspipe exits with a non-zero return code. Check for that instead.

[zorr]

Just ignore stderr. If there's a serious error vspipe exits with a non-zero return code. Check for that instead.

What kind of things count as serious error?

The error feedback is important because when the optimizer tries all kinds of parameter combinations it usually finds

combinations which the plugin author considers invalid and the plugin displays an error, usually with a helpful description
combinations which the plugin author considers invalid but which are not documented (no way to know until someone tries them)
combinations which the plugin author considers valid but which trigger a bug in the plugin and it crashes


Also the script could have a syntax error or a runtime error not related to plugins.

I would like to give feedback to the user in all of these cases. Are they all "serious errors" which return non-zero value?

[zorr]

Just ignore stderr. If there's a serious error vspipe exits with a non-zero return code. Check for that instead.

Never mind that previous question, checking the return code seems to work beautifully. :thanks:

The Avisynth path doesn't wait for the process to finish (which is needed for the return code) and I found that be somewhat faster, I will do some more testing to find out if it's also the case with VSPipe.