similar to: Ogg mux design

I'm hoping this is a new proposal, and not a rehash of something that's already been discussed and shot down. Without logs of the recent IRC discussion there's no way for me to know without asking. When I suggested it in #theora earlier derf_ or AndrewBachmann said that it had already been discussed, so I'm under the belief that this is a new idea. <p>Ok so we've

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

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

I've been looking over Benjamin Schwartz's Skeleton A-mod proposal. I've been pretty busy with other projects over the past few months, so haven't had a chance to look at Ogg indexing until now... In general, I think Benjamin's ideas are sound, they're improvements, and I'm open to being convinced to take them in the next index version. We may as well get the index

David Flynn has proposed a new Ogg Dirac mapping. The draft is here: http://davidf.woaf.net/dirac-mapping-ogg.pdf This is a much bigger break from other codecs than my draft (at http://wiki.xiph.org/index.php/OggDirac). We talked a bit about it on IRC today. Below is my summary; hopefully David can correct anything I got wrong or misleading. Comments? There are two main differences

dear list, i am trying to write a small program which reads an ogg file and writes it to another ogg file (and changes serial number, granulepos etc on the fly). reading the ogg file is ok (ogg_sync_pageout, ogg_stream_pagein, ogg_stream_packetout). but writing the file doesn't work - the granulepos and page structures don't match with the original file. here's what i am doing.

On 10 May 2010 23:20, Chris Pearce <chris at pearce.org.nz> wrote: > The granulepos radix was something that Conrad and Ralph were talking about > at FOMS2010. I don't know how it's supposed to be used, or why we need it. > It was supposed to be needed for Dirac? Maybe Ralph or Conrad can remember? > If not, we should remove it. There's no point in adding a poorly

> 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

Hello, I'm just totally confused. In my theora streams encoded using ffmpeg2theora (but also when using my own encoder) I have packets with a granulepos of -1 so I can't identify the packet during a seeking operation correctly. I can also see those strange value when I just print the packet granulepos before sending it to the Theora decoder. I know why there are PAGES with granularpos of

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

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

Hi all ! Following my recent issued with my encoder, I've narrowed the issue to the fact that, when encoding, for some returned pages, the granulepos returned by the libogg is -1. Is that normal ? How should I intepret it if I want to order the pages ? Romain

Chris Pearce wrote: > Hi Guys & Gals, > > I need you guys to decide whether we want to include extra granulepos > fields to Skeleton 4. Given the underwhelming discussion regarding this, > I'm guessing the need and/or desire for these fields isn't really there. I haven't commented mostly because I don't know what Monty's plans for a "grand unified

On Thu, Feb 28, 2008 at 1:53 AM, Ralph Giles <giles@xiph.org> wrote: > On 27-Feb-08, at 10:44 PM, Conrad Parker wrote: > > > Sure: I'm thinking about Ogg demuxers and seeking implementations. > > These need to know the framerate in order to be able to interpret the > > granulepos in terms of time. If they did not have to extract that from > > the

Hello, I recently added discontinuous stream support to libogg1. The patch is attached. I also wrote Writ codec for libogg1 (based on original code by Arc), and sample Writ encoder (SubRip to Writ converter) and decoder. Is anybody interested? WBR, Roman. -------------- next part -------------- Index: include/ogg/ogg.h =================================================================== ---

Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://westfish.xiph.org/pipermail/vorbis-dev/attachments/20040618/e7bee431/attachment.pgp

On 2/7/08, ogg.k.ogg.k@googlemail.com <ogg.k.ogg.k@googlemail.com> wrote: > And this is the crux of the problem, as far as I understand how it works: > you'll have to do a first bisection to find the page that maps to that > granulepos, > then, and only then, you get to know the low bits of the actual granulepos, > and then you have to do another bisection to find it.

On 28/02/2008, Ralph Giles <giles@xiph.org> wrote: > Conrad had suggested instead extending the now Ogg-specific initial > data to include the framerate (and possibly also frame size) since > these are somewhat tedious to parse out of the sequence header. It > turns out that gstreamer (the test framework everyone's been using > with schroedinger) was already

> 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

> 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