similar to: granulepos

Hi While implementing OSS Ogg/Vorbis encoding and streaming using RTP/RTCP for both unicast and multicast, I have come across a few issues I need to clear out regarding the numbering of ogg_packets and their granulepos value. Below are the result for two different scenarios. <p>In the first scenario, ogg_packets are generated using a) vorbis_analysis_headerout() b) while

Hi, I'm wondering if the Dirac granulepos parsing in liboggz and display in the oggz tools is currently correct, as I'd like to do a release of these soon. A couple of days ago David Schleef mentioned there were some problems. David, is that currently true (ie. since David Flynn's recent updates to support Dirac), and if so could you please explain what the problems are, or point me

On 2008-11-13, Conrad Parker <conrad at metadecks.org> wrote: > I'm wondering if the Dirac granulepos parsing in liboggz and display > in the oggz tools is currently correct, as I'd like to do a release of > these soon. I believe it is -- although if correct support in the rest of the liboggz tools is required, a little more work may need to happen. > Here's some

Hi all, something which came up recently in relation to the design of Kate's granulepos was whether or not the granulepos of successive Ogg pages is allowed to be the same, ie. whether or not granulepos must be strictly increasing. As this question is more generally about Ogg granulepos, how about we answer it first and then get back to the discussion of Kate's granulepos ... Here is

2008/11/21 David Flynn <davidf+nntp at woaf.net>: > On 2008-11-21, Conrad Parker <conrad at metadecks.org> wrote: >> 2008/11/15 David Flynn <davidf+nntp at woaf.net>: >>> On 2008-11-14, Conrad Parker <conrad at metadecks.org> wrote: >>>> It seems oggz chop, merge and sort will need some attention to deal >>>> with the Dirac

2008/11/15 David Flynn <davidf+nntp at woaf.net>: > On 2008-11-14, Conrad Parker <conrad at metadecks.org> wrote: >> It seems oggz chop, merge and sort will need some attention to deal >> with the Dirac granulepos and dependency ordering, so let's leave them >> for the next release. > > ok. -- may be worth having them 'warn' if they are operating

Hi, The Ogg-Speex test file I used is CBR. I am sure of that by running oggz-dump on the file and confirming that all audio packets have 38 bytes; that means (for narrowband) a constant 15 Kbps. I wrote a very basic test program in Visual Studio 2010 that demonstrates the strange behaviour I mentioned. The output shows that the audio file has 8 pages, 6 of them

On Thu, Nov 13, 2008 at 06:06:10PM +0900, Conrad Parker wrote: > A couple of days ago David Schleef mentioned there were some problems. > David, is that currently true (ie. since David Flynn's recent updates > to support Dirac), and if so could you please explain what the > problems are, or point me to a bugtracker where they are reported. eg. I mostly meant what you apparently

Hi all, I noticed the following Subversion commit today: r6719 | xiphmont | 2004-05-18 16:04:53 +1000 (Tue, 18 May 2004) | 11 lines Updated doc to reflect current proposal... Not as much a proposal at this point actually; this is the way I'm now implementing it. Although we're still in the 'RFC'/'look for horrible lossage' stage, this is close to being

2008/11/14 David Flynn <davidf+nntp at woaf.net>: > On 2008-11-13, Conrad Parker <conrad at metadecks.org> wrote: >> I'm wondering if the Dirac granulepos parsing in liboggz and display >> in the oggz tools is currently correct, as I'd like to do a release of >> these soon. > > I believe it is -- although if correct support in the rest of the >

2008/11/26 David Flynn <davidf+nntp at woaf.net>: >>>> http://trac.annodex.net/changeset/3801 >>> >>> I'll test this shortly. > > Ok, i've tested muxing some audio and video together and that works fine. > woo. great, thanks :-) So the last remaining tool to check is oggz-chop. I at first assumed it would not work with Dirac's granulepos,

I've been implementing Ogg FLAC support in an editor I'm working on, and I must admit to being frustrated by the lack of support for the codec on the Ogg layer... and this is more than lacking granulepos. The codec's I've worked with, and my own (Writ), use Page 0 for general information about the codec. Specifically, the samplerate, bitrate, quality, number of channels, all

Hi, i just wonder if there's a cheap way of getting the number of oggVorbis pcm frames in an ogg_page, without actually decoding it? Can i use the granulepos of the page, substract the granulepos of the previous page? is this always guaranteed to work? thanks, Chris

I have the following problem. Be an encoder application (station) and a decoder application (receiver). If I feed the vorbis encoder with 'n' pcm samples in the station I want to know how many pcm samples will be decoded in the receiver if I feed the decoder with the encoded output. The ogg_page_granulepos is right for the purpose? I read the documentation about the ogg_page_granulepos

Hi Vorbis-Dev, I'm investigating various WebM/Vorbis bugs in chromium. AFAIK muxing Vorbis inside of WebM does not have an official specification, so I'm using ffmpeg's implementation to try to answer 2 questions: 1. Under what circumstances is it valid to find WebM Blocks containing Vorbis data with zero duration? (This would mean the next Block in the Cluster has the exact

Hi, I'm busy working on a method of synchronising playback between two ogg decoders. To do this reliably, I need to create a cross-reference of the raw & pcm offsets in the bitstream. I have tried using the ov_raw/pcm_tell calls, but it appears as if the ov_raw_tell() only updates itsself in steps of 4096 bytes (as each read callback is done). This gives me a cross-reference every

I've made a lot of progress on my lossless Vorbis editing project. I have a few more questions about granulepos issues I don't quite understand. granulepos is a property of Ogg pages, yet it is a field in the ogg_packet struct. When reading packets from an Ogg stream, the granulepos is set to -1 for all packets except the last packet in a page. From this I infer that - for encoding,

Folks have noticed that the documentation is semi-silent about how to properly encode the granule position and interleave synchronization of keyframe-based video. The primary reasons for this: a) we at Xiph hadn't had to do it yet b) there are several easy possibilities, and the longer we had to think about it before mandating One True Spec, the better that spec would likely be. The

2008/10/29 Romain Beauxis <toots at rastageeks.org>: > > I am currently implementing theora for our application. > In our model for generating ogg streams, we may want to stop > a stream while not providing a new YUV data buffer for encoding. > > Current API doesn't allow such thing, since the eos flag is set by the > packetout function only when the last_p parameter

I've got a question about the granulepos in speex packets. >From the speex manual (http://www.speex.org/manual2/node7.html#SECTION00073000000000000000): >The third and subsequent packets each contain one or more (number found in header) Speex frames. These are identified with packetno starting from 2 and the granulepos is the number of the last sample encoded in that packet. In