similar to: Resyncing cut streams...

Listening to the meeting on granule pos tonight/today it became clear that the issues everyone is concerned with for the most part don't affect my implementations and the issues i have pretty much don't affect anyone else... and in the cases where they overlap, the reasoning seems to be different. And since everyone else has had a lot more time to consider all these issues and i'm

We are trying to debug a connection between Asterisk and a legacy PBX (Mitel SX200). We turned on the Zaptel debugging and we get the following message quite frequently: Oct 12 07:14:09 localhost kernel: T1: Lost our place, resyncing ( 28 ) Oct 12 07:14:09 localhost last message repeated 3 times -- Oct 12 07:14:11 localhost kernel: T1: Lost our place, resyncing ( 28 ) Oct 12 07:14:11 localhost

This one really has me stumped. I'm running 866MHz, 256MB RAM, 80GB Disk (7200RPM) on Linux-mandrake 8.2 icecast 1.3.12 & ices 0.2.3 & lame 3.91 all mp3s encoded with lame 3.91 or higher and --r3mix (VBR) Sorry for the long email but I'm hoping to get someone out there that's seen this before and give me some advice... I'm continually getting errors like this when running

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 liboggz). It is also compatible with other

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" > method, so

Hi, I have a question about seeking. In fact, it's more or less a kind of rambling and thinking aloud, circling around a question. I've been wondering how to deal with seeking in a stream, 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

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 =

> 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

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

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

> 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 algorithm so it can be > implemented without looking inside

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

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 granulepos by clearing the low bits of the frame's

On Saturday, 04 May 2002 at 17:52, Wade Carroll wrote: > This one really has me stumped. > I'm running 866MHz, 256MB RAM, 80GB Disk (7200RPM) on Linux-mandrake 8.2 > icecast 1.3.12 & ices 0.2.3 & lame 3.91 > all mp3s encoded with lame 3.91 or higher and --r3mix (VBR) ices behaves unpredictably in the face of VBR mp3s. It's on the TODO list, but I've never had the

> No particular answers, but I can at least point out that the way > things were designed for CMML was to work with the existing Ogg > seeking algorithm. The idea is that a generic seeking routine can work > on any Ogg file, as long as it knows the granulepos->time mapping for > the logical bitstreams in the file. That's why all the > timestamp-related info is crammed into

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

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

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,

Hello. If running dovadm replicator status, i get something like the following. root at mail2:~# doveadm replicator status Queued 'sync' requests??????? 0 Queued 'high' requests??????? 0 Queued 'low' requests???????? 0 Queued 'failed' requests????? 0 Queued 'full resync' requests 4 Waiting 'failed' requests???? 0 Total number of known users? 1000

A few folks have asked for specifics, at the spec level, on how sample granularity editing works in Vorbis. So, here's a whitepaper as the beginnings of a real document. This doc is also in CVS on branch_beta3. Note that vorbisfile is not actually tested with the beginning sample-offset spec for editing. I'll be testing/fixing any bugs in vorbisfile on that front now, and keeping