search for: oggdirac

...>> 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 on > something containing oggdirac. I started patching oggz sort and merge, and discovered they were very nearly working. After adding a custom function to convert granulepos to time for Dirac, rather than just going by the result of the granuleshift, it seems to be working. You can review the changeset here: http://trac.annodex.n...

...e to handle equal granulepos (if the earliest of a sequence of pages with equal granulepos is taken to be the first of those in the stream). * The draft mapping for Ogg Dirac uses successive equal granulepos, as the packets occur in coded order, not display order: http://wiki.xiph.org/index.php/OggDirac#Granulepos This is consistent with the definition of granulepos as the "count of decodable frames". I suggest we clarify that the granulepos of successive pages is allowed to be equal, as this is non-obvious from the available documentation. Thoughts? Conrad.

The definition of granule position for an OggDirac elementary stream isn't the same as theora. Index: tools/oggz_tools.c =================================================================== --- tools/oggz_tools.c (revision 3759) +++ tools/oggz_tools.c (working copy) @@ -454,7 +454,15 @@ iframe = granulepos >> granuleshift; pfram...

...gz 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 on >> something containing oggdirac. > > I started patching oggz sort and merge, and discovered they were very nearly > working. After adding a custom function to convert granulepos to time for > Dirac, rather than just going by the result of the granuleshift, it seems to > be working. You can review the changeset here...

...ort 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 on >>> something containing oggdirac. >> >> I started patching oggz sort and merge, and discovered they were very nearly >> working. After adding a custom function to convert granulepos to time for >> Dirac, rather than just going by the result of the granuleshift, it seems to >> be working. You can revie...

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 >

Ivo Emanuel Gon?alves wrote: > Hi Steve, > > Ogg is not an acronym. > > Besides Speex I am not aware of any other voice codec that has used > Ogg to this day, albeit it is possible. > > Hope that helps. > > -Ivo > Is there a well recognised procedure for adding new codec formats to ogg? If there is I'll probably add about 20-30 for the common speech codecs,

...he current mapping spec. > 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 on something containing oggdirac. > > As of changeset:3782, oggz-validate reports only this one error for that file: > > conrad at chichai:~/share/dirac$ oggz validate sage-640x360.ogg > sage-640x360.ogg: Error: > 00:02:36.077: serialno 1763535876: Granulepos decreasing within track Ok, that is due to the inval...

...; 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 >> problem for me in that i don't find the specification of skeleton >> particularly rigorous[1]. >> >> Actually, i don't even know what the definition of granule_rate applies >> to when...

...g such a packet first is currently invalid; the Dirac spec would have to be changed to allow this. In any case, David said he'd like to get this resolved in the next 48 hours or so, before doing a 1.0.1 bugfix release. So if you have input, now's the time! -r [1] http://wiki.xiph.org/OggDirac >

...39;s Ogg mapping: http://flac.sourceforge.net/ogg_mapping.html An "extra headers field" (like in FLAC and Speex) could be useful for forwards-compatibility, eg. if there could be a vorbiscomments packet in future. cheers, Conrad. > > > -r > > [1] http://wiki.xiph.org/OggDirac > >

...g-dev@xiph.org > Message-ID: <1201940074.15780.16.camel@BlackBook> > Content-Type: text/plain > > what about creating some consistent pages about codec encapsulation in > ogg, some of those pages already exist, what about creating the others? > http://wiki.xiph.org/index.php/OggDirac (exists) > http://wiki.xiph.org/index.php/OggFLAC > http://wiki.xiph.org/index.php/OggSkeleton (exists) > http://wiki.xiph.org/index.php/OggSpeex > http://wiki.xiph.org/index.php/OggTheora > http://wiki.xiph.org/index.php/OggVorbis > > j > > > > --------------------...

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 from the earlier proposal: * The granulepos is split into three fields instead of two, with the extra field encoding the reo...