Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2010-10-27T13:30:10Zhttps://gitlab.xiph.org/xiph/ogg/-/issues/484libogg2: ogg_page_getbuffer declaired but not defined2010-10-27T13:30:10ZArc Rileylibogg2: ogg_page_getbuffer declaired but not defined```
ogg_page_getbuffer() appears in ogg2/ogg.h but is not defined anywhere in the libogg2
sources.
``````
ogg_page_getbuffer() appears in ogg2/ogg.h but is not defined anywhere in the libogg2
sources.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/483Incorrect use of 'head' in autogen.sh2006-06-12T11:33:55Zrobert.mossIncorrect use of 'head' in autogen.sh```
autogen.sh uses 'head -1' instead of 'head -n 1'. The former usage is
deprecated, and will not work on a system using the latest version of coreutils.
This will break the build. Attached is a patch which fixes this behaviour.
``````
autogen.sh uses 'head -1' instead of 'head -n 1'. The former usage is
deprecated, and will not work on a system using the latest version of coreutils.
This will break the build. Attached is a patch which fixes this behaviour.
```https://gitlab.xiph.org/xiph/ogg/-/issues/478oggpackB not handling 9 bit values2006-06-12T11:29:55ZGhost UseroggpackB not handling 9 bit values```
There seems to be something screwy with the oggpackB implementation in libogg
1.1. I came across a problem with the theora setup header where if I write out
a value 2 as 9 bits (n_matricies-1) it gets read back as 32. Storing the sa...```
There seems to be something screwy with the oggpackB implementation in libogg
1.1. I came across a problem with the theora setup header where if I write out
a value 2 as 9 bits (n_matricies-1) it gets read back as 32. Storing the same
value in 8 bits works. Also oggpackB_read(opb, 0) does not return 0 like
oggpack_read() does.
Unfortunately I've not been able to construct a simpler test case that
demonstrates the 9 bit issue, but I don't think this is a good sign:
running bitwise.c compiled with -D_V_SELFTEST :
[...LSb tests all ok...]
Small preclipped packing (MSb): ok.
Null bit call (MSb): looked at incorrect value!
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/464[bitwise.c: CVS HEAD] oggpack_writecopy_helper() incorrectly moves buffer poi...2006-06-12T11:25:54ZTim van Holder[bitwise.c: CVS HEAD] oggpack_writecopy_helper() incorrectly moves buffer pointer```
In the HEAD (1.16) version of bitwise.c, the oggpack_writecopy_helper() function
bumps b->buffer (line 175) where previous versions bumped b->endbyte.
Since the 'buffer' field of an oggpack_buffer is an owned pointer when writing,
an...```
In the HEAD (1.16) version of bitwise.c, the oggpack_writecopy_helper() function
bumps b->buffer (line 175) where previous versions bumped b->endbyte.
Since the 'buffer' field of an oggpack_buffer is an owned pointer when writing,
and is free()d in oggpack_writeclear(), this seems like a (fairly major) bug.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/458oggpackB_writeclear() uses different bit packing conventions for source and t...2006-06-12T11:19:10ZTimothy B. TerriberryoggpackB_writeclear() uses different bit packing conventions for source and target buffers```
bitwise.c:177:
if(bits)
w(b,(unsigned long)(ptr[bytes]),bits);
The above line assumes that the last (n%8) bits of the input buffer are always in
the least most significant bits of the last byte.
However, this means one ca...```
bitwise.c:177:
if(bits)
w(b,(unsigned long)(ptr[bytes]),bits);
The above line assumes that the last (n%8) bits of the input buffer are always in
the least most significant bits of the last byte.
However, this means one cannot copy the bits from another oggpack_buffer written
to with oggpackB_write(), as it stores them in the most significant bits of the
last byte.
I.e., oggpackB_write(&opb1,oggpackB_get_buffer(&opb2),oggpackB_bits(&opb2))
fails in general.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/457Typo in bitwise.c:37/mask8B array2003-09-29T17:33:40ZTimothy B. TerriberryTypo in bitwise.c:37/mask8B array```
One of the constants has an extra 0:
-{0x00,0x80,0xc0,0xe0,0xf0,0xf8,0xfc,0xfe0,0xff};
+{0x00,0x80,0xc0,0xe0,0xf0,0xf8,0xfc,0xfe,0xff};
``````
One of the constants has an extra 0:
-{0x00,0x80,0xc0,0xe0,0xf0,0xf8,0xfc,0xfe0,0xff};
+{0x00,0x80,0xc0,0xe0,0xf0,0xf8,0xfc,0xfe,0xff};
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/374libxmms-flac.so references undefined plt symbol2007-06-17T08:42:16Zrretzlaflibxmms-flac.so references undefined plt symbol```
During build of src/plugin_xmms following messages are produced, the
resulting libxmms-flac.so contains undefined reference to plt
FLAC__plugin_common__init_dither_context which is reported when xmms attempts to load the plugin.
Al...```
During build of src/plugin_xmms following messages are produced, the
resulting libxmms-flac.so contains undefined reference to plt
FLAC__plugin_common__init_dither_context which is reported when xmms attempts to load the plugin.
All up looks like libtool suckage
$ libtool --version
ltmain.sh (GNU libtool) 1.4a (1.641.2.255 2001/05/22 10:39:30)
../../libtool-disable-static --mode=link gcc -I../.. -I./include -I../../includ
e -O3 -DNDEBUG -fomit-frame-pointer -funroll-loops -finline-functions -Wall -W -
Winline -DFLaC__INLINE=__inline__ -g -O2 -I/usr/pkg/include -I/usr/pkg/include/
xmms -I/usr/pkg/include/gtk-1.2 -I/usr/pkg/include/glib/glib-1.2 -I/usr/pkg/lib/
glib/include -I/usr/X11R6/include -o libxmms-flac.la -rpath /usr/pkg/lib/xmms
/Input -module -avoid-version charset.lo configure.lo plugin.lo wrap_id3.lo fil
einfo.lo ../../src/plugin_common/libplugin_common.a ../../src/share/grabbag/lib
grabbag.a ../../src/share/gain_analysis/libgain_analysis.a ../../src/share/utf
8/libutf8.a ../../src/libFLAC/libFLAC.la -L../../src/libFLAC/.libs -L/usr/pkg
/lib -L/usr/pkg/lib -Wl,-R/usr/pkg/lib -Wl,-R/usr/X11R6/lib -L/usr/X11R6/lib -L/
usr/X11R6/lib -lgtk -lgdk -lgmodule -lglib -lintl -lXi -lXext -lX11 -lm -lxmms
mkdir .libs
*** Warning: This library needs some functionality provided by ../../src/plugin_common/libplugin_common.a.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have.
*** Warning: This library needs some functionality provided by ../../src/share/grabbag/libgrabbag.a.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have.
*** Warning: This library needs some functionality provided by ../../src/share/gain_analysis/libgain_analysis.a.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have.
*** Warning: This library needs some functionality provided by ../../src/share/utf8/libutf8.a.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/343[RFE] Use ISO C99 types if available2006-06-12T11:04:43Zbero[RFE] Use ISO C99 types if available```
Your configure scripts go through great lengths to figure out the proper variable
types for 8, 16, 32 and 64 bit signed and unsigned; ISO C99 compilers (e.g. gcc
3.x) are required to define them in <stdint.h>, saving quite a lot of...```
Your configure scripts go through great lengths to figure out the proper variable
types for 8, 16, 32 and 64 bit signed and unsigned; ISO C99 compilers (e.g. gcc
3.x) are required to define them in <stdint.h>, saving quite a lot of trouble.
Attaching a patch that uses stdint.h if available and falls back to the old way of
doing things if the compiler is too old.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/295Runtime DLL used in Debug Mode2006-06-12T11:22:35ZGitlab BotRuntime DLL used in Debug Mode```
The DSP for this project is compiled against the DLL runtime library in debug. A
release build uses the static runtime library. This is at worst an annoying
inconsistency, but really should runtime use the static library as most
deve...```
The DSP for this project is compiled against the DLL runtime library in debug. A
release build uses the static runtime library. This is at worst an annoying
inconsistency, but really should runtime use the static library as most
developers (IMHO) use this under Win32.
The change is simple: "Project Settings" -> "C/C++" -> "Code Generation" and set
"Use run-time library" to "debug multithreaded" on the "ogg_static.dsp".
```Stan SeibertStan Seiberthttps://gitlab.xiph.org/xiph/ogg/-/issues/289[PATCH] MacOS building of ogg &amp; vorbis somewhat 'hacky'2009-04-19T20:20:08ZGitlab Bot[PATCH] MacOS building of ogg & vorbis somewhat 'hacky'```
This is my first submission, so bear with me. ;) I'm working with the Torque
Game Engine (garagegames.com), and have a number of Mac projects trying to use
oggvorbis audio support. It has been a bit of a pain.
os_types.h uses tw...```
This is my first submission, so bear with me. ;) I'm working with the Torque
Game Engine (garagegames.com), and have a number of Mac projects trying to use
oggvorbis audio support. It has been a bit of a pain.
os_types.h uses two explicit macros to shunt MacOS and MacOSX builds. I've
locally worked up a solution that does the 'proper' detection of compiler(s) as
an peer solution.
In addition, the other 'hacky' piece is that ogg uses a 'fake' sys/types.h file
in order to compile. But any project trying to build against just the base
headers will then fail under Codewarrior/Mac (under GCC/Project Builder, a real
sys/types.h exists...). My solution was to inline the types, which should be
safe on the Mac given any Codewarrior from the last few years.
I'd love to get this, and other, Mac-side enhancements checked into the
mainline tree to try to improve the 'Mac user experience'. (Other things I've
done, and could clean up for submission, include a Carbon-safe build.)
Regards,
David Chait
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/ogg/-/issues/245libogg's $(includedir) blitzing makes baby Jesus cry2009-04-19T20:17:38ZGitlab Botlibogg's $(includedir) blitzing makes baby Jesus cry```
In include/ogg/Makefile.am, you do:
includedir = $(prefix)/include/ogg
This makes those of us packaging libogg for the LNX-BBC very sad, as we keep
headers off in a side directory that doesn't get installed on the space-limited
Boo...```
In include/ogg/Makefile.am, you do:
includedir = $(prefix)/include/ogg
This makes those of us packaging libogg for the LNX-BBC very sad, as we keep
headers off in a side directory that doesn't get installed on the space-limited
Bootable Business Card. You should find some other way of appending "ogg" to
the $(includedir) variable that makes it so we don't have to hack around you.
Right now when I set --includedir= in the configure script, it is ignored. This
is just bad behavior.
Also, your bug system makes me jump through a ridiculous set of hoops just to
file a fucking bug. Why the hell should *I* set up an account? It's not like
any bugs will be assigned to me or anything. Just store my e-mail address and
move on. It's completely fucking bogus that I should have to go digging through
my mail for confirmation passwords sent by the mailer-daemon address. You're
lucky you get any bugs at all what with the barriers you put up. GARGARGAR!
Also, how come there are no versions in this thing later than rc3? Is anyone
actually using this bug system any more? Have you all moved on to something
sane like debbugs?
Oooh! Bug writing guidelines! Maybe I should follow that link and then submit
this to STRUNK and WHITE! Maybe the dizzying maze of input boxes aren't
STRUCTURE ENOUGH for this thing.
Any serious bug system would have, right on the front page, a big red button
marked "FILE A BUG". It should be easy to file, and then easy to triage. By
using bojira, YOU RUINED CHRISTMAS!
Oh yeah, and I love this doozy:
Bugzilla version 2.14.1
Posting Bug
One moment please...
The name baby jesus is not a valid username. Either you misspelled it, or the
person has not registered for a Bugzilla account.
Please hit the Back button and try again.
The BACK BUTTON, for krissakes. You'd think the folks who DESIGNED A WEB
BROWSER would know how to MAKE A WEB APP that didn't SUCK ARSE in the UI
department! I'll just use my BACK BUTTON to KEY IN MY BUG IN MORSE WHY DON'T I.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/229shared library not built2006-06-12T11:13:16Zshattyshared library not built```
When compiling everything goes smoothly except that a small warning is displayed:
warning: undefined symbols not allowed in beos shared libraries
And libogg.so is not built. (libogg.a is built) The fix is to add
-no-undefined to ...```
When compiling everything goes smoothly except that a small warning is displayed:
warning: undefined symbols not allowed in beos shared libraries
And libogg.so is not built. (libogg.a is built) The fix is to add
-no-undefined to the libtool link arguments. (in Makefile.am/Makefile.in)
old version:
libogg_la_LDFLAGS = -version-info @LIB_CURRENT@:@LIB_REVISION@:@LIB_AGE@
new version:
libogg_la_LDFLAGS = -no-undefined -version-info
@LIB_CURRENT@:@LIB_REVISION@:@LIB_AGE@
With this patch the library builds and works fine. (Tested with vorbis-tools.)
This patch informs libtool that this particular library has no undefined symbols
and so it can be built without problems on beos. (or any other platform without
the ability to compile/use libs with undefined symbols.)
Andrew Bachmann
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/222devel rpm doesn't include aclocal/ogg.m42002-07-29T18:45:54Znoadevel rpm doesn't include aclocal/ogg.m4```
The devel rpm doesn't include /usr/share/aclocal/ogg.m4 in it's file list,
therefore it doesn't get pacakged and distributed.
Should be fixed I guess.
``````
The devel rpm doesn't include /usr/share/aclocal/ogg.m4 in it's file list,
therefore it doesn't get pacakged and distributed.
Should be fixed I guess.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/163minor problem in in_vorbis plugin and may be ...2002-02-20T07:16:24Zxakepminor problem in in_vorbis plugin and may be ...```
my own encoder of ogg (write on pascal) make test.ogg. Winamp (with in_vorbis
plugin) playing him is normal (without artefacts), but decoder from vorbis_sdk
tools make garbage-like WAV file. :(
I place my test.ogg in followed link...```
my own encoder of ogg (write on pascal) make test.ogg. Winamp (with in_vorbis
plugin) playing him is normal (without artefacts), but decoder from vorbis_sdk
tools make garbage-like WAV file. :(
I place my test.ogg in followed link, please download and test this situation.
Thanks.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/152MSVC project settings for ogg_static_d.lib cause linker errors when used with...2006-06-12T11:39:41ZGitlab BotMSVC project settings for ogg_static_d.lib cause linker errors when used with "Debug Multithreaded" libs```
The project settings for ogg_static_d.lib default to "Debug Multithreaded
DLL". When I changed them to "Debug Multithreaded" to work with my
application, I still got linker errors that indicated something was linked with
the DLL ...```
The project settings for ogg_static_d.lib default to "Debug Multithreaded
DLL". When I changed them to "Debug Multithreaded" to work with my
application, I still got linker errors that indicated something was linked with
the DLL libs. Specific errors:
Linking...
MSVCRTD.lib(MSVCRTD.dll) : error LNK2005: _malloc already defined in libcmtd.lib
(dbgheap.obj)
MSVCRTD.lib(MSVCRTD.dll) : error LNK2005: _free already defined in libcmtd.lib
(dbgheap.obj)
MSVCRTD.lib(MSVCRTD.dll) : error LNK2005: _memmove already defined in
libcmtd.lib(memmove.obj)
MSVCRTD.lib(MSVCRTD.dll) : error LNK2005: _realloc already defined in
libcmtd.lib(dbgheap.obj)
LINK : warning LNK4098: defaultlib "MSVCRTD" conflicts with use of other libs;
use /NODEFAULTLIB:library
.\WinDebug/Game.exe : fatal error LNK1169: one or more multiply defined symbols
found
Error executing link.exe.
Cause: There are two files in the ogg_static project that are individually set
to use the "Debug Multithreaded DLL" libraries, and they do not change with the
project settings.
To fix: Open the ogg_static project with MSVC, go to Project->Settings, make
sure the active project ("Settings for:") is Win32Debug, select bitwise.c,
switch to the C++ tab, and hit the "Reset" button. This should not change the
file's settings, but it will set it to sync with the project settings, so that
changes to the entire Debug project will affect the individual file. Do the
same for framing.c.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/125media type audio/x-ogg or application/x-ogg should be added to Apache mime.types2002-01-11T11:17:12Zyusufgmedia type audio/x-ogg or application/x-ogg should be added to Apache mime.types```
Hi, I recommend the designers of Ogg vorbis decide on a media/mime type for
Ogg/Vorbis and submit it for inclusion to the Apache group. I suggest either
1) audio/x-ogg
2) application/x-ogg
With the media-type available, one can th...```
Hi, I recommend the designers of Ogg vorbis decide on a media/mime type for
Ogg/Vorbis and submit it for inclusion to the Apache group. I suggest either
1) audio/x-ogg
2) application/x-ogg
With the media-type available, one can then utilise Apaches mod_expires module
to generate cache-friendly headers for ogg file which speeds up serving ogg
streams to people behind ISP proxy caches
http://httpd.apache.org/docs/mod/mod_expires.html
This mechanism is explained in depth at
http://www.mnot.net/cache_docs/
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/104ogg.m4 refers to ogg-config2006-06-12T10:47:55ZGitlab Botogg.m4 refers to ogg-config```
Some leftovers in the ogg.m4 apparently, put me on a wild goosechase for a few
minutes :)
In ogg.m4, if configure fails to compile the test program, the error message
incorrectly mentions "ogg-config"
(Do I get extra credit for m...```
Some leftovers in the ogg.m4 apparently, put me on a wild goosechase for a few
minutes :)
In ogg.m4, if configure fails to compile the test program, the error message
incorrectly mentions "ogg-config"
(Do I get extra credit for most trivial 'bug'?)
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/94100189582017-04-07T21:51:41Zgumboot10018958```
ogg123 links against /usr/lib/libvorbis.so (which fails because it's out of date) despite there being a /usr/local/lib/libvorbis.so present. This is done explicity in the command issued by make:
gcc -O20 -ffast-math -fsigned-char...```
ogg123 links against /usr/lib/libvorbis.so (which fails because it's out of date) despite there being a /usr/local/lib/libvorbis.so present. This is done explicity in the command issued by make:
gcc -O20 -ffast-math -fsigned-char -o oggenc oggenc.o audio.o encode.o \
platform.o /usr/lib/libvorbis.so -L/lib /usr/lib/libvorbisenc.so -lm \
/usr/lib/libogg.so ../share/libutf8.a ../share/libgetopt.a
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/ogg/-/issues/91documentation doesn't mention gmake requirement2006-06-12T11:25:10Znisharfidocumentation doesn't mention gmake requirement```
comatoast@dymaxion: ~/cvsSandbox/ogg> make
Making all in src
Bad modifier: )
Unclosed variable specification
"Makefile", line 242: Need an operator
Fatal errors encountered -- cannot continue
*** Error code 1
unsurprisingly, neithe...```
comatoast@dymaxion: ~/cvsSandbox/ogg> make
Making all in src
Bad modifier: )
Unclosed variable specification
"Makefile", line 242: Need an operator
Fatal errors encountered -- cannot continue
*** Error code 1
unsurprisingly, neither $GZIP_ENV nor $TAR are defined in my shell.
```Segher BoessenkoolSegher Boessenkoolhttps://gitlab.xiph.org/xiph/ogg/-/issues/80crc block generation doesn't set crc_ready2006-06-12T10:57:30Ztimjcrc block generation doesn't set crc_ready```
the end of _ogg_crc_init() should actually read:
crc_ready=1; instead of the current crc_ready=0;
``````
the end of _ogg_crc_init() should actually read:
crc_ready=1; instead of the current crc_ready=0;
```Monty MontgomeryMonty Montgomery