similar to: Ogg Skeleton

Displaying 20 results from an estimated 5000 matches similar to: "Ogg Skeleton"

2009 Jun 05
2
Ogg Skeleton
On Fri, Jun 5, 2009 at 4:30 AM, ogg.k.ogg.k at googlemail.com <ogg.k.ogg.k at googlemail.com> wrote: > It holds the granulerate, so it'd allow this for those codecs that use the > granule shift way of encoding their granules (except for those pages > where no packet ends, as these will have no granpos set). BTW, we need to add another field out of the remaining reserved bits
2010 May 11
4
Fwd: Skeleton 4.0 draft, help with Dirac fields please!
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
2008 Aug 12
7
New Ogg Dirac mapping draft
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
2008 Nov 21
6
ogg dirac granulepos in oggz tools
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
2008 Nov 21
2
[Schrodinger-devel] ogg dirac granulepos in oggz tools
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
2008 Feb 19
4
non-decreasing granulepos
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
2008 Feb 22
2
Seeking to granules in discontinuous streams
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
2010 Jun 01
3
Fwd: Skeleton 4.0 draft, help with Dirac fields please!
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
2010 Apr 23
2
Ogg Index A-mod
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
2009 Jun 08
1
Ogg Skeleton
> any new fields. However, I cannot even find Dirac in oggz > http://git.xiph.org/?p=liboggz.git;a=blob;f=src/liboggz/oggz_auto.h; There's dirac.[ch] in the tools directory, though I haven't looked at what's in there. Not sure why it's segregated like that.
2010 Jun 01
2
Fwd: Skeleton 4.0 draft, help with Dirac fields please!
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
2008 Feb 28
2
Re: Updating the Ogg mapping for Dirac
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
2008 Mar 22
2
fishead granule rates
Hi, What are the two granule rates in a fishead packet supposed to be for ? Since each of the streams has a corresponding fisbone packet with its own granulerate in it, and they can be all different, wha does the presentationtime num/den means ? Also for hte basetime num/den, since the UTC time which is also present in fishead seems to be a textual representation rather than a linear count ?
2008 Feb 11
4
Seeking to granules in discontinuous streams
> 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
2008 Nov 21
0
ogg dirac granulepos in oggz tools
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
2009 Jun 08
2
libogg++ release 1.1.0
On Tue, 2009-06-09 at 00:12 +1000, Silvia Pfeiffer wrote: > On Sat, Jun 6, 2009 at 6:23 AM, ter<et at ihear.com> wrote: > >> If you are creating multitrack Ogg files, they should contain a > >> skeleton track to identify the different contained tracks. > >> http://wiki.xiph.org/OggSkeleton > > ALingA is a multitrack format > >
2008 Feb 12
2
Seeking to granules in discontinuous streams
> 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
2008 Feb 15
2
Seeking to granules in discontinuous streams
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
2016 Jan 17
0
Spec Error for OggSpots?
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
2008 Nov 25
0
ogg dirac granulepos in oggz tools
>>> 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