Thank you for your answer, even if you do not give a solution, the importance is that you took the time to answer my message and just give me a reflection perhaps allows me to think of a few things.
Le lun. 14 mars 2022 à 16:13, Dan Egnor <[email protected]> a écrit : > On Mon, Mar 14, 2022, 2:35 AM Algarve Branqueira <[email protected]> > wrote: > >> So my question is this, >> >> How can I in the callback method (for me wrapper_logger) retrieve the >> "jobj" variable (make it any variable of the main method) when the decoder >> or the encoder is in another thread? >> I hope I explained my problem well. >> > > In libav as in many frameworks, logging is understood to be a global, > context free operation. Other than the implicit context of thread ID (which > as you note isn't as useful when more threads are created) there is nothing > to distinguish a log event made by one of your instances from a log event > made by another. > > Your options as I know them (unless there's some secret inside libav I > don't know about): > > 1. Yes, use globals. Maybe have one singleton call from the Java side that > sets up the logging hook, and store its env and jobj value for the logging > callback. Within Java, you'll need to figure out what to do with those > callbacks, but I don't know your requirements there. > > Not necessarily, the thread id on the java side can be very important in some cases. example : the application connects to 10 cameras therefore 10 java threads therefore in JNI also 10 C threads. these 10 threads can create multiple threads each for its processing. Now for some reason we see a problem in the logs during decoding or encoding. even if it's a thread created by the main thread of ffmpeg, it can be interesting to know what is the name of the original Java thread to go back to the right camera. In addition, with the LOG4J logger, you can for example put the loggers in DEBUG for a specific thread and the others in INFO. If we use a global variable, we can no longer make the distinction. > 2. More complicated: Try to wrap thread creation in libav (I think there's > a hook?) to copy thread local logging context into every thread. I don't > really recommend this path. > > I had thought about that too, if I manage to have a link with the thread creator, maybe with pthread_self(), maybe > 3. Also more complicated: Store various env/jobj pairs for every active > object in some global structure on the C side, and try to figure out which > one to "dispatch" to. I don't recommend this path either. > > I don't know the details of your application, but my advice would be to > understand that logging is a stream of information that comes globally > without attribution to any particular object or instance, and architect > accordingly. That's not very helpful, I'm sorry! > With "obj" that JNI offers me, it allows me to make the link between the Java thread and JNI, the obj itself is not useful for logging. It could well have been the name of the java thread... Thank you > > -- egnor > >> _______________________________________________ > Libav-user mailing list > [email protected] > https://ffmpeg.org/mailman/listinfo/libav-user > > To unsubscribe, visit link above, or email > [email protected] with subject "unsubscribe". >
_______________________________________________ Libav-user mailing list [email protected] https://ffmpeg.org/mailman/listinfo/libav-user To unsubscribe, visit link above, or email [email protected] with subject "unsubscribe".
