Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2004-07-24T01:52:49Zhttps://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/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/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/520Failure to compile under Cygwin 1.5.72010-10-27T13:34:31Zjari.aaltoFailure to compile under Cygwin 1.5.7```
The current library does not compile under latest W2k/Cygwin. See below.
mv -f .libs/bitwise.lo bitwise.lo
/bin/bash ../libtool --mode=link gcc -O20 -fsigned-char -o libogg.la -
rpath /usr/lib -no-undefined -version-info 5:0:5 f...```
The current library does not compile under latest W2k/Cygwin. See below.
mv -f .libs/bitwise.lo bitwise.lo
/bin/bash ../libtool --mode=link gcc -O20 -fsigned-char -o libogg.la -
rpath /usr/lib -no-undefined -version-info 5:0:5 framing.lo bitwise.lo
rm -fr .libs/libogg.la .libs/libogg.* .libs/libogg.*
generating symbol list for `libogg.la'
dlltool --export-all --exclude-symbols
DllMain@12,_cygwin_dll_entry@12,_cygwin_noncygwin_dll_entry@12,DllMainCRTStartup
@12,DllEntryPoint@12 --output-def .libs/cygogg-0.dll-def framing.lo bitwise.lo
sed -e "1,/EXPORTS/d" -e "s/ @ [0-9]*//" -e "s/ *;.*$//" < .libs/cygogg-0.dll-
def > .libs/libogg.exp
if test "x`sed 1q .libs/libogg.exp`" = xEXPORTS; then
cp .libs/libogg.exp .libs/cygogg-0.dll-def; else echo EXPORTS > .libs/cygogg-
0.dll-def; _lt_hint=1; cat .libs/libogg.exp | while read symbol; do set dummy
$symbol; case $# in 2) echo " $2 @ $_lt_hint ; " >> .libs/cygogg-0.dll-def;; 4)
echo " $2 $3 $4 ; " >> .libs/cygogg-0.dll-def; _lt_hint=`expr $_lt_hint - 1`;;
*) echo " $2 @ $_lt_hint $3 ; " >> .libs/cygogg-0.dll-def;; esac;
_lt_hint=`expr 1 + $_lt_hint`; done; fi
gcc -Wl,--base-file,.libs/cygogg-0.dll-base -Wl,-e,__cygwin_dll_entry@12 -
o .libs/cygogg-0.dll framing.lo bitwise.lo
/bin/../lib/gcc-lib/i686-pc-cygwin/3.3.1/../../../libcygwin.a(libcmain.o)
(.text+0x7c): undefined reference to `_WinMain@16'
collect2: ld returned 1 exit status
make[1]: *** [libogg.la] Error 1
make[1]: Leaving directory `/usr/src/build/try/libogg-1.1/.build/.build/src'
make: *** [all-recursive] Error 1
/bin/cygbuild.sh.CygbuildCommandMain: [FATAL] status is 2.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/503better multiplexing example image2017-04-08T00:51:34Zin7y118better multiplexing example image```
The current image gives the impression that the final pages of a stream have to
be directly after each other, like the start pages.
It would be better if there were a normal data page displayed in between.
``````
The current image gives the impression that the final pages of a stream have to
be directly after each other, like the start pages.
It would be better if there were a normal data page displayed in between.
```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 Montgomeryhttps://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/489libogg2 threading doesn't work on FreeBSD2010-10-27T13:32:37ZArc Rileylibogg2 threading doesn't work on FreeBSD```
On FreeBSD there is no -lpthread, we use -pthread instead. libogg2 does not work with -pthread, which means threading needs to be disabled on BSD* platforms for it to compile.
``````
On FreeBSD there is no -lpthread, we use -pthread instead. libogg2 does not work with -pthread, which means threading needs to be disabled on BSD* platforms for it to compile.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/486libogg2's bitpackers cannot be init. due to missing structs2006-06-12T11:35:35ZArc Rileylibogg2's bitpackers cannot be init. due to missing structs```
In order to call oggpack_writeinit or oggpack_readinit you need to pass a oggpack_buffer, just
as you have to pass ogg_page and ogg_packet objects to other functions, however the
structure for oggpack_buffer has been removed from o...```
In order to call oggpack_writeinit or oggpack_readinit you need to pass a oggpack_buffer, just
as you have to pass ogg_page and ogg_packet objects to other functions, however the
structure for oggpack_buffer has been removed from ogg2/ogg.h (only in ogginternal.h).
This needs to be fixed before any further work can go into py-ogg2 or libwrit.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/485libogg2: direct access to change page header fields2010-10-27T13:31:16ZArc Rileylibogg2: direct access to change page header fields```
Alot of the uses I've found for libogg1 (py-ogg1) have been repairing Ogg streams, extracting
one logical bitstream from an Icecast archive, or other things which could take place entirely
within ogg_sync_state (to get ogg_page obj...```
Alot of the uses I've found for libogg1 (py-ogg1) have been repairing Ogg streams, extracting
one logical bitstream from an Icecast archive, or other things which could take place entirely
within ogg_sync_state (to get ogg_page objects), then editing the header fields of the pages to
change the CONT/BOS/EOS flags, granulepos, serialno, etc.
In one case, the Indymedia global radio stream at http://liveradio.indymedia.org/ is mixed on
the server using Python code that takes several different sources (live, playlist, etc) and mixes
them based on a schedule. This uses py-ogg1 to make the stream being sent to Icecast legal
and sequential serialno's, especially when the source streams get chopped off midway.
This is also useful for intentionally creating mangled test streams for testing codec software,
Icecast, etc.
With libogg2 moving to ogg_references instead of character buffers for the ogg_page header
and body fields, this is no longer possible. ogg_reference is not currently exposed, nor are
there functions for editing these values, so the only way to edit this data would be to send the
ogg_page objects into a second ogg_sync_state buffer then use ogg_sync_bufferout before
editing the fields, then into a third ogg_sync_state buffer to turn it back into an ogg_page.
Bug 484 ( http://bugs.xiph.org/show_bug.cgi?id=484 ), the declaired but not defined
ogg_page_getbuffer, may make this easier. But it would still involve re-importing the edited
data into another ogg_sync_state buffer.
It should be noted that, without the ability to edit the ogg_page header/body contents, having
ogg_page_checksum_set exposed serves no purpose.
```Monty MontgomeryMonty Montgomeryhttps://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 Seibert