Ogg issues
https://gitlab.xiph.org/xiph/ogg/-/issues
2020-11-06T04:06:07Z
https://gitlab.xiph.org/xiph/ogg/-/issues/2290
liboggplay mishandles live ogg streams in Firefox
2020-11-06T04:06:07Z
Miles
liboggplay mishandles live ogg streams in Firefox
(speculation)
See the following bug on Mozilla's tracker:
https://bugzilla.mozilla.org/show_bug.cgi?id=611519
Seems pretty likely the bug is actually in liboggplay. When an audio element points to a live stream and it is played in the...
(speculation)
See the following bug on Mozilla's tracker:
https://bugzilla.mozilla.org/show_bug.cgi?id=611519
Seems pretty likely the bug is actually in liboggplay. When an audio element points to a live stream and it is played in the browser, it works fine for roughly 20 minutes before severe stutter sets in. Pressing play also tends to play permanently cached audio instead of the actual stream. Is liboggplay perhaps treating this case as an infinitely large file transfer instead of a live stream?
Monty Montgomery
Monty Montgomery
https://gitlab.xiph.org/xiph/ogg/-/issues/2260
Buffer overflow in liboggz, httpdate.c, function httpdate_parse
2018-08-08T17:44:41Z
hanno
Buffer overflow in liboggz, httpdate.c, function httpdate_parse
The function httpdate_parse writes 4 bytes to the three byte variables wday and month. These are supposed to store a 3 byte string, however that misses that the string needs a null terminating byte. Making the variables 4 bytes fixes thi...
The function httpdate_parse writes 4 bytes to the three byte variables wday and month. These are supposed to store a 3 byte string, however that misses that the string needs a null terminating byte. Making the variables 4 bytes fixes this.
Also the parser string should limit the size of the month string. See attached patch.
This bug was found with the help of address sanitizer. Can be reproduced by compiling liboggz with -fsanitize=address in CFLAGS+LDFLAGS and running make check.
Monty Montgomery
Monty Montgomery
https://gitlab.xiph.org/xiph/ogg/-/issues/2197
Ten off by one errors ?
2019-08-13T16:56:04Z
David Binderman
Ten 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:155
Monty Montgomery
Monty Montgomery
https://gitlab.xiph.org/xiph/ogg/-/issues/2043
ogg-index produces multiple fisbones with the same name and role, where the i...
2020-11-06T04:02:56Z
Nick Burch
ogg-index produces multiple fisbones with the same name and role, where the input has several video or audio streams
If you use OggIndex on a file without a Skeleton stream, which has one Vorbis and one Theora stream in it, the resultant Skeleton fisbones will be correct. However, if you use it on a file with multiple Theora or Vorbis streams, it will ...
If you use OggIndex on a file without a Skeleton stream, which has one Vorbis and one Theora stream in it, the resultant Skeleton fisbones will be correct. However, if you use it on a file with multiple Theora or Vorbis streams, it will generate incorrect fisbones for the second and subsequent streams of the type, as it hard codes the name and role
Instead, OggIndex should check which stream this is of a given type, and use that to assign sequential names (eg audio_1, audio_2) rather than hardcoded (eg audio_1 for everything), and flag subsequent streams of a type as alternate ones (rather than hard coded as the main one)
https://gitlab.xiph.org/xiph/ogg/-/issues/2042
ogg-index fails with an unhelpful error message if the file contains Speex or...
2020-11-06T04:03:32Z
Nick Burch
ogg-index fails with an unhelpful error message if the file contains Speex or Opus streams
If you try running ogg-index on a file which contains Opus or Speex streams (eg a Theora + Opus file), then you get a rather unfriendly error such as
`FAIL: Unhandled stream type, serialno=478384172 aborting indexing!`
Where the stream...
If you try running ogg-index on a file which contains Opus or Speex streams (eg a Theora + Opus file), then you get a rather unfriendly error such as
`FAIL: Unhandled stream type, serialno=478384172 aborting indexing!`
Where the stream number is that of the Speex or Opus stream
Assuming it's not trivial to add support for those formats, it would be nice if ogg-index could instead give a more helpful message such as _Opus not supported (stream serialno=478384172) - aborting indexing! _
https://gitlab.xiph.org/xiph/ogg/-/issues/2041
ogg-index sets incorrect fisbone message header offset in the skeleton stream
2020-11-06T04:05:16Z
Nick Burch
ogg-index sets incorrect fisbone message header offset in the skeleton stream
According to http://svn.annodex.net/standards/draft-pfeiffer-oggskeleton-current.txt , in the skeleton fisbone,
> Offset to message header fields: 4 Byte unsigned integer that
> contains the number of Bytes used in this packet before t...
According to http://svn.annodex.net/standards/draft-pfeiffer-oggskeleton-current.txt , in the skeleton fisbone,
> Offset to message header fields: 4 Byte unsigned integer that
> contains the number of Bytes used in this packet before the
> message header fields. For the version of the skeleton
> bitstream described in this document this number is fixed to 44.
The skeleton stream generated by things like ffmpeg2theora and speexenc set the message header offset to be 44, which is the position less the fisbone\0 header
However, ogg-index creates fisbones where the message header offset is 0x2c=52, which is the offset including the fisbone\0 header, which (based on the docs) seems to be incorrect
Note that it is only the offset that is wrong, the message headers start in the expected place at 44 bytes after the fisbone header / 52 bytes after the start of the fisbone packet data
https://gitlab.xiph.org/xiph/ogg/-/issues/1970
build fails using libtool
2020-11-06T03:58:06Z
John T. Vonachen
build fails using libtool
While building libogg for use with sox, build for libogg version 1.3.1 failed with the following output:
make all-recursive
make[1]: Entering directory `/root/kalebmusic/libogg-1.3.1'
Making all in src
make[2]: Entering directory `/roo...
While building libogg for use with sox, build for libogg version 1.3.1 failed with the following output:
make all-recursive
make[1]: Entering directory `/root/kalebmusic/libogg-1.3.1'
Making all in src
make[2]: Entering directory `/root/kalebmusic/libogg-1.3.1/src'
/bin/bash ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I../include -I../include -O20 -Wall -ffast-math -fsigned-char -g -O2 -MT framing.lo -MD -MP -MF .deps/framing.Tpo -c -o framing.lo framing.c
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I../include -I../include -O20 -Wall -ffast-math -fsigned-char -g -O2 -MT framing.lo -MD -MP -MF .deps/framing.Tpo -c framing.c -fPIC -DPIC -o .libs/framing.o
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I../include -I../include -O20 -Wall -ffast-math -fsigned-char -g -O2 -MT framing.lo -MD -MP -MF .deps/framing.Tpo -c framing.c -o framing.o >/dev/null 2>&1
mv -f .deps/framing.Tpo .deps/framing.Plo
/bin/bash ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I../include -I../include -O20 -Wall -ffast-math -fsigned-char -g -O2 -MT bitwise.lo -MD -MP -MF .deps/bitwise.Tpo -c -o bitwise.lo bitwise.c
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I../include -I../include -O20 -Wall -ffast-math -fsigned-char -g -O2 -MT bitwise.lo -MD -MP -MF .deps/bitwise.Tpo -c bitwise.c -fPIC -DPIC -o .libs/bitwise.o
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I../include -I../include -O20 -Wall -ffast-math -fsigned-char -g -O2 -MT bitwise.lo -MD -MP -MF .deps/bitwise.Tpo -c bitwise.c -o bitwise.o >/dev/null 2>&1
mv -f .deps/bitwise.Tpo .deps/bitwise.Plo
/bin/bash ../libtool --tag=CC --mode=link gcc -O20 -Wall -ffast-math -fsigned-char -g -O2 -no-undefined -version-info 8:1:8 -o libogg.la -rpath /usr/local/lib framing.lo bitwise.lo
../libtool: eval: line 6444: unexpected EOF while looking for matching `''
../libtool: eval: line 6445: syntax error: unexpected end of file
make[2]: *** [libogg.la] Error 2
make[2]: Leaving directory `/root/kalebmusic/libogg-1.3.1/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/root/kalebmusic/libogg-1.3.1'
make: *** [all] Error 2
Monty Montgomery
Monty Montgomery
https://gitlab.xiph.org/xiph/ogg/-/issues/1921
Build with automake-1.13 broken
2019-08-13T16:36:06Z
Marko Lindqvist
Build with automake-1.13 broken
Automake-1.13 removed long obsolete AM_CONFIG_HEADER completely ( http://lists.gnu.org/archive/html/automake/2012-12/msg00038.html ) and errors out upon seeing it.
Attached patch replaces it with proper AC_CONFIG_HEADERS.
Automake-1.13 removed long obsolete AM_CONFIG_HEADER completely ( http://lists.gnu.org/archive/html/automake/2012-12/msg00038.html ) and errors out upon seeing it.
Attached patch replaces it with proper AC_CONFIG_HEADERS.
Monty Montgomery
Monty Montgomery
https://gitlab.xiph.org/xiph/ogg/-/issues/1747
libogg 1.2.1 contains invalid os_types.h file which causes libvorbis 1.3.1 to...
2021-09-27T21:10:42Z
Max Horn
libogg 1.2.1 contains invalid os_types.h file which causes libvorbis 1.3.1 to be uncompilable
Trying to compile libvorbis 1.3.1 with libogg 1.2.1 results in the following compiler error on Mac OS X 10.6, 32bit mode:
```
/bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I../include -I/sw/include -I/sw...
Trying to compile libvorbis 1.3.1 with libogg 1.2.1 results in the following compiler error on Mac OS X 10.6, 32bit mode:
```
/bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I../include -I/sw/include -I/sw/include -DDARWIN -fno-common -force_cpusubtype_ALL -Wall -g -O4 -ffast-math -fsigned-char -Wdeclaration-after-statement -DUSE_MEMORY_H -MT analysis.lo -MD -MP -MF .deps/analysis.Tpo -c -o analysis.lo analysis.c
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I../include -I/sw/include -I/sw/include -DDARWIN -fno-common -force_cpusubtype_ALL -Wall -g -O4 -ffast-math -fsigned-char -Wdeclaration-after-statement -DUSE_MEMORY_H -MT analysis.lo -MD -MP -MF .deps/analysis.Tpo -c analysis.c -fno-common -DPIC -o .libs/analysis.o
In file included from /sw/include/ogg/ogg.h:25,
from analysis.c:21:
/sw/include/ogg/os_types.h:73: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'ogg_uint16_t'
/sw/include/ogg/os_types.h:75: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'ogg_uint32_t'
```
Analysis: os_types.h contains this:
```
#elif (defined(__APPLE__) && defined(__MACH__)) /* MacOS X Framework build */
# include <inttypes.h>
typedef int16_t ogg_int16_t;
typedef u_int16_t ogg_uint16_t;
typedef int32_t ogg_int32_t;
typedef u_int32_t ogg_uint32_t;
typedef int64_t ogg_int64_t;
```
However, the types u_int16_t and u_int32_t are not defined by inttypes.h resp. stdint.h
Indeed, the correct names for these types as defined by the [spec for stdint.h](http://www.opengroup.org/onlinepubs/000095399/basedefs/stdint.h.html) (and by transiency for inttypes.h) are uint32_t and uint16_t. So the simple fix is to change these two lines in libogg's os_types.h.
This may affect #elif cases for other ports which incorrectly expect the u_intFOO types to be defined in stdint.h / inttypes.h
Of course the fact remains that checking for __APPLE__ and __MACH__ is a very fragile way to check for types, and that I would still recommend that os_types.h is rewritten to first try whatever types configure detected, and only fallback to such #define hackery if no configure script can be used... See the (now closed) bug + patch #849.
Monty Montgomery
Monty Montgomery
https://gitlab.xiph.org/xiph/ogg/-/issues/1654
support 64bit version of libogg and libvorbis under macosx snow leopard
2020-11-06T03:59:56Z
Vittorio G.
support 64bit version of libogg and libvorbis under macosx snow leopard
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/...
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 Montgomery
Monty Montgomery
https://gitlab.xiph.org/xiph/ogg/-/issues/1586
[liboggz] oggz-diff unable to process files with whitespace in filename
2018-08-08T17:45:36Z
GArik
[liboggz] oggz-diff unable to process files with whitespace in filename
oggz-diff unable to process files with whitespace in filename.
liboggz compiled from trunk on 21.08.2009 (yesterday)
oggz-diff unable to process files with whitespace in filename.
liboggz compiled from trunk on 21.08.2009 (yesterday)
Monty Montgomery
Monty Montgomery
https://gitlab.xiph.org/xiph/ogg/-/issues/1583
[liboggz] oggz-info reports incorrect duration for chained files
2018-08-08T17:46:39Z
GArik
[liboggz] oggz-info reports incorrect duration for chained files
Hi, all
I have:
libvorbis-1.2.3
vorbis-tools-1.2.0
libogg-1.1.4
liboggz-0.9.9 installed on my system.
The problem is that oggz-info unable to detect "Content-Duration" correctly. As the result "Content-Bitrate-Average" is also incorrec...
Hi, all
I have:
libvorbis-1.2.3
vorbis-tools-1.2.0
libogg-1.1.4
liboggz-0.9.9 installed on my system.
The problem is that oggz-info unable to detect "Content-Duration" correctly. As the result "Content-Bitrate-Average" is also incorrect. Also slightly different bitrate detection by ogginfo and oggz-info seems strange to me.
Here is an example:
```
lxuser@garik:~/oggz-bug$ ls
test0.ogg test1.ogg
lxuser@garik:~/oggz-bug$ LANG=C ogginfo *.ogg
Processing file "test0.ogg"...
New logical stream (#1, serial: 7f1f032f): type vorbis
Vorbis headers parsed for stream 1, information follows...
Version: 0
Vendor: Xiph.Org libVorbis I 20090624
Channels: 2
Rate: 44100
Nominal bitrate: 288.000000 kb/s
Upper bitrate not set
Lower bitrate not set
Vorbis stream 1:
Total data length: 1984900 bytes
Playback length: 0m:55.546s
Average bitrate: 285.871339 kb/s
Logical stream 1 ended
Processing file "test1.ogg"...
New logical stream (#1, serial: 7f1f0330): type vorbis
Vorbis headers parsed for stream 1, information follows...
Version: 0
Vendor: Xiph.Org libVorbis I 20090624
Channels: 2
Rate: 44100
Nominal bitrate: 288.000000 kb/s
Upper bitrate not set
Lower bitrate not set
Vorbis stream 1:
Total data length: 10962852 bytes
Playback length: 4m:07.520s
Average bitrate: 354.326180 kb/s
Logical stream 1 ended
lxuser@garik:~/oggz-bug$ oggz-info -a *.ogg
Filename: test0.ogg
Content-Duration: 00:00:55.546
Content-Length: 1.897 MB
Content-Bitrate-Average: 286.452 kbps
Vorbis: serialno 2132738863
4617 packets in 467 pages, 9.9 packets/page, 1.098% Ogg overhead
Content-Length: 1.897 MB
Content-Bitrate-Average: 286.452 kbps
Audio-Samplerate: 44100 Hz
Audio-Channels: 2
Page-Length-Maximum: 4.302 kB
Page-Length-StdDev: 230 bytes
Packet-Length-Maximum: 3.771 kB
Packet-Length-StdDev: 304 bytes
------------------------------------------------------------
Filename: test1.ogg
Content-Duration: 00:04:07.520
Content-Length: 10.459 MB
Content-Bitrate-Average: 354.455 kbps
Vorbis: serialno 2132738864
30765 packets in 2577 pages, 11.9 packets/page, 1.116% Ogg overhead
Content-Length: 10.459 MB
Content-Bitrate-Average: 354.455 kbps
Audio-Samplerate: 44100 Hz
Audio-Channels: 2
Page-Length-Maximum: 4.297 kB
Page-Length-StdDev: 111 bytes
Packet-Length-Maximum: 3.771 kB
Packet-Length-StdDev: 298 bytes
lxuser@garik:~/oggz-bug$ cat test0.ogg test1.ogg > test.ogg
lxuser@garik:~/oggz-bug$ LANG=C ogginfo test.ogg
Processing file "test.ogg"...
New logical stream (#1, serial: 7f1f032f): type vorbis
Vorbis headers parsed for stream 1, information follows...
Version: 0
Vendor: Xiph.Org libVorbis I 20090624
Channels: 2
Rate: 44100
Nominal bitrate: 288.000000 kb/s
Upper bitrate not set
Lower bitrate not set
Vorbis stream 1:
Total data length: 1984900 bytes
Playback length: 0m:55.546s
Average bitrate: 285.871339 kb/s
Logical stream 1 ended
New logical stream (#2, serial: 7f1f0330): type vorbis
Vorbis headers parsed for stream 2, information follows...
Version: 0
Vendor: Xiph.Org libVorbis I 20090624
Channels: 2
Rate: 44100
Nominal bitrate: 288.000000 kb/s
Upper bitrate not set
Lower bitrate not set
Vorbis stream 2:
Total data length: 10962852 bytes
Playback length: 4m:07.520s
Average bitrate: 354.326180 kb/s
Logical stream 2 ended
lxuser@garik:~/oggz-bug$ oggz-info -a test.ogg
Content-Duration: 00:04:07.520
Content-Length: 12.356 MB
Content-Bitrate-Average: 418.738 kbps
Vorbis: serialno 2132738863
4617 packets in 467 pages, 9.9 packets/page, 1.098% Ogg overhead
Content-Length: 1.897 MB
Content-Bitrate-Average: 64.282 kbps
Audio-Samplerate: 44100 Hz
Audio-Channels: 2
Page-Length-Maximum: 4.302 kB
Page-Length-StdDev: 230 bytes
Packet-Length-Maximum: 3.771 kB
Packet-Length-StdDev: 304 bytes
Vorbis: serialno 2132738864
30765 packets in 2577 pages, 11.9 packets/page, 1.116% Ogg overhead
Content-Length: 10.459 MB
Content-Bitrate-Average: 354.455 kbps
Audio-Samplerate: 44100 Hz
Audio-Channels: 2
Page-Length-Maximum: 4.297 kB
Page-Length-StdDev: 111 bytes
Packet-Length-Maximum: 3.771 kB
Packet-Length-StdDev: 298 bytes
```
conrad
conrad
https://gitlab.xiph.org/xiph/ogg/-/issues/1574
assertion failure in oggz_close at oggz.c:218 when scanning corrupted file
2018-08-08T17:46:51Z
keelerda
assertion failure in oggz_close at oggz.c:218 when scanning corrupted file
oggz-scan exits with "Assertion `oggz_dlist_is_empty(oggz->packet_buffer)' failed." when scanning a corrupted file.
oggz-scan exits with "Assertion `oggz_dlist_is_empty(oggz->packet_buffer)' failed." when scanning a corrupted file.
conrad
conrad
https://gitlab.xiph.org/xiph/ogg/-/issues/634
oggcodecs: Still can not play ogg files
2020-11-06T03:56:13Z
Gitlab Bot
oggcodecs: Still can not play ogg files
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.
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 Bot
Gitlab Bot
https://gitlab.xiph.org/xiph/ogg/-/issues/1845
ogg_int64_t incorrect on 64/32bit multilib systems
2017-08-26T14:29:54Z
Jonathan Hamilton
ogg_int64_t incorrect on 64/32bit multilib systems
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...
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 Montgomery
Monty Montgomery
https://gitlab.xiph.org/xiph/ogg/-/issues/1758
[PATCH] libogg & oggz configure's --docdir option are not honored
2017-08-26T14:29:54Z
Cristian Morales Vega
[PATCH] libogg & oggz configure's --docdir option are not honored
./configure --help outputs:
...
--docdir=DIR documentation root [DATAROOTDIR/doc/PACKAGE]
...
But that option is ignored, using a hardcoded doc dir.
./configure --help outputs:
...
--docdir=DIR documentation root [DATAROOTDIR/doc/PACKAGE]
...
But that option is ignored, using a hardcoded doc dir.
Monty Montgomery
Monty Montgomery
https://gitlab.xiph.org/xiph/ogg/-/issues/1623
Minor spelling fixes in comments
2017-08-26T14:29:54Z
Chris 'Xenon' Hanson
Minor spelling fixes in comments
While batch spell-checking some other code, I made these fixes and wish to contribute them.
While batch spell-checking some other code, I made these fixes and wish to contribute them.
Monty Montgomery
Monty Montgomery
https://gitlab.xiph.org/xiph/ogg/-/issues/1581
segfault in _oggz_comment_add_byname
2017-08-26T14:29:54Z
keelerda
segfault in _oggz_comment_add_byname
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.
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 Montgomery
Monty Montgomery
https://gitlab.xiph.org/xiph/ogg/-/issues/1484
[libogg] _os_body_expand uses realloc
2017-08-26T14:29:54Z
ps790809
[libogg] _os_body_expand uses realloc
realloc takes too much time when os->body_data is big, because of copying memory.
static void _os_body_expand(ogg_stream_state *os,int needed){
if(os->body_storage<=os-...
realloc takes too much time when os->body_data is big, because of copying memory.
static void _os_body_expand(ogg_stream_state *os,int needed){
if(os->body_storage<=os->body_fill+needed){
os->body_storage+=(needed+1024);
os->body_data=_ogg_realloc(os->body_data,os->body_storage*sizeof(*os->body_data));
}
}
Monty Montgomery
Monty Montgomery
https://gitlab.xiph.org/xiph/ogg/-/issues/1459
libogg configure script - SPARC / Solaris 9 / -mv8
2017-08-26T14:29:54Z
twigathy
libogg configure script - SPARC / Solaris 9 / -mv8
When compiling libogg on Solaris 9 SPARC, I found that the configure script would quit halfway through, complaining about a lack of 16 bit types:
"configure: error: No 16 bit type found on this platform!"
Clearly this is a bit crazy.
...
When compiling libogg on Solaris 9 SPARC, I found that the configure script would quit halfway through, complaining about a lack of 16 bit types:
"configure: error: No 16 bit type found on this platform!"
Clearly this is a bit crazy.
I had a look at the configure log and found that the -mv8 switch no longer exists. Removing it allowed the configure to complete and the compile to run through cleanly.
https://gitlab.xiph.org/xiph/ogg/-/issues/1454
Failed to build libogg on OpenSolaris
2017-08-26T14:29:54Z
brian.lu
Failed to build libogg on OpenSolaris
Failed to build libogg on OpenSolaris
Failed to build libogg on OpenSolaris
Monty Montgomery
Monty Montgomery
https://gitlab.xiph.org/xiph/ogg/-/issues/1450
fail to build liboggplay on OpenSolaris
2017-08-26T14:29:54Z
brian.lu
fail to build liboggplay on OpenSolaris
Failed to build liboggplay on OpenSolaris
Failed to build liboggplay on OpenSolaris
https://gitlab.xiph.org/xiph/ogg/-/issues/1433
libogg crashes when out of memory
2017-08-26T14:29:54Z
mgold
libogg crashes when out of memory
libogg uses pointers returned by malloc, realloc, etc. without checking whether they're null, which will happen when there's no memory available. This causes the application using libogg to segfault; for example,
```
$ ulimit -S -v 11000...
libogg uses pointers returned by malloc, realloc, etc. without checking whether they're null, which will happen when there's no memory available. This causes the application using libogg to segfault; for example,
```
$ ulimit -S -v 11000 -c hard
$ vcut vcut-test-tones.ogg a b +1.05
```
segfaults at a memcpy call in ogg_stream_packetin on my system.
Functions should return an error code if they can't allocate memory, so the application can handle this in an appropriate way. Unfortunately, not all functions that allocate memory internally can return error codes, so it may be impossible to fix this in a backwards-compatible way.
Monty Montgomery
Monty Montgomery
https://gitlab.xiph.org/xiph/ogg/-/issues/1400
configure wants C++ although not needed
2017-08-26T14:29:54Z
Gitlab Bot
configure wants C++ although not needed
liboggs (1.1.3 tarball from website) configure wants a working C++ compiler installed, but libogg has no parts written in C++. Therefore it's a useless dependency which should be removed.
By patching configure script not to exit if it c...
liboggs (1.1.3 tarball from website) configure wants a working C++ compiler installed, but libogg has no parts written in C++. Therefore it's a useless dependency which should be removed.
By patching configure script not to exit if it can't find a C++ compiler (it actually fails the "sanity check", which none can ever pass), I was able to make it build and running. As my autoconf installation is broken I had no chance to cleanly fix this in the source files.
Monty Montgomery
Monty Montgomery
https://gitlab.xiph.org/xiph/ogg/-/issues/1371
[PATCH] libogg-1.1.3 to support building on Haiku
2017-08-26T14:29:55Z
scottmc2
[PATCH] libogg-1.1.3 to support building on Haiku
This patch masks out BeOS workarounds that are not needed for Haiku. Since Haiku also defines !__BEOS!__ we need to mask them out by also checking for !__HAIKU!__
This patch masks out BeOS workarounds that are not needed for Haiku. Since Haiku also defines !__BEOS!__ we need to mask them out by also checking for !__HAIKU!__
Monty Montgomery
Monty Montgomery
https://gitlab.xiph.org/xiph/ogg/-/issues/1358
libogg-1.1.3 won't build universal dylibs on OS X
2017-08-26T14:29:55Z
Gitlab Bot
libogg-1.1.3 won't build universal dylibs on OS X
The libtool created by libogg-1.1.3 doesn't include LTCFLAGS, so it only builds dylibs for the current platform. The libvorbis configure creates a libtool that builds universal binaries properly.
I can build a universal binary my naviga...
The libtool created by libogg-1.1.3 doesn't include LTCFLAGS, so it only builds dylibs for the current platform. The libvorbis configure creates a libtool that builds universal binaries properly.
I can build a universal binary my navigating to the src directory after the make is finished and executing:
gcc -dynamiclib -o .libs/libogg.0.5.3.dylib .libs/framing.o .libs/bitwise.o -install_name /usr/local/lib/libogg.0.dylib -compatibility_version 6 -current_version 6.3 -arch i386 -arch ppc -arch ppc64 -arch x86_64
file .libs/libogg.0.5.3.dylib
The initial configure is: (Which s the same that I used for libvorbis)
./configure --disable-dependency-tracking CFLAGS="-arch i386 -arch ppc -arch ppc64 -arch x86_64"
Monty Montgomery
Monty Montgomery
https://gitlab.xiph.org/xiph/ogg/-/issues/1353
Discordant playback with Watershed
2017-08-26T14:29:55Z
plm
Discordant playback with Watershed
Encoded K.D Lang's Watershed CD to OGG format at a quality setting of 8.1 using the Winamp 5.53 and the Ogg-Vorbis 1.1 encoder. Playback under Windows Winamp 5.53 sounds find. The same audio files playing back under Linux libogg 1.1.3-74...
Encoded K.D Lang's Watershed CD to OGG format at a quality setting of 8.1 using the Winamp 5.53 and the Ogg-Vorbis 1.1 encoder. Playback under Windows Winamp 5.53 sounds find. The same audio files playing back under Linux libogg 1.1.3-74 with ogg123, xmms, amorok, etc, the playback is incredibly distorted. (Note this is same computer, same speakers, volume..)
Encoding the audio under Linux with Grip or KaudioCreator results in the same discord when played.
Monty Montgomery
Monty Montgomery
https://gitlab.xiph.org/xiph/ogg/-/issues/1329
BITWISE.C integer types , bugs when compiling, typedef's
2017-08-26T14:29:55Z
Gitlab Bot
BITWISE.C integer types , bugs when compiling, typedef's
From BITWISE.C:
```
/* Read in bits without advancing the bitptr; bits <= 32 */
long oggpackB_look(oggpack_buffer *b,int bits){
unsigned long ret;
int m=32-bits;
bits+=b->endbit;
if(b->endbyte+4>=b->storage){
/* not the ma...
From BITWISE.C:
```
/* Read in bits without advancing the bitptr; bits <= 32 */
long oggpackB_look(oggpack_buffer *b,int bits){
unsigned long ret;
int m=32-bits;
bits+=b->endbit;
if(b->endbyte+4>=b->storage){
/* not the main path */
if(b->endbyte*8+bits>b->storage*8)return(-1);
}
ret=b->ptr[0]<<(24+b->endbit);
if(bits>8){
ret|=b->ptr[1]<<(16+b->endbit);
if(bits>16){
ret|=b->ptr[2]<<(8+b->endbit);
if(bits>24){
ret|=b->ptr[3]<<(b->endbit);
if(bits>32 && b->endbit)
ret|=b->ptr[4]>>(8-b->endbit);
}
}
}
return ((ret&0xffffffff)>>(m>>1))>>((m+1)>>1);
}
```
```
/* bits <= 32 */
long oggpackB_read(oggpack_buffer *b,int bits){
long ret;
long m=32-bits;
bits+=b->endbit;
if(b->endbyte+4>=b->storage){
/* not the main path */
ret=-1L;
if(b->endbyte*8+bits>b->storage*8)goto overflow;
}
ret=b->ptr[0]<<(24+b->endbit);
if(bits>8){
ret|=b->ptr[1]<<(16+b->endbit);
if(bits>16){
ret|=b->ptr[2]<<(8+b->endbit);
if(bits>24){
ret|=b->ptr[3]<<(b->endbit);
if(bits>32 && b->endbit)
ret|=b->ptr[4]>>(8-b->endbit);
}
}
}
ret=((ret&0xffffffffUL)>>(m>>1))>>((m+1)>>1);
overflow:
b->ptr+=bits/8;
b->endbyte+=bits/8;
b->endbit=bits&7;
return(ret);
}
```
The stuff seems to be very unstable ... in works with some compilers but not with other ones (fails self-test) :-(
1. Why does the upper function use UNSIGNED, but the lower one SIGNED INT32 for "ret" ? Wouldn't all integers UNSIGNED do the job better ? In my tests YES ...
2. Why do the bit counters (seem to allow values 0...32 only) use an SIGNED INT32 rather than an UINT8 ?
3. What is the difference between "long" and "int" ? Why aren't the TYPEDEF's from OS_TYPES.H used ?
```
typedef short ogg_int16_t;
typedef unsigned short ogg_uint16_t;
typedef int ogg_int32_t;
typedef unsigned int ogg_uint32_t;
typedef __int64 ogg_int64_t;
```
4. "ret&0xffffffffUL" vs "ret&0xffffffff" (no "UL") - intentional ?
5. x=(a>>b)>>c can be done better: x=a>>(b+c) ... except for b=c=16 ... but then 0 is returned :-( Is it useful to pick 0 bits ? If for some reason YES, it might be better to "short-circuit" return 0 for 0 bits, rather than process the complete magic.
6. What exactly is it supposed to do ? Some more detailed comments would be appreciated, "endbit" meaning ... Seems the sophisticated stuff does not do much more than just ONE (!) ASM instruction SHLD/SHRD ;-) So I could replace it with cca 5 lines of inline ASM.
Monty Montgomery
Monty Montgomery
https://gitlab.xiph.org/xiph/ogg/-/issues/1311
Ogg Container Format Wastes Memory
2017-08-26T14:29:55Z
joe_somebody
Ogg Container Format Wastes Memory
Currently the maximum page size is 65307 determined by a limit of 255 page segments, times 255 bytes ...
I propose that the page_segments/segment table is replaced by a 16 bit unsigned integer, which won't be any larger in the case of s...
Currently the maximum page size is 65307 determined by a limit of 255 page segments, times 255 bytes ...
I propose that the page_segments/segment table is replaced by a 16 bit unsigned integer, which won't be any larger in the case of small pages, but will be smaller in all cases where a page size exceeds 254 bytes. It will also allow a page size of up to 65535 bytes. Maybe this could be internally identified as ogg2?
Monty Montgomery
Monty Montgomery
https://gitlab.xiph.org/xiph/ogg/-/issues/1280
[PATCH] ogg.m4 is not friendly to disabling
2017-08-26T14:29:55Z
vapier
[PATCH] ogg.m4 is not friendly to disabling
some projects have optional ogg support. like a good project, they just use the ogg.m4 that is provided by libogg. that's when they get screwed :).
ogg.m4 does not provide a way for the user to explicitly state "i do not want ogg supp...
some projects have optional ogg support. like a good project, they just use the ogg.m4 that is provided by libogg. that's when they get screwed :).
ogg.m4 does not provide a way for the user to explicitly state "i do not want ogg support". i've cleaned up the ogg.m4 so that if you do --without-ogg, you get the expected behavior. i've also fixed the case where doing --with-ogg causes broken -I/-L flags to get added (yes/lib and yes/include)
Monty Montgomery
Monty Montgomery
https://gitlab.xiph.org/xiph/ogg/-/issues/1264
autogen version checking broken
2017-08-26T14:29:55Z
Gitlab Bot
autogen version checking broken
I am runnign Debian etch, and have Automake version 1.10 and aclocal version 1.10. The autogen.sh scripts for ogg in trunk fail to correctly determine the version because VERSIONGREP only looks for a single digit number after the decima...
I am runnign Debian etch, and have Automake version 1.10 and aclocal version 1.10. The autogen.sh scripts for ogg in trunk fail to correctly determine the version because VERSIONGREP only looks for a single digit number after the decimal point. The test therefore fails.
This may affect other autogen.sh scripts - I haven't checked.
Monty Montgomery
Monty Montgomery
https://gitlab.xiph.org/xiph/ogg/-/issues/1235
No implementation due to poor documentation
2017-08-26T14:29:55Z
Gitlab Bot
No implementation due to poor documentation
Hi,
I have tried opening a OGG container with FLAC content in many players on Linux, Mac OS, and WinAmp on Windows. There is almost no support what so ever for this file type. Most players fail to recognize metadata (NEED STANDARD!!) in...
Hi,
I have tried opening a OGG container with FLAC content in many players on Linux, Mac OS, and WinAmp on Windows. There is almost no support what so ever for this file type. Most players fail to recognize metadata (NEED STANDARD!!) in the FLAC codec, and some fail to playback the file all together.
Tried most recent version of Amarok, Banshee, VLC, MPlayer, Xine, iTunes + XiphQT, WinAmp...
I think this is due to poor documentation on the Xiph website. FLAC's site does OK, but I do think it should be made more promontant in the OGG spesifications how FLAC, Vorbis, and other codecs works. Should be mentioned in the Vorbis documentation that OGG is a container format, and can contain other formats as well.
Monty Montgomery
Monty Montgomery
https://gitlab.xiph.org/xiph/ogg/-/issues/1219
debian/rules has syntax error
2017-08-26T14:29:55Z
samyboy1
debian/rules has syntax error
I Cannot create a .deb package.
### Actual Result
```
$pkg-buildpackage -rfakeroot
[...]
/bin/sh: -c: line 3: syntax error near unexpected token `fi'
/bin/sh: -c: line 3: `fi'
make: *** [clean] Error 2
```
### Expected result
Creatin...
I Cannot create a .deb package.
### Actual Result
```
$pkg-buildpackage -rfakeroot
[...]
/bin/sh: -c: line 3: syntax error near unexpected token `fi'
/bin/sh: -c: line 3: `fi'
make: *** [clean] Error 2
```
### Expected result
Creating a debian package
### How to solve
Uncomment line 87 of debian/rules
Monty Montgomery
Monty Montgomery
https://gitlab.xiph.org/xiph/ogg/-/issues/1120
calling _clear functions with already cleared structures results in crash
2017-08-26T14:29:55Z
Gitlab Bot
calling _clear functions with already cleared structures results in crash
When _clear functions (from all ogg libraries, not just libogg) are called with already cleared ogg structures they crash.
It would be very good if i could call, for example, theora_info_clear() with an already cleared theora_info struc...
When _clear functions (from all ogg libraries, not just libogg) are called with already cleared ogg structures they crash.
It would be very good if i could call, for example, theora_info_clear() with an already cleared theora_info structure. It simplifies the creation of code paths for error handling, presence or not of certain logic bitstreams and probably other reasons.
Monty Montgomery
Monty Montgomery
https://gitlab.xiph.org/xiph/ogg/-/issues/2292
Granulepos corruption with large/numerous packets (with test case)
2018-08-08T17:39:26Z
stenyak
Granulepos corruption with large/numerous packets (with test case)
I'm having issues when dealing with oggz streams that have certain amount of packets and/or certain packet size.
I have attached a test case.
I have reproduced the problem with:
- msvs2015 compiler
- both 32 and 64 bit
- both libog...
I'm having issues when dealing with oggz streams that have certain amount of packets and/or certain packet size.
I have attached a test case.
I have reproduced the problem with:
- msvs2015 compiler
- both 32 and 64 bit
- both liboggz v1.1.1 (git `70b58a45`, from 2010-04-29) and the head of master (git `f49574ed` from 2014-04-24). Repo URL: https://git.xiph.org/liboggz.git
In the attached test case, the file writing phase seems to go OK, at least no errors are returned anywhere.
[main.cpp](/uploads/466511c90df23933511eeb891b507af7/main.cpp)
The writer code is based on the example found here: https://xiph.org/oggz/doc/group__force__feed.html#details
The reading phase is more problematic:
- Passing the file through oggz-validate.exe (as downloaded from https://xiph.org/oggz ) crashes with an Out of Memory error
- Using oggz-dump.exe instead, it seems to read all packets correctly, and output the expected granule positions
- The attached source code is unable to finish without errors though.
To verify the problem, follow these steps:
1. Compile the code as-is, in debug mode (to run all asserts). Everything should go ok. The resulting file `foo.oggz` will be around 160 megs.
2. Set `FAIL = true`, compile and run. An assert will fail, around packet #491. The granule position is corrupted now.
3. Decrease packetSize 1 byte (setting it to `packetSize = 163388`), compile and run. Granule position will be okay again, all asserts will pass.
So it seems that both amount of packets and size of packets can contribute to the corrupted granulepos.
If you need any help reproducing the issue, please let me know.
https://gitlab.xiph.org/xiph/ogg/-/issues/2296
docs for ogg_stream_state have wrong type on `pageno` field
2019-08-13T15:58:40Z
Spencer Russell
docs for ogg_stream_state have wrong type on `pageno` field
In the [header file](https://gitlab.xiph.org/xiph/ogg/blob/0acd32d7cabf7e41cc29ea7c2bbffde969ff1ba0/include/ogg/ogg.h#L76) the `pageno` field is a `long`, but in the [docs](https://gitlab.xiph.org/xiph/ogg/blob/0acd32d7cabf7e41cc29ea7c2b...
In the [header file](https://gitlab.xiph.org/xiph/ogg/blob/0acd32d7cabf7e41cc29ea7c2bbffde969ff1ba0/include/ogg/ogg.h#L76) the `pageno` field is a `long`, but in the [docs](https://gitlab.xiph.org/xiph/ogg/blob/0acd32d7cabf7e41cc29ea7c2bbffde969ff1ba0/doc/libogg/ogg_stream_state.html#L52) it is listed as an `int`.
https://gitlab.xiph.org/xiph/ogg/-/issues/2297
framing.c: overflow on left shift
2019-03-06T21:34:00Z
Tristan Matthews
framing.c: overflow on left shift
There's a regression since commit bc82844df068429d209e909da47b1f730b53b689:
```framing.c:239:19: runtime error: left shift of 211 by 24 places cannot be represented in type 'int'```
I found this while generating the corpus for speex wit...
There's a regression since commit bc82844df068429d209e909da47b1f730b53b689:
```framing.c:239:19: runtime error: left shift of 211 by 24 places cannot be represented in type 'int'```
I found this while generating the corpus for speex with oss-fuzz:
```
git clone git@github.com:tmatth/oss-fuzz.git
cd oss-fuzz
python infra/helper.py build_image speex
python infra/helper.py build_fuzzers --sanitizer undefined speex
```
https://gitlab.xiph.org/xiph/ogg/-/issues/91
documentation doesn't mention gmake requirement
2006-06-12T11:25:10Z
nisharfi
documentation 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 Boessenkool
Segher Boessenkool
https://gitlab.xiph.org/xiph/ogg/-/issues/343
[RFE] Use ISO C99 types if available
2006-06-12T11:04:43Z
bero
[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 Montgomery
Monty Montgomery
https://gitlab.xiph.org/xiph/ogg/-/issues/549
sync-to-sync data loss
2004-07-24T01:52:49Z
Arc Riley
sync-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 Montgomery
Monty Montgomery
https://gitlab.xiph.org/xiph/ogg/-/issues/56
&#34;ogg_packet_clear&#34; not exported in ogg.def
2006-06-12T11:08:23Z
adonnai
"ogg_packet_clear" not exported in ogg.def
```
The function "ogg_packet_clear" isn't listed in ogg.def so linking fails when
calling it. One exmaple, vorbiscomment, couldn't compile because of this bug.
```
```
The function "ogg_packet_clear" isn't listed in ogg.def so linking fails when
calling it. One exmaple, vorbiscomment, couldn't compile because of this bug.
```
Monty Montgomery
Monty Montgomery
https://gitlab.xiph.org/xiph/ogg/-/issues/125
media type audio/x-ogg or application/x-ogg should be added to Apache mime.types
2002-01-11T11:17:12Z
yusufg
media 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 Montgomery
Monty Montgomery
https://gitlab.xiph.org/xiph/ogg/-/issues/289
[PATCH] MacOS building of ogg &amp; vorbis somewhat 'hacky'
2009-04-19T20:20:08Z
Gitlab 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 Smith
Michael Smith
https://gitlab.xiph.org/xiph/ogg/-/issues/23
oggenc manpage and --help disagree on default bitrate
2006-06-12T10:41:39Z
jemorris
oggenc 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 Montgomery
Monty Montgomery
https://gitlab.xiph.org/xiph/ogg/-/issues/60
src/Makefile.am doesn't work with outside-the-tree builds
2006-06-12T11:23:31Z
ahltorp
src/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 Moffitt
Jack Moffitt
https://gitlab.xiph.org/xiph/ogg/-/issues/457
Typo in bitwise.c:37/mask8B array
2003-09-29T17:33:40Z
Timothy B. Terriberry
Typo 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 Montgomery
Monty Montgomery
https://gitlab.xiph.org/xiph/ogg/-/issues/483
Incorrect use of 'head' in autogen.sh
2006-06-12T11:33:55Z
robert.moss
Incorrect 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/544
ogg_buffer_create missing from ogg2/ogg.h
2010-10-27T13:35:06Z
Arc Riley
ogg_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 Montgomery
Monty Montgomery
https://gitlab.xiph.org/xiph/ogg/-/issues/841
Debian rules for libogg 1.1.3 produces incorrect file names
2010-10-26T11:16:42Z
blenda
Debian rules for libogg 1.1.3 produces incorrect file names
Issuing "fakeroot debian/rules binary" on the libogg 1.1.3 source produces Debian packages with incorrect file names: libogg0_1.1.1-1_i386.deb and libogg-dev_1.1.1-1_i386.deb.
I'm not familiar with the debian/rules thingy, but I guess t...
Issuing "fakeroot debian/rules binary" on the libogg 1.1.3 source produces Debian packages with incorrect file names: libogg0_1.1.1-1_i386.deb and libogg-dev_1.1.1-1_i386.deb.
I'm not familiar with the debian/rules thingy, but I guess that debian/files is the culprit. It has these two lines:
libogg0_1.1.1-1_i386.deb libs optional
libogg-dev_1.1.1-1_i386.deb libdevel optional
BTW there is no option for chosing 1.1.3 as libogg version when creating ticket.
Monty Montgomery
Monty Montgomery
https://gitlab.xiph.org/xiph/ogg/-/issues/924
Incorrect Headers for Cygwin
2006-06-03T22:30:33Z
mdmkolbe
Incorrect Headers for Cygwin
The libogg header [trunk/ogg/include/ogg/os_types.h#11505](../tree/master/trunk/ogg/include/ogg/os_types.h#11505) will not compile on Cygwin because they reference _G_config.h which does not exist on a standard Cygwin install.
The libogg header [trunk/ogg/include/ogg/os_types.h#11505](../tree/master/trunk/ogg/include/ogg/os_types.h#11505) will not compile on Cygwin because they reference _G_config.h which does not exist on a standard Cygwin install.
Monty Montgomery
Monty Montgomery
https://gitlab.xiph.org/xiph/ogg/-/issues/2300
Check for overflow on growing buffer
2020-08-09T22:44:22Z
Clément Bœsch
Check for overflow on growing buffer
Hi,
I came across this code while debugging an issue in libshout (https://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2318), and it looked pretty unsafe to me: [0001-framing-check-for-overflow-on-growing-buffer.patch](/uploads/376286...
Hi,
I came across this code while debugging an issue in libshout (https://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2318), and it looked pretty unsafe to me: [0001-framing-check-for-overflow-on-growing-buffer.patch](/uploads/376286b5321247d4934f85e924bdb2be/0001-framing-check-for-overflow-on-growing-buffer.patch).
One could check that the `oy->storage<0` and similar checks are enough, but I still believe it's safer not to assign the invalid value in the first place.
https://gitlab.xiph.org/xiph/ogg/-/issues/489
libogg2 threading doesn't work on FreeBSD
2010-10-27T13:32:37Z
Arc Riley
libogg2 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 Montgomery
Monty Montgomery
https://gitlab.xiph.org/xiph/ogg/-/issues/485
libogg2: direct access to change page header fields
2010-10-27T13:31:16Z
Arc Riley
libogg2: 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 Montgomery
Monty Montgomery
https://gitlab.xiph.org/xiph/ogg/-/issues/740
libogg configure.in doubles up ldflags
2007-06-17T08:40:29Z
Gitlab Bot
libogg configure.in doubles up ldflags
an error in configure.in of libogg doubles the predefined ldflags.
Now this is not always a problem, but for some options (such as the SDK option for Mac OS X) it is.
This should fix it:
diff -ruN libogg-1.1.2/configure.in libogg/confi...
an error in configure.in of libogg doubles the predefined ldflags.
Now this is not always a problem, but for some options (such as the SDK option for Mac OS X) it is.
This should fix it:
diff -ruN libogg-1.1.2/configure.in libogg/configure.in
--- libogg-1.1.2/configure.in 2004-09-23 15:30:58.000000000 +0200
+++ libogg/configure.in 2005-11-14 22:16:04.000000000 +0100
@@ -28,17 +28,17 @@
case $host in
*-*-irix*)
DEBUG="-g -signed"
- CFLAGS="-O2 -w -signed"
+ EXTRA_CFLAGS="-O2 -w -signed"
PROFILE="-p -g3 -O2 -signed"
;;
sparc-sun-solaris*)
DEBUG="-v -g"
- CFLAGS="-xO4 -fast -w -fsimple -native -xcg92"
+ EXTRA_CFLAGS="-xO4 -fast -w -fsimple -native -xcg92"
PROFILE="-v -xpg -g -xO4 -fast -native -fsimple -xcg92 -Dsuncc"
;;
*)
DEBUG="-g"
- CFLAGS="-O"
+ EXTRA_CFLAGS="-O"
PROFILE="-g -p"
;;
esac
@@ -46,30 +46,30 @@
case $host in
*-*-linux*)
DEBUG="-g -Wall -fsigned-char"
- CFLAGS="-O20 -ffast-math -fsigned-char"
+ EXTRA_CFLAGS="-O20 -ffast-math -fsigned-char"
PROFILE="-Wall -W -pg -g -O20 -ffast-math -fsigned-char"
;;
sparc-sun-*)
DEBUG="-g -Wall -fsigned-char -mv8"
- CFLAGS="-O20 -ffast-math -fsigned-char -mv8"
+ EXTRA_CFLAGS="-O20 -ffast-math -fsigned-char -mv8"
PROFILE="-pg -g -O20 -fsigned-char -mv8"
;;
*-*-darwin*)
DEBUG="-fno-common -g -Wall -fsigned-char"
- CFLAGS="-fno-common -O4 -Wall -fsigned-char -ffast-math"
+ EXTRA_CFLAGS="-fno-common -O4 -Wall -fsigned-char -ffast-math"
PROFILE="-fno-common -O4 -Wall -pg -g -fsigned-char -ffast-math"
;;
*)
DEBUG="-g -Wall -fsigned-char"
- CFLAGS="-O20 -fsigned-char"
+ EXTRA_CFLAGS="-O20 -fsigned-char"
PROFILE="-O20 -g -pg -fsigned-char"
;;
esac
fi
-CFLAGS="$CFLAGS $cflags_save"
+CFLAGS="$EXTRA_CFLAGS $cflags_save"
DEBUG="$DEBUG $cflags_save"
PROFILE="$PROFILE $cflags_save"
-LDFLAGS="$LDFLAGS $ldflags_save"
+LDFLAGS="$EXTRA_LDFLAGS $ldflags_save"
dnl Checks for programs.
Monty Montgomery
Monty Montgomery
https://gitlab.xiph.org/xiph/ogg/-/issues/694
Could not find or load the file &#34;ELIB.LIB&#34; for target &#34;WINSCW UDE...
2007-06-17T08:39:21Z
senthilashok
Could not find or load the file "ELIB.LIB" for target "WINSCW UDEB" for project "ogg.mcp".
Hi,
I am getting the error, when i tried to compile this example program.
Please help me.
Thanks
Sen
Hi,
I am getting the error, when i tried to compile this example program.
Please help me.
Thanks
Sen
https://gitlab.xiph.org/xiph/ogg/-/issues/653
[PATCH] incorrect use of LIBS and CFLAGS in vorbis.m4 and ogg.m4
2009-04-19T20:23:36Z
Julien Cristau
[PATCH] incorrect use of LIBS and CFLAGS in vorbis.m4 and ogg.m4
Hi,
the autoconf documentation explains that the variable LIBS should
contain "`-l' options to pass to the linker". For `-L' options,
LDFLAGS should be used instead. This breaks compilation of other
software using libogg/libvorbis (and t...
Hi,
the autoconf documentation explains that the variable LIBS should
contain "`-l' options to pass to the linker". For `-L' options,
LDFLAGS should be used instead. This breaks compilation of other
software using libogg/libvorbis (and the XIPH_PATH_OGG/XIPH_PATH_VORBIS
macros) when running "./configure --prefix=foo" if {OGG,VORBIS}_LIBS are
assumed to contain only `-l' options.
Moreover, header file search directory options (`-IDIR') belong in
CPPFLAGS, not CFLAGS.
Patches are available at http://perso.ens-lyon.fr/julien.cristau/ogg.m4.diff
and http://perso.ens-lyon.fr/julien.cristau/vorbis.m4.diff
Regards,
Julien Cristau
Monty Montgomery
Monty Montgomery
https://gitlab.xiph.org/xiph/ogg/-/issues/650
compile error building oggplay from trunk svn
2017-04-07T17:11:03Z
Gitlab Bot
compile error building oggplay from trunk svn
oggplay fails to compile due to a missing header file, libmng.h. This is from svn from around 18:30 EDT 2005-04-14.
oggplay.c:19:20: libmng.h: No such file or directory
oggplay.c:36: error: parse error before "mng_uint32"
oggplay.c:36:...
oggplay fails to compile due to a missing header file, libmng.h. This is from svn from around 18:30 EDT 2005-04-14.
oggplay.c:19:20: libmng.h: No such file or directory
oggplay.c:36: error: parse error before "mng_uint32"
oggplay.c:36: warning: no semicolon at end of struct or union
oggplay.c:37: warning: data definition has no type or storage class
oggplay.c:42: error: parse error before "mymngalloc"
oggplay.c:42: error: parse error before "size"
oggplay.c: In function `mymngalloc':
oggplay.c:44: error: `mng_ptr' undeclared (first use in this function)
oggplay.c:44: error: (Each undeclared identifier is reported only once
oggplay.c:44: error: for each function it appears in.)
oggplay.c:44: error: parse error before "malloc"
oggplay.c: At top level:
oggplay.c:48: error: parse error before "p"
oggplay.c: In function `mymngfree':
oggplay.c:50: error: `p' undeclared (first use in this function)
oggplay.c: At top level:
oggplay.c:54: error: parse error before "mymngopenstream"
oggplay.c:54: error: parse error before "mng"
oggplay.c: In function `mymngopenstream':
oggplay.c:56: error: `stuff' undeclared (first use in this function)
oggplay.c:59: error: parse error before ')' token
oggplay.c:65: error: `MNG_FALSE' undeclared (first use in this function)
oggplay.c:88: error: `MNG_TRUE' undeclared (first use in this function)
oggplay.c: At top level:
oggplay.c:91: error: parse error before "mymngclosestream"
oggplay.c:91: error: parse error before "mng"
oggplay.c: In function `mymngclosestream':
oggplay.c:93: error: `stuff' undeclared (first use in this function)
oggplay.c:96: error: parse error before ')' token
oggplay.c:112: error: `MNG_TRUE' undeclared (first use in this function)
oggplay.c: At top level:
oggplay.c:116: error: parse error before "mymngreadstream"
oggplay.c:116: error: parse error before "mng"
oggplay.c: In function `mymngreadstream':
oggplay.c:119: error: `stuff' undeclared (first use in this function)
oggplay.c:127: error: parse error before ')' token
oggplay.c:129: error: `bytesread' undeclared (first use in this function)
oggplay.c:131: error: `byteswanted' undeclared (first use in this function)
oggplay.c:141: error: `buffer' undeclared (first use in this function)
oggplay.c:152: error: `MNG_TRUE' undeclared (first use in this function)
oggplay.c:192: error: `MNG_FALSE' undeclared (first use in this function)
https://gitlab.xiph.org/xiph/ogg/-/issues/586
[PATCH] ogg2-arc does not compile wiht mingw32
2009-04-19T21:13:43Z
j
[PATCH] ogg2-arc does not compile wiht mingw32
ogg2-arc from svn branches/ogg2-arc does not compile on mingw32,
since #include <_G_config.h> fails.
it should work as it is done in libogg/trunk - http://svn.xiph.org/trunk/ogg/include/ogg/os_types.h
```
# if defined(__CYGWIN__)
# ...
ogg2-arc from svn branches/ogg2-arc does not compile on mingw32,
since #include <_G_config.h> fails.
it should work as it is done in libogg/trunk - http://svn.xiph.org/trunk/ogg/include/ogg/os_types.h
```
# if defined(__CYGWIN__)
# include <_G_config.h>
typedef _G_int64_t ogg_int64_t;
typedef _G_int32_t ogg_int32_t;
typedef _G_uint32_t ogg_uint32_t;
typedef _G_int16_t ogg_int16_t;
typedef _G_uint16_t ogg_uint16_t;
# elif defined(__MINGW32__)
typedef short ogg_int16_t;
typedef unsigned short ogg_uint16_t;
typedef int ogg_int32_t;
typedef unsigned int ogg_uint32_t;
typedef long long ogg_int64_t;
typedef unsigned long long ogg_uint64_t;
```
Arc Riley
Arc Riley
https://gitlab.xiph.org/xiph/ogg/-/issues/564
oggpack_writecopy_helper erroneously updates b->buffer
2004-09-01T00:43:19Z
Timothy B. Terriberry
oggpack_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 Montgomery
Monty Montgomery
https://gitlab.xiph.org/xiph/ogg/-/issues/484
libogg2: ogg_page_getbuffer declaired but not defined
2010-10-27T13:30:10Z
Arc Riley
libogg2: 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 Montgomery
Monty Montgomery
https://gitlab.xiph.org/xiph/ogg/-/issues/478
oggpackB not handling 9 bit values
2006-06-12T11:29:55Z
Ghost User
oggpackB 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 Montgomery
Monty Montgomery
https://gitlab.xiph.org/xiph/ogg/-/issues/464
[bitwise.c: CVS HEAD] oggpack_writecopy_helper() incorrectly moves buffer poi...
2006-06-12T11:25:54Z
Tim 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 Montgomery
Monty Montgomery
https://gitlab.xiph.org/xiph/ogg/-/issues/104
ogg.m4 refers to ogg-config
2006-06-12T10:47:55Z
Gitlab Bot
ogg.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 Montgomery
Monty Montgomery
https://gitlab.xiph.org/xiph/ogg/-/issues/25
'win32/*.bat', harcoded path to 'vcvars32.bat' might be a bad idea
2009-04-19T20:39:35Z
tom
'win32/*.bat', harcoded path to 'vcvars32.bat' might be a bad idea
```
'win32/*.bat' all contain:
call "c:\program files\microsoft visual studio\vc98\bin\vcvars32.bat"
maybe this should be replaced with:
call "%MSDevDir%\..\..\vc98\bin\vcvars32.bat"
or (if we assume it is pathed, since later on we s...
```
'win32/*.bat' all contain:
call "c:\program files\microsoft visual studio\vc98\bin\vcvars32.bat"
maybe this should be replaced with:
call "%MSDevDir%\..\..\vc98\bin\vcvars32.bat"
or (if we assume it is pathed, since later on we see just 'msdev' without a
path):
call vcvars32.bat
```
starclass
starclass
https://gitlab.xiph.org/xiph/ogg/-/issues/24
missing 'ogg_stream_packetpeek' export in 'win32/ogg.def'
2006-06-12T10:30:29Z
tom
missing 'ogg_stream_packetpeek' export in 'win32/ogg.def'
```
This breaks the build of the vorbis for the win32 platform
```
```
This breaks the build of the vorbis for the win32 platform
```
Jack Moffitt
Jack Moffitt
https://gitlab.xiph.org/xiph/ogg/-/issues/21
oggpack_read() return value not well defined
2006-06-12T11:31:37Z
Segher Boessenkool
oggpack_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 Boessenkool
Segher Boessenkool
https://gitlab.xiph.org/xiph/ogg/-/issues/13
Minor portability issues
2006-06-12T11:22:27Z
aegisk
Minor portability issues
```
Lines 74, 76, 78, and 81 are missing explicit typecasts to unsigned char (VC++ 6
is complaining).
Lines 177 and 209 are assigning -1 to an unsigned long. This is unspecified
according to the C specification. Change to 0xFFFFFFFF...
```
Lines 74, 76, 78, and 81 are missing explicit typecasts to unsigned char (VC++ 6
is complaining).
Lines 177 and 209 are assigning -1 to an unsigned long. This is unspecified
according to the C specification. Change to 0xFFFFFFFF?
I'll attach a patch if desired.
```
Segher Boessenkool
Segher Boessenkool
https://gitlab.xiph.org/xiph/ogg/-/issues/245
libogg's $(includedir) blitzing makes baby Jesus cry
2009-04-19T20:17:38Z
Gitlab Bot
libogg'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 Montgomery
Monty Montgomery
https://gitlab.xiph.org/xiph/ogg/-/issues/1118
libogg Version: 1.1.3-2ubuntu1 crash when decoding fuzzed file
2007-05-28T08:28:38Z
ensonic
libogg Version: 1.1.3-2ubuntu1 crash when decoding fuzzed file
As sam pointed out in his blog
http:||sam.zoy.org/blog/2007-01-16-exposing-file-parsing-vulnerabilities
there is a crash when decoding a fuzzed ogg file in gstreamer.
The related gstreamer report is at
http:||bugzilla.gnome.org/show_bug...
As sam pointed out in his blog
http:||sam.zoy.org/blog/2007-01-16-exposing-file-parsing-vulnerabilities
there is a crash when decoding a fuzzed ogg file in gstreamer.
The related gstreamer report is at
http:||bugzilla.gnome.org/show_bug.cgi?id=397229
Unfortunately I don't get a decent backtrace here. The last function called is
ogg_stream_pagein()
Monty Montgomery
Monty Montgomery
https://gitlab.xiph.org/xiph/ogg/-/issues/849
[PATCH] libogg's os_types.h / config_types.h have limited portability (Mac OS X)
2010-11-02T09:22:09Z
Max Horn
[PATCH] libogg's os_types.h / config_types.h have limited portability (Mac OS X)
The following issue affects at least libogg 1.2.2 up to the current trunk version in your Subversion repository.
In an attempt to improve portability, libogg defines an assortment of types, like for example ogg_int32_t. This is done in ...
The following issue affects at least libogg 1.2.2 up to the current trunk version in your Subversion repository.
In an attempt to improve portability, libogg defines an assortment of types, like for example ogg_int32_t. This is done in os_types.h. The detection is based on various predefined #defines like _WIN32, __MINGW32__, __BEOS__ etc.
If none of these #if/#elif checks works, os_types.h finally gives up and includes ogg/config_types.h. And config_types.h is in turn generated by your configure script to use suitable types
So far, so good. The problem now is that your configure script checks whether int16_t is present. it does so by including sys/types.h.
However, this is not portable. The proper ISO99-C header for int16_t is inttypes.h. You will now say: "But it works". It does so on many systems since often sys/types.h pulls in inttypes.h implicitly, and things work. Unless somebody tries to compile code while enforcing standard conformance, on OS X this can for example be achieved by doing:
#define _XOPEN_SOURCE 600
which then leads to a compile error when including ogg/ogg.h unless one first includes inttypes.h or stdint.h
Proposed solution: Just don't use int16_t in config_types.h -- after all, it's meant to be your fallback code. If you want to use the int16_t etc. types if present, simply let your configure script #define HAS_INTTYPES_H and modify os_types.h by adding another branch that #includes <inttypes.h> and does the appropriate typedefs.
Sidenote: The check for __MACOSX__ can be safely removed from os_types.h. No compiler for OS X that I know ever #defines this :-).
https://gitlab.xiph.org/xiph/ogg/-/issues/498
sizeof(long) on x86_64 is 8 bytes, things break
2004-03-08T07:16:59Z
Gitlab Bot
sizeof(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 Montgomery
Monty Montgomery
https://gitlab.xiph.org/xiph/ogg/-/issues/520
Failure to compile under Cygwin 1.5.7
2010-10-27T13:34:31Z
jari.aalto
Failure 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 Montgomery
Monty Montgomery
https://gitlab.xiph.org/xiph/ogg/-/issues/152
MSVC project settings for ogg_static_d.lib cause linker errors when used with...
2006-06-12T11:39:41Z
Gitlab Bot
MSVC 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 Montgomery
Monty Montgomery
https://gitlab.xiph.org/xiph/ogg/-/issues/458
oggpackB_writeclear() uses different bit packing conventions for source and t...
2006-06-12T11:19:10Z
Timothy B. Terriberry
oggpackB_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 Montgomery
Monty Montgomery
https://gitlab.xiph.org/xiph/ogg/-/issues/26
'win32/*.bat' do not handle SRCROOT long path names with spaces correctly
2006-06-12T10:56:22Z
tom
'win32/*.bat' do not handle SRCROOT long path names with spaces correctly
```
as an example:
set SRCROOT=e:\Xiph CVS\
call build_vorbis_static.bat
produces the error:
cvs==. was unexpected at this time.
and does *not* set %SRCROOT% to any value
resolution:
replace the line:
if .%SRCROOT%==. set SRC...
```
as an example:
set SRCROOT=e:\Xiph CVS\
call build_vorbis_static.bat
produces the error:
cvs==. was unexpected at this time.
and does *not* set %SRCROOT% to any value
resolution:
replace the line:
if .%SRCROOT%==. set SRCROOT=c:\src
with the line:
if ".%SRCROOT%"=="." set SRCROOT=c:\src
```
starclass
starclass
https://gitlab.xiph.org/xiph/ogg/-/issues/80
crc block generation doesn't set crc_ready
2006-06-12T10:57:30Z
timj
crc 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 Montgomery
Monty Montgomery
https://gitlab.xiph.org/xiph/ogg/-/issues/545
start-time granulepos
2010-10-27T13:35:26Z
Arc Riley
start-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 Montgomery
Monty Montgomery
https://gitlab.xiph.org/xiph/ogg/-/issues/295
Runtime DLL used in Debug Mode
2006-06-12T11:22:35Z
Gitlab Bot
Runtime 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 Seibert
Stan Seibert
https://gitlab.xiph.org/xiph/ogg/-/issues/374
libxmms-flac.so references undefined plt symbol
2007-06-17T08:42:16Z
rretzlaf
libxmms-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 Montgomery
Monty Montgomery
https://gitlab.xiph.org/xiph/ogg/-/issues/548
sync-to-sync data loss
2004-07-24T01:53:10Z
Arc Riley
sync-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 Montgomery
Monty Montgomery
https://gitlab.xiph.org/xiph/ogg/-/issues/646
green screen
2017-04-08T00:51:34Z
Gitlab Bot
green screen
when i start to watch anime on DivX,it works. then out of nowhere,randomly, the entire screen turns green. what do i have to do.
when i start to watch anime on DivX,it works. then out of nowhere,randomly, the entire screen turns green. what do i have to do.
Monty Montgomery
Monty Montgomery
https://gitlab.xiph.org/xiph/ogg/-/issues/645
ogg problems
2017-04-07T17:11:03Z
Gitlab Bot
ogg problems
when i watch mostly anything on DivX. randomly the entire screen will turn green.why does it do this? is this my mistake?
when i watch mostly anything on DivX. randomly the entire screen will turn green.why does it do this? is this my mistake?
https://gitlab.xiph.org/xiph/ogg/-/issues/94
10018958
2017-04-07T21:51:41Z
gumboot
10018958
```
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 Smith
Michael Smith
https://gitlab.xiph.org/xiph/ogg/-/issues/501
ogg.m4:8: warning: underquoted definition of XIPH_PATH_OGG
2004-01-26T10:32:20Z
alexander.winston
ogg.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 Montgomery
Monty Montgomery
https://gitlab.xiph.org/xiph/ogg/-/issues/229
shared library not built
2006-06-12T11:13:16Z
shatty
shared 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 Montgomery
Monty Montgomery
https://gitlab.xiph.org/xiph/ogg/-/issues/770
*.ogg file can't play on web
2017-04-07T17:10:22Z
lewis38
*.ogg file can't play on web
I tried to embed ogg-file-link into html web to play with Microsoft Media Player,but it didn't work.I haved installed "MediaXW-0.0.6.msi".
---------------------------------------
My embed codes were like these:
<object classid="clsid:22...
I tried to embed ogg-file-link into html web to play with Microsoft Media Player,but it didn't work.I haved installed "MediaXW-0.0.6.msi".
---------------------------------------
My embed codes were like these:
<object classid="clsid:22D6F312-B0F6-11D0-94AB-0080C74C7E95" type="application/x-oleobject" width=350 height=280 align="middle"
standby="Loading Microsoft Windows Media Player components..."
id="MediaPlayer1">
<param name="transparentAtStart" value="True">
<param name="transparentAtStop" value="True">
<param name="AnimationAtStart" value="Ture">
<param name="AutoStart" value="True">
<param name="AutoRewind" value="true">
<param name="DisplaySize" value="0">
<param name="AutoSize" value="false">
<param name="ShowDisplay" value="false">
<param name="ShowStatusBar" value="ture">
<param name="ShowControls" value="ture">
<param name="FileName" value="music/pleasetellmewhy.ogg">
<param name="Volume" value="0">
<embed src="" width="350" height=280 autostart="True" align="middle" transparentatstart="True" transparentatstop="True"
animationatstart="Ture" autorewind="true" displaysize="0" autosize="false" showdisplay="False" showstatusbar="-1"
showcontrols="ture" filename="music/pleasetellmewhy.ogg" volume="0">
</embed>
</object>
---------------
The file route "music/pleasetellmewhy.ogg" has no problem ,I can download it from my web. I just couldn't play it on my web. Could you please tell me how to solve this problem?
https://gitlab.xiph.org/xiph/ogg/-/issues/503
better multiplexing example image
2017-04-08T00:51:34Z
in7y118
better 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 Montgomery
Monty Montgomery
https://gitlab.xiph.org/xiph/ogg/-/issues/486
libogg2's bitpackers cannot be init. due to missing structs
2006-06-12T11:35:35Z
Arc Riley
libogg2'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 Montgomery
Monty Montgomery
https://gitlab.xiph.org/xiph/ogg/-/issues/222
devel rpm doesn't include aclocal/ogg.m4
2002-07-29T18:45:54Z
noa
devel 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 Montgomery
Monty Montgomery
https://gitlab.xiph.org/xiph/ogg/-/issues/163
minor problem in in_vorbis plugin and may be ...
2002-02-20T07:16:24Z
xakep
minor 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 Montgomery
Monty Montgomery
https://gitlab.xiph.org/xiph/ogg/-/issues/2302
cwd autogen broken
2021-08-17T08:18:26Z
cjhih456
cwd autogen broken
Hello. I was using ogg install with my program.
So I was install with cwd child process.
But this error has been come.
```
configure.ac:5: installing './compile'
configure.ac:5: installing './config.guess'
configure.ac:5: installing './...
Hello. I was using ogg install with my program.
So I was install with cwd child process.
But this error has been come.
```
configure.ac:5: installing './compile'
configure.ac:5: installing './config.guess'
configure.ac:5: installing './config.sub'
configure.ac:9: installing './install-sh'
configure.ac:5: error: required file './ltmain.sh' not found
configure.ac:9: installing './missing'
src/Makefile.am: installing './depcomp'
autoreconf: automake failed with exit status: 1
```
My project's informations.
- langauge: Nodejs
- child process function : exec
- os: Ubuntu 20.04.2 LTS (GNU/Linux 5.8.0-53-generic x86_64)
succeed pc
- langauge: Nodejs
- child process function : exec
- os: Ubuntu 20.04.2 LTS (GNU/Linux 5.8.0-50-generic x86_64)