similar to: Ogg Index A-mod

Hi everybody, I've updated OggIndex to now output Skeleton 4.0 tracks. The differences between Skeleton 3.x and Skeleton 4.0 with OggIndex is: * The fisbone packet now includes a "Radix" field. * The fisbone packet now includes two new compulsory message headers; "Role" and "Name". * The fishead packet no longer includes "start time"

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

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

​Can you guys clarify that by Rice you don't mean unary coding, but exponential golomb coding? that issue has confused me before, and probably others.​ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/flac-dev/attachments/20170523/525651dc/attachment.html>

After some more thought on this, I'm trying to work out whether the back link offset needs precision. Semantically, the only need we have for this is to be able to seek back to a point before the start of the earliest event still active at the time of the original seek. As far as I know, and please correct me if I'm wrong, nothing in Ogg mandates that this backlink actually resolves to a

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

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

Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://westfish.xiph.org/pipermail/vorbis-dev/attachments/20040618/e7bee431/attachment.pgp

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

On 28/02/2008, Ralph Giles <giles@xiph.org> wrote: > Conrad had suggested instead extending the now Ogg-specific initial > data to include the framerate (and possibly also frame size) since > these are somewhat tedious to parse out of the sequence header. It > turns out that gstreamer (the test framework everyone's been using > with schroedinger) was already

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

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

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

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

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

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/11/14 David Flynn <davidf+nntp at woaf.net>: > On 2008-11-13, Conrad Parker <conrad at metadecks.org> wrote: >> I'm wondering if the Dirac granulepos parsing in liboggz and display >> in the oggz tools is currently correct, as I'd like to do a release of >> these soon. > > I believe it is -- although if correct support in the rest of the >

I've developed an indexer which embeds a keyframe index track in Ogg files. It embeds the index in its own track, so that players that don't understand or don't want to use the index can just ignore it. Ogg needs this to make seeking over networks faster and more efficient. Currently we must do a bisection search when seeking, which usually takes aound 6 HTTP requests, give or