[xiph-rtp] Difficulties with several RTP streams for a Vorbis stream.

[Aaron Colwell]

On Sun, Oct 31, 2004 at 11:27:49PM +0100, Ram?n Garc?a wrote:
> > Is it less "surprising" for the media framework to read the setup header
> > from an http url?"
> That is always posible. The depacketizer can create a socket and open
> a connection to a server on its own.
> 
> >  I checked the Java Media Framework and it seems as if
> > the depacketizer has no access at all to the session descriptor, so it
> > wouldn't be able to decode the stream at all if not all necessary info
> >  is sent in-band.
> 
> That would make it imposible to have any format specific  data in the 
> session descriptor. I will check.
>  
> Sending the codebook data in the RTP data stream is scalable. As it is
> sent once to all clients, thus it is not degraded with the number of
> clients. It is correct that it is sent to more clients than necessary,
> but they way multicasting works that does not degrade server
> performance, it is the job of routers to replicate packets until they
> reach clients. The issue of redundant sending to all clients also
> happens with your method, unless a different IP multicast address is
> used for the RTP session that sends codebooks, which would be too much
> administrative burden (just acquire a new multicast IP address to
> support Vorbis). If the same IP address is used for both sessions, the
> packets with the codebooks would be send to all clients, as all of
> them are suscribed to the IP multicast address (although the packets
> would be thrown away by the operating system of the clients as no
> process is listening that port).

If the client requests the codebook to be sent over the multicast channel, then
this mechanism is not scalable. Think of the case where clients join the
broadcast at different times. If they send a request when they join you could
be spamming tons of connected clients with codebooks they already have.
The server could filter these requests out and enforce a codebook transmission
interval, but that is basically the same as just having the server periodically
transmit the codebook. If you still wanted it to be request based in some way,
you could just monitor the RTCP channel for RR reports from client that you
have not seen before. Once the server has seen enough RRs from new clients it
can opt to send the codebook again.

Aaron

> 
> Ramon
> _______________________________________________
> xiph-rtp mailing list
> xiph-rtp at xiph.org
> http://lists.xiph.org/mailman/listinfo/xiph-rtp
>