Hello.. I've searching the mailing lists archives for udp streaming, but i only found some references to using rtp, but it doesnt answer all my questions.., I'm trying to implement a vorbis client/server for doing streaming over udp. Currently, using the examples in the vorbis source code I managed to make it work. (BTW, im using multicast, and it works fine). The problem is that the clients must connect from the begining of the stream, or they will not recieve the first packets and complain about the stream not being ogg/vorbis. In some post, someone told that he was re-transmitting these packets every N seconds. Is there some alternative to this ? I'd like to make a client that can connect in any time to the server. Thanks in advance for any idea. -- The names of their development products, visual this, visual that, almost makes one think that you can create software just by looking at your computer --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
eross+vorbis-dev@disc.ucn.cl wrote on 2003-09-10:> Hello.. > > I've searching the mailing lists archives for udp streaming, but i > only found some references to using rtp, but it doesnt answer all my > questions.., > > I'm trying to implement a vorbis client/server for doing streaming > over udp. Currently, using the examples in the vorbis source code I > managed to make it work. (BTW, im using multicast, and it works > fine).Are you sure you want to use UDP? It'll sort-of-work for a LAN (I guess that's how you tested it) but it will break horribly in the large. In particular, consider that the order of packets can change. I'm not sure what guarantees RTP gives but UDP sounds like really saking for trouble.> The problem is that the clients must connect from the begining of > the stream, or they will not recieve the first packets and complain > about the stream not being ogg/vorbis. >Vorbis requires the first packets, not only to nkow it's Vorbis but also because they contain a lot of info necessary for decoding the rest. All streaming schemes include some way to recieve the headers when you connect and the data from the point you connected.> In some post, someone told that he was re-transmitting these packets every > N seconds. > > Is there some alternative to this ? I'd like to make a client that can > connect in any time to the server. >If you use multicast, all clients get the same bits (or corrupted subsets of them). So you can't send the headers with UDP, excpet for the scheme of re-sending every X seconds. It has an inconveneint joining latency (unless X is very small but then you waste considerable bandwidth) but for really heavy multicast it's the most scalable way... If you don't want it, you need to have a separate (ideally - TCP) connection to the server for fetching the last headers. Then you get the data over UDP from the point when you joined. I believe it's the way Vorbis-over-RTP works, read its spec for more info.> Thanks in advance for any idea. >-- Beni Cherniavsky <cben@users.sf.net> --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
On Wed, 2003-09-10 at 12:05, eross+vorbis-dev@disc.ucn.cl wrote:> I'm trying to implement a vorbis client/server for doing streaming over > udp. Currently, using the examples in the vorbis source code I managed to > make it work. (BTW, im using multicast, and it works fine). The problem is > that the clients must connect from the begining of the stream, or they > will not recieve the first packets and complain about the stream not being > ogg/vorbis. > > In some post, someone told that he was re-transmitting these packets every > N seconds. > > Is there some alternative to this ? I'd like to make a client that can > connect in any time to the server.Another idea that has been mentioned is transmitting the three header packets via a reliable TCP channel separate from the UDP channel. It's added complexity, but one possible solution. (Such a channel might also be handy if you want information to come back from the clients.) --- Stan Seibert <p>--- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
Hi all, why not use UDP? You can easily find the same works-for-lan arguments for TCP considering the possible latency hazards commonly encountered e.g. in http streams. That should not be the point. The point is, if you really want to transmit data via UDP, you need to take care of 2 things: - UDP can transmit packets arbitrary times, ranging from 0(loss) to any other times. It would be "legal" to receive the same packet twice. And it happens. - Jitter happens, of course, but it can also affect the order of packets. So the only way to stream via UDP ist number the packets, best if you could also apply a Timestamp. The Method is called RTP, whatever you'll try will naturally look a lot like RTP. In case of packet loss (and e.g. Multicast transport) you will have to decide what to do. You have two major possibilities here: - server-side loss control - client-side loss control I prefer client-side control, as server-side control ends up in user-space programming of TCP-like algorithms, I'd prefer to leave this to the kernel. Client-side retransmission can be based on yet other possibilities, e.g.: - Forward error correction (FEC) - retransmission "on-demand" Shortly: if you are streaming into unknown territory, where you can expect great packet latency, use FEC mechanisms if you can spare some bandwidth. It will enable the client to react on packet loss on the rendundancy-encoded data he got from the server, reconstructing the lost packet if he can. Just in case you won't have the bandwidth and/or your transmission latency is very low (intranet), you could try to let the client request a retransmission of data, I'd rather not do it, but it could have some advantages. You should also check out google for links on "reliable Multicast" etc. there are settled methods to these things. Good luck, Hannes // // we apologize for the inconvenience // // Hannes Guddat // Fraunhofer IGD // A9 - Communication and Cooperation // Rundeturmstrasse 6 // 64283 Darmstadt // // WAM! internet radio - http://www.igd.fhg.de/~wam // // Tel.: +49 6151 155-217 // Fax.: +49 6151 155-559 // <p>> -----Original Message-----> From: owner-vorbis-dev@xiph.org [mailto:owner-vorbis-dev@xiph.org]On > Behalf Of eross+vorbis-dev@disc.ucn.cl > Sent: Mittwoch, 10. September 2003 19:05 > To: vorbis-dev@xiph.org > Subject: [vorbis-dev] UDP streaming vorbis > > > Hello.. > > I've searching the mailing lists archives for udp streaming, > but i only > found some references to using rtp, but it doesnt answer all my > questions.., > > I'm trying to implement a vorbis client/server for doing > streaming over > udp. Currently, using the examples in the vorbis source code > I managed to > make it work. (BTW, im using multicast, and it works fine). > The problem is > that the clients must connect from the begining of the > stream, or they > will not recieve the first packets and complain about the > stream not being > ogg/vorbis. > > In some post, someone told that he was re-transmitting these > packets every > N seconds. > > Is there some alternative to this ? I'd like to make a client > that can > connect in any time to the server. > > Thanks in advance for any idea. > > -- > The names of their development products, visual this, visual > that, almost > makes one think that you can create software just by looking > at your computer > > --- >8 ---- > List archives: http://www.xiph.org/archives/ > Ogg project homepage: http://www.xiph.org/ogg/ > To unsubscribe from this list, send a message to > 'vorbis-dev-request@xiph.org' > containing only the word 'unsubscribe' in the body. No > subject is needed. > Unsubscribe messages sent to the list will be ignored/filtered. ><p>--- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.