Hi there, for a streaming application developed for a project at the Society for Arts and Technology Montreal, Canada, we would need to know the exact delay of our ogg/vorbis streams. It seems there are several factors that make up the total delay I get. Is there a way to find out how large the delay introduced by the encoder and decoder is? Or in other words, how many unprocessed samples the enocder / decoder has stored internally? One idea that came up to determine latency was to add timestamping information, but since I would have to add this data into the ogg stream it would not go through the encoder and decoder and thus have a different latency than audio signals. Has anybody tried compressing SMPTE time code tracks with ogg/vorbis? Since this is audio data it would take the same route as my audio signal and thus have the same latency. But will a timecode signal survive the compression? And what about channel separation? Since we're trying to get the shortest latency possible another problem came up: in general it seems that the larger the bitrate the lower the latency (i.e. the decoder starts earlier to output some audio data). However, due to the VBR encoding even high bitrate streams might have low bitrates when there is only silence to be transmitted. Is there a way to completely disable VBR encoding in vorbis and use CBR instead? I've tried to flush the encoder like mad to get some ogg pages out of it but this still doesn't raise the bitrate to a signifficant value. Any help is very appreciated! best, Olaf <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.
On Fri, 9 Jan 2004, Olaf Matthes wrote:> Hi there, ><eye glaze inducing deletia>> Is there a > way to completely disable VBR encoding in vorbis and use CBR instead? > I've tried to flush the encoder like mad to get some ogg pages out of it > but this still doesn't raise the bitrate to a signifficant value.CVS libvorbis/oggenc is capable of doing Real CBR (tm), but you'd be beta-testing it for quality and other things.> Any help is very appreciated! > > best, > Olaf--- >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 Friday 09 January 2004 23:08, Olaf Matthes wrote:> Hi there, > > for a streaming application developed for a project at the Society for > Arts and Technology Montreal, Canada, we would need to know the exact > delay of our ogg/vorbis streams.[etc]> Since we're trying to get the shortest latency possible another problem > came up: in general it seems that the larger the bitrate the lower the > latency (i.e. the decoder starts earlier to output some audio data).The short answer is that vorbis isn't designed for low latency applications. This usually isn't a problem for net streaming except for special cases like voice over IP, in which case you'd probably want to look at speex. The long answer is that it depends on how low you need the latency to be. What's the application you had in mind? John --- >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 Friday 09 January 2004 21:08, Olaf Matthes wrote:> Hi there, > > for a streaming application developed for a project at the Society for > Arts and Technology Montreal, Canada, we would need to know the exact > delay of our ogg/vorbis streams. > > It seems there are several factors that make up the total delay I get. > Is there a way to find out how large the delay introduced by the encoder > and decoder is? Or in other words, how many unprocessed samples the > enocder / decoder has stored internally?This is pretty easy to do. Just hook up an encoder to a decoder, and measure how many samples you've put in before you start getting samples out. Note that for low-latency, the ogg layer is going to be causing you lots of problems - vorbis itself doesn't have particularly high latency, but because of the multiple vorbis packets per ogg page, the latency gets pretty high. Mike --- >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.
> From: Segher Boessenkool [mailto:segher@kernel.crashing.org] > Sent: 12 January 2004 23:39 > To: vorbis-dev@xiph.org > Subject: Re: [vorbis-dev] timestamping / latency > > On 12-jan-04, at 2:51, Michael Smith wrote: > > Note that for low-latency, the ogg layer is going to be causing you > > lots of > > problems - vorbis itself doesn't have particularly high > latency, but > > because > > of the multiple vorbis packets per ogg page, the latency > gets pretty > > high. > > Vorbis itself has a latency of just one window size (which is > max. 2048 > with current libvorbis encoders, i.e. about 50ms with normal sample > rates), > although the libvorbis implementation of the decoder (and > especially the > encoder) make for larger latencies. > > This still isn't worse than any of the other natural audio, good > compression, codecs. > > But yeah, Ogg framing amplifies the latency a lot. If that's > a problem for > your specialized application, nothing forces you to use Ogg > -- just send the Vorbis packets with some other framing method. > > SegherYou could still use Ogg if you force a page out for each encoded packet. That means you only have one packet per page, so the framing overhead will be a lot higher (about 5-10%), but it will work without modifying the decoder. - John Ripley. --- >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.
> -----Original Message----- > From: Olaf Matthes [mailto:olaf.matthes@gmx.de] > Sent: 13 January 2004 14:30 > To: vorbis-dev@xiph.org > Subject: Re: [vorbis-dev] timestamping / latency > > John Ripley wrote: > > >You could still use Ogg if you force a page out for each > encoded packet. > >That means you only have one packet per page, so the framing > overhead will > >be a lot higher (about 5-10%), but it will work without modifying the > >decoder. > > > Thanks for that, but just to make shure I got it right: > > If ogg_stream_pageout() returns 0 I call ogg_stream_flush() and then > ogg_stream_pageout() again to obtain the page that has been > created on > flushing? Or does ogg_stream_flush() by itself give me the page and I > don't have to call ogg_stream_pageout() afterwards?Have a look at how the comment and codebook packets are flushed out as a single page in examples/encoder_example.c. It looks like you call ogg_stream_flush() and write out bytes, until it returns 0. You probably want to replace the ogg_stream_pageout() in the encoding loop with an ogg_stream_flush(). Presumably ogg_stream_pageout() returns 0 until a page is completely filled, whereas ogg_stream_flush() ensures the page goes out even though it's not full. - John Ripley. --- >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.