[vlc-devel] Re: vlc: svn commit r10012 (fenrir)

Ross Finlayson finlayson at live.com
Fri Feb 25 23:59:44 CET 2005


> > One comment, though: As you note in your comments, your new 
> "RollOverTCP()"
> > 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
>that's all.

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:
         IsMulticastAddress(sub->connectionEndpointAddress())
(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...


	Ross Finlayson
	LIVE.COM
	<http://www.live.com/>

-- 
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 mailing list