similar to: Theora packets with granulepos of -1

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

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

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 all ! Following my recent issued with my encoder, I've narrowed the issue to the fact that, when encoding, for some returned pages, the granulepos returned by the libogg is -1. Is that normal ? How should I intepret it if I want to order the pages ? Romain

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

Hi, I am continuing to try to debug my ogg/theora decoder. The issue seems to be that not enough packets are being pulled from the bitstream, here is some sample output from my player with some debugging comments put in: (playback began at first frame, this is from the middle of the clip) get page at 1765027 got packet frame++, skip is 0 frame decoded page processed, kframe=414 : offs=442 get

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

So Thomas and I have been trying to hash out the seek and mux issues with grouped Ogg streams again, along with Conrad while he was here in Barcelona after Guadec. We'll put a longer proposal up later, but one question for the list: Thomas has suggested changing the theora granulepos so the first data packet the encoder spits out would be labeled 1/0 instead of 0/0, in "frame count of

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

Monty, Thanks for writing up your thoughts on the mux design (ogg/doc/ogg-multiplex.html in cvs) Now that there's something to argue with, I'd like to comment. To recap, the documented proposal is that we make two categories of streams within the OggFile multiplexing library. Pages are sorted chronologically by the timestamp equivalent of their granulepos fields. Normal data like

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

Hello, > (1) Split the content into chain segments > (2) extract the first and last data packet from each segment, for all tracks > (3) recover / calculate the granulepos values for the first and last data packets (*) > (4) convert the granulepos values from the first and last data packets into time values > (5) take the largest difference between start and end time as the total

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

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

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

One of the issues I've consistently run into with the cortado player app is seek behavior, so I was curious to see how cortado handles video encoded with the latest ffmpeg2theora (0.26) and the new -seek-index option, so I tried converting an h.264 video: ffmpeg2theora tronlegacy-tsr1_480p.mov --seek-index This output the following advisory messages: > Allocated 372 bytes for theora

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

On Fri, Dec 05, 2008 at 06:34:41AM +0900, Conrad Parker wrote: > So the last remaining tool to check is oggz-chop. I at first assumed it > would not work with Dirac's granulepos, but it seems to do something > vaguely useful: > > conrad at chichai:~/share/oggz-chop$ oggz chop -s 7 -e 11 -o > sage-7-11.ogv ../dirac/sage-640x360.ogg > conrad at chichai:~/share/oggz-chop$

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 Thu, Nov 13, 2008 at 06:06:10PM +0900, Conrad Parker wrote: > A couple of days ago David Schleef mentioned there were some problems. > David, is that currently true (ie. since David Flynn's recent updates > to support Dirac), and if so could you please explain what the > problems are, or point me to a bugtracker where they are reported. eg. I mostly meant what you apparently