Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2007-06-17T08:40:29Zhttps://gitlab.xiph.org/xiph/ogg/-/issues/740libogg configure.in doubles up ldflags2007-06-17T08:40:29ZGitlab Botlibogg configure.in doubles up ldflagsan 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 MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/694Could not find or load the file "ELIB.LIB" for target "WINSCW UDE...2007-06-17T08:39:21ZsenthilashokCould 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
SenHi,
I am getting the error, when i tried to compile this example program.
Please help me.
Thanks
Senhttps://gitlab.xiph.org/xiph/ogg/-/issues/653[PATCH] incorrect use of LIBS and CFLAGS in vorbis.m4 and ogg.m42009-04-19T20:23:36ZJulien Cristau[PATCH] incorrect use of LIBS and CFLAGS in vorbis.m4 and ogg.m4Hi,
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 CristauMonty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/650compile error building oggplay from trunk svn2017-04-07T17:11:03ZGitlab Botcompile error building oggplay from trunk svnoggplay 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/646green screen2017-04-08T00:51:34ZGitlab Botgreen screenwhen 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 MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/645ogg problems2017-04-07T17:11:03ZGitlab Botogg problemswhen 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/634oggcodecs: Still can not play ogg files2020-11-06T03:56:13ZGitlab Botoggcodecs: Still can not play ogg filesI have dowloaded the oggcodecs_0.69.8924 but windows media player and any other player will not play ogg files. Before I ran the file I removed any other ogg files and I closed all of the open files. I am running Windows XP.I have dowloaded the oggcodecs_0.69.8924 but windows media player and any other player will not play ogg files. Before I ran the file I removed any other ogg files and I closed all of the open files. I am running Windows XP.Gitlab BotGitlab Bothttps://gitlab.xiph.org/xiph/ogg/-/issues/586[PATCH] ogg2-arc does not compile wiht mingw322009-04-19T21:13:43Zj[PATCH] ogg2-arc does not compile wiht mingw32ogg2-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 RileyArc Rileyhttps://gitlab.xiph.org/xiph/ogg/-/issues/564oggpack_writecopy_helper erroneously updates b->buffer2004-09-01T00:43:19ZTimothy B. Terriberryoggpack_writecopy_helper erroneously updates b->buffer```
At the end of the aligned block copy path in oggpack_writecopy_helper, the
current code increments b->buffer, which is supposed to be a pointer to the
start of an allocated block of memory, that can later be realloc'd by one of the
o...```
At the end of the aligned block copy path in oggpack_writecopy_helper, the
current code increments b->buffer, which is supposed to be a pointer to the
start of an allocated block of memory, that can later be realloc'd by one of the
oggpack*_write functions or free'd. Instead, endbyte is the member that should
be adjusted.
--- bitwise.c (revision 7651)
+++ bitwise.c (working copy)
@@ -172,7 +172,7 @@
memmove(b->ptr,source,bytes);
b->ptr+=bytes;
- b->buffer+=bytes;
+ b->endbyte+=bytes;
*b->ptr=0;
}
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/549sync-to-sync data loss2004-07-24T01:52:49ZArc Rileysync-to-sync data loss```
I believe there to be a bug in sync.c's buffer handling whereas it doesn't
appear to be incrementing the buffer size when pages that come from one
ogg_sync_state object are passed into another. In the tests I've run, using
Vorbis...```
I believe there to be a bug in sync.c's buffer handling whereas it doesn't
appear to be incrementing the buffer size when pages that come from one
ogg_sync_state object are passed into another. In the tests I've run, using
Vorbis files to test with, I've been getting between 30% to 40% of the page
data I put in.
The data comes out unmangled but "short" in length. ogginfo shows the output
to be a normal Vorbis file, only shorted than it should be and lacking EOS.
I have only seen this error by using py-ogg2 and have not attempted to
replicate this with a C program, however I looked trough py-ogg2's sync.c and
saw nothing that could cause a bug such as this. It's really just glue code
between Python and libogg2, and it seems to work fine for full encoding and
decoding.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/548sync-to-sync data loss2004-07-24T01:53:10ZArc Rileysync-to-sync data loss```
I believe there to be a bug in sync.c's buffer handling whereas it doesn't
appear to be incrementing the buffer size when pages that come from one
ogg_sync_state object are passed into another. In the tests I've run, using
Vorbis...```
I believe there to be a bug in sync.c's buffer handling whereas it doesn't
appear to be incrementing the buffer size when pages that come from one
ogg_sync_state object are passed into another. In the tests I've run, using
Vorbis files to test with, I've been getting between 30% to 40% of the page
data I put in.
The data comes out unmangled but "short" in length. ogginfo shows the output
to be a normal Vorbis file, only shorted than it should be and lacking EOS.
I have only seen this error by using py-ogg2 and have not attempted to
replicate this with a C program, however I looked trough py-ogg2's sync.c and
saw nothing that could cause a bug such as this. It's really just glue code
between Python and libogg2, and it seems to work fine for full encoding and
decoding.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/545start-time granulepos2010-10-27T13:35:26ZArc Rileystart-time granulepos```
libogg2 lacks ability to handle start-time granulepos, as is used by
discontinuous codecs. the library needs a way to be told that a stream is
discontinuous for ogg_stream_state to handle the proper packet<->page mapping
of these...```
libogg2 lacks ability to handle start-time granulepos, as is used by
discontinuous codecs. the library needs a way to be told that a stream is
discontinuous for ogg_stream_state to handle the proper packet<->page mapping
of these fields.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/544ogg_buffer_create missing from ogg2/ogg.h2010-10-27T13:35:06ZArc Rileyogg_buffer_create missing from ogg2/ogg.h```
ogg_buffer_create is needed to pass new buffers to the bitpacker.
ogg_buffer_state *ogg_buffer_create(void);
``````
ogg_buffer_create is needed to pass new buffers to the bitpacker.
ogg_buffer_state *ogg_buffer_create(void);
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/520Failure to compile under Cygwin 1.5.72010-10-27T13:34:31Zjari.aaltoFailure to compile under Cygwin 1.5.7```
The current library does not compile under latest W2k/Cygwin. See below.
mv -f .libs/bitwise.lo bitwise.lo
/bin/bash ../libtool --mode=link gcc -O20 -fsigned-char -o libogg.la -
rpath /usr/lib -no-undefined -version-info 5:0:5 f...```
The current library does not compile under latest W2k/Cygwin. See below.
mv -f .libs/bitwise.lo bitwise.lo
/bin/bash ../libtool --mode=link gcc -O20 -fsigned-char -o libogg.la -
rpath /usr/lib -no-undefined -version-info 5:0:5 framing.lo bitwise.lo
rm -fr .libs/libogg.la .libs/libogg.* .libs/libogg.*
generating symbol list for `libogg.la'
dlltool --export-all --exclude-symbols
DllMain@12,_cygwin_dll_entry@12,_cygwin_noncygwin_dll_entry@12,DllMainCRTStartup
@12,DllEntryPoint@12 --output-def .libs/cygogg-0.dll-def framing.lo bitwise.lo
sed -e "1,/EXPORTS/d" -e "s/ @ [0-9]*//" -e "s/ *;.*$//" < .libs/cygogg-0.dll-
def > .libs/libogg.exp
if test "x`sed 1q .libs/libogg.exp`" = xEXPORTS; then
cp .libs/libogg.exp .libs/cygogg-0.dll-def; else echo EXPORTS > .libs/cygogg-
0.dll-def; _lt_hint=1; cat .libs/libogg.exp | while read symbol; do set dummy
$symbol; case $# in 2) echo " $2 @ $_lt_hint ; " >> .libs/cygogg-0.dll-def;; 4)
echo " $2 $3 $4 ; " >> .libs/cygogg-0.dll-def; _lt_hint=`expr $_lt_hint - 1`;;
*) echo " $2 @ $_lt_hint $3 ; " >> .libs/cygogg-0.dll-def;; esac;
_lt_hint=`expr 1 + $_lt_hint`; done; fi
gcc -Wl,--base-file,.libs/cygogg-0.dll-base -Wl,-e,__cygwin_dll_entry@12 -
o .libs/cygogg-0.dll framing.lo bitwise.lo
/bin/../lib/gcc-lib/i686-pc-cygwin/3.3.1/../../../libcygwin.a(libcmain.o)
(.text+0x7c): undefined reference to `_WinMain@16'
collect2: ld returned 1 exit status
make[1]: *** [libogg.la] Error 1
make[1]: Leaving directory `/usr/src/build/try/libogg-1.1/.build/.build/src'
make: *** [all-recursive] Error 1
/bin/cygbuild.sh.CygbuildCommandMain: [FATAL] status is 2.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/503better multiplexing example image2017-04-08T00:51:34Zin7y118better multiplexing example image```
The current image gives the impression that the final pages of a stream have to
be directly after each other, like the start pages.
It would be better if there were a normal data page displayed in between.
``````
The current image gives the impression that the final pages of a stream have to
be directly after each other, like the start pages.
It would be better if there were a normal data page displayed in between.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/501ogg.m4:8: warning: underquoted definition of XIPH_PATH_OGG2004-01-26T10:32:20Zalexander.winstonogg.m4:8: warning: underquoted definition of XIPH_PATH_OGG```
Automake-1.8 complains that vorbis.m4 has an underquoted definition of
XIPH_PATH_OGG. According to
<http://mail.gnu.org/archive/html/libtool-patches/2002-10/msg00031.html>, these
are known to cause problems and possibly even severer ...```
Automake-1.8 complains that vorbis.m4 has an underquoted definition of
XIPH_PATH_OGG. According to
<http://mail.gnu.org/archive/html/libtool-patches/2002-10/msg00031.html>, these
are known to cause problems and possibly even severer errors in the future.
Therefore, I am attaching a patch that quotes XIPH_PATH_OGG.
(This bug is related to bug 500.)
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/498sizeof(long) on x86_64 is 8 bytes, things break2004-03-08T07:16:59ZGitlab Botsizeof(long) on x86_64 is 8 bytes, things break```
libogg is using long for nearly all bitwise operations and sometimes with 32bit
types without a cast. this brakes some functions which imply that bits outside
of 32 bit are cleared.
for example on x86_64 (amd64),
from cvs_nightly,
b...```
libogg is using long for nearly all bitwise operations and sometimes with 32bit
types without a cast. this brakes some functions which imply that bits outside
of 32 bit are cleared.
for example on x86_64 (amd64),
from cvs_nightly,
bitwise.c, function oggpackB_read :
unsigned long ret;
..
ret= b->ptr[0]<<(24+b->endbit);
if endbit is zero and the highest bit of ptr[0] is set, the value of ptr[0] is
shifted, converted to signed int, and sign extended to 64 bits before stored in
the unsigned variable ret.
this brakes programs using these libogg functions.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/489libogg2 threading doesn't work on FreeBSD2010-10-27T13:32:37ZArc Rileylibogg2 threading doesn't work on FreeBSD```
On FreeBSD there is no -lpthread, we use -pthread instead. libogg2 does not work with -pthread, which means threading needs to be disabled on BSD* platforms for it to compile.
``````
On FreeBSD there is no -lpthread, we use -pthread instead. libogg2 does not work with -pthread, which means threading needs to be disabled on BSD* platforms for it to compile.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/486libogg2's bitpackers cannot be init. due to missing structs2006-06-12T11:35:35ZArc Rileylibogg2's bitpackers cannot be init. due to missing structs```
In order to call oggpack_writeinit or oggpack_readinit you need to pass a oggpack_buffer, just
as you have to pass ogg_page and ogg_packet objects to other functions, however the
structure for oggpack_buffer has been removed from o...```
In order to call oggpack_writeinit or oggpack_readinit you need to pass a oggpack_buffer, just
as you have to pass ogg_page and ogg_packet objects to other functions, however the
structure for oggpack_buffer has been removed from ogg2/ogg.h (only in ogginternal.h).
This needs to be fixed before any further work can go into py-ogg2 or libwrit.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/485libogg2: direct access to change page header fields2010-10-27T13:31:16ZArc Rileylibogg2: direct access to change page header fields```
Alot of the uses I've found for libogg1 (py-ogg1) have been repairing Ogg streams, extracting
one logical bitstream from an Icecast archive, or other things which could take place entirely
within ogg_sync_state (to get ogg_page obj...```
Alot of the uses I've found for libogg1 (py-ogg1) have been repairing Ogg streams, extracting
one logical bitstream from an Icecast archive, or other things which could take place entirely
within ogg_sync_state (to get ogg_page objects), then editing the header fields of the pages to
change the CONT/BOS/EOS flags, granulepos, serialno, etc.
In one case, the Indymedia global radio stream at http://liveradio.indymedia.org/ is mixed on
the server using Python code that takes several different sources (live, playlist, etc) and mixes
them based on a schedule. This uses py-ogg1 to make the stream being sent to Icecast legal
and sequential serialno's, especially when the source streams get chopped off midway.
This is also useful for intentionally creating mangled test streams for testing codec software,
Icecast, etc.
With libogg2 moving to ogg_references instead of character buffers for the ogg_page header
and body fields, this is no longer possible. ogg_reference is not currently exposed, nor are
there functions for editing these values, so the only way to edit this data would be to send the
ogg_page objects into a second ogg_sync_state buffer then use ogg_sync_bufferout before
editing the fields, then into a third ogg_sync_state buffer to turn it back into an ogg_page.
Bug 484 ( http://bugs.xiph.org/show_bug.cgi?id=484 ), the declaired but not defined
ogg_page_getbuffer, may make this easier. But it would still involve re-importing the edited
data into another ogg_sync_state buffer.
It should be noted that, without the ability to edit the ogg_page header/body contents, having
ogg_page_checksum_set exposed serves no purpose.
```Monty MontgomeryMonty Montgomery