[vlc-devel] rtsp module : vlc freeze

jboileau jboileau at gmail.com
Fri Sep 26 15:29:22 CEST 2008

Sometimes reaching for the gold, the complete solution, may seem very
difficult to achieve but a lesser fix that relieves part of the
problem may be easier and worthwhile.

As you are pointing out, the complete solution demands changes that
are probably not feasable for the VLC team right now (and maybe not
for a very long time, I assume there are much higher priorities). But
if Sébastien's small effort (sorry if I downsize your effort Sébastien
:-) ) relieves the problem in a substantial way, it seems worthwhile
to me.

In any situation its better to have a partial fix if the ultimate fix
is out of reach than no fix at all, no? Unless it generates new
problems of course.

Jacques Boileau

On Fri, Sep 26, 2008 at 9:05 AM, Rémi Denis-Courmont <rem at videolan.org> wrote:
> Le vendredi 26 septembre 2008 15:10:39 Sébastien Escudier, vous avez écrit :
>> > Since 'someday' can be a very long time, would it be possible in the
>> > interim to at least have these timeouts configurable somehow?
>> I did a quick hack in live555 library code, using a select instead of the
>> connect.
> That does not really solve the problem. select() for non-blocking connection
> is portable. I mean, it's in Win32 and POSIX. The real issue is, how do you
> interrupt live555 select() from VLC?
> As far as I can tell, live555 providing a Avahi-like thread interruption
> function, external I/O event loops binding, or network I/O callbacks are the
> only potential ways to fix this for real. Unfortunately, this would be a
> significant depart from the current API, and add quite much complexity to
> both live555 and VLC.
> --
> Rémi Denis-Courmont
> http://git.remlab.net/cgi-bin/gitweb.cgi?p=vlc-courmisch.git;a=summary
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> http://mailman.videolan.org/listinfo/vlc-devel

More information about the vlc-devel mailing list