Hi. I got bored of writing papers last week so I decided to write an app for sending and receiving multicast vorbis streams over RTP. A first version is available here: http://www.cdt.luth.se/~rolle/vorbis/ (I use the JOrbis decoder, so you need Java 2 with Javasound, e.g. JDK1.3. Since the decoding is done in Java, you probably need at least 300-350 MHz. Works with the IBM JDK1.3 on Linux on a K6-2 350) Is there anyone else that is working on RTP and vorbis? The payload format need to be a bit more complex than just putting Ogg packets inside RTP since a client can join a multicast stream at any time and need to get the first three packets to initialize the decoder (the info, comment and codebook packets). I currently resend these three packets continously, adding about 5 kbit/s to the bandwidth. (Can be reduced, but then the client have to wait longer for all packets, now it is less than 1 second.) The codebook and info packets can also change when a new file is transmitted. //Roland Parviainen --- >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-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.
Roland Parviainen wrote:> > Hi. > > I got bored of writing papers last week so I decided to write an app for > sending and receiving multicast vorbis streams over RTP. A first version > is available here: > > http://www.cdt.luth.se/~rolle/vorbis/ > > (I use the JOrbis decoder, so you need Java 2 with Javasound, e.g. > JDK1.3. Since the decoding is done in Java, you probably need at least > 300-350 MHz. Works with the IBM JDK1.3 on Linux on a K6-2 350) > > Is there anyone else that is working on RTP and vorbis? The payload > format need to be a bit more complex than just putting Ogg packets > inside RTP since a client can join a multicast stream at any time and > need to get the first three packets to initialize the decoder (the info, > comment and codebook packets). I currently resend these three packets > continously, adding about 5 kbit/s to the bandwidth. (Can be reduced, > but then the client have to wait longer for all packets, now it is less > than 1 second.) The codebook and info packets can also change when a new > file is transmitted. > > //Roland Parviainen >Dear Roland; I am working on this off and on in the context of the free amp player. We hope to begin multicast streaming of ogg/vorbis early in the new year. There needs to be a RFC written for the ogg/vorbis data payload format so it can become a RTP type. I was hoping to get this done in time of the next IETF in San Diego, but it is too late for that. I definitely want to do this in time for the Spring 2001 IETF in Minneapolis in March. With multicast streaming, packets can be dropped at any time, so it is useful to keep each packet as autonomous as possible (each packet should ideally be an application data unit, or ADU, as Ross Finlayson did for the MP3 format - see http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-mp3-04.txt ). In your RTP, do you send out the comments and codebook as a separate packet, or as part of a data packet ? Can these change in mid-stream ? It would also be nice if each packet was kept under 576 bytes (or at least 1500 bytes) in size, including the IP/UDP/RTP headers, to avoid fragmentation. Do you worry about packet sizes in your implementation ? Regards Marshall Eubanks Multicast Technologies, Inc. 10301 Democracy Lane, Suite 201 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@on-the-i.com http://www.on-the-i.com --- >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-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.
> Is there anyone else that is working on RTP and vorbis? The payload > format need to be a bit more complex than just putting Ogg packets > inside RTP since a client can join a multicast stream at any time and > need to get the first three packets to initialize the decoder (the info, > comment and codebook packets). I currently resend these three packets > continously, adding about 5 kbit/s to the bandwidth. (Can be reduced, > but then the client have to wait longer for all packets, now it is less > than 1 second.) The codebook and info packets can also change when a new > file is transmitted.In our work here, we assumed that a new client would 'connect' to a multicast stream by first requesting the headers out of band on a TCP connection (as the headers absolutely cannot be lost anyway). It's also possible for the headers to be much larger than they are right now, although in our encoder strategy we'll always be keeping size to a minimum. Still, adding 5kbps isn't a bad number... unless you only have 28.8 to start with... Monty --- >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-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, Just to add my 0.02$: I implemented some sort of vorbis RTP support for icecast2, based on the implementation I did for mpeg support for icecast1 some time ago, it is attached. It is very basic: it doesn't support grouping pages, is not much easily configurable at all (I daren't try to modify xml parsing...), but *it works* with a patched version of xmms, based on the mpeg support available as patch on the net. The conditions were we use it here at school is just a very local area network, with almost no lost at all. Getting the CodeBook is indeed much an issue. The patch I adapted for vorbis just waits for a bos-marked page, and uses it. In our conditions, this is not that much a trouble, sinc bos-marked pages are sent at each song change of our radio. Recovering frame drops is quite buggy as well: they are merely dropped, while inserting some fake "mute" page lasting for the same time should be done instead, getting much better synchronization. Regards, Samuel -------------- next part -------------- A non-text attachment was scrubbed... Name: icecast2-rtp-diff.gz Type: application/x-gunzip Size: 1908 bytes Desc: icecast2-rtp-diff.gz Url : http://lists.xiph.org/pipermail/vorbis-dev/attachments/20040530/fc418c41/icecast2-rtp-diff-0001.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: xmms-vorbis-rtp.diff.gz Type: application/x-gunzip Size: 9481 bytes Desc: xmms-vorbis-rtp.diff.gz Url : http://lists.xiph.org/pipermail/vorbis-dev/attachments/20040530/fc418c41/xmms-vorbis-rtp.diff-0001.bin
Hi all! Can any of you tell me which is the way to mark the last packet of a stream, in the same way e_o_s do it for Ogg transport? Thank you very much! V?ctor. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/vorbis-dev/attachments/20040905/370507c1/attachment.html