[vorbis-dev] UDP streaming vorbis
Hannes Guddat
hannes.guddat at igd.fhg.de
Thu Sep 11 02:50:57 PDT 2003
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 at xiph.org [mailto:owner-vorbis-dev at xiph.org]On
> Behalf Of eross+vorbis-dev at disc.ucn.cl
> Sent: Mittwoch, 10. September 2003 19:05
> To: vorbis-dev at 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 at 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 at xiph.org'
containing only the word 'unsubscribe' in the body. No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.
More information about the Vorbis-dev
mailing list