similar to: New Ogg Dirac mapping draft

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

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,

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

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

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

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

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

2008/11/24 David Flynn <davidf+nntp at woaf.net>: > On a slightly unrelated note, i keep hitting the following error in > liboggz when using the oggz tools on an ogg dirac stream: > > /home/davidf/project/liboggz/src/liboggz/oggz.c:202: oggz_close: > Assertion `oggz_dlist_is_empty(oggz->packet_buffer)' failed. > > I'll supply an example file tomorrow if that

We've been discussing this on irc. Short summary, followed by some responses. I think we've verified now that my old proposal works fine for MPEG-2 style reordered streams. I believe it can be made to work with 'open gop' streams by making the granulepos assignment more sophisticated than I described. However, Dirac allows essentially random reference structures, so it's

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 granulepos and dependency ordering, so let's leave them >>> for the next

On Tue, Jun 1, 2010 at 12:56 PM, Monty Montgomery <monty at xiph.org> wrote: > On Mon, May 31, 2010 at 10:51 PM, Timothy B. Terriberry > <tterribe at email.unc.edu> wrote: >> 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

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

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

On 2008-11-14, Conrad Parker <conrad at metadecks.org> wrote: > Should oggz-comment be modified to disallow modification of Dirac > streams, ie. does Ogg Dirac never contain VorbisComment metadata? Correct; there is no metadata handling capability in the current mapping spec. > It seems oggz chop, merge and sort will need some attention to deal > with the Dirac granulepos and

On Wed, Aug 13, 2008 at 3:05 AM, ogg.k.ogg.k at googlemail.com wrote: > And that's the canonical way AFAIK. Comparing times computed from > the granpos you get from pages you get from a bsearch requires good > knowledge of the codec, whereas comparing granpos can seek within > any codec. No. it's in general impossible to calculate the granulepos that corresponds to a

>>> 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. >> My only initial concern is about the definition >> of granule_rate. My intention is to add some guidance to the oggdirac >> mapping spec on how to apply oggskeleton. This raises the slight

On Tue, Aug 12, 2008 at 5:46 AM, ogg.k.ogg.k wrote: > This could be something to add to Skeleton. Kate (and probably CMML) > needs the one-packet-per-page thing also, and any discontinuous codec > probably needs it as well (well, not *need*, but no good buffering without > it). It's trivial for a muxer to do, and it's transparent to a demuxer. That's a good idea. Any