similar to: theora granulepos scheme

Hello, I'm just totally confused. In my theora streams encoded using ffmpeg2theora (but also when using my own encoder) I have packets with a granulepos of -1 so I can't identify the packet during a seeking operation correctly. I can also see those strange value when I just print the packet granulepos before sending it to the Theora decoder. I know why there are PAGES with granularpos of

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

Hi people, Next issue at hand here is after I have done a seek in a theora file. At this point, I have to reinitialize the decoder so the viewing can continue. Again, I have code that works most of the time, but, well... Just after the last file position seek, this code is run: while ((result = ogg_sync_pageout(&sync, &page)) == 0) bufferData(); while

I am trying to figure out how theora timestamps map to absolute time values. This information would be needed to seek by 1 sec, 5 secs etc. I understand the granulepos is interpreted as Absolute number of key frames so far | number of frames since last key frame. E.g. 1000|1, 1000|2, ... How does this map to absolute time in millisecs since the start, I can think of the following formula: Total

4) Subtract 1 from the keyframe, then repeat step 3). 5) Begin reading from the frame discovered in step 4. Drop any packets which are output on the first page. Count down until we reach the keyframe, dropping packets until then. 6) Continue counting down until we reach the target frame, we are now decoding each frame/packet. At the target frame produce the YUV output. You can see this in code

Dear all I'm aware that there have been several discussions about the seeking issue and I'm sorry to bring this up again. To solve the problem with Inter-Frame garbage, a seek to the previous keyframe has to be made. The keyframe number should be extracted from the granulepos of the frame where we want to seek to. I hope I understood the theory - unfortunately a few questions have

4) Subtract 1 from the keyframe, then repeat step 3). 5) Begin reading from the frame discovered in step 4. Drop any packets which are output on the first page. Count down until we reach the keyframe, dropping packets until then. 6) Continue counting down until we reach the target frame, we are now decoding each frame/packet. At the target frame produce the YUV output. You can see this in code

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

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

On 2/7/08, ogg.k.ogg.k@googlemail.com <ogg.k.ogg.k@googlemail.com> wrote: > And this is the crux of the problem, as far as I understand how it works: > you'll have to do a first bisection to find the page that maps to that > granulepos, > then, and only then, you get to know the low bits of the actual granulepos, > and then you have to do another bisection to find it.

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

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

4) Subtract 1 from the keyframe, then repeat step 3). 5) Begin reading from the frame discovered in step 4. Drop any packets which are output on the first page. Count down until we reach the keyframe, dropping packets until then. 6) Continue counting down until we reach the target frame, we are now decoding each frame/packet. At the target frame produce the YUV output. Steps 4 and 5 are

HOgg 0.4.0 Released ------------------- The HOgg package provides a commandline tool for manipulating Ogg files, and a corresponding Haskell library. HOgg is in hackage, or on the web at: http://www.kfish.org/~conrad/software/hogg/ This is the third public release. The focus is on correctness of Ogg parsing, production and editing. The capabilities of the hogg commandline tool are roughly on

Hi, I'm hacking on and off on oggmerge (from ogg-tools). I've added support for Theora, Speex, and Kate, as well as a few other fixes and changes. Now, I've got an issue relating to the ordering of pages as done by oggmerge, and the way oggz-validate tests for presentation time ordering. oggmerge, when deciding what timestamp to assign to a page, uses the previous page's

Hi Ralph, What speexenc does (Speex itself does not know about Ogg) is that it gives packet N the granulepos "N*frame_size - lookahead". In the case of narrowband, the first frame would have granulepos "1*160 - 80", so 80. I can't say about your example because Speex cannot encode a frame of one sample, which is a good thing becuse otherwise, the granulepos would be -79.

Jean-Marc, What exactly does the speex code do to calculate the granulepos? With vorbis it's the 'count of decodable samples including this packet'. So if you had a packet that allowed you to decode 1024 samples since the beginning of playback, the granulepos is 1024, not for example 1023 which would be the *index* of the last sample assuming C-style array indicies starting at

On Thu, Nov 13, 2008 at 2:54 PM, David Flynn <davidf+nntp at woaf.net> wrote: > The only niggle i have with this file is that the EOS page has a bizare > timestamp. imho, because there is no picture in the eos page, there is > no meaningful time for it, so the granulepos should be -1 on the eos > page on the dirac logical stream. ds and I talked about this a bit yesterday. The

Hello all, I have been trying to play the Guadec Theora files ( http://stream.fluendo.com/archive/6uadec/ ) on Windows with no success. At first I thought it was just the machine which I was trying it on, but I now have seen another machine play other Theora files (Systm, Ubuntu Below Zero) without problems, but treat Guadec as just being audio files. I do also have another machine here which

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