similar to: Spec Error for OggSpots?

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

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

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

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 ?

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

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

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; pframe = granulepos - (iframe << granuleshift);

Hi, I got a short question regarding the ogg skeleton. As far as I understand it, the skeleton information helps to decode the timeing from the granule position, that is available in every ogg page, so that I can say, what is the end time of the last full ogg packet within an ogg page. So but it does not help me finding out the timing information about the other packets in between? -Yorn

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, 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 Tue, Jun 9, 2009 at 9:23 AM, ter<et at ihear.com> wrote: > 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. >> >>

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

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

On 5/24/08, Ralph Giles <giles at xiph.org> wrote: > It's supposed to be finalized though there many be some granulepos > issues still in current implementations. I don't expect the BBCD\0 > magic to change. Great. > OggMNG defines the following magics: > > char[8]: "\211PNG\r\n\032\n" png > char[8]: "\212MNG\r\n\032\n" mng > char[8]: