[vlc-devel] Re: vlc: svn commit r10012 (fenrir)
finlayson at live.com
Fri Feb 25 23:59:44 CET 2005
> > One comment, though: As you note in your comments, your new
> > function duplicates a *lot* of code from "Open()". It would be better to
> > remove this duplication, by having just a single 'RTSP open' routine that
> > requests either UDP or TCP streaming, based on a parameter.
> I've done it this way to be able to test changes faster (and to avoid
>remove/add of all ES), but yes it should be reworked :)
> I thought that I just need to issue a setup with new parameters and
No - no RTSP server will let you switch to streaming over TCP just by
sending another "SETUP". Instead, you need to "TEARDOWN" the existing
connection, then do "DESCRIBE", "SETUP", "PLAY" all over again.
As far as I can tell, your new "RollOverTCP()" function is correct. Thanks
again for doing this. My only comment was that because it duplicates a lot
of code from "Open()", the code from these two functions should - at some
point - be folded together into a single, common routine.
> (the server was openRtsp from live.com),
FYI, "openRTSP" is a RTSP client, not a server.
>Oh btw, is there any way we can know if the streaming is using multicast
>or unicast ?
I think the following should work:
(This should be called *after* the RTSP "SETUP" has been done.)
> The problem is that on large multicast network, the time you
>start receiving data can be higher than 0.9s (people reported 10s as common).
> (I would like to increase the timeout for multicast).
In fact, for multicast streams, it's unlikely that - if no multicast data
is received - that a new attempt to stream from the same URL using
RTP-over-TCP will work (because TCP streams are, by definition,
unicast). I suppose there's no harm in trying, though...
This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://developers.videolan.org/lists.html
More information about the vlc-devel