[Libav-user] variable scope into callback av_log_set_callback and multi threading

[Algarve Branqueira]

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 <egnor at ofb.net> a écrit :

> On Mon, Mar 14, 2022, 2:35 AM Algarve Branqueira <branqueira at gmail.com>
> 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
> Libav-user at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/libav-user
>
> To unsubscribe, visit link above, or email
> libav-user-request at ffmpeg.org with subject "unsubscribe".
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://ffmpeg.org/pipermail/libav-user/attachments/20220314/a2fb0e33/attachment.htm>