similar to: Timestamps...

Hi, I've seen several implementations of Ogg demuxing that use a zero granulepos to detect headers. However, I do not recall seeing this in the Ogg docs - is this an abuse that happens to work because Vorbis is timed by end granule, or is it a proper way to check ? Thanks

OK... i've come across a problem trying to get the granule pos of the start of the page... it's not so crucial with single stream ogg files... but now that i have theora+vorbis in a file, i'm finding that when i seek to a position, i have no way to determine the relative offsets of the different streams at the new seek point and hence the av is out of sync. So given a page, is it

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

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

I have been developing some directshow filters for ogg, and vorbis and speex... currently i have an ogg demux filter and a speex/vorbis decoding filter. In this pre-release only vorbis is operational... but the speex decoder is pretty much done... i jsut need to tweak the demux filter so that it can negotiate a speex connection with the other filter. Just though some people might find them useful

> 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

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.

Listening to the meeting on granule pos tonight/today it became clear that the issues everyone is concerned with for the most part don't affect my implementations and the issues i have pretty much don't affect anyone else... and in the cases where they overlap, the reasoning seems to be different. And since everyone else has had a lot more time to consider all these issues and i'm

Ups! Maybe it's time somebody corrected that statement then - the wiki seems the right place to put the correct algorithm, IMHO. Cheers, Silvia. On Feb 13, 2008 10:06 AM, Ralph Giles <ralph.giles@artifex.com> wrote: > > On 12-Feb-08, at 2:57 PM, Ralph Giles wrote: > > > http://wiki.xiph.org/index.php/GranulePosAndSeeking > > I'm not sure it's helpful to

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

On 02/05/07, Elaine YueLien <et@ihear.com> wrote: > Hi, > > Several months ago, I asked a question about seeking without a metric. > You can find one answer in this beta release, demonstrated in the > example program multiThreadSeek. There is also an example demuxer, and a > rewriter. Hi Elaine, congratulations :-) that's a nicely designed API you've got there.

After a few other attempts at hacks to determine start times of pages, the only other option left is to partially decode the packets in the demuxer in order to give correct start time stamps after a seek. Someone mentioned it was relatively easy to do without a full decode. I've had a bit of a search in the mailing lists and on the web and can't find any details about it. What i need is

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

> There are a usually lot more data packets than header packets, so > having an internal length there hurts your bitrate a lot more. Of > course, it may not be significant for an uncompressed text codec. If muxed with a video, it's insignificant (well, for my test cases). > With codecs using the 'count of decodable samples' rule to calculate > their granulepos, the

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

Folks have noticed that the documentation is semi-silent about how to properly encode the granule position and interleave synchronization of keyframe-based video. The primary reasons for this: a) we at Xiph hadn't had to do it yet b) there are several easy possibilities, and the longer we had to think about it before mandating One True Spec, the better that spec would likely be. The

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

> 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

> 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

Hi all, I'm actually learning how to use ogg, theora and vorbis. My idea is to create a small program running, that is able to concatenate ogg video+audio files. However I have some small questions. Here I will start with the first one: I read the following for seeking in ogg for a theora key-frame: ---- snipp (http://www.xiph.org/ogg/doc/ogg-multiplex.html) ---- [...]The third point