asticode/go-astiav

Scoped logging helper functions

Closed this issue · 2 comments

I'd like to be able to capture the logs from a specific block of go-astiav/ffmpeg code and be able to correlate a specific code block with specific log output.

I don't think doing this is possible in a perfect way, but I'm still pretty new to FFmpeg's c api and wanted to ask to make sure I'm not missing a better way to accomplish this task.

I'm picturing an api in go-astiav that looks sort of like

astiav.WithScopedLogger(myLogCallback, func() {
  // lots of go-astiav/ffmpeg code in here that has the logger overwritten/scoped somehow into this calling goroutine's instance of myLogCallback
})

I'm guessing this would have to set the ffmpeg logger to a threadsafe c dispatching function that can connect back to goroutine IDs/scopes somehow - not exactly sure of specifics here and I'm not exactly sure how this should best be implemented though.

Happy to contribute code/testing help here if I can, been having a great time working with astiav so far.

First off thanks for the kind words ❤️

The way ffmpeg logging works, you won't be able to correlate logs to a block of code directly. You will however be able to correlate them to certain objects, and if those objects are specific to your block of code, you will be able to correlate logs to your block of code indirectly.

The ffmpeg log callback is global therefore you can only have one. Its signature is func(c Classer, l LogLevel, fmt, msg string) and what is the most important for you is the first argument c Classer. A Classer is an object with a method Class() *Class. Objects implementing this interface are for instance CodecContext or FormatContext.

Therefore if in your block of code you create such objects, you can save their reference and if in the log callback you get them in the Classer argument, then you know this log belongs to your block of code.

You will however also get logs without a classer (which can be nil in the log callback) and won't be able to determine whether it belongs to your block of code.

Does that answer your question?

Yeah, it definitely does! I think I should be able to get that to work. Thanks for the info!

I think there's a mechanism to get this to work more cleanly in the future (lots of user-transparent wrapping of this functionality could eventually make the API I'm looking for).

Are you interested in proposals/code that provides non 1-1 ffmpeg api functionality, but creates a more general user-friendly api?