[vlc-devel] Problem using libvlc

[Pierre d'Herbemont]

On Fri, May 22, 2009 at 3:39 PM, Laurent Aimar <fenrir at via.ecp.fr> wrote:
> Hi,
>
> On Fri, May 22, 2009, Pierre d'Herbemont wrote:
>> >> I may end up fixing it. There are some vlc core limitation that needs
>> >> to be addressed first.
>> >  What are the limitations you have in mind ?
>>
>> Variables callback can't be removed from within a callback. This is
>> doable but requires some careful work. (We have that for the events.c
>> stuff - which has its own limitation though)
>  At least for input_thread_t you MUST have a thread dedicated to manage
> it, so it should not be a problem. (if you don't you will end up having
> a lot of deadlock problems and you will perturb too much the input if
> any time is used inside the callback for intf-event).

Well, I see what you mean, but what is the rationale behind this?

So the inputthread would be not re-entrant. Not being reentrant here,
basically prevents fine grained operation that a client may want to
do, such as pausing as soon as first frame get received (just to be
more specific... I should probably figure out a better use case :) ).

In the end, it is a nice idea to have the input thread re-entrant. It
allows to do cool thing from a client side, and saves an event
dispatcher thread that the client might not require. And this removes
all the glue code needed for synchronization and stuff.

Though, I think that the input_thread_t code is reentrant on most event already.

> (But there is currently a problem bypassing the PL, all playlist parsing
> demuxer/access use playlist_t directly :(

I am not sure about that, I removed most of the dependency from
SD/playlist demuxer. They should be using an input_item_t interface.
That allows you to get the media contained in a playlist file with
libvlc, or the SD list, without using the playlist.

Pierre.