similar to: q re vorbis packetizing in ogg stream

Hi, I am not sure if this is the right mailinglist (since I have an ogg problem not a vorbis)..... I am looking for some pointers on how to packetize an ogg stream. My idea is to use udp packets for transport, so I would need a way that would minimalize the impact of lost packets. Are there any code examples out there for this? Thanks, Jeroen p.s. Please cc me, I am not subscribed to this

Hi, I am not sure if this is the right mailinglist (since I have an ogg problem not a vorbis)..... I am looking for some pointers on how to packetize an ogg stream. My idea is to use udp packets for transport, so I would need a way that would minimalize the impact of lost packets. Are there any code examples out there for this? Thanks, Jeroen p.s. Please cc me, I am not subscribed to this

This is the first draft of the audio/vorbis media registration form to be handled to the IANA. PLEASE comment extensively, even minor spelling mistakes etc are to be stamped out of this I hope. A media type for application/ogg (or should it be application/oggsquish?) will be created separately. I would be very happy if someone could supply the 4-letter filetype code used by MacIntosh .ogg files.

Monty Montgomery wrote: > Yes. Without the first three packets (which hold all the codec > settings and all the instruction how to handle the subsequent packets) > the rest of the stream is gibberish. Vorbis can't even unpack the > bits without the codebooks packed into the third header. Curiosity man here. Is there a finite set of predetermined codebooks or is the codebook

Mandag, 2 juni 2003, skrev du: >On Mon, 02 Jun 2003 21:22, Vitaly Nechyos wrote: >This is what people usually want when they say 'normalization'. AFAIK, you >can't easily tinker with the vorbis frames to add a scale factor in the same >way you can with MP3, but I could be wrong. I could be wrong too, but if I haven't overseen anything, it should be possible to

Monty Montgomery wrote, on 7/14/2009 1:44 AM: > On Tue, Jul 14, 2009 at 1:41 AM, Erik de Castro > Lopo<mle+la at mega-nerd.com> wrote: >> Monty Montgomery wrote: >> >>> Yes. Without the first three packets (which hold all the codec >>> settings and all the instruction how to handle the subsequent packets) >>> the rest of the stream is gibberish.

Conrad Parker wrote, on 7/8/2009 8:20 PM: >> Anything I can do to keep this on radar? I'm not sure if it is really a bug >> -- perhaps at least a wishlist request. Will putting it in a tracker >> somewhere help? > yes, a tracker would help. I'm somewhat confused about the right place to file this--can you suggest? There seem to be few separate projects it might

The codebase sets up ogg_int32_t, etc, but then uses long directly in several structures. Unfortunately for me longs are 64 bits on my platform, not 32, and I end up getting hammered by unnecessary software math routine calls. Should I be able to just search/replace 'long' with 'ogg_int32_t' in the code or would that cause more problems than it fixes? -Dave --- >8 ---- List

Hi all, Apologies in advance, this email is quite long. I've prepared an updated Vorbis RTP Internet Draft, which is a continuation of draft-moffitt-vorbis-rtp-00.txt which can be found below. If this new draft gets the ok I'd like to submit this to the AVT WG later this week. There are a number of changes over the original I-D, notably the changing of the M bit function in the RTP

Hi I have gone through the document available in the net regarding the Vorbis encoder /Decoder. Based on that i have prepared a understanding document on the encoder/decoder block. I would like to know whether my understanding of the coder is OK. If there are any other additional block /information pl. provide me with the same. Thanks and regards S.Padmashri <HR NOSHADE> <UL>

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

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

Go monty! jack. ----- To: cvs@xiph.org Subject: [xiph-cvs] cvs commit: vorbis/vq huffbuild.c latticetune.c make_residue_books.pl Date: Sun, 3 Jun 2001 22:50:13 -0700 (PDT) From: xiphmont@xiph.org (Monty) Precedence: bulk Reply-To: cvs@xiph.org xiphmont 01/06/03 22:50:12 Modified: lib codebook.c codebook.h floor0.c mapping0.c os.h res0.c vq

Hi, From the vorbis decoder specification, it is clear that the decoder needs to have all the codebooks before decoding can actually begin. I will appreciate if someone can clear the following questions: 1. I guess the codebooks are derived from the actual input data. Probably the encoder may be making two passes through the input. The first pass finds out the frequency of different symbols

I have been researching using vorbis for streaming (music and sound effects) in our xbox game. As it turns out every stream takes about 300 kb when decoding from it. This is pretty ok, if I only had to deal with one stream. Unfortunately I have to be able to handle more streams simultaneously, and 400 kb would be ideal for all stream to take as a maximum. Is it possible to share some of the

ogg.k.ogg.k at googlemail.com wrote, on 7/14/2009 7:16 AM: >> easy to replace. The second packet is the metadata, which we can lose. >> It's just the third packet that needs to be reconstructed. After that, >> you could start at any packet division in the rest of the file and it >> would play fine? So this generic restore tool that I'm positing would >> just

Hi John A trimer/vcut type application is possible but unfortunately not a fade/normaliser. Not without decoding/encoding. I asked about this a couple of years ago. Unlike MP3, the Ogg Vorbis format doesn't store a global gain setting per frame. I have often downloaded MP3 files from mp3.com and other sources for broadcasting, and with the type of music I need, it is often not normalised

Hi all, I'm in the final stages of putting a new Vorbis RTP draft together, the new sections are below. There are a number of open questions: 1.) At present there is a 16 bit length field for the codebooks. As they are spec'd as being unbound in length, but typically around 15K, are there situations where they may be greater than 64KB? The size limit can be extended to 2MB as there

As an optimisation to reading Ogg encapsulated files, I've been thinking about a strategy of reading entire packets out of the stream, and sending them to the decoder. This has the advantages that: * The packet is just a linear array of bits in memory, with length known in advance. * The routine which gets bits out of the packet is then trivial and possibly inlined. * There is no possibility

Hello, Vorbis uses codebooks, for example to do vectorquantization and huffman-encoding. My question is - are all these codebook dynamicly generated ("trained") or are there also static codebooks used ? If yes, what specific tasks are these 2 types used for, during encoding ? Thanks Stoffke <p>--- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project