search for: granules

On 15-Feb-08, at 6:44 AM, ogg.k.ogg.k@googlemail.com wrote: > Well, it doesn't quite work because the second part of the gpos is > an offset, > rather than absolute, and the precision we shed on one, we need to > recover > on the other one, to keep the ability to timestamp events at the > correct > granularity. It would have worked if the second part was absolute

After trying to find out what to do when no packets complete on a page... i reread the ogg spec and found this... "A special value of -1 (in two's complement) indicates that no packets finish on this page." So i searched through a few files and it appears that the muxer doesn't do this... has this been depracated ? In all cases i can find that this happens the page has the same

..., theora). It is implemented in libkate, so it works and the changes needed are minimal. I'm happy to make the necessary changes in oggmerge/liboggz if needed. The two advantages this change brings are increased usable time (for the same timestamping precision) and the ability to map different granules to the same time. Both are adjustable by client code. That said, I see the interest of having a shared method of mapping time and granules, and I'll use the Theora/CMML method if this proposed method doesn't convince you. See the end of the mail for the trivial code difference between the...

...in libkate, > so it works and the changes needed are minimal. I'm happy to make the > necessary changes in oggmerge/liboggz if needed. > > The two advantages this change brings are increased usable time (for the > same timestamping precision) and the ability to map different granules > to the same time. Both are adjustable by client code. > > That said, I see the interest of having a shared method of mapping time > and granules, and I'll use the Theora/CMML method if this proposed > method doesn't convince you. > > See the end of the mail for t...

Hi all, I've just grabbed a copy of SVN head for libogg and 'make check' is failing: ./test_framing testing single page encoding... 0, (0), granule:0 ok. testing basic page encoding... 0, (0), granule:0 1, (1), granule:6151 ok. testing basic nil packets... 0, (0), granule:0 1, (1), granule:10247 ok. testing initial-packet lacing > 4k... 0, (0), granule:0

Hello all, there is an ambiguity within the Vorbis specification regarding the granule position of the Ogg encapsulation. I'm referring to section "A.2. Encapsulation" of the Vorbis I specification, as found here: https://xiph.org/vorbis/doc/Vorbis_I_spec.html#x1-132000A.2 The specification both says > The granule position of these first pages containing only headers > is

> The advantage of storing this in the granulepos field itself, like > theora and CMML do, is that the seek code may already understand how > to handle the back pointer. Right now everything assumes the mapping > is from 'initialized decoder' + 'granulepos from page header' => > timestamp, or in the case of theora and CMML => 'timestamp' + 'last

Ups! Maybe it's time somebody corrected that statement then - the wiki seems the right place to put the correct algorithm, IMHO. Cheers, Silvia. On Feb 13, 2008 10:06 AM, Ralph Giles <ralph.giles@artifex.com> wrote: > > On 12-Feb-08, at 2:57 PM, Ralph Giles wrote: > > > http://wiki.xiph.org/index.php/GranulePosAndSeeking > > I'm not sure it's helpful to

...r Kate, which can have any number of active events at a given time, though that might be OK for CMML. But if this is enough, then it doesn't matter at all that the granulepos of the previous clip be shoved into the lower bits of the granulepos of the current packet, this would just decrease the granulespace by 4 billionfold for no gain. And I don't really want to do that for Kate anyway since I need a few bits for allowing multiple events at the same time (this avoids things like increasing granulepos's necessarily mapping to different times). Anyway, this means that you have to do two se...

Hi, If this is true: "Granule Position Information in Ogg Header is a hint for the decoder and gives some timing and position information." So say if granule position is 10000, it means that 10000 PCM samples are encoded in this page approximately. If this is true we can neglect this information, it will not effect the decoding right(but might effect for streaming)? Ravi

I have a technical question about the vorbis granule position, but I would like to put the question into context. When a ogg vorbis stream is ripped using wget, fetch, or streamripper under Linux or FreeBSD, the resulting file has problems both with granule position and with a missing EOS. I think I can figure out how to add an EOS, but is there a way to determine the granule position in a stream

...> Of course we could add your scheme to Skeleton as well, but the start > of the packet data could be on a completely different page from the > granulepos. That was not the intent, my scheme is likely to be very specific to my case. My point was to try to understand how the splitting of granules in two would avoid a double bisection, which it doesn't if I got that well, so I'm trying to get an explanation of its interest, which so far seems to be that it keeps all the granule data in the same place, at the page level, which so far does not convince me it is worth the loss of 32 bit...

On 11-Feb-08, at 2:46 AM, ogg.k.ogg.k@googlemail.com wrote: > For reference, my data packets start with start granule, end > granule, backlink > granule, all 64 bits, so picking the granule is just a simple > constant offset > lookup into the data packet, eg, you replace: > > backlink = granulepos<<32; > > by > > backlink =

..., you do just skip pages marked with a -1 one when you're seeking because they don't tell you anything, but that's not the only case. > That was not the intent, my scheme is likely to be very specific to > my case. > My point was to try to understand how the splitting of granules in > two would > avoid a double bisection, which it doesn't if I got that well, so > I'm trying to > get an explanation of its interest, which so far seems to be that > it keeps all > the granule data in the same place, at the page level, which so far > does &gt...

...can find any frame's previous keyframe granulepos by clearing the low bits of the frame's granulepos. In CMML, this is the other way round: you have to shift left by 32 to get the previous frame. This is what puzzled me I think. Now, if one were to swap the 2 32 bit granulepos bits in CMML granules, then you would still get a strictly increasing granulepos (since the previous pointer can never get backwards in time), and this would be more similar to Theora (eg, clear off the low bits). The high bits are now the backlink, and the low bits are the granulepos are the actual granule of the curre...

Hi, I've seen several implementations of Ogg demuxing that use a zero granulepos to detect headers. However, I do not recall seeing this in the Ogg docs - is this an abuse that happens to work because Vorbis is timed by end granule, or is it a proper way to check ? Thanks

...granulerate is to be interpreted as in Ogg Skeleton so it should be possible to calculate `granulepos / granulerate` to get time. But it also says: The default granule rate for OggSpots is: 1/30 (30 frames per second resolution). To me that doesn't make sense. If we want to specify 30 granules per second the granulerate should be 30/1 (i.e. the inverse). So the calculation becomes X granules / (30 granules / 1 s) == X granules * 1 s / 30 granules == (X / 30) s Is there an error in my thinking or is the spec wrong? Problem: I have encountered fi...

Hi, I have a question regarding Ogg’s multiplexing process. Let’s say we have two logical streams, S1 and S2, which need to be muxed together into one physical stream. On logical stream S1, we have a packet that’s too big and needs to be split into two pages, P1 and P2. On the other hand, logical stream S2 also has a page Px that needs to go out. When these 2 logical streams are muxed together,

Hi! I don't find any detailed information about this in the specification, so I try a question here. If two plain, unmultiplexed Ogg/Vorbis-files are chained into one file, you end up with an Ogg-file with two logical Vorbis streams. When playing this file, would it be correct for a decoder to synchronize the two streams according to the granule position of the Ogg pages (playing them

...keyframe granulepos by clearing > the low bits > of the frame's granulepos. In CMML, this is the other way round: you > have to shift > left by 32 to get the previous frame. This is what puzzled me I think. > > Now, if one were to swap the 2 32 bit granulepos bits in CMML granules, then you > would still get a strictly increasing granulepos (since the previous > pointer can never > get backwards in time), and this would be more similar to Theora (eg, > clear off the low > bits). The high bits are now the backlink, and the low bits are the > granulepos...