search for: granule

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

...ound 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 granule pos as the previous page. Is this a bug in the encoder or muxer or is the spec wrong ? Also when looking more closely the granule pos appears to get out of whack at each point where this happens... with the granule pos increasing by a large amount. An example.... Ver No : 0 Head Flags : 1...

Hi, I've now got another way of encoding granule (oh, not *again*, I hear you cry). I believe it's an improvement over the existing "generic" method, so I'll outline it here for your consideration. Again, it's different from what Skeleton can handle, but it's a simple superset and would be easy to add to Skeleton (and li...

Hi, do you still think you need all this, if you are allowed to have equal granulepos on subsequent pages? Conrad. On 18/02/2008, ogg.k.ogg.k@googlemail.com <ogg.k.ogg.k@googlemail.com> wrote: > Hi, > > I've now got another way of encoding granule (oh, not *again*, I hear > you cry). I believe it's an improvement over the existing "generic"...

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 1, (1), granule:2055 ok. testing single packet page span... 0, (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 hea...

> 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...

...dy 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 keep linking to this. It's important > historically, but Monty's whole thesis about "start decoding here and you're > good" is WRONG because of the continued packet issues. > > > To clarify, the seeking...

...tream, and what to do when seeking in the middle of a set of active events (eg, when several bits of text are supposed to be shown, but you seek after the time when they are first shown, and before the time when they are hidden). The three main ways I see to do this are: - The CMML way: split the granule pos in two and encode the previous clip's start granule in the low bits - this preserves the continuity of granulepos's. - The Writ way: repeat events at regular intervals, so you can always be sure to have all packets if you seek to at least that interval before the actual tim...

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 d...

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 w...

> It is more complex, because the granulepos is available at the page > level. Ah. Good point, I always forget about the partial page problem :( I conveniently flush pages after each data packet in my case (due to unknown/arbitrary latency), so I tend to forget easily about those. > We've generally designed the seeking algorith...

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 = read64le(op.packet+constant_offset); It is more co...

On 12-Feb-08, at 2:02 AM, ogg.k.ogg.k@googlemail.com wrote: >> It is more complex, because the granulepos is available at the page >> level. > > Ah. Good point, I always forget about the partial page problem :( > I conveniently flush pages after each data packet in my case (due to > unknown/arbitrary latency), so I tend to forget easily about those. Ah, right. So it might be ok fo...

Some more thinking about this whole granulepos splitting. Sorry for the badgering :) The CMML way was presented as a similar way as the Theora way, which I didn't see (I actually use such a system to allow multiple events to start at the same time, and this feels like the Theora way). Theora can find any frame's previous keyframe gr...

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

Hi, I'm currently implementing OggSpots [1] support for VLC. In the "spec" it says that the 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 granule...

...t looks like … P1, Px, P2 … I found the following info from the Multiplexing section in this document: https://www.xiph.org/ogg/doc/ogg-multiplex.html: Ogg bitstreams multiplex multiple logical streams into a single physical stream at the page level. Each page contains an abstract time stamp (the Granule Position) that represents an absolute time landmark within the stream. After the pages representing stream headers (all logical stream headers occur at the beginning of a physical bitstream section before any logical stream data), logical stream data pages are arranged in a physical bitstream in st...

...bout 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 simultaneously), or should the streams be played separately and in order? Chaining Ogg files is explicitly allowed for Vorbis- only-files, and in that case, it would be proper to play them after eachother. On the other hand, it makes sense to synchronize t...

Hi, sorry, there is a bug in the CMML spec and wiki page ... I discussed this with Silvia earlier this week but haven't gotten around to correcting it yet. CMML granulepos is much like theora's; the previous granule is stored in the higher bits, and the delta since then is stored in the lower bits. The current timestamp is the sum of the two. This is the behavior of the implementations (and has been for many years), and what is supposed to be in the spec ......