Ogg issueshttps://gitlab.xiph.org/xiph/ogg/-/issues2004-01-26T10:32:20Zhttps://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/1917ogg.m4 sets OGG_LIBS to incorrect path on some 64-bit distros2017-08-26T14:29:54ZAdam Spiersogg.m4 sets OGG_LIBS to incorrect path on some 64-bit distrosSome distros such as openSUSE use /usr/lib64 rather than /usr/lib, but ogg.m4 does not allow for this. I notice that whoever packaged ogg.m4 for openSUSE opted for hacking a patch into the spec file which is only applied on x86_64:
htt...Some distros such as openSUSE use /usr/lib64 rather than /usr/lib, but ogg.m4 does not allow for this. I notice that whoever packaged ogg.m4 for openSUSE opted for hacking a patch into the spec file which is only applied on x86_64:
https://build.opensuse.org/package/view_file?expand=1&file=libogg.spec&package=libogg&project=openSUSE%3AFactory
https://build.opensuse.org/package/view_file?expand=1&file=lib64.dif&package=libogg&project=openSUSE%3AFactory
Personally it's better if ogg.m4 itself is fixed, because then it works even when not building rpms. I'll attach a suggested patch ...
Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/104ogg.m4 refers to ogg-config2006-06-12T10:47:55ZGitlab Botogg.m4 refers to ogg-config```
Some leftovers in the ogg.m4 apparently, put me on a wild goosechase for a few
minutes :)
In ogg.m4, if configure fails to compile the test program, the error message
incorrectly mentions "ogg-config"
(Do I get extra credit for m...```
Some leftovers in the ogg.m4 apparently, put me on a wild goosechase for a few
minutes :)
In ogg.m4, if configure fails to compile the test program, the error message
incorrectly mentions "ogg-config"
(Do I get extra credit for most trivial 'bug'?)
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/2041ogg-index sets incorrect fisbone message header offset in the skeleton stream2020-11-06T04:05:16ZNick Burchogg-index sets incorrect fisbone message header offset in the skeleton streamAccording 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 datahttps://gitlab.xiph.org/xiph/ogg/-/issues/2043ogg-index produces multiple fisbones with the same name and role, where the i...2020-11-06T04:02:56ZNick Burchogg-index produces multiple fisbones with the same name and role, where the input has several video or audio streamsIf 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/2042ogg-index fails with an unhelpful error message if the file contains Speex or...2020-11-06T04:03:32ZNick Burchogg-index fails with an unhelpful error message if the file contains Speex or Opus streamsIf 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/1674OGG RFCs in libogg package don't meet Debian DFSG2017-08-26T14:29:54ZMonty MontgomeryOGG RFCs in libogg package don't meet Debian DFSGDebian strips the Ogg RFCs out of the Deb packages due to the RFCs not meeting DFSG.
relevant info:
http://wiki.debian.org/NonFreeIETFDocuments
Debian strips the Ogg RFCs out of the Deb packages due to the RFCs not meeting DFSG.
relevant info:
http://wiki.debian.org/NonFreeIETFDocuments
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/2295ogg double free issue2019-08-14T02:08:40Zniugxogg double free issuethere is an issue in ogg_sync_clear when set the second parameter of ogg_sync_buffer to 1.
test code:
modify line 161 of test/write_read.c of libvorbis-1.3.6 as following:
buffer = ogg_sync_buffer(&oy, 1);there is an issue in ogg_sync_clear when set the second parameter of ogg_sync_buffer to 1.
test code:
modify line 161 of test/write_read.c of libvorbis-1.3.6 as following:
buffer = ogg_sync_buffer(&oy, 1);https://gitlab.xiph.org/xiph/ogg/-/issues/1311Ogg Container Format Wastes Memory2017-08-26T14:29:55Zjoe_somebodyOgg Container Format Wastes MemoryCurrently 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 MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/1235No implementation due to poor documentation2017-08-26T14:29:55ZGitlab BotNo implementation due to poor documentationHi,
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 MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/152MSVC project settings for ogg_static_d.lib cause linker errors when used with...2006-06-12T11:39:41ZGitlab BotMSVC project settings for ogg_static_d.lib cause linker errors when used with "Debug Multithreaded" libs```
The project settings for ogg_static_d.lib default to "Debug Multithreaded
DLL". When I changed them to "Debug Multithreaded" to work with my
application, I still got linker errors that indicated something was linked with
the DLL ...```
The project settings for ogg_static_d.lib default to "Debug Multithreaded
DLL". When I changed them to "Debug Multithreaded" to work with my
application, I still got linker errors that indicated something was linked with
the DLL libs. Specific errors:
Linking...
MSVCRTD.lib(MSVCRTD.dll) : error LNK2005: _malloc already defined in libcmtd.lib
(dbgheap.obj)
MSVCRTD.lib(MSVCRTD.dll) : error LNK2005: _free already defined in libcmtd.lib
(dbgheap.obj)
MSVCRTD.lib(MSVCRTD.dll) : error LNK2005: _memmove already defined in
libcmtd.lib(memmove.obj)
MSVCRTD.lib(MSVCRTD.dll) : error LNK2005: _realloc already defined in
libcmtd.lib(dbgheap.obj)
LINK : warning LNK4098: defaultlib "MSVCRTD" conflicts with use of other libs;
use /NODEFAULTLIB:library
.\WinDebug/Game.exe : fatal error LNK1169: one or more multiply defined symbols
found
Error executing link.exe.
Cause: There are two files in the ogg_static project that are individually set
to use the "Debug Multithreaded DLL" libraries, and they do not change with the
project settings.
To fix: Open the ogg_static project with MSVC, go to Project->Settings, make
sure the active project ("Settings for:") is Win32Debug, select bitwise.c,
switch to the C++ tab, and hit the "Reset" button. This should not change the
file's settings, but it will set it to sync with the project settings, so that
changes to the entire Debug project will affect the individual file. Do the
same for framing.c.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/24missing 'ogg_stream_packetpeek' export in 'win32/ogg.def'2006-06-12T10:30:29Ztommissing '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 MoffittJack Moffitthttps://gitlab.xiph.org/xiph/ogg/-/issues/1623Minor spelling fixes in comments2017-08-26T14:29:54ZChris 'Xenon' HansonMinor spelling fixes in commentsWhile 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 MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/163minor problem in in_vorbis plugin and may be ...2002-02-20T07:16:24Zxakepminor problem in in_vorbis plugin and may be ...```
my own encoder of ogg (write on pascal) make test.ogg. Winamp (with in_vorbis
plugin) playing him is normal (without artefacts), but decoder from vorbis_sdk
tools make garbage-like WAV file. :(
I place my test.ogg in followed link...```
my own encoder of ogg (write on pascal) make test.ogg. Winamp (with in_vorbis
plugin) playing him is normal (without artefacts), but decoder from vorbis_sdk
tools make garbage-like WAV file. :(
I place my test.ogg in followed link, please download and test this situation.
Thanks.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/13Minor portability issues2006-06-12T11:22:27ZaegiskMinor 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 BoessenkoolSegher Boessenkoolhttps://gitlab.xiph.org/xiph/ogg/-/issues/125media type audio/x-ogg or application/x-ogg should be added to Apache mime.types2002-01-11T11:17:12Zyusufgmedia type audio/x-ogg or application/x-ogg should be added to Apache mime.types```
Hi, I recommend the designers of Ogg vorbis decide on a media/mime type for
Ogg/Vorbis and submit it for inclusion to the Apache group. I suggest either
1) audio/x-ogg
2) application/x-ogg
With the media-type available, one can th...```
Hi, I recommend the designers of Ogg vorbis decide on a media/mime type for
Ogg/Vorbis and submit it for inclusion to the Apache group. I suggest either
1) audio/x-ogg
2) application/x-ogg
With the media-type available, one can then utilise Apaches mod_expires module
to generate cache-friendly headers for ogg file which speeds up serving ogg
streams to people behind ISP proxy caches
http://httpd.apache.org/docs/mod/mod_expires.html
This mechanism is explained in depth at
http://www.mnot.net/cache_docs/
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/374libxmms-flac.so references undefined plt symbol2007-06-17T08:42:16Zrretzlaflibxmms-flac.so references undefined plt symbol```
During build of src/plugin_xmms following messages are produced, the
resulting libxmms-flac.so contains undefined reference to plt
FLAC__plugin_common__init_dither_context which is reported when xmms attempts to load the plugin.
Al...```
During build of src/plugin_xmms following messages are produced, the
resulting libxmms-flac.so contains undefined reference to plt
FLAC__plugin_common__init_dither_context which is reported when xmms attempts to load the plugin.
All up looks like libtool suckage
$ libtool --version
ltmain.sh (GNU libtool) 1.4a (1.641.2.255 2001/05/22 10:39:30)
../../libtool-disable-static --mode=link gcc -I../.. -I./include -I../../includ
e -O3 -DNDEBUG -fomit-frame-pointer -funroll-loops -finline-functions -Wall -W -
Winline -DFLaC__INLINE=__inline__ -g -O2 -I/usr/pkg/include -I/usr/pkg/include/
xmms -I/usr/pkg/include/gtk-1.2 -I/usr/pkg/include/glib/glib-1.2 -I/usr/pkg/lib/
glib/include -I/usr/X11R6/include -o libxmms-flac.la -rpath /usr/pkg/lib/xmms
/Input -module -avoid-version charset.lo configure.lo plugin.lo wrap_id3.lo fil
einfo.lo ../../src/plugin_common/libplugin_common.a ../../src/share/grabbag/lib
grabbag.a ../../src/share/gain_analysis/libgain_analysis.a ../../src/share/utf
8/libutf8.a ../../src/libFLAC/libFLAC.la -L../../src/libFLAC/.libs -L/usr/pkg
/lib -L/usr/pkg/lib -Wl,-R/usr/pkg/lib -Wl,-R/usr/X11R6/lib -L/usr/X11R6/lib -L/
usr/X11R6/lib -lgtk -lgdk -lgmodule -lglib -lintl -lXi -lXext -lX11 -lm -lxmms
mkdir .libs
*** Warning: This library needs some functionality provided by ../../src/plugin_common/libplugin_common.a.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have.
*** Warning: This library needs some functionality provided by ../../src/share/grabbag/libgrabbag.a.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have.
*** Warning: This library needs some functionality provided by ../../src/share/gain_analysis/libgain_analysis.a.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have.
*** Warning: This library needs some functionality provided by ../../src/share/utf8/libutf8.a.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/2290liboggplay mishandles live ogg streams in Firefox2020-11-06T04:06:07ZMilesliboggplay 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 MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/484libogg2: ogg_page_getbuffer declaired but not defined2010-10-27T13:30:10ZArc Rileylibogg2: ogg_page_getbuffer declaired but not defined```
ogg_page_getbuffer() appears in ogg2/ogg.h but is not defined anywhere in the libogg2
sources.
``````
ogg_page_getbuffer() appears in ogg2/ogg.h but is not defined anywhere in the libogg2
sources.
```Monty MontgomeryMonty Montgomery