On Mon, 31 Oct 2011, Luca Barbato wrote:
On 10/31/11 6:28 AM, Martin Storsjö wrote:
Hi,
This is a patchset I wrote some time ago but haven't submitted
until now.
A possibility is to:
- leverage our thread manager, since avf needs avc no matter what, and
use those call.
This might be doable, but feels kinda messy - it'd need quite tight
coupling between the TLS library code and the lock manager. (Currently I
just use the lavc lock manager for making sure the library initialization
is threadsafe within lavf.)
- provide an avoption to set or not the threading callbacks
We don't support passing avoptions to protocols from avformat_open_inpu()
yet, afaik.
- provide explicit network setup calls to avoid lazy loading/eager
unloading.
This way advanced users have a way to override what we provide by default.
The last option might perhaps be the best choice though. If we add
something like avformat_network_init()/_deinit(), an application that
either wants to avoid extra initializations/deinitializations for
each request, or wants to have control over thread callbacks, can call
this optional avformat network setup function. (We can check whether the
callbacks are set already, if they are, we don't set any of our own.)
If we add such a setup function, we perhaps even could make it mandatory
after some major bump, which would reduce the amount of mess around
ff_network_init() and such which is implicitly called at all kinds of
places at the moment.
Also, the case of custom callbacks seems to be more and more going away,
with both gnutls setting it automatically nowadays, and I also found this
in the gcrypt manual: "Note that future versions of Libgcrypt will drop
this flexible thread support and instead only support the platforms
standard thread implementation."
So I guess the best way forward is, then:
- Set pthread/win32 mutex callbacks automatically, unless other callbacks
are already set
- Add now-optional, later-perhaps-mandatory
avformat_network_init()/_deinit() functions, that can reduce the
overhead of this kind of initialization, and reduce the mess around
implicit initialization in libavformat later if made mandatory.
That seems straightforward enough for me, without too big compromises in
any area.
// Martin
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
