Diederick C. Niehorster (12021-06-12): > As an API user, my main benefit would be to keep log for separate jobs > going on in parallel separate. My application allows capturing data > from one or more high-bandwidth machine vision cameras and storing > them to file with ffmpeg. This often means multiple encodes are > occurring in parallel, either because using multiple cameras or > because a previous job didn't finish yet before the next one starts > (these cameras generate so much data the encoder often can't quite > keep up). I'd like each task to have its own log, not all of it mashed > together into one.
Thanks for the feedback. > What is the intention here, have one context per library (so my > filters have a different log_ctx than my muxer)? I think it would make > most sense to allow user let them all use the same context, or not, > depending on their use case (e.g. may want one specific filter to use > a different log context as you need its output, or want it to use > different memory allocation function for some reason)? In any case, i You raise an interesting question. For things like lists of registered components, it makes sense to use a single instance for a large part of the program, a whole decode-filter-encode system maybe. But indeed, for logging, it makes sense to have a different context for each active component. I suspect here, log is more the exception than the norm. And if we implement error messages to replace logging, the need for separate logging callbacks would be significantly lowered. > guess a bunch of different functions, like > avformat_alloc_output_context2, avcodec_alloc_context3, > avfilter_inout_alloc, avfilter_graph_alloc, would each need an extra > input argument allowing user to set context to use. Yes, this is what I am thinking about. On the other hand, for functions that already have an AVSomethingContext as argument, no change in prototype is necessary. > Further, AVLibrary or what it'll be called user have a user data > pointer. I would like use the log callback from C++ classes, and need > the user data to point to a specific class instance. This also means > that av_log should provide the relevant context when calling the > callback. This, for me, goes without saying: every time there's a user-provided callback, there should be user-provided data too. Regards, -- Nicolas George
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
