[vlc-devel] [PATCH 0/2] Add avio url output support (for rtmp)

Keary Griffin keary.griffin at unwiredappeal.com
Tue Oct 4 17:17:32 CEST 2011

Let me start by saying I'm not really advocating one way or the other 
for this patch.  I don't need it for my particular use case :-)  I just 
thought with the change to allow using avio for output as well as input, 
it would be nice (if possible) to allow it to be used simultaneously, 
and this was the best I could come up with.

Comments below.

On 10/4/2011 10:23 AM, Rémi Denis-Courmont wrote:
> On Mon, 03 Oct 2011 15:32:52 -0400, Keary Griffin
> <keary.griffin at unwiredappeal.com>  wrote:
>>> In fact, I guess TLS could still fail if input-slave
>>> is in use; it looks to me like VLC runs all inputs in the same thread.
>> I don't think this should be an issue since the avio module should be
>> calling PrepareAvioCall with the correct (currently active) vlc access
>> object before entering any libavio calls, thus setting the thread local
>> storage for that thread to the right value (and that same thread won't
>> have a chance to make another avio call until that call returns...)
> I don't see at all how that solves the problem of two concurrent avio
> inputs in the same thread.
> You would have to reset the TLS at every Read|Seek|Control entry.
And this was indeed what the patch was supposed to do (but maybe I'm 
missing something)--  It adds a call to PrepareAvioCall( access_object ) 
before every call to an avio url_xxxx(...) function.  PrepareAvioCall  
calls vlc_threadvar_set to set the TLS for the callback.

>>> Also, what if any libavio back-end becomes multi-thread?
>> This would indeed be an issue, but only if it makes the callback from a
>> different thread, which I would hope would be a big enough "change" that
>> they would think twice before making a change like that(?)
>> Another option is to just not use the callback at all (so there would be
>> no way to cancel an avio call), but I'm not sure what the repercussions
>> would be.
> I don't understand how it's supposed to work right now already. How does
> avio know _when_ to check the callback? It can't be busy looping.
A quick look at libavformat, and it looks like it uses loops with 
smallish timeouts to check the callback (I didn't look at all the cases, 
just a few of them).


More information about the vlc-devel mailing list