[libav-devel] [RFC 0/6] TLS/SSL support

Martin Storsjö martin at martin.st
Tue Nov 1 10:01:08 CET 2011

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

More information about the libav-devel mailing list