Hi, While building an ogg-vorbis stream encoder, I encountered some problems with silence in the audiostream. The bitrate drops to almost zero, and pages going out less then ones a minute what makes the stream to stop / buffer. In earlier postings I read that I shout use ogg_stream_flush as an alternative to ogg_stream_pageout, in case of silence. My question is this; Is there any reason for not using ogg_stream_flush all the time. So what are the advantages of ogg_stream_pageout? Regards, Joost Pennings. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/vorbis-dev/attachments/20060221/ae44e827/attachment.htm
On 2/21/06, Joost Pennings <joostpen@zonnet.nl> wrote:> Hi, > > While building an ogg-vorbis stream encoder, I encountered some problems > with silence in the audiostream. > > The bitrate drops to almost zero, and pages going out less then ones a > minute what makes the stream to stop / buffer. > > In earlier postings I read that I shout use ogg_stream_flush as an > alternative to ogg_stream_pageout, in case of silence. > > My question is this; Is there any reason for not using ogg_stream_flush all > the time. > > So what are the advantages of ogg_stream_pageout?It's a very bad idea to always use ogg_stream_flush - that will mean you're outputting a full ogg page for every vorbis packet. The bitrate overhead for doing this will be quite large on normal input. Generally, you want to issue a flush if you haven't output a page with more than (some threshold) seconds of data - commonly, you might use half a second, or one second. Mike
On Tue, Feb 21, 2006 at 10:20:12AM +0100, Joost Pennings wrote:> While building an ogg-vorbis stream encoder, I encountered some problems > with silence in the audiostream. > > The bitrate drops to almost zero, and pages going out less then ones a > minute what makes the stream to stop / buffer.You are correct. I intend to add an API call that will direct libogg to flush either at some specified page size, or after a given period of time to make the automagic behavior more flexible.> In earlier postings I read that I shout use ogg_stream_flush as an > alternative to ogg_stream_pageout, in case of silence. > > My question is this; Is there any reason for not using ogg_stream_flush all > the time. > > So what are the advantages of ogg_stream_pageout?ogg_stream_pageout currently attempts to keep pages to an approximate constant size (~4kB). ogg_stream_flush will immediately flush a page, even if it contains only a single packet or fraction of a packet. Ogg pages introduce a roughly fixed overhead per page; they're 26 bytes each plus one byte per packet fragment. If each of your Vorbis packets are, say, ten bytes each, using a page per packet would nearly triple the bitrate. Flushing a page for every packet is perfectly valid; there's nothing wrong with the structure or correctness of the stream. However, you pay a bitrate premium for doing so. Monty
On Tue, Feb 21, 2006 at 10:20:12AM +0100, Joost Pennings wrote:> So what are the advantages of ogg_stream_pageout?More succinctly, ogg_stream_pageout will pack multiple ogg packets into each ogg page, and only flush after reaching a threshold size. This works well for most data, but digital silence produces much, much smaller packets than usual, and so it's easy to underflow the playback buffer if a manual flush isn't inserted. libogg doesn't do this automatically because the mapping between the granulepos field in the ogg_packet structure and real playback time belongs to a higher abstraction layer (i.e. your paging code). HTH, -r