Ogg issueshttps://gitlab.xiph.org/xiph/ogg/-/issues2003-09-29T17:33:40Zhttps://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/2197Ten off by one errors ?2019-08-13T16:56:04ZDavid BindermanTen off by one errors ?[timespec.c:123]: (error) Width 16 given in format string (no. 1) is larger than destination buffer 'timespec[16]', use %15s to prevent overflowing it.
[timespec.c:127]: (error) Width 16 given in format string (no. 1) is larger than dest...[timespec.c:123]: (error) Width 16 given in format string (no. 1) is larger than destination buffer 'timespec[16]', use %15s to prevent overflowing it.
[timespec.c:127]: (error) Width 16 given in format string (no. 1) is larger than destination buffer 'timespec[16]', use %15s to prevent overflowing it.
[timespec.c:131]: (error) Width 16 given in format string (no. 1) is larger than destination buffer 'timespec[16]', use %15s to prevent overflowing it.
[timespec.c:135]:
timespec.c:139
timespec.c:143
timespec.c:147
timespec.c:151
timespec.c:155Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/549sync-to-sync data loss2004-07-24T01:52:49ZArc Rileysync-to-sync data loss```
I believe there to be a bug in sync.c's buffer handling whereas it doesn't
appear to be incrementing the buffer size when pages that come from one
ogg_sync_state object are passed into another. In the tests I've run, using
Vorbis...```
I believe there to be a bug in sync.c's buffer handling whereas it doesn't
appear to be incrementing the buffer size when pages that come from one
ogg_sync_state object are passed into another. In the tests I've run, using
Vorbis files to test with, I've been getting between 30% to 40% of the page
data I put in.
The data comes out unmangled but "short" in length. ogginfo shows the output
to be a normal Vorbis file, only shorted than it should be and lacking EOS.
I have only seen this error by using py-ogg2 and have not attempted to
replicate this with a C program, however I looked trough py-ogg2's sync.c and
saw nothing that could cause a bug such as this. It's really just glue code
between Python and libogg2, and it seems to work fine for full encoding and
decoding.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/548sync-to-sync data loss2004-07-24T01:53:10ZArc Rileysync-to-sync data loss```
I believe there to be a bug in sync.c's buffer handling whereas it doesn't
appear to be incrementing the buffer size when pages that come from one
ogg_sync_state object are passed into another. In the tests I've run, using
Vorbis...```
I believe there to be a bug in sync.c's buffer handling whereas it doesn't
appear to be incrementing the buffer size when pages that come from one
ogg_sync_state object are passed into another. In the tests I've run, using
Vorbis files to test with, I've been getting between 30% to 40% of the page
data I put in.
The data comes out unmangled but "short" in length. ogginfo shows the output
to be a normal Vorbis file, only shorted than it should be and lacking EOS.
I have only seen this error by using py-ogg2 and have not attempted to
replicate this with a C program, however I looked trough py-ogg2's sync.c and
saw nothing that could cause a bug such as this. It's really just glue code
between Python and libogg2, and it seems to work fine for full encoding and
decoding.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/1654support 64bit version of libogg and libvorbis under macosx snow leopard2020-11-06T03:59:56ZVittorio G.support 64bit version of libogg and libvorbis under macosx snow leopardI've been using the 64 bit versions from quite some time and i have no issues to report.
However it would be nice to have the sources compatible with the new architecture
for libogg you just need to remove the line
```
#include <Carbon/...I've been using the 64 bit versions from quite some time and i have no issues to report.
However it would be nice to have the sources compatible with the new architecture
for libogg you just need to remove the line
```
#include <Carbon/Carbon.h>
```
from Ogg_Prefix.pch
and in both project you need to set "gcc-4.0" as default compiler.
A further step could be to set "build type" to "universal 32/64" but i don't know how this would affect pre 10.6 build systems.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/545start-time granulepos2010-10-27T13:35:26ZArc Rileystart-time granulepos```
libogg2 lacks ability to handle start-time granulepos, as is used by
discontinuous codecs. the library needs a way to be told that a stream is
discontinuous for ogg_stream_state to handle the proper packet<->page mapping
of these...```
libogg2 lacks ability to handle start-time granulepos, as is used by
discontinuous codecs. the library needs a way to be told that a stream is
discontinuous for ogg_stream_state to handle the proper packet<->page mapping
of these fields.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/60src/Makefile.am doesn't work with outside-the-tree builds2006-06-12T11:23:31Zahltorpsrc/Makefile.am doesn't work with outside-the-tree builds```
The Makefile.am in src/Makefile.am does not properly set the include path
if building in a separate obj directory. The patch below fixes that problem.
Index: Makefile.am
=========================================================
===...```
The Makefile.am in src/Makefile.am does not properly set the include path
if building in a separate obj directory. The patch below fixes that problem.
Index: Makefile.am
=========================================================
==========
RCS file: /usr/local/cvsroot/ogg/src/Makefile.am,v
retrieving revision 1.3
diff -u -r1.3 Makefile.am
--- Makefile.am 2000/11/02 20:11:33 1.3
+++ Makefile.am 2001/10/08 01:29:52
@@ -2,7 +2,7 @@
AUTOMAKE_OPTIONS = foreign
-INCLUDES = -I../include
+INCLUDES = -I../include -I$(top_srcdir)/include
lib_LTLIBRARIES = libogg.la
```Jack MoffittJack Moffitthttps://gitlab.xiph.org/xiph/ogg/-/issues/498sizeof(long) on x86_64 is 8 bytes, things break2004-03-08T07:16:59ZGitlab Botsizeof(long) on x86_64 is 8 bytes, things break```
libogg is using long for nearly all bitwise operations and sometimes with 32bit
types without a cast. this brakes some functions which imply that bits outside
of 32 bit are cleared.
for example on x86_64 (amd64),
from cvs_nightly,
b...```
libogg is using long for nearly all bitwise operations and sometimes with 32bit
types without a cast. this brakes some functions which imply that bits outside
of 32 bit are cleared.
for example on x86_64 (amd64),
from cvs_nightly,
bitwise.c, function oggpackB_read :
unsigned long ret;
..
ret= b->ptr[0]<<(24+b->endbit);
if endbit is zero and the highest bit of ptr[0] is set, the value of ptr[0] is
shifted, converted to signed int, and sign extended to 64 bits before stored in
the unsigned variable ret.
this brakes programs using these libogg functions.
```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/1581segfault in _oggz_comment_add_byname2017-08-26T14:29:54Zkeelerdasegfault in _oggz_comment_add_bynameoggz_comments_decode calls _oggz_comment_add_byname with "value" as NULL under certain situations. This can then sometimes cause _oggz_comment_add_byname to try to run strcmp on NULL, which fails.oggz_comments_decode calls _oggz_comment_add_byname with "value" as NULL under certain situations. This can then sometimes cause _oggz_comment_add_byname to try to run strcmp on NULL, which fails.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/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/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/564oggpack_writecopy_helper erroneously updates b->buffer2004-09-01T00:43:19ZTimothy B. Terriberryoggpack_writecopy_helper erroneously updates b->buffer```
At the end of the aligned block copy path in oggpack_writecopy_helper, the
current code increments b->buffer, which is supposed to be a pointer to the
start of an allocated block of memory, that can later be realloc'd by one of the
o...```
At the end of the aligned block copy path in oggpack_writecopy_helper, the
current code increments b->buffer, which is supposed to be a pointer to the
start of an allocated block of memory, that can later be realloc'd by one of the
oggpack*_write functions or free'd. Instead, endbyte is the member that should
be adjusted.
--- bitwise.c (revision 7651)
+++ bitwise.c (working copy)
@@ -172,7 +172,7 @@
memmove(b->ptr,source,bytes);
b->ptr+=bytes;
- b->buffer+=bytes;
+ b->endbyte+=bytes;
*b->ptr=0;
}
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/21oggpack_read() return value not well defined2006-06-12T11:31:37ZSegher Boessenkoologgpack_read() return value not well defined```
If <long> is 32 bit on your platform, the return value -1 can mean
two different things: an out of data error occured, or we just read
32 bits, all 1.
And there's a signed/unsigned issue as well.
I'll convert everything that needs ...```
If <long> is 32 bit on your platform, the return value -1 can mean
two different things: an out of data error occured, or we just read
32 bits, all 1.
And there's a signed/unsigned issue as well.
I'll convert everything that needs to be unsigned, in ogg as well as
in vorbis.
This will get rid of a lot of compiler warnings on non-x86 and non-gcc
platforms...
```Segher BoessenkoolSegher Boessenkoolhttps://gitlab.xiph.org/xiph/ogg/-/issues/23oggenc manpage and --help disagree on default bitrate2006-06-12T10:41:39Zjemorrisoggenc manpage and --help disagree on default bitrate```
The oggenc manpage says
-b n, --bitrate=n
Sets encoding to the bitrate closest to n (in
kb/s). Defaults to 160 kb/s for stereo.
And oggenc --help says (under MODES)
The default is the 128 k...```
The oggenc manpage says
-b n, --bitrate=n
Sets encoding to the bitrate closest to n (in
kb/s). Defaults to 160 kb/s for stereo.
And oggenc --help says (under MODES)
The default is the 128 kbps mode.
(I think line 54 of oggenc.c sets the actual default to 128.)
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/634oggcodecs: Still can not play ogg files2020-11-06T03:56:13ZGitlab Botoggcodecs: Still can not play ogg filesI have dowloaded the oggcodecs_0.69.8924 but windows media player and any other player will not play ogg files. Before I ran the file I removed any other ogg files and I closed all of the open files. I am running Windows XP.I have dowloaded the oggcodecs_0.69.8924 but windows media player and any other player will not play ogg files. Before I ran the file I removed any other ogg files and I closed all of the open files. I am running Windows XP.Gitlab BotGitlab Bothttps://gitlab.xiph.org/xiph/ogg/-/issues/1845ogg_int64_t incorrect on 64/32bit multilib systems2017-08-26T14:29:54ZJonathan Hamiltonogg_int64_t incorrect on 64/32bit multilib systemsOn a x86_64 system, the autoconf created header config_types.h is used to define ogg sized types, including 'ogg_int64_t' as 'long'.
This causes 32bit compilers using this header to break, as 'long' is only 32 bits using such a compiler...On a x86_64 system, the autoconf created header config_types.h is used to define ogg sized types, including 'ogg_int64_t' as 'long'.
This causes 32bit compilers using this header to break, as 'long' is only 32 bits using such a compiler.
This can be recreated simply with the attached C program.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/544ogg_buffer_create missing from ogg2/ogg.h2010-10-27T13:35:06ZArc Rileyogg_buffer_create missing from ogg2/ogg.h```
ogg_buffer_create is needed to pass new buffers to the bitpacker.
ogg_buffer_state *ogg_buffer_create(void);
``````
ogg_buffer_create is needed to pass new buffers to the bitpacker.
ogg_buffer_state *ogg_buffer_create(void);
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/501ogg.m4:8: warning: underquoted definition of XIPH_PATH_OGG2004-01-26T10:32:20Zalexander.winstonogg.m4:8: warning: underquoted definition of XIPH_PATH_OGG```
Automake-1.8 complains that vorbis.m4 has an underquoted definition of
XIPH_PATH_OGG. According to
<http://mail.gnu.org/archive/html/libtool-patches/2002-10/msg00031.html>, these
are known to cause problems and possibly even severer ...```
Automake-1.8 complains that vorbis.m4 has an underquoted definition of
XIPH_PATH_OGG. According to
<http://mail.gnu.org/archive/html/libtool-patches/2002-10/msg00031.html>, these
are known to cause problems and possibly even severer errors in the future.
Therefore, I am attaching a patch that quotes XIPH_PATH_OGG.
(This bug is related to bug 500.)
```Monty MontgomeryMonty Montgomery