search for: ogg_

Hi, I've started working on libogg2 support in liboggz and Tremor support in libfishsound. I'm running into some problems with namespace clashes. Specifically, each of libogg, libogg2 and libvorbisidec (Tremor) define conflicting ogg_* symbols and declare incompatible ogg_* types in their headers. While I understand that a dedicated Ogg Vorbis decoder would only need to use one of these libraries, that can't always be guaranteed in general media frameworks. Consider two situations: * a media framework that separates demux...

..., but: Could someone please tell me which of the two is the compression algorithm and which of the two is the framing methodology? From what I can figure, Vorbis is the compression and OGG is the framing. What is confusing me is the fact that libvorbis has a bunch of functions that start with ogg_, so I'm wondering if it should really be libogg instead. Basically, I'm more interested in the compression algorithm than the framing one, because I will most likely be using UDP or some other Internet packet protocol to send the data from my server to the client. Thanks. Tim -=-=-=-...

...and flac/vorbiscomment.c that won't work if get_utf8_argv() failed: ... #ifdef _WIN32 /* everything in UTF-8 already. Must not alter */ ... So, flac.exe calls get_utf8_argv(), then calls encode_file() which uses flac_fopen() itself, and then indirectly calls FLAC__stream_encoder_init_{ogg_}file() from libFLAC. One of the parameters of this function is const char *filename. Since filename is an UTF-8 encoded string, this libFLAC function must call file functions from share/win_utf8_io/win_utf8_io.c. ****** TL;DR: some functions in libFLAC/stream_decoder.c, libFLAC/stream_encoder.c...

I am having problems with my program decoding .ogg files on the Win64 platform and am wondering if this is a known issue or not. I have tried using the prebuilt .dll's, the static .lib's and building from source (1.1.3) and I get the same results. My program is being compiled on a win32 platform, but the decoder fails if I run it on a win64 system. Unfortunately this is being reported

...B, _VORBISLIB and _VORBISENCLIB), and 2) added MS specific #pragma pack statements to allow for fixed structure element alignment seperate to my projects desired structure element alignment. If you have questions, I'd be glad to field them. One further note, header file naming conventions. All ogg_ prefixed functions are in ogg.h, all vorbis_ prefixed functions are in vorbis.h and all vorbisenc_ prefixed functions are in codec.h (note the differenct and discontinuity?). All together, nice job folks. I hope these changes can make it into the code in the next version. It would greatly help to...

...played. My current attack is as follows (note this isn't very robust and I realized that): For first and second packet i grab all the header stuff in the same way as decoder_example. From the third packet on, I send it to a bunch of code: float **pcm; int samples; buffer=ogg_sync_buffer(&oy,4096); bytes = 4096; buffer = memcpy (buffer, data, bytes); ogg_sync_wrote(&oy,bytes); ogg_sync_pageout(&oy,&og); ogg_stream_pagein(&os,&og); /* can safely ignore errors at this point */...

...defined for metadata. This is a >better solution than id3 in just about every technical sense. The Ogg >bitstream code to support this already exists. Can you please elaborate? Is this functionality complete? The only mention to metadata in the codebase that I can find is in codec.h: /* ogg_packet is used to encapsulate the data and metadata belonging to a single raw Ogg/Vorbis packet *************************************/ Looking at ogg_packet its not clear to me what I need to do here. Do you use some other nomenclature in the codebase? >The comment fields in the Vorbis heade...