similar to: start-time granulepos

Hi all, I noticed the following Subversion commit today: r6719 | xiphmont | 2004-05-18 16:04:53 +1000 (Tue, 18 May 2004) | 11 lines Updated doc to reflect current proposal... Not as much a proposal at this point actually; this is the way I'm now implementing it. Although we're still in the 'RFC'/'look for horrible lossage' stage, this is close to being

it's good you brought this up, I want to finalize the Ogg FLAC bitstream mapping and add it to the docs. currently the way it is done in flac 1.1.0 is not ideal and probably should change. --- Arc Riley <arc@Xiph.org> wrote: > I've been implementing Ogg FLAC support in an editor I'm working on, > and > I must admit to being frustrated by the lack of support for the

I've been implementing Ogg FLAC support in an editor I'm working on, and I must admit to being frustrated by the lack of support for the codec on the Ogg layer... and this is more than lacking granulepos. The codec's I've worked with, and my own (Writ), use Page 0 for general information about the codec. Specifically, the samplerate, bitrate, quality, number of channels, all

Ok guys and gals Monty assigned me as libogg2 maintainer a few weeks ago, with the provision that I get consensus on API changes from everyone. In order to facilitate discussion, and to "move on" vs letting this stalemate hold development at a stand still, I'm setting an initial deadline of this comming Monday, May 30th. If nobody has a strong objection why these API changes

Hello, I recently added discontinuous stream support to libogg1. The patch is attached. I also wrote Writ codec for libogg1 (based on original code by Arc), and sample Writ encoder (SubRip to Writ converter) and decoder. Is anybody interested? WBR, Roman. -------------- next part -------------- Index: include/ogg/ogg.h =================================================================== ---

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 liboggz tools is required, a little more work may need to happen. > Here's some

Ok guys and gals Monty assigned me as libogg2 maintainer a few weeks ago, with the provision that I get consensus on API changes from everyone. In order to facilitate discussion, and to "move on" vs letting this stalemate hold development at a stand still, I'm setting an initial deadline of this comming Monday, May 30th. If nobody has a strong objection why these API changes

Ok guys and gals Monty assigned me as libogg2 maintainer a few weeks ago, with the provision that I get consensus on API changes from everyone. In order to facilitate discussion, and to "move on" vs letting this stalemate hold development at a stand still, I'm setting an initial deadline of this comming Monday, May 30th. If nobody has a strong objection why these API changes

Ok guys and gals Monty assigned me as libogg2 maintainer a few weeks ago, with the provision that I get consensus on API changes from everyone. In order to facilitate discussion, and to "move on" vs letting this stalemate hold development at a stand still, I'm setting an initial deadline of this comming Monday, May 30th. If nobody has a strong objection why these API changes

Ok guys and gals Monty assigned me as libogg2 maintainer a few weeks ago, with the provision that I get consensus on API changes from everyone. In order to facilitate discussion, and to "move on" vs letting this stalemate hold development at a stand still, I'm setting an initial deadline of this comming Monday, May 30th. If nobody has a strong objection why these API changes

Folks, the packets I want to place in an ogg stream are concatenations of two hunks of memory. Rather than memcopy() them into one then pass them to libogg, I patched framing.c to accept iovecs. The unified diff is 80 lines, minus the OS-specific stuff for defining struct ogg_iovec_t - pretty trivial. Is there any interest in it? Or is libogg frozen while all efforts are concentrated on

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

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 >

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

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

Hello, I'm new to this list, and pretty much also to the codec universe. In a computer game I'm working on, there is an 3D TV-screen onto which I project the frames of a movie. The movie is of course stored as theora, no audio as it's not needed yet. I have it working so far, extracting a frame and uploading it to the graphics card when the scene is drawn. The example file

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

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

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