search for: libogg1

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

...ms differently is a good idea. Before you argue this you had better read Monty's full documentation on this since it was published months ago. II. Undisputed API changes and extentions A. Namespace change One of the very good ideas to come from the Annodex crew was to provide libogg1 backwards compatability. Toward this goal all libogg2-specific functions and structures have been renamed so that, in the near future, functions and structures with the same name as the libogg1 functions/structs they emulate can be added. B. Page header manipulation functions In li...

...ms differently is a good idea. Before you argue this you had better read Monty's full documentation on this since it was published months ago. II. Undisputed API changes and extentions A. Namespace change One of the very good ideas to come from the Annodex crew was to provide libogg1 backwards compatability. Toward this goal all libogg2-specific functions and structures have been renamed so that, in the near future, functions and structures with the same name as the libogg1 functions/structs they emulate can be added. B. Page header manipulation functions In li...

...ms differently is a good idea. Before you argue this you had better read Monty's full documentation on this since it was published months ago. II. Undisputed API changes and extentions A. Namespace change One of the very good ideas to come from the Annodex crew was to provide libogg1 backwards compatability. Toward this goal all libogg2-specific functions and structures have been renamed so that, in the near future, functions and structures with the same name as the libogg1 functions/structs they emulate can be added. B. Page header manipulation functions In li...

...ms differently is a good idea. Before you argue this you had better read Monty's full documentation on this since it was published months ago. II. Undisputed API changes and extentions A. Namespace change One of the very good ideas to come from the Annodex crew was to provide libogg1 backwards compatability. Toward this goal all libogg2-specific functions and structures have been renamed so that, in the near future, functions and structures with the same name as the libogg1 functions/structs they emulate can be added. B. Page header manipulation functions In li...

...ms differently is a good idea. Before you argue this you had better read Monty's full documentation on this since it was published months ago. II. Undisputed API changes and extentions A. Namespace change One of the very good ideas to come from the Annodex crew was to provide libogg1 backwards compatability. Toward this goal all libogg2-specific functions and structures have been renamed so that, in the near future, functions and structures with the same name as the libogg1 functions/structs they emulate can be added. B. Page header manipulation functions In li...

Hi, I am creating a new ogg stream for theatrical/stage/disco lighting and am having trouble encoding my comment header with the following code in _tp_writelsbint function, it does not write the second byte to the ogg buffer. I am using windows and have created a new win32 library project with visual studio and added my code, what do i have to do to get the function working? Is there a project

I wish I would have come across this in time for the libogg-1.1.1 release... Maybe I'm doing something wrong but here it is. One FLAC compressed frame becomes one packet when encapsulated in Ogg, and FLAC packets can be much larger than the nominal 4k page size. For CD audio they are usually 10-15Kbytes. Imagine this Ogg stream where the lines denote page boundaries and the x's are one

Michael Smith wrote: > libogg has two bitpackers; a little endian one and a bigendian one. ok, I didn't see it in the docs at http://www.xiph.org/ogg/doc/libogg/reference.html and didn't look in the header file first. My bad. Is it correct to state that the oggpack_* functions use little endian order, and the oggpackB_* functions use big endian order? Is it safe to mix calls to

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

...going) This depends which 'project' you mean. You've posted to ogg-dev, the libogg api itself hasn't needed to change much, though this change made it in: <http://lists.xiph.org/pipermail/ogg-dev/2007-January/000357.html> I think Monty's statement there sums it up: "libogg1 isn't particularly frozen, it was just considered 'finished' is all." Last I heard Monty is still working on libogg2 when he gets time, which isn't often. Xiph in general, there's stuff happening, although most of it is peripheral to what you might think are the central...

According to the archives, these lists haven't been used in months. Have they been migrated to sourceforge? --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'flac-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe

According to the archives, these lists haven't been used in months. Have they been migrated to sourceforge? --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'flac-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe

.... Hence almost half the time spent in the hundreds of thousands of calls to that function per frame was for mucking around with the stack in a one-line call that should've been inlined away anyway. And on top of that Theora had an additional wrapper to handle various problems with the libogg1 API when reading past the end of a packet, which added even more overhead. Vorbis, on the other hand, calls the little endian versions of the functions directly and decodes far fewer bits per second, typically. Also, Ralph reported that x86-64 showed only a 7% speed-up in Theora with the a...

Hi, it seems Ogg keeps track of a packet's size at the byte level, rather than at the bit level (eg, if I encode a packet with just one bit, decode will think there are 8 bits available). Am I right ? Not that it's a particularly important issue, since remaining bits will probably be initialized, but I noticed this while adding some calls to oggpack_look1 at the end of my decode routines

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

...G_PCM_LE_FLOAT32 > OGG_PCM_BE_FLOAT32 > ... This I did not put into the draft because, while a seperate endian flag is unused for 8bit samples, it greatly simplifies implementation when the libogg bitpacker is used, which is on a seperate layer than data decoding. Both libogg1 and libogg2 allow you to read multi-byte values of up to 32 bits (no, this doesn't include 64-bit values) with the endian you specify. It also nearly doubles the number of values which must be known/tested by implementors, which is something I believe should be avoided. > A number of pe...

Hi everyone, I just landed into the theora planet, as a game programmer, I searched for a free video fomat/codec and the theora choice became obvious. However I experienced rather bad performance (at least from a game programming point of view) After a couple a profiling, I discovered, as previous discused in a post found via Google, that the bottleneck is in the ogg library. An unsane part of the

Arc wrote: > Ok so we cap it to 64bit, since much more than that doesn't make sense (96bit > would be a "long double" C type) On x86 CPUs, "long double" is 80 bits. > I really don't like this idea, but I will entertain, formatting it as follows: > > ID Type Bits > 0 Int 8 > 1 uInt 8 > 2 Int 16 > 3 Int 24 > 4 Int