<div dir="ltr"><div dir="ltr">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.<br></div><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le lun. 14 mars 2022 à 16:13, Dan Egnor <<a href="mailto:egnor@ofb.net">egnor@ofb.net</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 14, 2022, 2:35 AM Algarve Branqueira <<a href="mailto:branqueira@gmail.com" target="_blank">branqueira@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">So my question is this,<br><br>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?<br>I hope I explained my problem well.<br></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">Your options as I know them (unless there's some secret inside libav I don't know about):</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div></div></blockquote><div><br></div>Not necessarily, the thread id on the java side can be very important in some cases.<br><br>example :<br><br>the application connects to 10 cameras therefore 10 java threads therefore in JNI also 10 C threads.<br><br>these 10 threads can create multiple threads each for its processing.<br><br>Now for some reason we see a problem in the logs during decoding or encoding.<br>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.<br><br>In addition, with the LOG4J logger, you can for example put the loggers in DEBUG for a specific thread and the others in INFO.<br><div>If we use a global variable, we can no longer make the distinction.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="auto"></div><div dir="auto">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.</div><div dir="auto"><br></div></div></blockquote><div><br></div>I had thought about that too, if I manage to have a link with the thread creator, maybe with pthread_self(), maybe<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="auto"></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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!</div></div></blockquote><div><br></div> 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.<br><div>It could well have been the name of the java thread...</div><div><br></div><div>Thank you </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="auto"><br></div><div dir="auto">-- egnor</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"></div>
</blockquote></div></div></div>
_______________________________________________<br>
Libav-user mailing list<br>
<a href="mailto:Libav-user@ffmpeg.org" target="_blank">Libav-user@ffmpeg.org</a><br>
<a href="https://ffmpeg.org/mailman/listinfo/libav-user" rel="noreferrer" target="_blank">https://ffmpeg.org/mailman/listinfo/libav-user</a><br>
<br>
To unsubscribe, visit link above, or email<br>
<a href="mailto:libav-user-request@ffmpeg.org" target="_blank">libav-user-request@ffmpeg.org</a> with subject "unsubscribe".<br>
</blockquote></div></div>